Разработка мобильных приложений на платформе 1С:Предприятие сопряжена с уникальными сложностями, особенно когда речь идет о тестировании и эксплуатации на слабых Android-устройствах. В отличие от публикации в Google Play или AppGallery, где разработчик получает готовые отчеты о сбоях, при прямом распространении (через APK) отслеживание причин "вылетов" становится нетривиальной задачей. Проанализируем ситуацию, когда приложение внезапно закрывается у пользователя "в поле", и разберем методы получения технической информации для исправления ошибок.
Самый надежный способ узнать, что произошло в момент падения — это анализ системного журнала Android. Разберем этот метод подробно. Каждое событие в операционной системе, от нажатия кнопки до критической ошибки ядра, записывается в буферизированный журнал. Для доступа к нему нам понадобится инструмент ADB (Android Debug Bridge), входящий в состав Android SDK.
Рассмотрим последовательность действий для получения логов:
Проанализируем фильтрацию логов. В системном журнале за минуту могут генерироваться тысячи строк, поэтому крайне важно фильтровать данные по идентификатору приложения (Package Name). Выясним его: обычно для мобильной платформы 1С это com.e1c.mobile, но если вы используете сборщик мобильных приложений, имя пакета будет уникальным (например, com.mycompany.myapp).
Для получения бесконечного потока логов в режиме реального времени используем команду:
adb logcat --pid=$(adb shell pidof -s com.e1c.mobile)
Если приложение уже упало, и мы хотим выгрузить историю событий за последнее время в текстовый файл, выполним следующую команду:
adb logcat -d > crash_log.txt
В полученном файле следует искать ключевые слова: Fatal, Exception, Error, а также специфические теги, такие как 1C или v8. Это позволит увидеть стек вызовов операционной системы в момент аварийного завершения процесса.
Рассмотрим более продвинутый вариант, который подходит для "боевой" эксплуатации, когда у разработчика нет физического доступа к устройству. Посмотрим на архитектуру решения: внутри конфигурации создается механизм перехвата ошибок и отправки их на центральный сервер (Mothership).
Разберем, как реализовать программную фиксацию исключений. В критически важных участках кода, таких как открытие тяжелых форм или обработка больших массивов данных, необходимо использовать конструкцию Попытка...Исключение. Однако обычного вывода сообщения пользователю недостаточно. Нам нужно собрать контекст ошибки.
Пример функции для фиксации состояния устройства:
Процедура ЗафиксироватьОшибку(ИнформацияОбОшибке) Экспорт
Статистика = Новый Структура;
Статистика.Вставить("Дата", ТекущаяДата());
Статистика.Вставить("ОписаниеОшибки", ПодробноеОписаниеОшибки(ИнформацияОбОшибке));
// Попробуем собрать данные о памяти, если платформа позволяет
ИнформацияОСистеме = Новый СистемнаяИнформация;
Статистика.Вставить("ВерсияОС", ИнформацияОСистеме.ВерсияОС);
Статистика.Вставить("Платформа", ИнформацияОСистеме.ТипПлатформы);
// Сохраняем локально, если нет связи
ЗаписатьЛогВФайл(Статистика);
// Пытаемся отправить на сервер
ОтправитьСтатистикуНаСервер(Статистика);
КонецПроцедуры
Выясним причину, по которой такой метод может не сработать. Если происходит "жесткий" краш самой мобильной платформы (например, Segmentation Fault или Out of Memory на уровне ядра), код 1С просто перестает исполняться, и блок Исключение не сработает. В этом случае данные можно будет отправить только при следующем успешном запуске приложения, проанализировав наличие локальных логов или используя средства технологического журнала.
Проанализируем одну из самых частых причин падения 1С на слабых Android-девайсах — ошибку "Недостаточно памяти для загрузки картинки". На устройствах с объемом оперативной памяти 2 ГБ и менее операционная система крайне агрессивно завершает процессы, потребляющие много ресурсов.
Почему это происходит в 1С? Рассмотрим механизм работы с графикой. Даже если вы используете векторные иконки в формате SVG, мобильная платформа для отображения их на экране часто производит растеризацию (перевод в растровый формат). Этот процесс требует выделения непрерывного блока памяти в куче (Heap Size). Если в приложении одновременно открыто много форм с динамическими списками и иконками, память быстро заканчивается.
Для борьбы с этой проблемой рекомендуется:
Закрыть() для форм, которые больше не нужны пользователю.УдалитьФайлы(КаталогВременныхФайлов()).Мало кто знает, что мобильная платформа 1С поддерживает упрощенную версию Технологического журнала. Разберем, как его задействовать. Для этого в папку с установленным приложением на Android-устройстве необходимо поместить файл logcfg.xml. Это позволяет фиксировать события на уровне ядра платформы, даже если само приложение "схлопывается" без системных уведомлений.
Пример минимального файла конфигурации для сбора ошибок:
<config xmlns="http://v8.1c.ru/7.4/protocols/logcfg">
<log location="/sdcard/1C/logs" history="24">
<event>
<eq property="Name" value="EXCP"/>
</event>
<property name="All"/>
</log>
</config>
Важный момент: для работы этой схемы приложению должны быть выданы разрешения на запись во внешнее хранилище. После падения вы сможете забрать файлы логов из указанной папки и проанализировать их на компьютере. В этих логах будет содержаться детальная информация о том, какой именно внутренний процесс 1С вызвал критическую ошибку.
Диагностика крашей на "самописных" мобильных приложениях требует комплексного подхода. Рассмотрим краткий чек-лист для разработчика:
adb logcat с фильтрацией по package.Попытка...Исключение с отправкой через HTTP-сервис.logcfg.xml для сбора технологического журнала.Помните, что мобильная платформа 1С является ресурсоемкой средой, и на бюджетных смартфонах (особенно версиях Android Go) борьба за каждый мегабайт оперативной памяти — это залог стабильной работы вашего приложения.