宗心：淘宝无线事业部资深开发工程师，手机淘宝iOS架构组开发工程师，2012年底参与开发手机淘宝iOS3.0版本，经历大小几十个版本的变迁，针对手机淘宝总体设计架构，hybrid框架解决方案，插件化解决方案以及手机淘宝核心业务组件均有参与和贡献。（阿里巴巴无线事业部：负责手机淘宝并为阿里巴巴各条无线产品线提供基础技术和设施）。
2014年手机淘宝经历了自诞生以来最大规模的一次重构。经历了去年业务的爆炸性增长，以及性能稳定性等多方面挑战后，手机淘宝在开发模式，客户端架构上面都必须做到轻量，透明，延展，敏捷。本内容会重点介绍手机淘宝iOS基础架构的第三代架构如何演进落地，实现多条业务线间独立并行、研发效率提升的目标，以及如何应对未来可能变化。以下是关于手机淘宝客户端架构探索实践的精彩内容：
3.0版本发展历程
如图所示，手机淘宝从1.0用单工程编写开始，东西非常简陋；到2.0为索引许多三方库的庞大的单工程；再到3.0打破了单工程开发模式实现业务复用，包括承载充值，聚划算，航旅等业务，由于业务越来越多，我们想到了插件化的方案，就是制定一套业务的规则和标准，让这些插件按照我们的标准，我们提供的库进行开发。
我们遇到了产品和技术上的挑战和开发的痛点，协同方式上的迭代依赖和分支管理困难，合并依赖关系过于复杂！调试自测效率低——模块依赖下的不稳定因素，业务多，回归成本大，测试资源严重不足！其他模块引起的不稳定性因素。发布的灵活性不足——版本发布无法快速响应，线上已发布版本稳定性，灰度以及线上版本crash难以修复！由于很多APP集成到客户端，各个业务的对接有一定的难度，自己的业务开发完全不够支持这些功能，十余个团队的代码整合也不易，业务持续增长的量变将会导致质变。
2014年是手机淘宝自诞生以来最大规模的底层重构，改变了开发方式、工程结构、结构模型、打包方式。我们将围绕开发效率和性能稳定性等一系列问题探索新的路线，主要有：
工程拆分——支持多团队并行开发
多个业务团队更改一个或多个文件，交叉管理时，底层的东西不稳定就没有办法进行上层开发，所以首先进行业务解耦；其次要进行独立调试；最后修改配置完成集成。拆分的结果如图所示，实践证明，工程拆分以后，整体业务的盆跑速度有了明显提升。
工程拆分分为三个阶段：
- 开发阶段：提供稳定的开发环境（底层库，接口），各个业务方独立开发；
- 测试阶段：单独业务独立打包，针对该业务的测试回归；
- 集成阶段：修改podfile进行集成测试，针对整体流程做回归。
架构重构——重新梳理容器和总线规则。
架构重构需要解决几个问题：迭代开发，并行开发能力差；
耦合严重，核心功能（URL导航）复杂；试错成本过高，增加减少业务带来的成本；快速迭代下的稳定性问题。架构重构的指导思想如图所示，我们制定规范，让各个业务方自己运行，依照规范直接集成进来或出去。核心的架构在容器层，初始化在容器层统一管理，总线是一个核心的解耦方案，通过图2中三种方式进行解耦。容器之上下全部为bundles，每一个业务全部做成bundle以后，当耦合度解的很好的时候，任何的bundles都可以拼成一个APP。
指导思想
用总线的方式解除耦合，制定标准。
URL总线（跨平台统一URL寻址方式）：三平台统一URL，自动降级，中心分发（支持hook）。
服务总线 ：根据服务接口提供稳定服务。
消息总线 ：中心分发，按需加载。
总线也是为了分而治之的原则，各个业务方对其他业务方都是透明的，减少了以前全在一起的中心总线的复杂度问题。只需要遵守规则，不关心底层/其他业务实现。下图是一个总线图，
总线图
减少新业务接入/移除成本：
标准化：统一的通信调用标准，bundle间互通的基础；无法回避的瘦身问题。
灵活性：Bundle自由组装（淘宝生活，码上淘），中间件基础库自由引入。
下图为一个bundlapp,将手机淘宝等的部分bundles拿出来作一个配置 ，将业务bundles，底层bundles作一个重组，组出一个app手机窗口，目的是做一个bundle的复用。
bundleApp
及时响应线上问题如下所示
『Move fast and break things』
via Hot Patch
- 线上严重问题快速修复（小时级的响应时间）
AOP编码形式 - Before/After/Replace 某个方法
- 编写容易，发布规范
配套工具——使用有力工具增加开发效率。
工程拆分遇到的问题：频繁的更换spec；源码引入造成的pod update缓慢等原因；开发阶段集成阶段等问题。
工具解决：摩天轮自动打包平台（自动生成spec，framework引入）；开发-集成-灰度，多阶段管理。
其他工具解决的问题：核心链路性能监控平台；Crash分析平台。
6月初上线以来，重构结果为：集成 Bundle：30+；改造为服务：10+（登录、缓存、搜索组件）；Hot Patch 修复线上严重故障 10+ 起；Patch 最大6KB，大部分不到1KB（iOS）。最大的阵痛是底层依赖迁移引起的编译失败，主要是由于底层库的pod依赖规则不同步造成问题。
关于重构之后的未来探讨如图所示
未来
PPT下载地址：http://club.alibabatech.org/resource_detail.htm?topicId=153
网友评论