Почему вылетает мобильная платформа 1С на Android с ошибкой «В приложении произошла ошибка» и как это исправить?

← На главную

При разработке и внедрении мобильных решений на платформе 1С разработчики нередко сталкиваются с ситуацией, когда приложение на мобильном устройстве или терминале сбора данных (ТСД) внезапно закрывается с системным сообщением операционной системы: «В приложении произошла ошибка». Сбой может происходить как при выполнении ресурсоемких операций, так и при открытии простых списков, форм ввода или даже на практически пустой конфигурации. Разберем по шагам ключевые причины такого поведения мобильной платформы и выясним, как диагностировать и устранить эти ошибки.

1. Нехватка оперативной памяти и особенности ОС Android

Мобильная платформа 1С функционирует на мобильном устройстве как полноценный программный комплекс, объединяющий клиентскую часть, серверную логику и встроенную СУБД для работы с локальной базой данных. На бюджетных смартфонах и ТСД с объемом оперативной памяти 1 ГБ или менее операционная система жестко ограничивает лимит памяти (Heap Size) для одного процесса.

При резком увеличении потребления памяти служба Low Memory Killer в Android принудительно завершает процесс приложения без возможности перехватить исключение через конструкцию Попытка ... Исключение в коде 1С. Основными факторами переполнения памяти являются:

Отображение длинных списков: прокрутка объемных таблиц справочников, документов или регистров с большим числом колонок и строк приводит к быстрому расходу доступной ОЗУ под графические элементы.
Частая смена ориентации экрана: поворот устройства вызывает повторную инициализацию формы и отрисовку интерфейса, что временно удваивает объем используемой памяти.
Накопление временных файлов: сохранение файлов обмена, картинок или логов во временном каталоге устройства без последующего удаления.

Для минимизации риска выгрузки процесса системой выполним следующие оптимизации при сборке мобильного приложения:

В файле AndroidManifest.xml через настройки сборщика мобильных приложений включим параметр android:largeHeap="true", что позволит запросить у операционной системы максимальный лимит памяти для Java-процесса.
Зафиксируем ориентацию экрана параметром android:screenOrientation="portrait", если специфика работы пользователей не требует альбомного режима.

2. Ошибки в коде при работе с сетевыми службами

Проанализируем частую причину сбоев, связанную с взаимодействием с сетевыми протоколами. Попытка выполнить прямое обращение к внешнему ресурсу при отсутствии подключения к сети Интернет (например, когда отключен Wi-Fi или мобильная передача данных) на мобильной платформе может приводить к аварийному закрытию приложения.

Посмотрим на пример: вызов метода ИнтернетПочта.Подключиться() или отправка HTTP-запроса без предварительной проверки статуса подключения гарантированно вызывает ошибку. Перед выполнением любых сетевых операций необходимо проверять доступность подключения:


Если СредстваТелефонии.Поддерживается() И НЕ СредстваТелефонии.ПолучитьИнформациюОСети().Подключено Тогда
    Сообщить("Отсутствует подключение к сети. Операция отменена.");
    Возврат;
КонецЕсли;

Попытка
    // Выполняем сетевое взаимодействие
    ПочтовыйПрофиль = Новый ИнтернетПочтовыйПрофиль;
    ПочтовыйПрофиль.АдресСервераPOP3 = "pop.example.com";
    
    Почта = Новый ИнтернетПочта;
    Почта.Подключиться(ПочтовыйПрофиль);
Исключение
    Сообщить("Ошибка при подключении к почтовому серверу: " + ОписаниеОшибки());
КонецПопытки;

3. Проблемы с конкретными элементами интерфейса и модальностью форм

Практический опыт разработки на различных версиях мобильной платформы (начиная с 8.3.9 и выше) показывает, что нестабильность может быть связана с отображением определенных интерфейсных элементов и режимами открытия форм:

Элементы управления: в некоторых релизах платформы (например, 8.3.11.52) наличие на форме таких элементов, как Поле полосы регулирования, приводит к нативному сбою графической подсистемы. Если форма вылетает сразу при открытии, проверим состав ее реквизитов и временно скроем нестандартные элементы управления.
Немодальные вспомогательные формы: открытие небольших немодальных окон для ввода значений поверх динамических списков может вызывать конфликт отрисовки на устаревших версиях Android. Замена вызова немодальной формы на блокирующий ввод (или использование модального режима открытия) позволяет стабилизировать работу окна.

4. Интенсивная обработка данных при сканировании штрихкодов на ТСД

При использовании мобильной платформы на терминалах сбора данных (например, моделей Urovo, Motorola Symbol, CipherLab) частые падения происходят при интенсивном последовательном сканировании нескольких десятков позиций подряд.

Если после каждого сканирования запускается тяжелая процедура валидации или выполняется непрерывная запись в базу данных с частым автосохранением, файловая СУБД мобильного приложения блокирует интерфейсный поток, что приводит к зависанию и системному сбою. Разберем рекомендации по организации работы с торговым оборудованием:

Буферизация ввода: накапливать отсканированные штрихкоды в оперативной коллекции (например, в объекте Массив) и выполнять их пакетную обработку или запись в базу порциями, а не на каждое считывание.
Использование широковещательных сообщений (Broadcast Receiver): вместо эмуляции клавиатурного ввода на ТСД использовать специализированные мобильные внешние компоненты, перехватывающие события сканирования через системные Intent-сообщения Android.

5. Сбор логов и диагностика причин падения

Если локализовать причину падения из кода 1С не удается, необходимо получить системный журнал операционной системы с помощью утилиты ADB (Android Debug Bridge). Выполним следующие действия:

Включим на мобильном устройстве режим Отладка по USB в меню разработчика.
Подключим устройство к компьютеру и запустим командную строку.
Выполним команду для фильтрации критических ошибок: adb logcat -v time *:E > crash_log.txt
Воспроизведем ошибку на устройстве. В созданном текстовом файле найдем строки с маркерами Fatal signal, SIGSEGV или OutOfMemoryError. Это позволит точно определить, был ли сбой вызван нехваткой памяти, сбоем видеодрайвера устройства или ошибкой в библиотеках самой платформы.
Для фиксации ошибок на уровне 1С настроим технологический журнал мобильной платформы, поместив конфигурационный файл logcfg.xml с событиями EXCP и CRASH в рабочий каталог приложения на устройстве.

6. Подбор стабильной версии мобильной платформы

На разных версиях ОС Android (от 4.2 до актуальных) и сторонних оболочках производителей поведение релизов мобильной платформы может существенно различаться. Если проект разворачивается на парке одинаковых бюджетных устройств, рекомендуется провести сравнительное тестирование смежных релизов платформы (например, линеек 8.3.10, 8.3.11 или более новых) для выбора версии с наименьшим количеством системных ошибок в условиях конкретного оборудования.