Как отлаживать мобильное приложение на 1С

Отладка мобильного приложения 1С начинается в конфигураторе: включаете режим отладки, публикуете или собираете приложение с её поддержкой и подключаете устройство к отладчику по сети. Дальше ошибки ищут тремя путями — пошаговой отладкой кода, выводом значений через Сообщить() и чтением системных логов самого устройства.

Мобильная платформа работает не как настольный клиент: нет окна конфигуратора на телефоне, базы данных под рукой и привычного журнала на экране. Поэтому часть диагностики уходит на сторону Android или iOS, а инструментом становятся adb и Xcode.

Ниже — как настроить подключение отладчика, какие приёмы работают, когда до кода не достучаться, как разбирать аварийные завершения и проверять обмен с сервером.

С чего начать: включаем режим отладки

Отладчик 1С соединяется с приложением по сети, поэтому сначала нужно разрешить отладку на обеих сторонах.

В конфигураторе откройте Сервис → Параметры, закладку Отладка. По умолчанию платформа 8.3 использует протокол HTTP — проверьте адрес и порт сервера отладки. Этот же адрес должно «знать» приложение на устройстве.

Дальше зависит от того, что именно вы отлаживаете:

• 📱 Мобильный клиент (тонкий клиент, работает с центральной базой). Отладку включают при публикации клиента на веб-сервере — в параметрах публикации есть соответствующий флажок.
• 📦 Автономное мобильное приложение (собственная база на устройстве). Приложение собирают в сборщике мобильных приложений с включённой поддержкой отладки, иначе отладчик его не увидит.

Два технических условия, без которых подключение не состоится:

1. Устройство и компьютер разработчика — в одной сети, и устройство видит компьютер по указанному адресу.
2. Порт отладки не закрыт брандмауэром или антивирусом на компьютере.

Простые способы поймать ошибку без подключения

Полноценная пошаговая отладка нужна не всегда. Часто быстрее вставить вывод значения и посмотреть, что происходит.

Вывод через Сообщить(). Самый быстрый приём: в нужных точках кода выводите значения переменных. На мобильном они попадают в окно служебных сообщений приложения. Для чисел и дат используйте Формат(), чтобы не склеить значение неправильно.

Запись в журнал регистрации. Метод ЗаписьЖурналаРегистрации() сохраняет событие с комментарием. В автономном приложении журнал хранится локально на устройстве, и его потом можно выгрузить и разобрать. Это удобнее Сообщить(), когда ошибка плавающая и ловить её у экрана некогда.

Трассировка этапов. Расставьте по ходу сложной операции короткие отметки с меткой этапа и ключевыми значениями. Когда что-то падает, по последней дошедшей отметке сразу видно, где оборвалось выполнение.

Замер производительности. Если приложение не падает, а тормозит, подключённый отладчик умеет замерять время выполнения по строкам кода. Запустите замер, воспроизведите медленный сценарий, остановите — и увидите, какие строки съедают время. Чаще всего виноват запрос в цикле или выборка, которую можно получить одним обращением к базе.

Сравните, какой способ когда применять:

Удалённая отладка: подключаем отладчик к устройству

Когда нужно пройти код построчно и посмотреть значения в реальном времени, подключают отладчик по сети.

Порядок такой:

1. Запустите приложение на устройстве — оно должно быть собрано с поддержкой отладки.
2. В конфигураторе откройте список предметов отладки (меню Отладка). Запущенное на устройстве приложение появится в списке доступных для подключения.
3. Выберите его и подключитесь. После этого работают точки останова, пошаговое выполнение, табло со значениями и стек вызовов — всё как при отладке настольного клиента.

Точку останова ставят в нужной строке модуля заранее. Когда выполнение на устройстве дойдёт до неё, оно приостановится, а управление перейдёт в конфигуратор.

Частые загвоздки при подключении:

Логи устройства: adb для Android и Xcode для iOS

Когда отладчик подключить не удаётся или сбой происходит без участия встроенного языка, остаются системные логи. Это основной инструмент, если приложение падает ещё до запуска кода.

Android — через adb (Android Debug Bridge из состава Android SDK):

• adb devices — проверить, что устройство видно компьютеру.
• adb logcat — поток системного лога в реальном времени; платформа 1С пишет туда свои сообщения и ошибки.
• adb logcat *:E — оставить только ошибки, чтобы не тонуть в потоке.
• adb install app.apk — поставить сборку, adb pull — забрать с устройства файл (например, выгруженный журнал).

Чтобы не искать нужные строки вручную, запустите adb logcat, воспроизведите сбой и смотрите последние записи перед обрывом.

iOS — через Xcode:

• Подключите устройство и откройте в Xcode окно Devices and Simulators — там доступна консоль устройства с текущими логами.
• Системное приложение Console на macOS показывает тот же поток и позволяет фильтровать по имени приложения.
• Аварийные отчёты (crash logs) по конкретному устройству тоже доступны в Xcode — по ним видно, в каком месте нативного кода произошло падение.

Разбор аварийных завершений и нехватки памяти

Аварийное закрытие (приложение «вылетает») почти всегда видно в системном логе, а не в коде 1С. Начинайте разбор именно с логов устройства.

На Android ищите в logcat запись о фатальной ошибке процесса перед закрытием — там будет нативный стек. Отдельный симптом — ANR (Application Not Responding): система сообщает, что приложение не отвечает. Чаще всего это тяжёлая операция, запущенная в основном потоке интерфейса.

На iOS готовый crash log лежит в отчётах устройства в Xcode: по нему видно поток и место падения.

Нехватка памяти — частая причина вылетов на слабых устройствах:

• большие выборки данных целиком в память вместо постраничной загрузки;
• тяжёлые изображения в полном разрешении;
• накопление объектов, которые не освобождаются по ходу длинной операции.

Система Android при нехватке памяти просто убивает процесс — в логе это выглядит как внезапное завершение без явной ошибки встроенного языка.

У платформы есть собственный технологический журнал для глубокой диагностики, но на мобильных устройствах его возможности ограничены по сравнению с сервером. На практике для разбора краша быстрее сработают logcat и отчёты Xcode, а код 1С проверяют уже прицельно, зная место сбоя.

Если приложение падает только на конкретной модели или версии ОС — это почти наверняка память или особенность железа, а не логика кода. Воспроизводите на том же классе устройств.

Что ломается в обмене с сервером и как это проверить

Мобильное приложение обменивается данными с центральной базой через веб-сервис или HTTP-сервис, опубликованный на веб-сервере. Большинство «необъяснимых» ошибок обмена — это недоступность сервиса, а не ошибка в коде на телефоне.

Проверяйте по слоям, от внешнего к внутреннему:

1. Доступность сервиса. Откройте адрес веб-сервиса в браузере с того же устройства или из той же сети. Не открывается — проблема в сети, сертификате или публикации, а не в приложении.
2. Сертификат HTTPS. Самоподписанный или просроченный сертификат устройство может не принять. В логе это выглядит как ошибка защищённого соединения.
3. Таймауты. Медленный канал мобильного интернета обрывает длинные запросы. Проверьте, нет ли передачи больших объёмов за один вызов.
4. Код обмена. Только после первых трёх — логируйте этапы обмена на стороне приложения и смотрите ответ сервера.

Отдельно проверьте аутентификацию и права. Мобильное приложение заходит на сервис под своей учётной записью, и если у неё не хватает прав на объект или сервис закрыт для анонимного доступа, обмен упадёт с ошибкой доступа, а не соединения. В логе это разные записи — не перепутайте «нет связи» и «связь есть, но доступ запрещён».

Полезный приём — записывать в журнал регистрации тело запроса и ответ (без персональных данных). Когда обмен срывается у пользователя на объекте, выгруженный журнал покажет, на каком шаге оборвалось. Это особенно выручает, когда ошибка не повторяется на вашем устройстве, а живёт только у пользователя в поле.

Проверка на разных устройствах и версиях ОС

То, что работает на вашем телефоне, может падать на чужом. Мобильные приложения тестируют на нескольких устройствах разом.

С чего собрать минимальный набор проверок:

• 🤖 Android и iOS раздельно. Платформы по-разному работают с памятью, правами и файлами — проверяйте на обеих.
• 📐 Разные размеры экрана. Планшет и небольшой телефон показывают формы по-разному; проверьте, не обрезаются ли элементы.
• 🔢 Разные версии ОС. Старая версия Android ведёт себя иначе, чем свежая, особенно в правах доступа и работе с памятью.
• 📶 Слабая сеть и офлайн. Обрыв связи во время обмена — штатная ситуация на мобильном; приложение не должно «зависать».

Эмуляторы (Android Virtual Device и симулятор iOS в Xcode) закрывают часть сценариев, но память, камеру, GPS и реальную скорость сети честно воспроизводят только живые устройства. Критичные сценарии проверяйте на реальном железе.

Повторяющиеся проверки удобно оформить сценарным (автоматизированным) тестированием: один раз описать последовательность действий и прогонять её после каждой сборки. Это экономит время, когда правок много и регрессии ловятся вручную.

Частые вопросы