导读
文章详细描述了安居客iOS客户端在平台支撑业务发展过程中的架构实践以及提升研发效率的思考。清晰地表述了问题与解决，同时也体现了APP工厂的中台赋能。
背景
安居客业务覆盖新房、二手房、租房、商业地产、海外地产五大领域，安居客App中除了这几个主要业务，还有房产大内容、用户中心、IM等模块，年一系列人效提升、业务整合的动作，安居客上海团队需要负责安居客App（包含新房、二手房、大内容、IM等业务）的开发，同时还要开发58App中二手房、新房、房产大内容等业务。业务的快速发展对技术支撑提出了更高的要求。为线上用户提供高稳定的服务体验，保障全链路业务和系统高可用运行的同时，要提升多入口业务的研发速度，推进App系统架构的合理演化，进一步提升跨部门跨地域团队之间的协作效率。年初，我们联合58无线团队、58房产团队、前端、后端等多个团队的同学一起发起了「木星计划」，在此基础上，安居客App底层架构与58App已保持基本统一，组件化已经告一段落，一套代码能够同时在安居客和58两个平台部署并上线。项目的架构以及开发模式发生了巨大的变化，但基础设施并未及时作出相应的调整。一套业务两个平台，随着版本的迭代发现以下几个问题：1.一套代码两套平台同时运行，开发结束后集成测试、联调等工作量是否能够保持不变？2.在人力不变，工作量翻倍的情况下，要如何保证业务的迭代速度不受影响？3.「木星计划」完成后理想的开发效率应是完成前的2倍，但随着版本的迭代，发现实际的开发效率只有1.5倍左右。本文主要介绍安居客iOS走向平台化后，所做的一些改变如何提升开发效率。“木星计划”演变
业务发生改变后，通过拷贝代码迭代一两个版本后，发现当前的人力不足以支撑整个业务线的发展，迭代的速度也会受到影响。
为了从根本上解决这一问题，协同58无线团队、58房产团队、前端、后端等多个团队的同学对App的架构升级。最终要求一套业务代码开发一次能够在两个App上同时运行，即能够“多端复用”。人力不变的情况下，开发效率翻倍，又称「木星计划」。下面简单介绍其演变过程。
1.安居客App与58App现状分析：
图1：安居客App与58App差异对比图
通过上图的简单分析发现问题有：
1.底层库不统一，三方库版本不一致。
2.同一业务之间存在差异。
3.组件化不完善，平行业务依赖，壳工程存在业务代码。
存在的最大的问题在于安居客App与58App两个不同的平台差异所带来的影响，为了解决该问题，引入中间层来抹平差异，屏蔽底层细节，同时对外提供统一的接口。每一个中间件执行权利传递给下一个中间件并等待其结束以后又回到当前并做别的事情。
设计如下：
图2：新增中间件设计图
新增中间件最主要的任务是与58房产的团队定义规范的接口，以便业务方的调用和后期的扩展。接口定义完成后由对应的开发实现即可，把实现拆分为三个模块：安居客服务、58服务、房产业务中间件。在开发中间件的同时，对项目的架构进行升级，对基础组件进行梳理，避免重复造轮子，取长补短。统一底层的架构，并保证三方库SDK版本是一致的。
最终的架构图如下：
图3：当前App架构图
2.多端复用
在「木星计划」中，涉及到最多一个名词就是“多端复用”，从一端到多端，开发思维发生了巨大的变化。
所谓的多端复用指的是：
相同的业务有多个入口。像二手房业务线同时存在安居客App和58App中。
基础能力保持一致。像二手房、新房、租房、内容几个大的业务线，会依赖很多底层服务，比如IM、地图、网络通信、路由等，所涉及到的底层服务都需要保持一致。
多端复用当前的实现思路是：
图4：多端复用设计图
如上图所示，主要突出“多端复用”的整体设计思路。简而言之，就是将原有主工程的代码抽出独立组件（Pods），然后各自工程使用Podfile依赖所需的独立组件，独立组件再通过Podspec间接依赖其他独立组件。
3.壳工程分离
对比58App发现安居客App中的壳工程已发生异味，壳工程分离主要将原来project中的代码全部拆出去，得到一个空壳，仅仅保留一些工程配置选项和依赖库管理文件。
壳工程分离的意义主要有如下几点：
壳工程当前身兼数职，过于繁重，拆分后职能更加明确
脱离成私有Pods，和主业务的形势保持一致，为后续二进制化做铺垫
单独的Pods往往要比project代码层面上要更容易管理
安居客App向58App开发环境靠齐，降低适配成本
首先看下壳工程分离的演变历程：
图5：安居客App壳工程分离演变图
整个演变过程分为三步走：
第一步：联合PM，先进行业务梳理，评估其影响范围，同QA进行协调，保证当前的风险可控，确定好测试周期。
第二步：由于该部分内容历史悠久，存在不可控的风险，首先对代码进行分析，删除无用代码、废弃代码、重复代码、资源文件等。对壳工程的代码进行清理，壳工程仅保留一些工程配置选项和依赖库管理文件。涉及到所有代码，整体打包成Pods独立出去，基于所有的业务层之上（暂定为「共有业务层」）。并修改项目配置，回接原有的代码。
第三步：对「共有业务层」进行拆解。其中主要分为平移-下沉-回接三个步骤。最终「共有业务层」被分解到适合的组件，只剩没有任何业务属性的AppOnly，与新房、二手房等业务处于平级关系。修改脚本等配置文件，确保独立出去的Pods能够正常运行。
平移、下沉、回接具体解释？
1.平移：是平行业务的移动；当前未细分业务的拆分，比如之前project文件中的个人中心模块独立单独的业务模块，以私有Pods形式对外提供；已存在业务的拆分，比如之前project文件中的话题移动至内容模块、首页移动至二手房等。
2.下沉：是将处理后的代码解耦并独立处理，移动到下层的Pods或者下层的SubPods。比如之前project