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

单团队单App架构：主要矛盾是研发效率和需求完成度，通过组件架构实现业务复用，采用Hybrid、React Native、Flutter等跨平台技术提升研发效率。
多团队单App架构：主要矛盾是部门协同研发效率，采用基于工程组件的架构实现代码隔离、复用和编译速度提升。
多团队多App架构：主要矛盾是公共垂直业务多App复用和App快速生成，通过App工厂架构实现代码复用、体验统一和流量共享，支持Native和跨平台代码，以及公共垂直业务的近0成本复用。

研发背景与目标：App工厂旨在支持标准化能力的产出、子App的生成迭代和支持垂直业务平移，通过一套代码多App复用降低成本、提升效率。
58App架构现状与问题：核心问题是工程代码耦合导致业务平移时携带过多无关代码，增加迭代成本和无法控制包大小。
解决方案：通过工程级别解耦，按需配置业务平移时依赖的代码。
App工厂架构设计原则：
- 上层可以依赖下层，下层不可以依赖上层。
- 可以隔层依赖。
- 业务pod间不能产生依赖。
- 中间件pod和基础库pod可以在同一层级单向依赖。
支持垂直业务平移和创新App生成：
- 组件解耦需把握好度，避免架构耦合、职能耦合和引用耦合。
- 通过工程上全面重塑、组件粒度把控和改动风险最小化实现解耦。
- 具体措施包括组件分层、接口隔离、依赖分析工具、防劣化工具和包大小治理工具。
App工厂中台能力：通过一套代码多App复用、App工厂架构准则、依赖分析、防污染劣化、符合准则的组件、包大小、标准中间件、业务中间件、自动化质量工具和垂直业务等能力，实现业务驱动架构，多App场景下降本提效。

首个实施项目：房产业务在同城App、安居客App实现一套代码复用，通过App工厂实现双App无缝平移，降低业务迭代成本，控制平移后包大小。
实施方案：采用基于底层统一的多业务长期方案，支持创新app和垂直业务，一劳永逸。
组件改造案例：
- Hybrid中间件：谨慎设计、反复沟通，以业务代码改动与影响最小为目标，考虑业务的双向平移。
- 跳转中心组件：针对垂直业务统一跳转协议与跳转中心，针对非垂直业务保留各自逻辑。
公共数据统一问题：通过统一参数集合，针对垂直业务参数获取接口隔离，迁入App独立实现。
App间公共交叉业务兼容问题：定义通用数据接口，个性化业务通过通用数据接口获取垂直业务产生的数据，接口实现类各独立业务分别实现，配置中心动态决定业务调用的接口实现类。
收益：
- 支持房产垂直业务平移+研发提效。
- 支持下沉市场业务平移+研发提效。
- 支持创新app研发提效。
- 包大小收益：租房依赖的中间件和基础库大小减去安居客接入App工厂的中间件和基础库大小，计算得出36.8%和26%的包大小缩减。

测试成本问题：研发成本降低后，测试成本成为主要问题，需要通过接口隔离、松散耦合规避单一定制业务需求带来的中间件升级，降低非关联业务测试成本。
其它思考：
- 进一步降低测试成本：能否做到一定比例底层代码升级不用上层业务测试？
- 进一步提升组件复用效率：与业务协同，将事业部下的业务拆分的更细、可复用。
- 进一步提升性能治理能力：以工程组件为维度，在启动时间、页面加载速度、崩溃、卡顿等性能上进行精细化治理。
核心观点：关键还是以业务为导向，服务好业务的发展。