阿里妹导读：现实工作中经常可以听到这样的说法：框架的升级带来协议性能的提升、编程模式的变革带来业务的飞跃...... 姑且不论这些表述是否有问题，实际上如果系统地看待事物整体，可能会有不一样的发现。以LINUX为例，尽管其内核大获成功，但如果不是遵循POSIX、并成为一个开源、精简的UNIX实现，很难想象其最终会有何种发展。因此，对事物进行全局和一定深入的探究有时会有更多启发。

今天，阿里高级无线开发专家所为将结合自己多年的经验，为你深入阐述整个 Android 技术域及移动研发生态，期待与大家共同探讨。

架构的工程意义在于：定义并解决一类问题，为需求到实现的平稳过渡提供保障。传统意义的Android架构（图1）已被人熟知，但不同角色的视角不同，例如认为Runtime和框架是其核心、或者将Android看做是一种特异性JVM平台、还有从嵌入式出发将其看做是Linux…… 实际上，Android是极少数几个用设计来解决自身发展问题的系统，其核心在于通过硬件抽象、组件化、接口层三种能力来为发展提供基础，并为诸多变数预留大量可操作、斡旋的空间。

图3. 具备核心竞争力的厂商的发展趋势

1.2 能力的枢纽：组件化

对能力进行如何组织和复用是架构的最大挑战，借鉴现有能力是发展的捷径。无论是Mircosoft的COM，还是OMG的CORBA，或是从EJB到Spring、从SOA到Serverless，随着基础设施如网络、终端设备的能力提升，这些技术的发展呈现出从重量到轻量、从对中心(总线)的重度依赖到轻量级依赖的趋势。Android充分结合各领域先进技术，并基于移动端资源受限这一最大特色，形成了自身的技术特色：AIDL衍生自复杂的CORBA IDL，组件由SOA精简而来，各独立生老病死的System Service类似一个个微服务，Binder可以看做是对一种弱化总线、性能更好、可点对点通信的DBUS，UI布局系统则极大程度受到SWING的影响、manifest实际上就是APP与系统通信所必须的组件接口描述文件......

上面提到的领域技术的确有利于Android发展，但远远不够。回想之前谈到的HAL以及整体架构，我们看到Android实际上就是个大杂烩，使用的是诸多技术的混合。过去除Palm等Web OS外，无论是基于Linux/Unix构建的系统如Meego，还是Symbian、MTK、UCOS、WindowsCE，无论是实时系统还是非实时系统，这些移动端系统都以C/C 为主且小巧精悍，对内存使用和要求极为考究，虽然满足了资源受限设备的使用诉求但带来了门槛；虚拟机类的平台如KJAVA、.NET on Windows Phone虽然内存使用和能耗方面比较大方，却胜在研发效率和容错性，因而受到不少开发者欢迎。

所以选择混合架构对于缺乏完整移动领域产业链支撑的Google既符合其自身技术理念、又胜算最大，于是量身定制的组件化能力便肩负起这一使命，使得各组件得到有机组合、应用之间以及应用和系统的沟通更为明确和有约束，最终帮助整个系统灵活运转，能力被迅速放大。

观察Android系统的启动运行流程（图4）以及APP对系统能力的使用（图5），可以发现其各类能力已按照组件化标准和粒度进行组织（能力的注册发现、接口和通信的标准化、运行空间的隔离等），让快速迭代的手机硬件和持续升级的系统能力以最小代价透出，将复用的价值在移动设备系统上具体化并最大化，从而具备更高的灵活性和兼容性；其背后软件工程的意义在于为软件需求、设计之间架起一座桥梁，解决了系统结构和研发需求向实现平坦过渡的问题。

图4. Android系统进程架构概要

图7. Android内部对调用链路的3种实现

这意味着几乎所有系统能力的核心，已在native library被实现殆尽，并结合上层提供良好屏蔽。这为其他语言实现Framework提供了可能，尤其是一门特性与JAVA相近的语言。所以是什么语言、是不是kotlin都只事先设计规范下的一种合适的选择。

图9. Android设计对解决问题的启示

回到我们自身，在重用户、重交互、手机即人的今天，我们的产品有理由也有必要用其内涵延展并放大服务的价值。要做到这一点并非易事。首先，业务迭代越来越快，各种应用层出不穷对中间件意味着广泛的需求；其次，环境在改变，无论是运行硬件和设备的五花八门、还是对接集群的复杂多样，都对阿里原有端侧中间件带来巨大冲击；再次，在基础技术发展变缓的今天，技术的价值需要被持续放大，我们希望基于自身能力来构建服务和业务的泛连接基础,并将其作为发展愿景。这要求我们基于集团背景以及核心APP发展的主要目标下，来综合思考这个发展问题（图10）。

图10. 对泛连接能力建设的思考

通过Android的启发，结合环境和现状，在满足业务目标的同时我们从三个层面不断演进网络能力（图11）。

图11. 泛连接能力的系统性建设

基于以上的不断沉淀，目前我们已能触达海量设备和用户，成为接入阿里内外各服务和平台的接口，并为终端和服务分别屏蔽集群的多元化及设备的多样性，实现新零售系统能力与用户的泛连接（图12）。

图12.团队能力在集团中所处的位置

结合传统的C/S观念，服务端获取的信息来源于各网络终端，网络 协议屏蔽或规范了外界对服务输入的多样性，使得服务端过去关注的是集群和高并发，但现在无论是上云还是利用率，背后都是业务、成本规模和边际效应在驱动，这里面发展的代际主旨鲜明。但回到客户端，由于受到环境和交互等多样性直接影响，即便是动态性的技术也难以代表端侧的全部甚至是主流。所以在某种局部技术比拼武功，成为过去客户端的一种行业“潮流”。

在局部技术和单点深入的确有其意义，笔者也曾有过一些班门弄斧，如非轮询方式获取手机栈顶Activity、面向阿里特有复杂集群的SDK多实例设计、Sophix热修复及云上产品等。但结合过往经验及Android设计，可以更系统性地看待这一现象：即除了满足业务核心诉求（因为投入大量资源，必须、肯定要成，至少小成），更应该关注技术如何更好地服务业务以及如何持续挖掘能力护城河这两头的问题。所以要打造和发展好一个系统，除构建系统各中坚能力外，还需维护好系统发展的前提、组织好各系统能力的内聚、满足好外部对系统的诉求。

作者：所为

花粉社群VIP加油站