Обновление технологической платформы 1С — это всегда ответственный шаг, который иногда преподносит неприятные сюрпризы. Одной из часто встречающихся проблем в ветке 8.3.17.1851 (и соседних релизах) стало аномальное зависание интерфейса при работе с обычными формами. Особенно это критично для конфигураций, основанных на «Управлении торговлей 10.3» или других сильно переработанных решениях прошлых поколений. Рассмотрим подробно, почему возникают задержки более 400 секунд и как с этим бороться.
Представим типичную ситуацию: после перехода на новую версию платформы пользователи начинают жаловаться на то, что некоторые документы (например, «Заказ покупателя») открываются крайне долго. При этом зависание происходит не на всех объектах, а только на определенных. Проанализируем техническую сторону процесса открытия формы. Если мы воспользуемся отладчиком, то увидим следующую последовательность:
ПолучитьФорму().ПередОткрытием.Важно понимать, что в этот момент программный код разработчика практически не выполняется. Зависание происходит внутри механизмов самой платформы, которые отвечают за построение графического интерфейса и подготовку элементов управления к отображению. Выясним, что именно вызывает такую реакцию движка отрисовки.
Как показывает практика и опыт разработчиков, столкнувшихся с этой проблемой, основной причиной является наличие на форме полей ввода, в которых отображаются длинные строки текста без пробелов. В современных реалиях это часто бывают сырые данные от маркетплейсов или внешних сайтов, хранящиеся в формате JSON или XML.
Проанализируем, почему новая платформа реагирует на них так болезненно. В версии 8.3.17 были внедрены изменения в алгоритмы расчета геометрии элементов. Когда платформа пытается отобразить многострочное текстовое поле с включенным автоматическим переносом строк или автовысотой, она анализирует содержимое. Если в строке отсутствуют пробелы (минимизированный JSON), алгоритм расчета высоты и разбиения на строки начинает потреблять колоссальное количество ресурсов процессора, что и приводит к «зависанию» интерфейсного потока.
Если нам необходимо оставить данные на форме для просмотра, разберем самый эффективный способ оптимизации. Вместо стандартного типа «Поле ввода» для реквизита с JSON-данными следует использовать Поле текстового документа. Этот объект в 1С гораздо лучше оптимизирован для работы с большими массивами неструктурированного текста.
Для реализации этого решения выполним следующие шаги:
ПолеТекстовогоДокумента (в обычных формах это делается через палитру свойств или замену элемента).Рассмотрим ситуацию, когда данные нужны лишь эпизодически. В этом случае лучшим решением будет полное удаление тяжелого текстового поля с основной формы. Вместо этого мы можем использовать кнопку просмотра. Разберем пример кода для реализации такого подхода:
Процедура КоманднаяПанельПросмотрДанных(Кнопка)
// Создаем вспомогательное окно для отображения тяжелых данных
ФормаПросмотра = ПолучитьОбщуюФорму("ФормаПросмотраТекста");
ФормаПросмотра.Текст = ЭтотОбъект.ДанныеМаркетплейса;
ФормаПросмотра.Открыть();
КонецПроцедуры
Такой подход гарантирует, что при открытии основного документа платформа не будет тратить время на парсинг и отрисовку огромных строк, а пользователь получит доступ к информации только тогда, когда она ему действительно понадобится.
В релизах ветки 8.3.17 разработчики 1С по умолчанию активировали некоторые функции, которые могут конфликтовать со старыми «обычными» формами. Проанализируем свойство Проверка орфографии. Когда в текстовое поле попадает JSON на 50 000 символов, система пытается проверить каждое «слово». Поскольку в JSON нет привычных разделителей, вся строка воспринимается как одно слово, что вызывает программный сбой или бесконечный цикл проверки.
Также стоит обратить внимание на свойство Расширенное редактирование. Для обычных полей ввода его лучше отключить, если там не планируется форматирование текста (RTF). Это существенно снизит нагрузку на графическую подсистему Windows-клиента.
Если вышеописанные меры не помогают, необходимо провести глубокую диагностику. Выясним причину через стандартные инструменты:
Реструктуризация таблиц.Посмотрим на ситуацию глобально. Версия 8.3.17.1851 была признана многими специалистами как переходная и содержащая ряд ошибок в движке обычных форм. Если бизнес-требования позволяют, рекомендуется выполнить одно из следующих действий:
Подводя итог, можно сказать, что проблема «зависания на 400 секунд» — это классический конфликт новых механизмов анализа текста платформы и специфических данных в устаревших интерфейсах. Следуя нашим рекомендациям по замене элементов управления и оптимизации отображения JSON, вы сможете вернуть комфортную скорость работы пользователям без отката на старые версии ПО.