Файл
pubspec.yaml для многих остается просто местом, где перечислены зависимости. На деле это единственная точка, через которую
Flutter общается с нативными мирами
Android и
iOS. Одна неверная строчка и приложение либо не собирается, либо падает на конкретных устройствах, либо молча теряет производительность. Разбираем ошибки, которые дорого обходятся на практике.
Версии, которые живут своей жизнью:
Самая частая проблема: использование кареток
^2.0.0 без понимания последствий. Запись
^2.0.0 означает «любая версия от
2.0.0 до
3.0.0, кроме ломающих изменений». Но что считать ломающим изменением для
pub и что для нативного кода не всегда совпадает. Плагин может обновиться с
2.0.0 до
2.3.0, где для
Android внезапно потребуются новые разрешения, а вы узнаете об этом только после релиза.
Выход: явные диапазоны версий
'>=2.0.0 <3.0.0'. Да, строкой длиннее, зато контроль полный.
Платформы все же отличаются:
То, что отлично работает на
iOS, может валиться на
Android, и наоборот. Указывая зависимости глобально, вы часто тянете в сборку код, который не нужен на другой платформе. Или, что хуже, конфликтующие нативные библиотеки.
В
pubspec.yaml можно (и нужно) указывать зависимости отдельно для каждой платформы с уточнением минимальных версий
SDK, классов плагинов и прочих нативных параметров. Это не только решает конфликты, но и уменьшает размер итогового приложения.
Ресурсы, которые раздувают приложение:
- - assets/ - классическая запись, которая тащит в сборку вообще все, включая служебные файлы, исходники и мусор. На реальном проекте такой подход может добавить к размеру APK и IPA десятки мегабайт.
- Правильно - указывать точные пути и разделять ассеты по платформам. Картинки для ретина-экранов, шрифты, нативные ресурсы - все должно лежать в своих папках и подключаться адресно.
Окружение, о котором забывают:
Помимо версии
Dart и
Flutter, в
environment стоит указывать ограничения для нативного мира:
min_android_sdk,
min_ios_version,
kotlin_version,
swift_version. Это страхует от ситуаций, когда разработчик с новым
Kotlin пушит код, а у
CI стоит старая версия, и сборка падает.
Плагины, которые конфликтуют:
Зависимости - это не только имена пакетов, но и их настройки. Разрешения, конфигурации, порядок инициализации - все это влияет на рантайм. Часто плагины тянут одни и те же нативные библиотеки, и без явного указания версий возникают конфликты, которые проявляются только на этапе выполнения.
В
pubspec.yaml можно уточнять не только версию, но и конкретные параметры плагина для каждой платформы, включая разрешения и классы.
Сборка, которая не оптимизирована:
Флаг
uses-material-design: true многие ставят не задумываясь, хотя приложению могут быть не нужны иконки
Material. Но речь не только об этом. В секции
flutter можно (и нужно) указывать параметры сборки для каждой платформы:
proguard,
multidex,
bitcode,
target platform. Это напрямую влияет на размер и скорость запуска.
Тесты, которые не включают:
dev_dependencies часто остаются минимальными: только
flutter_test. Но для полноценной проверки нативной интеграции нужны инструменты:
integration_test,
flutter_driver, мок-генераторы. Их отсутствие не ломает сборку, но делает тестирование поверхностным, а баги уходят в прод.
Вывод:
pubspec.yaml - не просто список зависимостей, а полноценный конфигурационный файл, управляющий нативной частью приложения. Отношение к нему как к формальности приводит к сбоям, раздутому размеру и потерянному времени на отладку. Аккуратное управление версиями, разделение по платформам и явные настройки сборки превращают этот файл из источника проблем в инструмент контроля качества. В
Flutter «просто собралось» и «собралось правильно» - часто две большие разницы.
