В процессе разработки на платформе 1С:Предприятие 8.3 многие программисты сталкиваются с ситуацией, когда форма справочника или документа открывается с заметной задержкой. При этом стандартный замер производительности в конфигураторе не показывает длительного выполнения программного кода в процедурах ПриСозданииНаСервере или ПриОткрытии. В этой статье мы детально разберем скрытые механизмы платформы, которые влияют на скорость запуска интерфейсных окон, и выясним, как оптимизировать этот процесс.
Одной из самых распространенных причин «подтупливания» формы является избыточный объем данных, передаваемых между сервером и клиентом. Рассмотрим ситуацию: у вас есть справочник Контрагенты с сотней реквизитов и несколькими тяжелыми табличными частями. Даже если на самой управляемой форме вы вывели только Наименование и Код, платформа по умолчанию может пытаться передать весь объект целиком.
Проанализируем работу механизма ДанныеФормыСтруктура. Когда форма инициализируется, сервер подготавливает структуру данных для клиента. Если в свойствах реквизитов объекта на уровне формы стоит определенная настройка, происходит полная сериализация всех полей объекта в XML или JSON, их передача по сети и последующая десериализация на стороне клиента. Это создает колоссальную нагрузку на процессор и увеличивает объем трафика.
Для решения этой проблемы разберем по шагам следующие действия в конфигураторе:
Объект).Если этот флаг установлен, данные будут передаваться на клиент в любом случае. Снимите галочку Использовать всегда для всех реквизитов, которые не нужны пользователю непосредственно в интерфейсе или в обработчиках на клиенте. Это существенно уменьшит объем передаваемого контекста и ускорит открытие формы.
Выясним причину задержек, связанных с физическим хранением данных. Даже если мы оптимизировали передачу данных на клиент, сервер 1С все равно должен прочитать объект из базы данных. Если объект (справочник или документ) содержит огромное количество реквизитов, SQL-сервер выполняет выборку по «широкой» таблице.
Проанализируем ситуацию: чтение строки, в которой содержится 200 полей, включая длинные строки и ХранилищеЗначения, всегда будет медленнее, чем чтение компактной таблицы. SQL-серверу требуется больше времени на чтение блоков данных с диска и заполнение кэша. Если вы заметили, что создание нового документа с 3 реквизитами происходит мгновенно, а открытие существующего справочника с сотней полей тормозит — проблема может заключаться в архитектуре метаданных. В таких случаях рекомендуется выносить редко используемые данные в отдельные связанные справочники или регистры сведений.
Посмотрим, как на скорость открытия влияет механизм Record Level Security (RLS). Если для текущего пользователя настроены ограничения прав доступа на уровне записей, то при каждом обращении к объекту платформа модифицирует SQL-запрос, добавляя в него сложные условия и подзапросы (джойны с таблицами прав).
Зачастую эти задержки не видны в замере производительности, так как они происходят внутри платформенных методов при обращении к базе. Чтобы проверить эту гипотезу, попробуйте открыть ту же форму под пользователем с полными правами. Если «тормоза» исчезли — необходимо оптимизировать шаблоны ограничений доступа или уменьшить количество условий в RLS.
Рассмотрим еще один неочевидный фактор — Функциональные опции. Платформа 1С автоматически управляет видимостью элементов формы в зависимости от настроек системы. Если в конфигурации активно используются функциональные опции, завязанные на параметры сеанса или реквизиты объекта, то перед отрисовкой формы система выполняет расчеты видимости для каждого элемента.
Если элементов на форме много (даже скрытых), расчет дерева видимости на сервере может занимать значительное время. Проанализируем состав элементов: большое количество вложенных групп, страниц и декораций усложняет расчет геометрии формы. Старайтесь минимизировать количество невидимых элементов, которые не нужны в конкретном сценарии работы пользователя.
Разберем, как влияют табличные части на скорость инициализации. Даже если табличная часть не выведена на экран, обращение к объекту через ДанныеФормыВЗначение в серверном коде приведет к полной загрузке всех строк из базы в память сервера. Если в табличной части тысячи строк, это вызовет задержку.
Пример кода, который может замедлять работу при открытии:
&НаСервере
Процедура ПриСозданииНаСервере(Отказ, СтандартнаяОбработка)
// Данный вызов заставляет платформу вычитать весь объект со всеми ТЧ из БД
ТекОбъект = РеквизитФормыВЗначение("Объект");
// Какие-то действия с объектом...
ЗначениеВРеквизитФормы(ТекОбъект, "Объект");
КонецПроцедуры
Для оптимизации старайтесь избегать полной конвертации ДанныеФормы в объект и обратно без крайней необходимости. Используйте методы Запрос для получения конкретных значений из базы данных, не читая весь объект целиком.
Выясним влияние Условного оформления. Если на форме настроено множество правил оформления (цвета, шрифты, доступность), платформа вычисляет их в момент отрисовки. Особенно критично это для динамических списков, но и на формах объектов при большом количестве полей это дает о себе знать.
Также не стоит забывать про кэш метаданных. При первом открытии формы после обновления конфигурации или на новом рабочем месте платформа тратит время на получение описания формы с сервера. Если же задержка стабильна, проверьте производительность клиентской станции и сетевое соединение (ping и пропускную способность), так как отрисовка сложных интерфейсов в управляемых формах чувствительна к скорости работы видеоподсистемы и процессора на стороне клиента.
Подводя итог, для ускорения открытия формы объекта следует выполнить следующие шаги:
РеквизитФормыВЗначение в серверных процедурах при инициализации.Соблюдение этих простых правил позволит сделать интерфейс вашего решения на базе 1С быстрым и комфортным для конечных пользователей.