Меня зовут Люлюк Евгений. Я разработчик. Для меня эффективность интерфейса — это не количество кликов и не расположение кнопок, а программистская эффективность: то, насколько быстро интерфейсы выводятся и насколько мало они памяти потребляют.
Я разрабатываю Infostart Toolkit, Infostart Data Form Wizard, Data Conversion 3 Booster. Это продукты с достаточно удобным и быстрым интерфейсом. Они работают с метаданными, с большими объемами и при этом адекватно все отображают. То, о чем я буду рассказывать, основано на опыте разработки этих продуктов.
Оптимизация работы с табличным документом
Первая тема, которую хочу осветить — это табличный документ. Простая вещь. Удивительно, но можно в него вывести данные неправильно. И это очень легко.
Сам объект «Табличный документ» очень продвинутый, в нем много возможностей, он здорово спроектирован. Когда все понимаешь, им удобно пользоваться. Но он еще, помимо этого, динамический. То есть, если он большого объема, он данные считывает не сразу. У вас может быть 100 страниц табличного документа, а на экране вы видите только одну-две. По мере пролистывания данные загружаются. Это очень важно для эффективности.
Вариант первый: неправильный подход
Это самый распространенный вариант неправильного вывода. Мы на клиенте создаем табличный документ как поле на форме. Затем вызываем серверную функцию (например, «ПримерТабличногоДокумента»). Она может быть без контекста, это не важно. Функция выводит все в табличный документ, а затем результат возвращается на клиент.
// НЕПРАВИЛЬНО!!!
&НаКлиенте
Процедура ВывестиОбычным(Команда)
// ~1,5Mb, ~18,5Mb, ~2,4 c
ТабличныйДокумент = ПримерТабличногоДокумента();
КонецПроцедуры
Если мы так сделаем, с сервера прилетит весь табличный документ, например, 20 мегабайт, и поместится в табличный документ на клиенте. То есть полностью весь трафик с сервера перетечет на клиента. У клиента потребление памяти будет большое, и на сервере будет то же самое.
Вариант второй: правильный подход
Нужно сделать контекстный вызов сервера, перейти на сервер в контексте и выполнить те же действия.
// ПРАВИЛЬНО
&НаКлиенте
Процедура ВывестиВТабДокНаСервере(Команда)
// ~2Kb, ~10Kb, ~1,23 c
ВывестиВТабДокСервер();
КонецПроцедуры
&НаСервере
Процедура ВывестиВТабДокСервер()
ТабличныйДокумент = ПримерТабличногоДокумента();
КонецПроцедуры
В этом случае табличный документ будет располагаться на сервере, и по мере пролистывания он будет прогружаться. Возможно, вы замечали, что когда листаете табличный документ, идут серверные вызовы. Никакого дискомфорта этот механизм не вызывает, но он позволяет оптимизировать работу.
Результаты измерений
У меня есть данные замеров. В первом случае 18 мегабайт трафика «переплыло» с сервера на клиент. Это заняло 2,4 секунды. А во втором примере — 10 килобайт, то есть только то, что умещается на экране. И за 1,2 секунды.
Тот пример, который я описал, дает выигрыш в 2 раза. При выводе 20 000 строк обычным способом — 2,5 секунды, оптимизированным — 1,2 секунды.
Интересно, что механизмы БСП, печать, механизм отчетов — все это реализовано корректно. То есть в них такой проблемы нет. А вот если мы возьмем консоль запросов, которая доступна на сайте 1С, которую мы все скачиваем, то она жутко медленно выводит данные. Я буквально пять строк переписал в ней, используя этот подход, и добился выигрыша в 10%. Там главная проблема в другом — сам вывод табличного документа занимает много времени, но даже пять строк позволяют добиться улучшения.
Оптимизация метода «Присоединить»
Относительно табличного документа есть еще одна проблема. Консоль запросов выводит каждую колонку через метод «Присоединить». Для вывода четырех строк по семь колонок через метод «Присоединить» требуется 28 повторений.
Для 1С большие циклы — это проблема. 10 000 строк и 10 колонок — это 100 000 операций. Вывод может занимать до 20 секунд.
Я рекомендую метод «Присоединить» по возможности не использовать, он очень медленный. Лучше делать область (обычно в ней одна-две колонки), заполнять поле значением и идти дальше. Если выводите строку, используйте «ПолучитьОбласть», заполните ее и выведите сразу семь параметров. Это работает намного быстрее.
Если вы смотрели внутренние механизмы, то знаете, что в схеме компоновки данных есть макет, где она заранее готовит то, что будет выводиться. Для каждой группировки, для каждой строки создается область, которая будет выведена сразу для всего отчета. Поэтому она выводит быстро.
Важно понимать, что табличный документ — порционный. Хорошо, когда он не передается полностью с клиента на сервер, и это все реализуется платформой. Не нужно бояться, что когда вы нажмете печать, той части, которая не загружена, не будет. Все само прогрузится и появится.
Работа с большими деревьями на форме
Далее рассмотрим работу с большими деревьями на форме и реализацию поиска. Многие не любят работать с деревьями в 1С. Это механизм, который позволяет пользователям отображать данные в удобном виде.
Однако с этим объектом есть сложности. Когда дерево большое (например, каталог проводника с большим количеством файлов и папок), если попытаться сразу все развернуть, как мы обычно делаем, система может зависнуть надолго.
Аналогичный пример — когда нам нужно отобразить дерево метаданных и что-то выбрать. В 1С:ERP легко может быть 5 000 объектов: в справочниках 1 000, документов 500 и т.д. Все это накапливается, и дерево получается очень большим. Если выводить все его сразу, это будет неэффективно — из-за большого потребления памяти и долгой работы.
Оптимизация загрузки дерева
Эта хитрость придумана очень давно, думаю, многие о ней знают. Смысл следующий: мы добавляем корневые части дерева (константы, справочники, документы) и внутрь добавляем фиктивную строку. Для чего? Чтобы появился плюсик, чтобы интерфейс думал, что там есть какие-то ветки дерева.
Когда ветки есть, дерево можно разворачивать. И в момент, когда строка разворачивается, мы загружаем туда необходимые данные.
Простой пример: дерево метаданных может состоять из 9 000 строк. При традиционном подходе добавляются все 9 000. Если использовать описанный мной подход, добавится только 20 строк. Дерево будет открываться мгновенно, а в традиционном подходе — за полторы секунды.
Естественно, когда пользователь нажимает плюсик, идет микрозадержка, но ее даже не замечаешь. Дискомфорта это не вызывает.
Я привел пример с номенклатурой в каталоге: вы будете нажимать плюсик, и данные будут выпадать без задержки. Если дерево содержит одну колонку — это одно. Если оно содержит семь колонок — другое: добавить сразу 9 000 строк будет еще тяжелее.
Кроме того, мы знаем, что при вызове серверного метода передается контекст формы, содержащий все данные. Если дерево большое, это может вызвать проблемы.
Вот простой код, который показывает этот подход:
ЗаполнитьВсе(); // Просто заполняет все строки
// Добавление фиктивной строки
НоваяСтрока = Дерево.Строки.Добавить();
Некоторые в фиктивную строку добавляют название «фейк» или «фиктивная строка», но это на ваше усмотрение. Мне удобнее использовать пустую строку, потому что если пользователь ее видит, то ему сразу понятно, что это какая-то ошибка или проблема.
В обработчике события «ПередРазворачиванием» мы находим разворачиваемую строку по идентификатору, проверяем, что ее необходимо развернуть. Если там уже все добавлено, считывать ничего не надо.
Функция «НеобходимоРазвернутьСтроку» отвечает за эту проверку и проверяет, что добавлена именно фиктивная строка. Может быть такое, что у вас добавилась одна осмысленная строка, тогда это уже не будет разворачивать.
Иногда нужно в заголовке написать, например, «Констант: 15», чтобы пользователь знал, сколько элементов в группе. Тогда можно либо при разворачивании дополнить заголовок, либо заранее создать заголовок «Константы (15)». Когда они развернутся, внутри будет 15 элементов.
Реализация поиска в динамически загружаемом дереве
Когда мы реализовываем дерево описанным методом, мы сразу сталкиваемся с проблемой. Есть удобный платформенный поиск, который появился в 1С:Предприятие 8.3.15. Он ищет по всем колонкам таблицы или дерева и подсвечивает результаты. Но если мы будем использовать этот поиск в нашем случае, у нас просто ничего не отобразится. В дереве нет всех строк, поэтому поиск ничего не найдет.
У стандартного поискового окошка нет события, когда в нем что-то набрали. Мы могли бы в этот момент догрузить дерево и поиск бы сработал. Но там нет никаких подписок на события, он закрыт. Поэтому приходится реализовывать поиск самостоятельно.
Сразу кажется, что поиск по 400 000 строк или 20 000 метаданных будет медленным. Так и есть, если пойти неверным путем. Если пойти верным, то это работает быстро.
Алгоритм эффективного поиска
&НаКлиенте
Процедура ПоискПриИзменении(Значение)
ОбновитьПоискСервер();
КонецПроцедуры
&НаСервере
Процедура ОбновитьПоискНаСервере()
РезультатПоиска.Очистить();
НетПоиска = (Шаг(Поиск) = 0);
ШаблонПоискаНижний = НРег(СокрЛП(Поиск));
Для Каждого ОбъектМетаданных По ДоступнымКоллекциям Цикл
Если СтрНайти(НРег(ОбъектМетаданных.Представление()), ШаблонПоиска) Тогда
РезультатПоиска.Добавить(ОбъектМетаданных.Представление(), ОбъектМетаданных.ПолноеИмя());
КонецЕсли;
Если КоличествоНайденных = 30 Тогда
Возврат;
КонецЕсли;
КонецЦикла;
КонецПроцедуры
Вот основные моменты реализации:
-
В интерфейсе добавляется окошко поиска, которое запускает наш алгоритм.
-
В момент поиска не нужно добавлять в дерево все строки — они там не нужны. Они появятся, когда пользователь развернет соответствующие ветки.
-
Тяжелое место — сам поиск. Если будет миллион итераций, это будет медленно. Все, что можно вынести из цикла поиска, выносим.
-
Функция «СтрНайти» регистрозависимая. Чтобы искать без учета регистра, нужно перевести все в верхний или нижний регистр. Опыт показывает, что нижний регистр предпочтительнее — меньше действий (т.к. большая часть текста — в нижнем регистре).
-
Ограничиваем количество результатов. Нет смысла искать и показывать все 10 000 совпадений. Достаточно 30-50 строк. Пользователь никогда не долистает до 105-го элемента. Если нужно, он может уточнить поисковый запрос.
-
Если не очевидно, что в результате поиска не все элементы, можно внизу вывести сообщение «Внимание, выведено не все». Для этого, если у вас ограничение 30 строк, нужно найти 31-ю и вывести предупреждение.
Плюсы и минусы своего поиска
Типовой платформенный поиск прекрасен — он подсвечивает найденные буквы. В самостоятельной реализации не всегда это можно сделать. Стандартный поиск работает, пока им можно пользоваться.
У стандартного поиска есть один недостаток: например, он не найдет «контрагент» в поле «НоменклатураКонтрагентов». Аналогично, когда ищешь «основание», а реквизит называется «ДокументОснование», он ничего не находит.
Свой поиск позволяет реализовать дополнительные возможности. Например, я сделал так: при поиске объекта метаданных можно поставить дробь «/» и указать имя коллекции (например, «справочники»). Тогда поиск будет выполняться только в справочниках. Это оптимизация — если раньше поиск искал по 10 коллекциям и обходил 10 000 строк, теперь он обходит 100 или 1 000 строк. Поиск работает в разы быстрее.
В конфигураторе очень не хватает такой возможности. Если я ищу регистр сведений «Номенклатура» и набираю «номенклатура», он находит все реквизиты с этим именем. По ключевому слову практически невозможно найти нужный объект.
При необходимости можно реализовать поиск, который работает в фоне — все в ваших руках.
Оптимизация передачи дерева между клиентом и сервером
Дерево — тяжелый объект для передачи между клиентом и сервером. Если табличный документ позволяет передать часть данных, то дерево — нет. Если в дереве 10 000 строк, оно будет работать медленно. Когда вы переходите на сервер, чтобы отсортировать эти 10 000, даже если поменяются местами только три строки, это займет 2 секунды.
Выход есть: делайте операции с деревом на клиенте. Это нормально работает . Я использовал даже алгоритм быстрой сортировки для элементов дерева.
Например, у меня есть групповая обработка, которая обрабатывает сто тысяч объектов. Каждый объект, обработанный успешно, должен попасть в ветку «Обработано успешно». Все объекты с ошибками должны быть сгруппированы по типам ошибок.
Обработалась тысяча строк, они добавились. Обработали следующую тысячу, их нужно добавить туда же и отсортировать. Проблема: если каждый раз выполнять сортировку на сервере, к концу обработки вы столкнетесь с тем, что сама обработка будет выполняться за секунду, а добавление десяти строк в дерево — за минуту.
Работа только с реально используемыми данными
Не нужно брать все данные сразу. Возьмите ограниченную часть, выполните работу. Не стоит руководствоваться подходом «вытащить все, а потом работать». Пока вы будете все перетаскивать, может прийти «хозяин» и сказать, что передумал и ничего перетаскивать не надо. Работа будет сделана впустую.
Часто бывает, что у АРМ менеджера есть закладки с таблицами. Не нужно загружать все закладки сразу, когда пользователь только вошел. Когда закладка активирована, то можно загрузить содержимое. Так все будет работать быстро и эффективно, даже если код не оптимален. Если же все загружать сразу, проблемы проявятся уже при открытии.
Использование механизма длительных операций
Хочу провести агитацию за использование механизма длительных операций из БСП. Используйте его везде, где возможно. Он несложный, с ним можно разобраться, и он дает большую пользу.
Я когда-то разбирался, как в платежном поручении работает заполнение выписки. Зашел, нажал «Заполнить». Оказалось, заполнение табличной части платежного поручения работает на длительных операциях. В тот момент я понял, что этот механизм надежный и широко используется.
Преимущества механизма длительных операций
Очевидные плюсы:
-
Не блокирует работу пользователя,
-
Поддерживает многопоточную оптимизацию.
Если у вас есть АРМ с тремя закладками, вы можете сделать так, чтобы все три закладки одновременно начали заполняться. Многопоточность сработает без каких-либо сложных решений.
Небольшой недостаток — некоторая сложность реализации, но она не критична. Требуется наличие БСП. Если вам необходимо отлаживать длительные операции, используйте параметр запуска режима отладки «/РежимОтладки». При этом задания запускаются не в фоне, а как обычные, и их можно отладить.
Примеры использования длительных операций
В Infostart Toolkit есть обработка подписки на события. Когда активируешь подписку, справа показывается, какие объекты подписаны, какие модули затрагиваются. Часто обновление происходит так быстро, что индикатор прогресса даже не появляется. А когда появляется, он не вызывает задержек. Если пользователь переключился на другую строку до завершения обработки, предыдущее задание отменяется и запускается новое. Все происходит незаметно.
Другие примеры использования длительных операций в Toolkit:
-
Поиск ссылок на объект (занимает время, но не блокирует интерфейс);
-
Фоновое выполнение запроса (тяжелый запрос можно отменить и запустить заново).
Прочие проблемы, рекомендации
Проблема с описанием оповещения о закрытии
Есть интересная проблема. Когда мы открываем подчиненную форму, у нее есть параметр «ОписаниеОповещенияОЗакрытии». Возникает мысль создать переменную с таким же именем, записать в нее обработчик и передать его. Вроде все работает нормально.
Но потом оказывается, что при закрытии какой-то формы она попадает в код, который совершенно не должна затрагивать. Дело в том, что у формы клиентского приложения есть глобальная переменная «ОписаниеОповещенияОЗакрытии». И я нечаянно ее заменил своим обработчиком.
Как избежать проблемы:
-
Не использовать это название для переменных,
-
Явно объявить переменную через «Перем» и зафиксировать ее под себя.
С этой проблемой можно не столкнуться, если у вас один уровень вложенности форм. Но если у вас пять вложенных форм, которые открываются одна за другой, то проблема проявится.
Не используйте коллекции картинок
В динамическом списке приходится сталкиваться с коллекциями картинок. Лучше использовать каждую картинку отдельно, тогда их можно совмещать. Если вам нужно вывести легенду, вы можете вставить ее в справку или в другое место. Когда у вас коллекция, вы можете использовать ее только как коллекцию, отдельно отредактировать картинки не получится.
Декларирование параметров формы
Есть стандарт, до которого редко доходят руки. На закладке «Параметры» можно задать значения параметров, которые будут передаваться в форму. При этом будут приводиться типы к этим значениям, и на входе они будут обязательны.
Это описание интерфейса формы. 1С рекомендует им пользоваться, но большинство разработчиков этого не делают. Я сам два года не знал, зачем эта закладка нужна. Потом понял, что если нужно передать какое-то проблемное значение, которое нельзя указать, приходится устанавливать тип «Произвольный».
Стандартные команды
В 1С есть стандартные команды — такие как «ИзменитьФорму», «ДобавитьСтрокуТаблицы» или «ДобавитьСтрокуДерева». Эти команды нельзя создать программным путем. Сначала у меня появилась мысль : я сделаю программно команду «ИзменитьФорму», добавлю ее во все формы, и когда-нибудь сделаю свою. Но это невозможно. Стандартные команды добавляются только интерактивно, программно их добавить нельзя.
Еще одна особенность: команда «ИзменитьФорму» не локализуется автоматически. Если пользователь откроет англоязычную платформу или конфигурацию, вместо «ИзменитьФорму» он должен увидеть Change Form, но этого не происходит.
Разработчик должен сам прописывать идентификаторы для разных языков. Это особенно важно, если обработка должна запускаться и в английской, и в русской конфигурации.
*************
Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TECH EVENT.
Вступайте в нашу телеграмм-группу Инфостарт
