Разработка для мобильных платформ на базе 1С существенно отличается от создания решений для настольных ПК. Основные сложности часто возникают не в написании бизнес-логики, а в обеспечении стабильности приложения при активном обмене данными с центральной базой. В этой статье мы подробно разберем, почему мобильное приложение может внезапно закрываться, как избежать ошибки «база разрушена» и какие методы обмена данными наиболее эффективны в условиях мобильной ОС Android.
Одной из самых неприятных ситуаций является «гуляющая» ошибка: приложение вылетает рандомно, а отладчик не фиксирует проблемное место. Разберем ситуацию, когда во время фоновой выгрузки заказов происходит еще один запрос к серверу (например, получение бонусных баллов), и приложение закрывается с сообщением о приостановке.
Первая вероятная причина — конкуренция потоков и блокировки. В мобильной платформе 1С фоновые задания выполняются в отдельных потоках, но в рамках одного процесса. Если основной поток и фоновое задание одновременно пытаются обратиться к сетевому ресурсу или локальной базе данных через общие объекты, это может привести к критическому сбою. На платформе Windows такие ситуации обрабатываются мягче, но Android при возникновении подобных конфликтов на уровне ядра часто просто убивает процесс приложения.
Для диагностики таких случаев проанализируем совет из практики: необходимо внедрить детальное логирование. Так как отладчик может не успеть сработать, мы должны записывать состояние в текстовый файл до и после выполнения подозрительных операций.
// Пример упрощенного логирования в файл на мобильном устройстве
ТекстЛога = Новый ЗаписьТекста(ПутьКФайлуЛога, КодировкаТекста.UTF8, , Истина);
ТекстЛога.ЗаписатьСтроку(ТекущаяДата() + ": Начало вызова postChanges");
ТекстЛога.Закрыть();
Результ = cоединение.postChanges(id, входныеДанные);
ТекстЛога = Новый ЗаписьТекста(ПутьКФайлуЛога, КодировкаТекста.UTF8, , Истина);
ТекстЛога.ЗаписатьСтроку(ТекущаяДата() + ": Успешное завершение postChanges");
ТекстЛога.Закрыть();
Если в файле есть запись «Начало», но нет записи «Успешное завершение», мы точно локализуем строку кода, вызывающую вылет.
Рассмотрим способ обмена, который часто выбирают разработчики: прямое использование WSПрокси и объектов XDTO. Хотя этот метод кажется удобным благодаря типизации, он таит в себе скрытые угрозы для мобильной платформы.
Накладные расходы памяти: Использование ФабрикаXDTO для создания больших структур данных (например, справочника номенклатуры или списка заказов) потребляет значительный объем оперативной памяти. В ОС Android работает механизм Low Memory Killer. Если пиковое потребление памяти приложением 1С превышает лимит, система мгновенно завершает его работу. Именно поэтому вылеты кажутся «рандомными» — они зависят от текущей загрузки памяти устройства другими приложениями.
Посмотрим на типичный код создания XDTO, который может вызвать перегрузку:
// Данный подход создает множество объектов в памяти
входныеДанные = cоединение.ФабрикаXDTO.Создать(cоединение.ФабрикаXDTO.Тип(URL, "inData"));
Для каждого строкаРегистрации Из таблицаРегистраций Цикл
партнер = cоединение.ФабрикаXDTO.Создать(тип_partnersItem);
партнер.id = строкаРегистрации.Объект.Идентификатор;
// ... заполнение полей
входныеДанные.partners.items.Добавить(партнер);
КонецЦикла;
Для повышения стабильности рекомендуется рассмотреть переход на использование HTTP-сервисов и формата JSON. Формат JSON гораздо легче, а методы ПрочитатьJSON и ЗаписатьJSON работают быстрее и экономнее с точки зрения памяти, чем фабрика XDTO. К тому же, SOAP-протокол (Web-сервисы) требует загрузки тяжелого описания WSDL, что на мобильном интернете может приводить к таймаутам и зависаниям.
Ошибка разрушения локальной базы (SQLite) в мобильном приложении 1С обычно связана с некорректным завершением транзакций записи. Это происходит в следующих случаях:
НачатьТранзакцию(), файлы базы могут остаться в промежуточном состоянии.Чтобы минимизировать риск, проанализируем следующие рекомендации:
ТестированиеИсправление программно, если при запуске обнаружены проблемы, но лучше предотвращать их через стабильный код.Неопределено, чтобы помочь сборщику мусора освободить память.Выясним, какой способ обмена считается наиболее надежным для «продвинутых» разработчиков. Вместо прямой передачи объектов через WSПрокси, многие переходят к схеме с использованием ХранилищаЗначений и сжатия.
Рассмотрим пошагово этот алгоритм:
ХранилищеЗначения с максимальным сжатием.Этот метод позволяет передавать огромные объемы данных (десятки тысяч элементов номенклатуры) без вылетов, так как основная нагрузка ложится на эффективные алгоритмы сжатия платформы, а не на создание тысяч мелких XDTO объектов.
Для создания профессионального мобильного продукта на платформе 1С недостаточно просто написать код. Необходимо учитывать специфику мобильных ОС:
HTTPСоединение и WSПрокси всегда устанавливайте явные таймауты (не более 20-30 секунд), чтобы не «подвешивать» интерфейс.Следуя этим правилам, мы сможем создать стабильное приложение, которое не потребует еженедельного «лечения» базы данных и не будет разочаровывать пользователей внезапными закрытиями.