При разработке собственных конфигураций или кастомизации типовых решений программисты часто сталкиваются с ситуацией: после интеграции подсистемы Библиотека подключаемого оборудования (БПО), которую часто путают с термином ДТО (драйверы торгового оборудования), размер файла конфигурации (.cf) взрывным образом увеличивается. Если изначально «нетленка» весила 2–10 Мб, то после внедрения БПО она может раздуться до 800 Мб и более. В этой статье мы разберем, является ли это нормой, проанализируем причины такого поведения системы и рассмотрим по шагам, как вернуть конфигурации легкость без потери функциональности.
Проанализируем структуру современной БПО. Основной объем занимают не программные модули, а Общие макеты. В состав библиотеки включены десятки драйверов для самого разного оборудования: ККТ с передачей данных, сканеры штрихкодов, терминалы сбора данных, весы и, конечно, эквайринговые системы.
Разберем факторы, влияющие на размер:
.dll, .so) под все эти архитектуры (x86, x64, ARM).Самый простой и эффективный способ оптимизации — это удаление неиспользуемых макетов. Если вы используете БПО только для подключения эквайринга, вам совершенно не нужны макеты драйверов для весов самообслуживания или фискальных регистраторов всех мастей. Выясним, как это сделать правильно.
Зайдем в Общие макеты и найдем объекты, чьи имена начинаются с Драйвер.... Рассмотрим алгоритм очистки:
После такой процедуры размер .cf файла обычно сокращается с 800 Мб до комфортных 50–100 Мб.
Более продвинутый способ, который позволяет сохранить чистоту конфигурации, — это использование механизма загрузки драйверов из внешних файлов. Проанализируем, как это работает в современных версиях БПО.
В справочнике ДрайверыОборудования (название может варьироваться в зависимости от версии БПО) предусмотрена возможность загрузки компоненты из файла. Это означает, что сам бинарный файл драйвера будет храниться не в структуре метаданных (которая проверяется при каждом сравнении/объединении), а в таблицах базы данных как обычный файл или ХранилищеЗначения.
Разберем шаги для реализации этого подхода:
Этот подход позволяет оставить конфигурацию легкой, при этом сохраняя все преимущества централизованного обновления драйверов для всех пользователей. При первом обращении к оборудованию система подтянет файл из базы и установит его локально.
Многие задаются вопросом: «А что плохого в 800 Мб, если диски сейчас терабайтные?». Разберем, почему размер имеет значение для разработчика:
.dt, создание копий для разработки — все эти процессы замедляются пропорционально размеру .cf.Посмотрим на пример кода, который БПО использует для работы с компонентой. Важно понимать, что если вы «вырезали» макет, код должен уметь обрабатывать отсутствие встроенного драйвера и предлагать пользователю загрузить его извне.
// Пример логики проверки наличия компоненты
ПараметрыПодключения = МенеджерОборудованияВызовСервера.ПолучитьПараметрыПодключения(СсылкаНаДрайвер);
Если ПараметрыПодключения.ДрайверУстановлен Тогда
// Работаем с оборудованием
Иначе
// Если макет в конфигурации пуст, система предложит загрузить драйвер из файла
МенеджерОборудованияКлиент.УстановитьДрайвер(СсылкаНаДрайвер);
КонецЕсли;
Использование метода УстановитьДрайвер позволяет интерактивно подгрузить компоненту, даже если вы очистили все макеты в конфигураторе для уменьшения размера базы.
Размер конфигурации в 800 Мб после подключения БПО — это нормальное, но нежелательное явление. Это плата за универсальность и удобство «коробочного» внедрения. Для профессиональной разработки рекомендуется:
Соблюдение этих правил позволит вам сохранить высокую скорость разработки и удобство поддержки системы, не заставляя клиентов и коллег страдать от гигантских файлов обновлений.