作者：醉仙

随着优酷业务的快速发展，随之而来的是模块数量的爆发式增长，基本每年以大量新增模块的速度增加，到目前为止优酷已经有非常庞大的模块依赖。模块之间通信往往是相互直接依赖调用，以至于耦合十分严重且混乱，每一个库依赖都是一颗“树”，甚至于一张“网”，对日常研发造成很多困扰：

插件化落地结果

iOS 模块插件化已经全面在优酷落地，沉淀出各业务线的轻量工程，大量的业务及架构插件，后续可根据不同业务需求，自由组装插件工程。以下是目前插件化工程落地后的一些收益：

• 直接收益

• 业务插件工程编译效率提升 显著，本地编译时间大幅降低，相关全部开发已使用起来；

• 通过插件组装生成业务插件工程，插件工程支持模拟器编译调试，并支持热重载；

• 模块工程和整包工程均使用插件作为依赖，彻底解决模块工程和整包工程依赖模块版本不一致情况，并支持依赖模块版本自动更新；

• 业务插件工程依赖库数量大幅减少，且 pod 直接复用缓存，大幅提升 pod 成功率及速度，磁盘占用大幅减少；

• 间接收益

• 可提供运行内存、app 启动、功耗等插件卡口，常态化保持良好的用户体验；

• 所有插件支持自由组装，通过配置中心，提供快速孵化极速版、国际版、Apple Watch、Apple TV 等 App 的能力；

• 依赖减少，swift 断点调试时的 module 树快速生成，断点效率提升；

• 提速打包效率，建立插件工程构建平台，测试同学使用平台动态配置生成插件组合安装包即可进行测试。

插件是什么

• 插件是由一组模块聚合而成，同时也可依赖其他插件。在物理上，插件是一个文本描述文件，描述其包含的模块和插件信息；

• 插件基于 Xcode 工程，可独立编译并生成 App 产物，支持多插件自由组合。

简单插件

一个简单的插件可以仅由一个模块组成。

# 图片库插件target 'Plugin' do       #模块A    pod '模块A','5.9.4' end

复杂插件

一个复杂插件可以由一个或多个插件和模块组成。

# 插件target 'Plugin' do    # 图片库插件    plug '1.图片库插件'      #webp图片解析模块    pod '模块B','0.1.4'     #webp基础模块    pod '模块C','1.1.0.1' end

为什么需要插件

和多个业务团队同学沟通后，我们发现大部分的业务在功能调试时，往往只关注涉及到自己需要迭代的业务功能，对于其他业务并不关心。于是我们想到可以基于整包工程，裁剪出一个只有单业务功能的 APP，这样编译速度肯定会有极大的提升。

裁剪 APP 需要对模块进行解耦，如果按模块颗粒度进行解耦，巨量模块进行解耦人力成本过高，而且过大的改动也会对线上稳定性有较大的影响。于是我们对解耦粒度进行了放大，从模块解耦粒度放大到以插件为粒度进行解耦，这样我们只需要解耦插件和插件之间的横向耦合关系，插件允许向下依赖其他插件，且插件内部模块也允许相互耦合，这样极大的的降低解耦的人力成本，也方便后续以插件维度进行依赖关系进行维护。

插件使用规范

插件聚合原则

• 业务插件：业务模块按业务功能维度划分边界，聚合成业务插件；

• 通用业务插件：通用业务模块按业务可复用最小集划分边界，聚合成通用业务插件；

• 架构功能插件：集团中间件模块、优酷中间件模块，按功能最小集划分边界，聚合成架构功能插件。

插件依赖原则

• 业务插件不允许横向依赖其他业务插件，允许依赖下层插件；

• 架构层插件不允许依赖上层插件，允许依赖下层插件及其他架构插件。

模块归属原则

• 一个模块仅能归属到一个插件，需要明确模块的职能；

• 同一个模块被多个插件依赖，需要考虑下沉该模块为插件；

• 一个模块可以写成一个插件。

插件版本原则

• 每个插件没有版本的概念；

• 一个集成区的模块和版本对应一套插件中的模块和版本；

• 一套插件中的模块和版本默认和线上版本的集成区一致，也可设置并同步到最新集成区或历史集成区。

插件层级大图

基于以上插件的概念和使用规范，我们对优酷 APP 架构进行插件化改造，从集团中间件到业务层，自下而上解耦聚合模块形成插件，最终沉淀了大量插件和如下层级的 APP 架构。

• 业务实现层：对优酷现有的业务进行插件化改造，聚合成多个通用业务插件，通过业务插件和其依赖的通用业务插件、架构功能插件等少量插件，能快速组合出一个轻量级业务 APP，用于提升业务 Pod 速度和开发调试速度；

• 业务接口层：对优酷现有的业务进行横向解耦，形成多个业务接口插件，支撑上层业务插件横向解耦；

• 通用业务插件：通用业务模块按业务可复用最小集划分边界，聚合成通用业务插件；

• 架构功能插件：集团中间件模块、优酷中间件模块，按功能最小集划分边界，聚合成架构功能插件。

低成本管控方案

优酷所有模块已经完成插件化改造，为了保障在后续版本迭代过程中，防止工程腐化，制定了一套低成本管控方案，可以自动更新插件内容，管控插件依赖关系。

插件自动更新

插件内容主要包括模块名称和模块版本号，每次版本迭代，插件都面临插件中模块的新增、删除、名称变更、版本变更等问题，优酷每个版本集成大量的模块，如果全部人工手动维护，成本将非常巨大，所以我们部署了一套自动同步及巡检服务，主要有以下目的：

• 插件中新增、删除模块自动更新；

• 插件中的模块版本号自动变更；

• 插件内容更新完成自动对所有插件进行编译巡检；

• 如果巡查通过，插件合并到插件工程集成分支提供给业务插件工程使用；

• 如果巡查失败，钉钉通知失败信息（失败插件名称、编译失败日志链接、插件新增模块提示）到钉钉群，方便快速排查问题。

插件依赖管控

我们基于插件的归属和层级，抽象出标准的模块依赖关系数据，然后在模块构建打包时，增加依赖检测卡口，在每次模块构建过程中，执行依赖检测卡口，只有通过依赖检测的插件才能打包通过。

结果数据呈现

构建提效

业务插件工程本地编译效率对比整包工程：

• 本地编译效率得到极大的提升，平均提效显著，本地编译时间大幅降低，相关全部开发已使用起来。

计算公式：

• 编译提效公式：本地编译提效 = (整包工程构建时长 - 业务插件工程构建时长) / 整包工程构建时长

• 节约时间公式：每月节约编译时间(8 小时工作日) = 插件工程月编译次数 * 平均单次编译节约时间(秒) / (60 * 60 * 8)

模拟器支持

优酷存在部分模块不支持模拟器，导致优酷整包不支持模拟器，插件化改造后，业务在通过插件组装自己业务调试工程的时候，剔除这部分不支持模拟器的插件，使得业务插件工程可以使用模拟器进行调试。模拟器优势：

• 一个企业号真机调试限制 100 台设备，而模拟器无限制；

• 模拟器支持所有 iOS 系统，针对一些旧系统开发和测试成本低；

• 模拟器支持热重载，无需编译和重新运行，修改代码保存即生效；

• 提前适配 iOS 新机型 UI。

磁盘占用

在模块插件化改造前，我们只能使用整包工程进行开发，使用整包工程进行日常开发的时候，需要将所有模块下载，而插件化改造完成后，我们从整包工程拆分出了多个业务插件工程，插件工程的模块数量相比整包工程大幅减少，插件工程的磁盘占用相比整包工程大幅减少。下图是整包工程和部分业务插件工程磁盘大小对比：

内存占用

插件化可提供运行内存、app 启动、功耗等插件卡口，常态化保持良好的用户体验，以播放页的运行内存为例，播放页有播放器、页面容器、弹幕、评论等功能，以前是对整个播放页计算内存值，而现在可以按照细碎的功能来计算内存值，分别得到播放器插件、播放页容器插件、弹幕插件、评论插件的内存值。

结语

综上所述，iOS 工程插件化是运用分而治之的思想，把一个复杂的 App 分成多个子 App。通过子 App 可将研发聚焦于需求研发和用户体验提升上。同时，插件化的拆装特性也提高了线上可复现问题的排查效率。因此插件化对研发效率以及开发幸福感的提升都是非常有帮助的。

关注【阿里巴巴移动技术】，阿里前沿移动干货 &实践给你思考！