предисловие
Компонентизация — это единственный способ для любого приложения со сложными бизнес-сценариями и продуктами после нескольких итераций.Компонентизация относится к процессу разделения и реорганизации нескольких функциональных модулей при разделении сложных систем. Компонентизация должна делать не только разделение и разъединение модулей на поверхности, но за ней стоит большая работа по поддержке реализации компонентизации, например, стратегии разделения модулей в сочетании с бизнес-характеристиками, взаимодействием между модулями и т.д. и система строительства.
В этой статье в основном описывается, как приложение iQIYI Knowledge APP объединяет свои бизнес-характеристики для изучения и применения набора эффективных решений для компонентизации мобильных терминалов.
01 Предыстория и цели
1.1 Предыстория
iQIYI Knowledge в настоящее время имеет несколько носителей услуг, включая подключаемый модуль знаний мобильного приложения iQIYI, подключаемый модуль знаний мобильного приложения iQIYI iPad, подключаемый модуль знаний мобильного приложения Suike и независимое приложение мобильного терминала знаний iQIYI. Из-за разного времени работы каждого терминала выполняемые сервисные функции не полностью согласованы, что приводит к ситуации с несколькими наборами кодов на нескольких терминалах, а стоимость обслуживания высока. Во-первых, когда одни и те же или аналогичные функции необходимо итеративно модернизировать, разработку и тестирование необходимо проводить одновременно на нескольких концах, а стоимость возрастает в геометрической прогрессии; во-вторых, с быстрым развитием бизнеса бизнес-модули постоянно увеличиваются, а зависимости между модулями также становятся все более размытыми, а связанность и сложность кода увеличиваются, кроме того, станет очень сложно добавлять дополнительные бизнес-цели на основе существующих трудозатрат. Следовательно, это очень неблагоприятно для эффективной итерации бизнеса в долгосрочной перспективе. На следующем рисунке показана архитектура бизнес-модуля каждого конца знания iQIYI до компонентизации.
Из приведенного выше рисунка мы также видим, что на самом деле между каждым концом находится много общедоступных бизнес-модулей, а базовые модули поддержки каждого бизнес-модуля почти одинаковы.Поэтому, в сочетании с бизнес-характеристиками самого iQIYI Knowledge, мы предлагаем решение, подходящее для iQIYI Компонентное решение мобильного терминала Qiyi Knowledge.
1.2 Цели
Мы определяем цели компонентизации следующим образом:
· Решать проблемы обслуживания многотерминального кода
В соответствии с бизнес-характеристиками компоненты делятся по горизонтали и вертикали, повторяющиеся требования выполняются в единицах компонентов, а компоненты повторно используются на каждом конце;
· Решить проблему межкомпонентного вызова и маршрутизации между компонентами
Разделение бизнеса становится более четким, разделение между компонентами более тщательным, взаимодействие между компонентами более эффективным, исходные бизнес-модули извлекаются и интегрируются, а бизнес-границы между компонентами определяются;
· Повышение эффективности разработки и облегчение разработки и отладки
Компоненты можно компилировать и отлаживать по отдельности, чтобы разработчики модулей могли больше сосредоточиться на работе этого модуля;
· Повышение эффективности интеграции и тестирования
Какие компоненты необходимы для каждого конечного проекта, можно быстро интегрировать и протестировать непосредственно с помощью инструментов.
Основываясь на вышеуказанных целях, мы разработали стратегию разделения компонентов, подходящую для бизнеса знаний iQIYI. На следующем рисунке показана диаграмма функциональной архитектуры после компонентизации. Она разделена на основные компоненты, функциональные компоненты и бизнес-компоненты по горизонтали. Подразделение; с точки зрения Компоненты включают в себя не только функциональные SDK, но и бизнес-интерфейсы. Цель состоит в том, чтобы бизнес-модули были независимыми, с четкими границами и легко расширялись и поддерживались.
02 Общая техническая архитектура
Основанная на функциональной архитектуре техническая архитектура компонентизации знаний показана на рисунке ниже.
Нижний уровень — это базовые компоненты, в том числе baselib и componentService.Мы формируем базовые компоненты с общими реализациями нижнего уровня, такими как сетевые библиотеки, пингбэки, базы данных, журналы и классы инструментов, которые скрывают различия между системой и каждым концом, и находятся в нижнем слое функциональных и бизнес-компонентов. Все функциональные и бизнес-компоненты используют один и тот же набор базовых компонентов, что позволяет обеспечить единство общих частей. Базовые компоненты относительно стабильны и не часто повторяются.
Следующий уровень — это функциональные компоненты, такие как компоненты проигрывателя и истории, которые предоставляют возможности воспроизведения, платежные и маркетинговые компоненты, которые предоставляют платежные возможности, а также компоненты обмена и постера, которые предоставляют настраиваемые возможности обмена несколькими терминалами.Основные функции на каждом конце, функциональные компоненты расположены между базовыми компонентами и бизнес-компонентами, и функциональные компоненты будут итеративно обновляться в соответствии с потребностями бизнес-компонентов.
Далее следует бизнес-компонент. Этот уровень может содержать или не содержать основной бизнес-модуль. Для удобства разработки и обслуживания мы выделяем основной бизнес-модуль в бизнес-компоненты, такие как поиск, фильтрация, обнаружение потоков каналов, комментарии и оценки. ., работа работает и т. д. Бизнес-компоненты расположены на верхнем уровне базовых компонентов и функциональных компонентов, и итерации часты, но сам бизнес относительно самостоятелен и границы четкие.
Верхний уровень — это проект оболочки. Каждому концу нужен основной проект, отвечающий за интеграцию необходимых компонентов. Мы все вместе называем его проектом оболочки. Проект оболочки включает базовую структуру каждого конца, такую как логика регистрации и инициализации компонентов, зависимость от платформы логика обработки и т. д., а также существуют уникальные для каждого конца сервисные модули, которые не подходят для извлечения и разборки.
Справа находятся MoudleRouter и UIRouter, отвечающие за управление взаимодействиями и переходами между компонентами. Эта часть представляет собой общественную инфраструктуру, и все концы должны быть интегрированы.
Слева — система сборки, которая не входит в компонентный код, а принадлежит вспомогательной системе, отвечающей за сборку компонентов и пакетов приложений на каждом конце.
03 Реализация основной технологии
Двумя основными техническими моментами в практике компонентизации являются взаимодействие между компонентами и маршрутизация между компонентами.
3.1 Взаимодействие компонентов
Сложность взаимодействия между компонентами заключается в снижении степени связанности компонентов, а лучше всего добиться полностью ненавязчивых вызовов. После исследования способ использования ModuleManager на стороне iOS определяется как компонент службы самого низкого уровня.Каждый компонент должен предоставлять интерфейсы службы, вызываемые извне.Определение интерфейса существует в компоненте ModuleManager. Код ModuleManager не мешает коду других компонентов и отвечает только за анализ переданных данных и передачу сообщения вызова соответствующему компоненту.
Чтобы решить проблемы жестко закодированного URL-адреса и неясного типа параметра словаря, сторона iOS принимает схему протокола в схеме компонентизации.Когда программа начинает работать, она регистрирует свой собственный класс в ModuleManager и отражает протокол в виде строки в качестве ключа. , Класс соблюдает протокол и реализует методы, определенные протоколом. Внешний мир получает класс через протокол и создает его экземпляр как объект, а также вызывает метод протокола, реализованный на стороне службы. Время регистрации независимого приложения и каждого подключаемого модуля отличается. Независимое приложение — это запуск программы, а подключаемый модуль — внешний вызов подключаемого модуля. Когда подключаемый модуль закрывается, его необходимо отменить. для освобождения ресурсов. Схема протокола описывается следующим образом:
На стороне Android для взаимодействия между компонентами используется компонент ZRouter.Идея реализации аналогична реализации на стороне iOS.Она относится к механизму SPI (механизм предоставления услуг) в java.Каждый компонент предоставляет сервисный интерфейс службы. , а реализация интерфейса передается соответствующему компоненту. Когда компонент инициализирован и зарегистрирован, интерфейс службы и соответствующая реализация службы будут зарегистрированы одновременно. Когда бизнес-сторона использует его, ей нужно только вызвать функцию компонента через интерфейс службы. Таким образом, между компонентами нет прямой зависимости, а реализуется развязка и изоляция между компонентами. Конкретный вызов показан на следующем рисунке:
3.2 Маршрутизация компонентов
С точки зрения маршрутизации перехода между компонентами, на стороне iOS используется метод регистрации URL-адреса. Время регистрации делится на три типа: статическая, динамическая и отложенная загрузка. Метод отложенной загрузки заключается в проверке того, были ли зарегистрированы URL-адрес и имя класса и связанный при вызове метода перехода. , если он не связан, получить его из таблицы статической информации модуля и выполнить привязку регистрации. Обработчик может быть указан во время динамической регистрации, так что логика перехода может быть полностью настроена без прохождения через базовая унифицированная логика перехода. Обратите внимание, что сторона плагина должна освободить ресурсы и отменить регистрацию при выходе из плагина.
Для реализации перехода пользовательского интерфейса между компонентами на стороне Android, хотя упомянутый выше ZRouter также может переключаться между Activity, Fragment и View, реализация кода слишком сложна. Поэтому мы опираемся на прекрасную идею компонентизации в отрасли и специально разработали UIRouter для перехода пользовательского интерфейса между компонентами. Во время компиляции с помощью аннотации @RouterPath, добавленной к действию, создается таблица маршрутизации с ключом в качестве схемы или шорткодом страницы и значением в качестве действия. Переход любого действия передается структуре маршрутизации, которая определяет, какое действие следует запустить в соответствии с таблицей маршрутизации.
Чтобы повысить эффективность разработки и сократить повторяющийся код разработки во время инициализации UIRouter, мы разработали плагин gradle, который вставляет код автоматической регистрации, и использовали этот плагин для внедрения кода инициализации в указанный метод через ASM во время компиляции.
В то же время этот прием используется и при регистрации библиотеки компонентов, класс инициализации компонента добавляет память через отражение в режиме отладки, а регистрационный код вставляет через ASM в режиме выпуска. Таким образом, время компиляции может быть сокращено в режиме отладки для повышения эффективности разработки, а потребление, вызванное отражением, может быть уменьшено при работе в пакете официального выпуска.
Весь процесс оптимизации выглядит следующим образом:
04 Система сборки
Благодаря четкой иерархии компонентов быстрое создание компонентов и проектов стало необходимостью. Для компонентизации команда специалистов iQIYI разработала набор подсистем быстрого строительства, подходящих для компонентизации, на основе существующей системы построения компании.
Чтобы решить проблему совместного использования набора кода для нескольких терминалов и ограничения размера пакета на каждой стороне подключаемого модуля, разностный код, существующий в библиотеке компонентов, управляется макросегментацией для реализации изоляции разностного кода. При компиляции компилируется только один из указанных в данный момент терминалов.При упаковке кода задайте конфигурацию макроса, указав параметры упаковки для завершения построения указанного конца.
Каждый компонент на стороне iOS — это отдельный проект, управляемый разными приватными репозиториями git, каждый компонент интегрирован в основной проект через CocoaPods, а все компоненты интегрированы в основной проект как сторонние библиотеки. Хотя приложение iQIYI Knowledge APP и подключаемые модули на каждом конце используют решение для интеграции Cocoapods, они различаются в зависимости от версии.Чтобы повысить эффективность разработки, приложение Knowledge, как независимое приложение, напрямую использует метод указания тега хранилища git. число, на которое следует полагаться Библиотеки компонентов и подключаемые модули должны устанавливать зависимости через podsec библиотеки подключаемых модулей для интеграции библиотеки компонентов.Для этого требуется, чтобы библиотека компонентов была преобразована в двоичный файл библиотеки и загружена в облако, а podspec библиотеки компонентов загружается в частную библиотеку. Сторона подключаемого модуля iOS интегрирует компоненты в основной проект двумя способами: исходный код и инфраструктура.На этапе разработки и отладки используется метод исходного кода, и код может быть напрямую изменен для завершения разработки по требованию. упаковка, тестирование и публикация, фреймворк используется для ускорения процесса.Скорость компиляции не раскрывает исходный код внешнему миру.
Сторона iOS выбирает Jenkins в качестве системы сборки.На начальном этапе компонентизации построение наших компонентов завершается сначала созданием самых основных компонентов, а затем созданием компонентов верхнего уровня для завершения общей конструкции.По количеству увеличивается количество библиотек компонентов, зависимости становятся более сложными Ручной запуск сборок по одной стал проблемой в процессе сборки, поэтому мы начали оптимизировать сборку, внедрили плагин ParameterizedTrigger для Jenkins и использовали его со сценариями оболочки, чтобы мы можем поддерживать единую сборку компонентов и запускать несколько компонентов при сборке основного проекта.Когда компонент создается отдельно, он также поддерживает настройку проекта, который зависит от сборки, что реализует завершение сборки всех компонентов за один раз. время.
При сборке библиотеки компонентов код текущей ветки итерации будет проверяться на наличие обновлений.Если есть обновление, будет построена библиотека компонентов.Если обновления нет, сборка будет пропущена напрямую. С увеличением числа терминалов система сборки поддерживает многотерминальное построение.Плагин iPhone и подключаемый модуль iPad представляют собой разные подключаемые модули, и построение завершается путем различения терминалов с помощью сценариев. Система сборки также реализует автоинкремент версии и сборку по времени.Номер версии в файле podspec будет обновляться после каждой сборки.Если версия сборки не указана вручную в следующей сборке, предыдущая версия будет получена и добавлена одним для достижения автоинкремента версии. Система строительства подключается к системе обмена мгновенными сообщениями внутри предприятия, и после завершения строительства подписавшимся пользователям отправляется уведомление. Следующая диаграмма описывает процесс сборки компонента:
Со стороны Android каждый бизнес-компонент также является отдельным приложением, которое может работать как независимое приложение и должно соответствовать требованиям отдельной работы и тестирования, что может повысить скорость компиляции и эффективность разработки.
В настоящее время общепринятой практикой в отрасли является то, что каждый компонент представляет собой проект, который управляется константой в build.properties для различения различных сценариев, а наборы источников в build.gradle задают конфигурацию при отладке компонентов по отдельности, что отличается из независимой среды выполнения при выпуске компонента aar.configure;
Однако это решение не в полной мере применимо к клиенту знаний iQIYI, поскольку основной целью нашей компонентизации является достижение многотерминального повторного использования компонентов, что также потребует многотерминальной адаптации.Информация о конфигурации, базовые стили пользовательского интерфейса и т. д. отличаются , и настроить их в каждом новом компонентном проекте невозможно. Поэтому в качестве проекта для отладки компонента используйте непосредственно проект оболочки исходного проекта хаоса, задайте папку runalone в соответствующем проекте оболочки, управляйте режимом компиляции через константу isModuleType в корневом каталоге build.properties и динамически загружайте компонент. зависимости, необходимые для теста, чтобы можно было тестировать компоненты по отдельности в каждой среде.
Независимый от компонентов режим отладки в настоящее время фактически эквивалентен режиму разработки оболочки компонентов в идеальном состоянии: только небольшой объем кода, связанного с конфигурацией, никакой другой независимой от компонентов логики страницы и динамическая загрузка компонентов по запросу.
Корневой каталог проекта оболочки gradle.properties содержит различные константы, включая управление терминалом, номер версии библиотеки компонентов, управление средой компиляции, управление зависимостями во время выполнения и параметры управления режимом работы.
isDependenceMaven используется для управления тем, является ли режим зависимости исходным кодом или удаленным maven.Во время разработки отладка может использовать режим исходного кода для облегчения отладки, а формальная среда использует режим удаленной зависимости для экономии времени компиляции и облегчения повторного использования.
maven_version используется для унифицированного управления номером версии компонента.При обновлении каждой версии соответствующая обновленная версия библиотеки компонентов и версия зависимой библиотеки компонентов компилируются, загружаются и обновляются пакетами с помощью пользовательского сценария загрузки maven_publish.
Для версии Android SDK и версии сторонней библиотеки мы единообразно извлекаем ее в файл dependencies.gradle на внешнем уровне для унифицированного управления, чтобы можно было удобно и интуитивно управлять номером версии.
Резюме и перспективы
Мобильный терминал iQIYI Knowledge в основном достиг всех целей компонентизации, и границы бизнеса между компонентами стали очень четкими, он получил многоцелевые преимущества от обновления одного компонента и значительно повысил эффективность разработки и тестирования. Кроме того, гибкое добавление и удаление компонентов делает стоимость добавления нового носителя службы очень низкой.Необходимо только объединить существующие компоненты и изменить компоненты для этого нового конца, чтобы мобильный терминал iQIYI Knowledge мог достичь меньшего рабочая сила Способность поддерживать больше целей. Некоторые проблемы, возникающие в процессе компонентизации, были полностью решены.В настоящее время компонентизация запущена от базовых базовых компонентов до бизнес-компонентов верхнего уровня, а компонентная система построения также внедрена в производственную среду.
Конечно, компонентизация не достигается в одночасье, это непрерывный процесс, и в будущем потребуется постоянная оптимизация и совершенствование, чтобы компонентизация играла большую роль в развитии бизнеса знаний.
i Технологический соус Ции[Воздействие] Бог операция хардкорных игроков, на шаг впереди не мечта. Дважды коснитесь в любом месте экрана двумя пальцами, зрелище станет для вас еще более захватывающим! #технологии расширяют возможности развлечений #спектакль #amway #openingbox #черная технология @iqiyi video account
Может быть, вы все еще хотите увидеть
Эволюция решения для динамических компонентов iQIYI Page