App工厂架构设计及在58集团应用

1. App工厂架构设计及在58集团应用彭飞 58集团-高级架构师 2022-08-18

2.

3. • Part1：App 架构变迁 —— 不同场景下的架构设计 • Part2: App 工厂架构设计—— 方法论与工具设计 • Part3: App 工厂在58实施经验—— 聚焦实践中具体问题 • Part4: App工厂后续思考和规划—— 业务导向+更为深入

4. PART 01 App架构变迁

5. • 单团队单App架构：研发效率、需求完成度是主要矛盾（人少、活多、迭代快） Hybrid React Native Flutter 组件架构，实现业务复用！跨平台-研发效率！ 5

6. • 多团队单App架构：部门协同研发效率是主要矛盾（人多跨部门、业务代码独立与相互干扰）基于工程组件的架构！代码隔离、代码复用、代码编译速度！

7. • 多团队多App架构：公共垂直业务多app复用+ App快速生成代码复用、体验统一、流量共享房产招聘公共业务到家服务   下沉业务支持Native代码、跨平台代码支持公共垂直业务近0成本复用

8. PART 02 App工厂架构设计

9. • App工厂研发背景与目标催生 2.业务的扩大与细化催生 3.业务的合并融合催生目标1:支持标准化能力的产出 1.业务的快速试错目标2:支持子App的生成迭代目标3:支持垂直业务平移技术收益：一套代码多APP复用，降本提效！ 9

10. • 58App架构现状与问题 & 基于问题的解决方案核心问题：工程代码耦合使得在业务平移时携带过解决思路：工程级别解耦，使得在业务平移时能多无关代码，增加迭代成本+无法控制包大小。按需配置所依赖的代码！

11. • App工厂架构设计架构依赖准则：  1.上层可以依赖下层，但下层不可以依赖上层。比如房产组件可以依赖微聊组件，反之不可以；  2.可以隔层依赖。比如业务 pod可以依赖基础库pod；  3.业务pod间不能产生依赖。比如房产pod不能依赖招聘pod；  4.中间件pod和基础库pod可以在同一层级单向依赖。比如 RN组件可以依赖跳转组件。

12. • 如何支持垂直业务平移&创新App生成如何支持子App快速生成 12 如何支持垂直业务平移

13. • 组件解耦如何恰如其分把握好度？解耦方案耦合类型架构耦合耦合复杂度逐步升高（组件分层的问题）职能耦合准则：分层依赖难点1：工程上全面重塑基于Coc oa p od s 依赖管理准则：单一职能工程上全面重塑（同层组件依赖问题）难点2：组件粒度的把控引用耦合准则：高内聚、低耦合（逻辑、数据耦合问题）难点3：改动⻛险最小上浮、下沉拆分、聚合接口隔离 URL路由核心准则：基于App 工厂⻓远⺫标，根据业务要求按需解耦，逐步迭代解耦成本逐步升高

14. 架构耦合：基于组件依赖准则，工程上全面重塑 •  架构耦合，指不同层级组件耦合以及依赖不规范；  组件分层，特别是中间件根据具体业务场景而定 1. 组件和代码工程库物理上和逻辑上一一对应 2. 解决组件循环依赖、下层组件依赖上层组件等问题 3. 组件依赖标准化（PodSpec设置），依赖生成自动化 4. 壳工程设置直接依赖组件，一键生成所需工程代码

15. • 引用耦合-基于接口隔离  更加轻量，聚焦支持面向接口的消息通讯  支持基于注解的注册，使用更加轻便和灵活，支持接口及实现类的一对多关系  支持多种状态的生命周期控制（方法体内/容器内/APP应用内）  从代码编译层面解除了编译耦合；  与方法调用通讯、基于路由通讯有机结合，灵活使用；  在业务中间件和标准中间件中应用广泛  例如：Hybrid 框架中的Url白名单

16. • 依赖分析工具：如何自动化分析出工程组件依赖关系？ 1.分析代码文件依赖关系 2.分析代码文件与工程组件从属关系 3.建立工程组件之间依赖关系代码文本匹配法：基于字符串匹配import等关键字文件 Clang插件：基于AST解析代码文件依赖关系依赖分析 Mach-O技术：基于Mach-O解析文件依赖关系（WBBlades开源：https://github.com/wuba/WBBlades）

17. • 防劣化工具：解耦后的工程组件如何避免污染？污染检测依据：一种有向无环图业务组件污染检测业务中间件污染检测标准中间件污染检测

18. • 包大小治理工具：如何高效产出以工程pod为维度的包大小报告？ 1.剔除架构 2.剔除bitcode中间信息静态库、动态库模拟链接 Mach-O文件 3.剔除debug信息 4.剥离符号表更加高效维护成本低结果更精准无需编译支持业务扩展资源文件预处理

19. • App工厂中台能力一套代码多App复用业务架构工具 20+标准中间件 App工厂架构准则依赖分析防污染劣化符合准则的组件包大小业务驱动架构，多App场景下降本提效！ 1套架构 2种App 支持 5大垂直业务 30+业务中间件 3种自动化质量工具 4类核心问题兼容方案 2万多可复用类

20. PART 03 业务应用

21. • App工厂首个实施项目：房产业务在同城App、安居客App实现一套代码复用技术背后的业务目标驱动？租房二手房房产新房    商业地产一套代码，双app无缝平移业务迭代成本低，不增加研发资源平移后包大小极限控制，不携带无关代码

22. • 项目里程碑 1个半月，跨2个版本 1个半月，跨2个版本 1个半月 App平台提供垂直业务所需公共库里程碑1 58App接入上述公共库安居客App接入上述公共库 2个月，跨3个版本北京房产业务改造，实现双 App平移可并行里程碑2 2个月，跨3个版本上海房产业务改造，实现双 App平移可并行里程碑3 里程碑4 里程碑5

23. • 实施方案关键：短期的低风险还是长期的一劳永逸？业务层  基于适配层的单业务短期方案：  不动底层代码，对其它业务无影响  适配层开发量巨大，迭代成本高，不能支持创新app 中间件层基础库层   每增加1个App，将增加1倍的开发量  每增加1个业务，将重复进行上述开发基于底层统一的多业务长期方案：  统一底层，短期成本高，涉及整个App  支持创新app和垂直业务，一劳永逸  增加App和业务，随着架构和组件的完善，开发量逐步减少

24. • 一团乱麻的耦合，从何处入手成本最低？   从中间件层开始解耦组件：  不分析上层业务代码引用  从组件本身功能属性出发  需要一次性解耦所有中间件  上线后的不可控性增高从业务层开始解耦组件：  分析业务所依赖的代码工程  不“过度”考虑组件聚合、松散耦合  按需进行解耦，只解耦业务依赖部分  上线后的稳定性有保证

25. • 组件改造案例：Hybrid中间件  业务代码依赖的底层代码差异大，需要谨慎设计、反复沟通，以达到方案最优；  涉及到的中间件包括 Hybrid、RN、网路、跳转、缓存、埋点等10多个核心中间件；  解耦过程中需以业务代码改动与影响为最小目标；  解藕过程需严密考虑业务的双向平移；

26. • 组件改造案例：跳转中心组件  垂直业务平移过程中，跳转协议不兼容导致不能跳转  针对垂直业务统一跳转协议与跳转中心  独立App之间跳转协议方案差异较大，只能留其一  针对非垂直业务，各App短期保留各自逻辑

27. • 公共数据统一问题：http请求header和cookie统一  不能无差别合并参数集合，需要考虑header头大小（与后端安全策略有关）；  业务获取header参数耦合度高，修改参数名称对业务带来高成本；  需要考虑App间业务双向平移以及后期业务的扩展；  解决方案：统一参数集合，针对垂直业务，参数获取接口隔离，迁入App独立实现。

28. • App间公共交叉业务兼容问题  业务场景：  电话拨打、浏览筛选、分享收藏等App行为记录数据  不同App展现这些记录的终端界面功能不同，属于App独有功能  但App独有功能依赖公共业务（拨打收藏等）产生的数据  解决方案：  定义一套通用数据接口  个性化业务只能通过通用数据接口获取垂直业务产生的数据  接口实现类各独立业务分别实现，配置中心动态决定业务调用的接口实现类

29. • 支持房产垂直业务平移+研发提效

30. • 支持下沉市场业务平移 +研发提效

31. • 包大小收益计算方法：计算方法：租房依赖的中间件大小（19.3MB） +租房依赖的基础库大小(84.0MB) 同镇县域改造接入的中间件大小（7.3MB） -安居客接入App工厂的中间件大小(4.7MB) +同镇县域改造接入的基础库大小(56.5MB) -安居客接入App工厂的基础库大小(49.0MB) =63.8MB/245.8MB（V10.8.5）= 26% =49.6MB/134.7MB（V15.9.1）= 36.8%

32. • 支持创新app研发提效

33. PART 04 一些思考和规划

34. • 研发成本降低了，测试成本成为主要问题中间件定制业务场景：  通用UI库升级，如导航栏、弹框、相册选择  通用header、cookie等数据升级  支付、微聊、认证、多媒体能力升级  动态库懒加载能力等统一能力升级解决方案：  规避某个单一定制业务需求带来中间件升级，给其它业务带来的测试成本最差情况测试成本：某个底层功能测试成本*8大业务*5大App  理论上可大大降低非关联业务测试成本  接口隔离、松散耦合

35. • 其它思考 1.进一步降低测试成本 •能否做到一定比例底层代码升级不用上层业务测试？ 2.进一步提升组件复用效率 •与业务协同，将事业部下的业务拆分的更细、可复用 3.进一步提升性能治理能力 •以工程组件为维度，在启动时间、页面加载速度、崩溃、卡顿等性能上进行精细化治理关键还是以业务为导向，服务好业务的发展！

36.

37.

38.

39.