При разработке мобильных решений на платформе 1С:Предприятие 8.3 разработчики часто сталкиваются с проблемой: мобильный клиент, настроенный для работы в автономном режиме, запускается крайне медленно. В некоторых случаях время ожидания на современных ТСД (терминалах сбора данных) может достигать 3–5 минут даже на пустых базах. Рассмотрим подробнее, почему это происходит, как продиагностировать проблему и какие шаги предпринять для оптимизации системы.
Для начала проанализируем, что именно происходит в момент запуска мобильного клиента с поддержкой автономности. В отличие от обычного мобильного клиента, который работает напрямую с сервером «в прямом эфире», автономный режим подразумевает наличие локальной базы данных на мобильном устройстве (обычно это SQLite). При первом запуске или при изменении состава метаданных мобильная платформа выполняет колоссальный объем работы.
Во-первых, происходит инициализация структуры таблиц. Даже если в конфигурации всего два справочника, 1С создает системные таблицы, индексы и служебные объекты, необходимые для функционирования мобильной платформы. Во-вторых, выполняется регистрация мобильного устройства в основной базе как «Автономного узла» в соответствующем плане обмена. Выясним причину задержек: если в состав автономной конфигурации включено много объектов, платформа тратит время на сверку версий метаданных и подготовку первичного пакета данных для синхронизации.
Одной из главных причин долгого «висения» приложения на заставке является механизм планов обмена. Рассмотрим ситуацию: в основной базе создан план обмена, который указан в свойстве «План обмена автономной работы». При первом подключении клиента сервер создает новый узел в этом плане. Если для объектов, входящих в этот план, установлено свойство Авторегистрация — Разрешить, сервер пытается зарегистрировать изменения для всех существующих записей в базе данных для этого нового узла.
Даже если данных мало, сам процесс обращения к таблицам регистрации в файловой базе (как в нашем примере) может вызывать блокировки и замедление ответа. Проанализируем рекомендации: крайне важно минимизировать количество объектов, включенных в автономную конфигурацию. Если объект не нужен пользователю в режиме оффлайн, его не должно быть в составе автономных метаданных.
Если мобильный клиент «замирает», нам необходимо понять, чем занят процессор устройства в этот момент. Поскольку большинство ТСД (например, Urovo i6200s) работают на ОС Android, мы можем использовать инструмент Android Debug Bridge (adb). Подключим устройство к компьютеру по USB и выполним команду в терминале:
adb logcat
В открывшемся потоке системных сообщений следует искать теги, помеченные как V8 или 1C. Мы увидим сообщения о выделении памяти, об ошибках доступа к файловой системе или о длительных операциях записи в базу SQLite. Если лог пестрит сообщениями о нехватке памяти или ошибках ввода-вывода (I/O), проблема может быть в производительности самого ТСД или его накопителя.
Мало кто знает, что для мобильной платформы также можно настроить подобие технологического журнала. Это позволит нам детально увидеть, на каком именно методе или запросе к серверу «висит» приложение. Для этого необходимо создать файл logcfg.xml и поместить его в каталог установленного приложения на мобильном устройстве (для этого могут потребоваться права разработчика или доступ к папке данных приложения).
Пример структуры файла logcfg.xml для мобильного клиента:
<config xmlns="http://v8.1c.ru/7.4/get/logcfg">
<log location="/sdcard/1c_logs" history="24">
<event>
<eq property="Name" value="EXCP"/>
</event>
<event>
<eq property="Name" value="CALL"/>
</event>
<property name="All"/>
</log>
</config>
Проанализировав полученные логи, мы сможем точно определить, вызвана ли задержка сетевым ожиданием ответа от Apache или же это внутренние вычисления мобильной платформы по сборке метаданных.
Посмотрим на ситуацию со стороны сервера. Мобильный клиент общается с базой через веб-сервер. Если Apache настроен некорректно, каждый запрос на получение метаданных может занимать секунды из-за переустановки соединений. Разберем основные параметры, которые стоит проверить в конфигурационном файле httpd.conf:
KeepAlive On включен. Это позволит мобильному клиенту отправлять несколько запросов в рамках одного TCP-соединения, что критично при загрузке множества мелких файлов метаданных.KeepAliveTimeout (например, 15–30 секунд), чтобы соединение не разрывалось преждевременно.Подводя итог, выделим основные шаги, которые помогут сократить время запуска мобильного клиента в автономном режиме:
Проанализируем состав метаданных. Нужно оставить только те справочники, документы и регистры, которые действительно необходимы для работы без связи. Каждый лишний объект увеличивает размер локальной базы и время её инициализации.
В плане обмена, который используется для автономной работы, рекомендуется установить Авторегистрация — Запретить для большинства объектов. Вместо этого используем программную регистрацию только необходимых данных. Рассмотрим пример кода для ручной регистрации изменений при необходимости:
Процедура ЗарегистрироватьДанныеДляАвтономногоУзла(Узел, Ссылка)
ПланыОбмена.ЗарегистрироватьИзменения(Узел, Ссылка);
КонецПроцедуры
Это позволит избежать массовой регистрации данных при первом подключении и ускорит создание «Автономного узла».
Выясним, не включена ли отладка в настройках мобильного приложения на ТСД. Активная отладка по протоколу HTTP может замедлять запуск приложения в десятки раз, так как каждый шаг инициализации будет пытаться синхронизироваться с конфигуратором на компьютере разработчика.
Если возможно, настройте кэширование статических файлов на стороне веб-сервера. Это поможет мобильному клиенту быстрее проверять актуальность локального кэша и не скачивать заново неизмененные компоненты платформы.
Соблюдение этих рекомендаций и внимательный анализ логов позволят сократить время запуска мобильного клиента с нескольких минут до приемлемых 10–15 секунд, обеспечив комфортную работу пользователей с ТСД в любых условиях связи.