При разработке мобильных приложений на платформе 1С программисты часто сталкиваются с неприятной ситуацией: приложение, которое активно обменивается данными с сервером по HTTP, через некоторое время перестает запускаться. При попытке входа пользователь получает критическую ошибку «произошло неожиданное прерывание проверки или исправления файла бд», а стандартное тестирование и исправление (ТиИ) не приносит результатов. Особенно обидно то, что в режиме обычного ПК-клиента та же конфигурация может работать неделями без сбоев.
В этой статье мы подробно разберем, почему «умирает» файл 1CD на мобильных устройствах, как продиагностировать проблему и, самое главное, как изменить архитектуру обмена, чтобы сделать приложение максимально отказоустойчивым. Проанализируем ситуацию комплексно: от особенностей работы файловой системы до нюансов мобильных операционных систем.
Для начала давайте разберем механизмы, которые приводят к порче структуры 1CD. В отличие от серверных решений (MS SQL, PostgreSQL), мобильная платформа 1С использует упрощенную файловую СУБД. Рассмотрим основные факторы риска:
Low Memory Killer. Даже если вы отключили все настройки энергосбережения, система все равно может «прибить» процесс, если он потребляет много ресурсов в фоновом режиме или при сворачивании. Критическая точка — момент записи ответа от HTTP-сервиса.Поскольку в мобильной платформе отсутствует привычный нам Технологический журнал, диагностика превращается в детектив. Рассмотрим инструменты, которые помогут нам «отловить» момент гибели файла.
Во-первых, попробуем запустить мобильное приложение в среде Windows в режиме мобильной платформы. Это позволит исключить специфические баги конкретных прошивок смартфонов. Используйте специальную сборку мобильной платформы под Windows (appx-пакеты). Если ошибка воспроизводится и там, значит, проблема в логике записи или объеме данных.
Во-вторых, проанализируем системные логи Android через ADB Logcat. Для этого подключите устройство к компьютеру, активируйте режим разработчика и выполните команду в консоли. Это единственный способ увидеть системные сообщения: было ли приложение убито из-за Out of Memory (OOM) или произошла ошибка Segmentation fault внутри библиотек 1С в момент обращения к файлу 1CD.
Самый надежный способ защитить 1CD — минимизировать время, в течение которого база открыта на запись. Разберем стратегию «буферного обмена».
Вместо того чтобы записывать данные непосредственно в справочники или регистры сразу после получения HTTP-ответа, мы будем использовать внешние файлы. Проанализируем алгоритм:
HTTP.JSON) во внутреннюю память устройства.1CD.JSON и переносим их содержимое в базу 1С.Рассмотрим пример кода для сохранения входящих данных в файл, чтобы не нагружать базу в фоновом режиме:
// Пример сохранения данных обмена во внешний файл
ПутьКФайлу = КаталогДокументов() + "sync_data_" + Строка(Формат(ТекущаяДата(), "ДФ=yyyyMMddHHmmss")) + ".json";
ТекстЗаписи = Новый ЗаписьТекста(ПутьКФайлу, КодировкаТекста.UTF8);
ТекстЗаписи.ЗаписатьСтроку(ДанныеОтСервераJSON);
ТекстЗаписи.Закрыть();
После того как данные «приземлились» в файловую систему, риск их потери минимален. Даже если приложение закроется, файл 1CD не пострадает, так как транзакция записи в него еще не начиналась.
Чтобы снизить риск повреждения базы, нужно понимать, в каком состоянии находится приложение. Платформа предоставляет нам инструменты для проверки активности. Разберем, как использовать методы СостояниеФоновогоЗадания и проверку нахождения в фоновом режиме.
Проанализируем ситуацию: если приложение свернуто, операционная система может прервать любой процесс в любой момент. Поэтому критические операции (например, тяжелое тестирование и исправление или массовое обновление данных) лучше выполнять только тогда, когда приложение активно. Для этого можно использовать обработчики событий ПриАктивизацииПриложения и ПриПриостановкеПриложения в модуле управляемого приложения.
Если отказаться от прямой записи в базу невозможно, необходимо максимально сократить размер транзакций. Посмотрим на типичную ошибку: попытка записать 1000 объектов в одной транзакции. На мобильном устройстве это «смертный приговор» для 1CD при любом входящем звонке или переключении приложения.
Рассмотрим правильный подход: разбиение данных на порции. Выполняйте ЗафиксироватьТранзакцию() как можно чаще. Например, после каждых 5–10 измененных объектов.
// Пример порционной записи данных
НачатьТранзакцию();
Счетчик = 0;
Для Каждого ОбъектДанных Из МассивОбъектов Цикл
ОбъектДанных.Записать();
Счетчик = Счетчик + 1;
Если Счетчик % 10 = 0 Тогда
ЗафиксироватьТранзакцию();
НачатьТранзакцию();
КонецЕсли;
КонецЦикла;
ЗафиксироватьТранзакцию();
Иногда корень проблемы кроется в багах самой платформы. Выясним, какие версии наиболее стабильны. Опытным путем установлено, что в ветках 8.3.18 и 8.3.19 наблюдались утечки дескрипторов файлов при работе с HTTP-соединениями. Это приводило к тому, что файл базы оставался заблокированным даже после завершения операции, что повышало риск его порчи при закрытии приложения ОС.
Рекомендуется обновить мобильную платформу до актуальных релизов (например, ветка 8.3.21 и выше), где многие ошибки работы с файловой системой были исправлены. Также убедитесь, что приложение установлено во внутреннюю память устройства, а не на SD-карту. Скорость записи (I/O) на карту памяти значительно ниже, что увеличивает «окно уязвимости» при записи транзакции.
Подводя итог нашему разбору, выделим ключевые правила выживания 1CD в мобильной среде:
JSON или XML файлы.HTTP-соединениями.Применяя эти архитектурные приемы, мы создадим надежное решение, которое не потребует от оператора постоянного проведения ТиИ и переустановки приложения.