Free Fish Technology-Камбоджа Супер
С появлением кросс-энд фреймворков, таких как Flutter, студентам, изучающим бизнес-разработки, часто требуется кросс-энд бизнес-разработка и выявление проблем на Android/IOS. Построение новой и незнакомой среды всегда будет сталкиваться с различными проблемами, что приведет к провалу построения, особенно среды разработки IOS, которая является наиболее сложной.Не только громоздкость построения среды, но и скорость упаковки после ветвления работает очень медленно, поэтому мы разработали и внедрили два инструмента для оптимизации процесса разработки Xianyu IOS.
Проблемы с опытом разработки IOS
Сложность создания среды разработки
-
Среда разработки зависит от конкретной версии ПО, а конфигурация сложна
Проект Xianyu IOS опирается не только на XCode, но и на два инструмента управления пакетами: taobaoenv 1.2.0 и Cocopods 1.2.0. По общему опыту, эти два инструмента имеют меньше проблем в ruby2.3.x. Определенные версии программного обеспечения, конфликтующие версии собственного программного обеспечения системы, настройки переменных среды и т. д. приводят к созданию сложной среды, и вам нужно попросить разработчиков IOS сделать это.
-
сложно поддерживать
После обновления системы Mac у Cocopod возникли проблемы, и ему пришлось перестраивать среду разработки. Конкретные причины также различны: системные переменные окружения изменились, так что конкретная версия ruby не может быть найдена; ruby обновляется вместе с системой, так что Cocopod нельзя использовать и его нужно переустанавливать; версия Gem проблемы; проблемы с исходным кодом Ruby и т. д. Это также приводит к тому, что многие разработчики не решаются легко обновить систему и не могут вовремя опробовать функции новой системы.
-
Pod зависит от большого количества загрузок
Из-за принципа работы самого Cocoapod, когда модуль обновляет и загружает зависимости проекта, он загружает информацию о файле каждой версии, и общий объем очень велик. Взяв в качестве примера проект Xianyu IOS, необходимо загрузить около 20 ГБ файлов кеша, и большинство из них представляют собой небольшие файлы размером в несколько К. Время загрузки может длиться более десяти часов, что приводит к очень долгому времени. от построения новой среды до первого опыта.
Упаковка приложения выполняется медленно после сегментации
Когда разработчики работают в нескольких ветках/версиях, им часто приходится переключаться между ветками для отладки и исправления ошибок. Но после переключения веток время упаковки всего IOS проекта составляет около 30-40 минут. Иногда, чтобы исправить ошибку в версии, приходится переключать ветки, а затем переупаковывать и отлаживать. Исправление и проверка ошибок может занять всего пять минут, но упаковка занимает более 30 минут, а ввод и вывод непропорциональны.
Чтобы решить эти существующие проблемы, мы провели серию исследований и поделились ими с вами. Мы также приветствуем лучшие решения.
Создание среды IOS
Непрерывное развитие технологии виртуализации дало нам новые идеи по унификации среды разработки на стороне терминала.Мы полагаем, что если среду разработки IOS можно отделить от Mac, а также легко портировать и повторно использовать, то первая и вторая проблемы будет решаться легко. Для этого мы предприняли несколько попыток:
Решение для виртуальной машины
Создайте виртуальную машину локально на MacOS и установите систему MacOS. Создайте среду разработки IOS на виртуальной машине, а затем осуществите миграцию среды разработки IOS с помощью копии образа виртуальной машины, чтобы решить проблему построения среды.
В этой схеме есть несколько проблем:
А. Проблемы с производительностью. Процесс компиляции IOS является операцией с интенсивным вводом-выводом и процессором. Виртуальная машина проходит через диск и ЦП виртуальной хост-системы, и производительность будет значительно снижена, что приведет к увеличению времени компиляции и влияет на опыт разработки.
б. Вопросы безопасности. Чтобы установить виртуальную машину на рабочую машину Mac, вам необходимо пройти аудит безопасности компании.
в) Проблема с черным яблоком: система Mac на виртуальной машине не авторизована, что может привести к пиратству и нарушению прав.
Виртуальная машина — это относительно тяжелая технология виртуализации, поэтому мы обратимся к более легкой технологии Docker.
Полностью докеризованный
Докеризируйте все программное обеспечение и переменные среды, от которых зависит разработка IOS. Портирование среды разработки IOS осуществляется через docker-образ. Руби-подобные инструменты, такие какcocopod, taobaoenv и т. д., благодаря кроссплатформенным характеристикам ruby, могут быть легко перенесены в docker. Но для XCode, который сильно зависит от MacOS, мы пытаемся заменить его на xcbuild, созданный Facebook. Это инструмент компиляции, совместимый с xcodebuild, и в Интернете действительно есть несколько пользователей сети, которые используют это программное обеспечение для создания среды компиляции IOS.
В этой схеме есть несколько проблем:
А. Совместимость между Xcbuild и Xcodebuild не может быть оценена
б) После обновления xcode, в течение периода времени, когда xcbuild совместим с обновлением, он может только вернуться к исходному решению для разработки и переключать среду разработки туда и обратно, что приводит к ухудшению работы.
Ни одно из двух вышеперечисленных решений не решает проблему переноса и разделения среды разработки IOS очень хорошо, но в полной попытке докеризации мы обнаружили, что наиболее сложная часть установки и настройки Cocopod и Ruby может быть докеризирована. требуется настройка, поэтому мы разработали и внедрили компромиссное решение: разработка на хосте (частичная докеризация)
Разработка на хосте (частично докеризованная)
В этом решении работа по разработке, компиляции и отладке по-прежнему выполняется локально в MacOS с использованием xcode, а конфигурация программного обеспечения и переменных среды, связанных с Cocoapod и taobaoenv, докеризована. Это не только следует последовательному опыту разработки студентов-разработчиков, но также принимает во внимание переносимость среды разработки. 
Чтобы разрешить распознавание файлов зависимостей, извлеченных Coapod в Docker, и сгенерированный проект модуля, локальный XCode, мы монтируем локальный каталог кеша модуля в докер, чтобы зависимости, извлеченные модулем, могли быть обновлены в докере и также может быть доступен XCode в MacOS, как показано на следующем рисунке (унифицированный терминал плоскости программирования + схема архитектуры программного обеспечения Faas):
Это не только упрощает создание среды разработки, но и помогает учащимся, которые хотят попробовать себя в разработке для IOS, быстро создать среду, а также дает учащимся, занимающимся разработкой, уникальный опыт. И благодаря этому решению наша среда разработки IOS может быть легко перенесена в среду разработки каждого одноклассника, а также может быть обновлена и преобразована единообразно.
Это решение переносит зависимости, связанные с Pod, в Docker, который отделен от MacOS, поэтому разработчики IOS могут свободно обновлять системы Mac, не беспокоясь о разрушении среды разработки, что решает проблему сложного обслуживания.
Чтобы решить проблему, связанную с тем, что большое количество зависимостей модуля необходимо вытащить во вновь созданную среду, мы загружаем локальные промежуточные файлы модуля на облачный диск OSS (синий облачный диск OSS на картинке выше). разработчикам нужно только один раз загрузить сжатый пакет и распаковать его локально, а затем добавочные обновления в порядке.
Проблема со скоростью упаковки приложения после ветвления
Студентам, изучающим клиентскую разработку, часто приходится развивать бизнес в нескольких филиалах (версиях), и им часто приходится переключаться туда и обратно для развития бизнеса и выявления проблем. Это приводит к одной из проблем: когда разработчики переключаются с ветки A на ветку B, приложение необходимо переупаковывать, и весь процесс занимает около 30-40 минут.
Проанализировав процесс упаковки проекта Xianyu IOS, мы разделяем трудоемкий процесс на два этапа: работа с модулем и компиляция XCode. Оптимизация скорости упаковки также будет проводиться в два этапа:
Ускорение работы модуля
Основная задача установки/обновления Pod — чтение Podfile, контроль версий зависимостей и разрешение конфликтов, а также создание проекта Pod. Сгенерированные связанные файлы хранятся в каталоге Pods и в Pods.xcodeproj. При переключении обратно на предыдущую ветку подфайл часто не меняется, поэтому регенерировать проект пода — пустая трата времени.
После тестирования, если мы сохраним эти промежуточные файлы после многократного переключения ветвей, эти промежуточные файлы все еще могут восстановить предыдущий проект Pod, что позволяет избежать этапа регенерации проекта Pod после ветвления, экономя около 10 минут накладных расходов.
Оптимизация скорости компиляции XCode
Для оптимизации скорости компиляции XCode в Интернете есть множество решений, которые можно условно разделить на три категории:
- Ускорение, зависящее от компилятора Cocoapods:
Например, Cocopods-packager может упаковывать зависимости модулей в статические библиотеки, а проекты IOS вводят зависимости модулей в виде статических библиотек, экономя время на повторную компиляцию.
Но и у этого решения есть некоторые проблемы, очень хлопотно обновлять приватные библиотеки и сторонние библиотеки, и каждый раз нужно переупаковывать статическую библиотеку и заливать в репозиторий кода, и сложно отлаживать исходный код
- Распределенная компиляция: например, distcc
Принцип распределенной компиляции заключается в том, чтобы распространять файлы, которые необходимо скомпилировать, на другие машины в кластере компиляции для компиляции, а затем возвращать скомпилированные двоичные файлы. Затем собственный компилятор связывает эти двоичные файлы вместе. Распределенная компиляция, очевидно, ускоряет большие проекты, но для небольших проектов она замедляет скорость компиляции.
- Кешировать промежуточные результаты компиляции: CCache, BUCK
Более обширная схема ускорения заключается в кэшировании промежуточных результатов компиляции, таких как CCache, Buck и т.п. Подробная информация по этим схемам есть в Интернете, поэтому я не буду повторять их по порядку. Однако внедрение этих решений требует трансформации текущего проекта IOS и даже привычек разработки пользователя, поэтому оно не соответствует нашим требованиям. Но схема кэширования промежуточных результатов компиляции нас вдохновляет:
Мы знаем, что XCode имеет возможность инкрементной компиляции, которая фактически использует промежуточный продукт предыдущей компиляции.При повторной локальной компиляции, если обнаружено, что файл не изменился, файл будет проигнорирован.Если метка времени исходного файла обновляется, то файл будет проигнорирован.Перекомпилируйте этот файл, потому что исходный код каждого изменения является небольшим, так что цель ускорения компиляции может быть достигнута.
Для проекта Xianyu IOS, если мы сохраним промежуточные продукты, скомпилированные текущей веткой IOS, перед вырезанием ветки, а затем восстановим промежуточные продукты, сохраненные ранее, при переключении обратно на текущую ветку, сможем ли мы запустить инкрементную компиляцию XCode? Это правда.
конкретный план:
-
Кэшируйте проект Pods текущей ветки, проект Flutter и скомпилированные промежуточные продукты, Podfile.lock, карту ссылок и другие связанные файлы перед разделением.
-
переключить ветку
-
промежуточные продукты, которые были закэшированы перед восстановлением новой ветки
-
Переупакуйте приложение IOS.
С помощью этих двух шагов оптимизации мы сократили время упаковки проекта Xianyu IOS после разветвления с 30-40 минут до пяти минут, а эффективность повысилась почти в шесть раз.
**Суммировать**
Сложные и трудоемкие этапы построения среды IOS значительно сокращаются за счет оптимизации образа докера и кеша, и новичок в IOS может выполнить их в основном за три часа.
В то же время за счет кэширования и повторного использования промежуточных продуктов, созданных в процессе упаковки, время упаковки после переключения веток контролируется в пределах пяти минут, что сокращается до одной шестой от исходного, что повышает эффективность разработки.