Android 总体设计及背后意义

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

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

1. Android设计的现实意义

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

1.1 发展的前提：硬件抽象

2008年，我国迈入3G时代前夜，基础设施的变革让移动领域充满变数，不管设备、硬件仍是软件都均未定型。擅长架构和软件的Google在这一领域要得到生存和长足发展，须要团结一切可能的、甚至是未知的力量，取得移动运营商、芯片供应商、手机制造商的支持则是生存的第一步。

硬件抽象层（HAL）在必定程度上起到这样的目的：它为移动领域五花八门、标准不统一的硬件驱动定义标准接口，避免Android过度依赖Linux，让后续的扩展和整机集成更加高效，知足了手机制造商的重要诉求；同时还起到隔离Linux内核的做用，避免厂商充满硬件秘密的驱动源码受GPL协议影响而开源，保障了芯片等硬件制造商的核心利益。传统手机OS的定制和集成流程须要修改大量代码，负担很多，从这个角度来看Android HAL其设计是领先的。结合AOSP优良的代码分支、模块管理，加上基于GNU automake巨集造成的Android build system，厂商享受到超越以往的便捷。

然而HAL并没有固定作法（如图2所示），Android 8.0以前，最初大量采用HAL旧版方式，表现为framework直接加载*.so并依赖，主要集中在网络、蓝牙等模块；旧版方式致使framework与具体驱动接口耦合过紧，后来造成HAL传统方式，即提供必定规范和接口进行改进，从而减小直接耦合，但每次厂商支持新版Android依旧有大量改动和适配；为更有效地解决这一问题，Android 8.0开启Treble项目，今后芯片厂商能经过基于Binder的HIDL提供稳定接口，制造商则可不受芯片厂商影响而直接更新Framework，甚至得到无需从新编译HAL便可OTA的能力。

受益于HAL这一设计，Google在全球得到更普遍的支撑，尤为是Android 8.0在国内厂商的迅速适配可见一斑。HAL为Android设备量的持续增加提供了基础，并促进有实力的厂商向设备上层及基础设施两个领域纵深发展（图3），体如今掌握核心技术的厂商（如高通、华为、MTK），经过不断建设系统能力来强化竞争力（支持5G标准、硬件能力、软硬结合以及系统能力的深度定制等），而具有渠道和资源整合优点的手机制造商（华为、OPPO、小米、VIVO等），则立足OS持续构建更高效的应用来拓展版图（UI、推送、商店、轻应用等），这都体现出Android HAL对整个产业的凝聚和影响，间接弥补Android自身的诸多不足。

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

固然，历史上其余公司面临这类挑战时也有不同的想法，例如Windows Phone 8.0选择了另一条路，不管是提供媲美JAVA的C#及VB.NET框架、仍是基于Sliverlight Dependency Property + XAML的UI系统、甚至是为了支持C++研发出来的C++/CX及一套运行时，都仿佛无时无刻标榜着其系统技术的多样化与复杂性，算得上是一场技术盛宴。

Meego则是另一个例子，被期待救Nokia于危难，并由Intel联袂推出，经过各类开源能力的组合来完成系统的建设，如Linux内核+QEMU模拟器+QT+QML界面，但实际上昙花一现。

1.3 应用的基础-接口层

系统能力基本就绪，如何迎来更多开发者对Android长远发展相当重要。选择JAVA做为上层语言，既须要勇气又足够彰显其野心；为迎合资源受限这一移动领域过去、如今也是将来的最大客观事实，其设计了基于寄存器架构、可执行文件更小的Dalvik虚拟机，并经过净室工程来高质量实现，同时结合诸多工具对外提供了流畅的JAVA编程方式，摆脱相似MTK feature phone只能用KJava写些小游戏的局限，使得Android研发兼具JAVA的便利和不错的性能。

天有不测风云，SUN在09年4月被Oracle收购，距离Android 1.0发布还不到一年。虽然最初选择Apache Harmony来提供JAVA API十分明智，但却遭遇到技术上不支持JAVA 7/八、版权上Oracle诉讼纷至沓来等诸多挑战。为应对这一切，Google从Android N开始，将JAVA的支持变动为OpenJDK。另外，Kotlin由于特性相近、又可被编译为class或者dx字节码，也得到了Google青睐和收编（图6）。

实际上，之因此Android敢这么作，仍是由于有其设计基础的支撑，根据我的的一点粗鄙了解，从Android API的调用链路（图7）上能发现端倪：不管底层依赖、实现和流程如何变化，上层的使用形式并不会改变。

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

2. 对于咱们的象征意义和实践

综上所述，Android从三个方面来解决其发展的关键问题：

• 硬件驱动：造成厂商的合做基础，并反过来对整个产业施加影响。
• 组件化：高效组织各类内部能力，寻求自身的更快发展。
• 接口层：知足上层对系统和硬件能力的各类使用诉求。

移动互联网产业巨头发展由于起点以及执行理念不一样而有所不一样，Apple围绕着其App Store构建其整个体系并精心维护，并且在现代化API编程、整机体验、垂直领域技术如网络/算法等各纵深领域走在前列；Google则用Android带路，须要在各个层面维护和团结不一样力量来造成本身的发展特点。因此，Android为系统如何发展提供了另一种答案：除关注系统自身能力的发展，如何维护好系统不断发展的基础和前提、如何更好地暴露和让外界使用系统能力也相当重要（见图九）。

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

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

• 首先，经过覆盖线上线下、各种场景、形态万千的设备，不断打造高效私有、支持通用标准的协议，并提供部分其余端侧网络不能或者及其难以提供的特殊能力，来帮助咱们构建设备和服务、用户与业务的泛链接基础。
• 其次，自底向上地抽象，将非阻塞的IO复用、用户态网络栈支持、通道能力扩展以及可支持混合集群的多实例架构进行高效组织，从而保障了数据在不通层面的流转和管理诉求。
• 最后，基于SDK矩阵和接入能力的建设，咱们实现了服务接入到业务、业务透出给用户的目的，并经过提供丰富的数据带来更多价值。

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

3. 小结

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

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

原文连接 本文为云栖社区原创内容，未经容许不得转载。