Вы все еще эмулируете? Тогда мы идём к вам…

Скорость (да и качество) разработки прямо пропорциональна отзывчивости  и плавности системы, на которой эта самая разработка и ведется. Большинство мобильных разработчиков ежедневно на протяжении всего рабочего времени использует эмуляторы мобильных операционных систем. С одной стороны, эмуляторы позволяют значительно сократить  время в том плане, что при использовании эмулятора экономия происходит за счет ненужности заливки разрабатываемого приложения на реальное устройство, последующей его установки и запуска. А с другой стороны, эти же эмуляторы пожирают системные ресурсы, да порой так яростно, что о продуктивной работе речь вообще не идет. Самое время поговорить о том, можно ли что-то улучшить в подобной ситуации или нет. Если вы тоже задавались подобным вопросом, то добро пожаловать под кат.

Эмулятор эмулятору рознь, да и от мощности рабочего компьютера также многое зависит. И, хотя сегодня речь пойдет, в принципе, о мобильных эмуляторах, возможно, конкретно у вас нет такого рода проблем и скорость разработки не страдает от наличия запущенного эмулятора или даже пары. Но в большинстве случаев рабочий компьютер не является представителем топ сегмента. В лучшем случае это что-то среднее. Таким образом, так или иначе приходится ресурсы экономить. И, при всем этом, в большинстве случаев эмуляторы готовы потребить неограниченное количество ресурсов, практически как Chrome. Начнем с того, что эмуляторы съедают огромное количество свободного места. Эмулятор может занимать и 3 гигабайта, и 7, и 14, и даже больше. И вроде бы все не так страшно, если бы не одно «но»: в большинстве случаев одного эмулятора недостаточно. И тогда папка может разрастись до нереальных размеров. Особенно это критично на маках, где со свободных местом просто швах. С другой стороны, как выше уже было упомянуто, рабочие ПК также могут (а довольно часто и испытывают) испытывать проблемы с нехваткой места на жестком диске.

Зачастую и это не самая страшная проблема. Предположим, что места достаточно. Но эмуляторы не отказывают себе и в удовольствии поедать другие доступные ресурсы. Для более или менее приемлемой работы необходимо выделить как минимум 2 гигабайта оперативной памяти. И это не предел. Также помним про запущенный Chrome. Процессорное время- это еще один ресурс, к которому эмуляторы небезразличны. Если вы взаимодействуете с эмулятором, то использование процессора может легко находиться в районе 30-40% (а иногда и того больше). А уж если, не дай Бог, на экране что-то происходит (проигрываются анимации, запущена отладка, происходят какие-то ресурсоёмкие вычисления или еще что-то), то пиши пропало. Использование процессора может легко подскочить и до 100%, что само собой приводит к слайд-шоу в работе эмулятора: анимация проигрывается с жуткими рывками. И непонятно: это где-то ошибка в коде? Или просто эмулятор тормозит?

Перечисленных выше проблем уже достаточно, чтобы хотелось искать какую-то более производительную альтернативу. Но, к сожалению, проблемы с эмуляторами на этом не заканчиваются. Давайте рассмотрим еще несколько моментов. Бывают случаи, когда необходимо сразу запустить несколько эмуляторов одновременно. Например, чтобы сравнить поведение приложения в текущей версии и в предыдущей. Что будет, если попробовать запустить один и тот же эмулятор дважды? Правильно, эмулятор ругнется и прекратит свой запуск:

Любое мобильное приложение обычно состоит как минимум из нескольких экранов с многообразием элементов пользовательского интерфейса. А в связи с тем, что разнообразие вариантов разрешения и соотношения сторон экранов мобильных устройств стремится к бесконечности, довольно остро встает вопрос о том, как это все тестировать (в том числе и во время разработки). Основная проблема состоит в том, что размеры эмулятора мобильного устройства нельзя изменить во время его работы. Другими словами, размеры экрана статичны; таким образом тестирование разметки пользовательского интерфейса становится ежедневной головной болью мобильного разработчика. Единственный выход (а единственный ли? А как вы решаете данную проблему?) в сложившихся условиях — это плодить эмуляторы под десятки разных разрешений экрана. А так как эмуляторы поглощают ресурсы как не в себя, запустить их несколько  одновременно довольно проблематично. Ах, если бы было можно просто растянуть окошко эмулятора под необходимый размер и соотношение сторон, как это делается с любым другим десктоп приложением…

Так как речь зашла о взаимодействии эмулятора и десктопной ОС, то нельзя пройти мимо, не упомянув еще один момент: непосредственный ввод с клавиатуры. Удивительно, но даже такая, казалось бы, простая вещь, как ввод с клавиатуры, в эмуляторе не работает должным образом. Само собой, можно вводить что-то с экранной клавиатуры… Конечно можно слегка подшаманить, и ввод начнет работать. Но, к сожалению, только на английском языке. Что, конечно, не может не радовать (. А если все-таки нужно что-то ввести на родном, то только экранная клавиатура, только хардкор.

Допустим, с вводом с экрана смирились. Но даже здесь, как бы печально это ни звучало, есть проблемы. Дело в том, что по умолчанию на вновь созданном эмуляторе (или эмуляторе с полностью очищенной памятью) доступна только клавиатура на английском языке. А для того, чтобы было можно использовать русский язык, необходимо пробираться через дебри настроек, искать русский в списке всех поддерживаемых. Целый квест, пропустить который, увы, не получится… Но ведь, один раз добавив русскую раскладку, далее можно с ней работать без проблем?

Во-первых, мы уже обсуждали момент, что для работы может  потребоваться несколько эмуляторов. А запустить один и тот же эмулятор несколько раз нельзя. Поэтому в каждом новом эмуляторе придется это все настраивать заново. Но это еще полбеды. Если бы на одной настройке эпопея заканчивалась, то этого пункта, скорее всего, не было бы в этом списке. Так в чем же тогда проблема? Это будет ясно из следующего пункта.

Не так давно перейдя в мобильную разработку, я довольно быстро столкнулся с проблемой, а, точнее, с ошибкой. При попытке запуска приложения из IDE во время установки возникает странная ошибка  INSTALL_FAILED_INSUFFICIENT_STORAGE . Пораспрашивав более опытных коллег,  выяснил, что с ошибкой, которая у меня возникает чуть ли не каждый второй запуск, никто не сталкивался. Далее, использовав поиск, выяснил, что ничто не ново под луной). И даже нашлись какие-то решения. И даже несмотря на это, эта ошибка все так же часто появлялась, и приходилось использовать решение с ручным удалением приложения с эмулятора; чисткой папок приложения, что конечно, сильно раздражало и занимало уйму времени. В какой-то момент, как говорится, что-то пошло не так, и решение перестало работать. Перепробовал еще несколько вариантов, и решение с очисткой данных эмулятора, вроде бы, заработало. Само по себе это решение все так же занимает кучу времени, т.к. очистить данные на работающем эмуляторе нельзя:

Сначала необходимо завершить работу эмулятора, перейти в AVD Manager, найти в списке необходимый эмулятор, раскрыть список доступных действий, выбрать  Wipe Data , после чего нужно снова запустить эмулятор и перезапустить приложение. Все это занимает просто колоссальное количество времени, особенно с учетом того, что ошибка может проявляться чуть ли не каждый второй запуск. Здесь же нужно учесть, что необходимо восстановить данные приложения для дальнейшей работы с ним; закрыть все информационные окна, которые всплывают при первом открытии. Здесь же возникает и проблема с восстановлением русской раскладки клавиатуры. В общем, кошмар. Еще один маленький ад в разработке. Конечно, вопрос о том, почему эта проблема есть у меня, а у других разработчиков ее нет, сильно волновал. Но разобраться с ним было довольно затруднительно, учитывая карантин и удаленку. В какой-то момент выяснилось, что часть разработчиков используют отличную от стандартной ВМ, а часть не используют андроид ВМ вообще. А в момент, когда потребовалось запустить приложение в андроид эмуляторе, ошибка тут же дала о себе знать).

Таким образом, можно сделать вывод, что корнем многих проблем, с которыми сталкивается мобильный разработчик, является эмулятор. Но работать напрямую с устройством так же напряжно и времязатратно. Есть ли какое-то альтернативное решение? Наверное, нельзя на этот вопрос дать однозначный ответ, поэтому ответом будет: зависит. Очевидно, чтобы не использовать эмулятор при разработке под мобильные платформы, необходимо, чтобы была возможность компилировать приложение и под настольные операционные системы. И если вы разрабатываете на Flutter, то, возможно, вы уже в курсе, что такая опция уже давно в разработке. Более того, ею уже можно начинать пользоваться, а по отзывам некоторых «первопроходцев», можно практически полностью отказаться от эмулятора. Разве это не повод для праздника?).

Какие у нас есть варианты для запуска на десктопе? А что, разве мы еще не успели упомянуть момент, что таких вариантов больше одного?. Давайте кратенько рассмотрим основные возможности:

1. go-flutter-desktop — это неофициальный плагин, который, как скорее всего понятно из названия, позволяет использовать все возможности языка Go. Не знаете язык Go? Возможно, самое время совместить приятное с полезным? С помощью этого плагина можно получить версию приложения под основные десктопные ОС, потребляющие мало ресурсов. Такое приложение будет поддерживать такие крайне полезные возможности Flutter как Hot Reload и Hot Restart. А благодаря языку Go можно реализовывать (или использовать уже кем-то реализованные) плагины для взаимодействия с Flutter частью приложения. Другой немаловажный плюс использования Go — это возможность использования одной кодовой базы под все платформы. А огромное количество уже реализованных модулей и библиотек на Go, позволит реализовать необходимый функционал быстро и качественно. Стоит отметить, что основные (хотя это, конечно, для кого как) плагины, а именно file_chooser, path_provider, video_player и другие, уже реализованы.

2. Плюс минус все тоже самое можно получить, если использовать другой неофициальный плагин flutter-rs, основной язык которого (не побоимся этого слова) — всеми любимый Rust. 

3. Еще один вариант — это использование плагина flutter-desktop-embedding, который теперь является частью Flutter Sdk. Теперь он является официальным плагином, который позволяет запускать десктопные приложения, не покидая уютного мира мобильной (теперь уже мультиплатформенной) разработки. Также все основные десктопные ОС поддерживаются (хотя степень готовности и отличается). Такие возможности, как Hot Reload и Hot Restart, работают без проблем. Реализованы самые необходимые плагины. А вот реализовывать кастомный плагин, к сожалению (хотя, смотря с какой стороны на этот момент посмотреть; ведь в таком случае можно использовать любые нативные для целевой платформы средства), придется для каждой платформы отдельно.

Какую из перечисленных выше возможностей выбрать, каждый решит сам. А в качестве примера давайте рассмотрим последний вариант чуть более подробно.

Как уже было выше сказано, поддержка настольных ОС еще не добралась до релизного состояния. И это стоит учитывать. Первое, что необходимо сделать, — это сменить Flutter канал. Если вы используете Windows, то необходимо переключиться на канал master (для macOS и linux — dev).  Для этого необходимо выполнить команду:

Следующим шагом необходимо включить поддержку соответствующих платформ. Для этого выполняем команду:

или

или

Далее необходимо создать проект:

Для запуска необходимо перейти в папку с проектом и запустить команду:

После чего, если все прошло без проблем, можно увидеть примерно такую картину:

Если открыть проект, то также появится соответствующая возможность выбрать Windows в качестве «эмулятора»:

А для того, чтобы добавить поддержку настольных ОС, необходимо выполнить следующую команду в папке с проектом:

Стоит учитывать, что, так как работа над реализацией этого функционала еще не закончена, с большой вероятностью можно столкнуться с какими-то проблемами. С другой стороны, а когда и кого это останавливало?

А что вы думаете об использовании мультиплатформенных возможностей Flutter-а в повседневной жизни мобильного разработчика? Уже используете? Или, может быть, планируете? Ждем ответ в комментариях под этим постом. Если есть вопросы, не стесняйтесь — задавайте, постараемся ответить. Есть идеи для освещения? Милости просим, всегда рады услышать. Нашли ошибку? С кем не бывает…) Спасибо за внимание, увидимся совсем скоро, уже в следующей статье.