在实际工作中，经常可以听到这样的说法：框架的升级带来协议性能的提升，编程方式的改变带来业务的飞跃。..不管这些表达是否有问题。事实上，如果你系统地看待整个事情，你可能会发现一些不同的东西。以LINUX为例，虽然它的内核很成功，但如果不遵循POSIX，成为一个开源、精简的UNIX实现，很难想象它最终会发展成什么样。因此，对事物进行全局的、一定的深入探索，有时更具有启发性。今天，阿里巴巴资深无线开发专家将结合多年经验，为大家深入讲解整个Android技术领域和移动研发生态，期待与您共同探讨。一、Android设计的现实意义该架构的工程意义在于：定义和解决一类问题，为从需求到实现的平滑过渡提供保障。传统意义上的Android架构（图1）已经广为人知，但是不同的角色有不同的视角，比如把Runtime和framework作为核心来考虑，或者把Android当作一个具体的JVM平台来考虑，或者把嵌入式当作asLinux...事实上，Android是为数不多的使用设计来解决自身开发问题的系统之一。变量为可操作性和中介性保留了大量空间。图1.Android传统架构1.1开发前提：硬件抽象2008年我国进入3G时代，基础设施的改造让移动领域充满变数。不管是设备、硬件还是软件都定型了。擅长架构和软件的谷歌需要联合所有可能的，甚至是未知的力量，才能在这个领域生存和发展。获得移动运营商、芯片供应商和手机制造商的支持是生存的关键。步。硬件抽象层（HAL）在一定程度上起到了作用：它为移动领域各种标准不统一的硬件驱动定义了一个标准接口，避免Android过度依赖Linux，并为后续的扩展和机整合更高效。同时也起到隔离Linux内核的作用，防止厂商充满硬件机密的驱动源代码被GPL协议开源，保护芯片等硬件厂商的核心利益。传统手机OS的定制集成过程需要修改大量代码，负担很大。从这个角度来说，AndroidHAL的设计是领先的。结合AOSP优秀的代码分支和模块管理，以及基于GNUautomake宏的Android构建系统，厂商享受前所未有的便利。但是，HAL并没有固定的方法（如图2所示）。Android8.0之前，一开始大量使用老版本的HAL，表现为框架直接加载*.so并依赖，主要集中在网络、蓝牙等模块；具体的驱动接口耦合太紧，后来形成了传统的HAL方式，提供一定的规范和接口进行改进，从而减少直接耦合，但是每次厂商支持新版本的Android，还是有很多变化和改编；为了更有效地解决这个问题，Android8.0启动了Treble项目。从此，芯片厂商可以通过基于Binder的HIDL提供稳定的接口，厂商可以直接更新Framework而不受芯片厂商的影响，甚至无需重新编译HAL就可以获得OTA的能力。图2Android的硬件驱动设计得益于HAL的设计，谷歌在全球范围内获得了更广泛的支持，尤其是国内厂商对Android8.0的快速适配。HAL为Android设备的持续增长提供了基础，推动有实力的厂商向设备和基础设施的上层深度发展（图3），体现在掌握核心技术的厂商（如高通、华为,MTK),通过持续打造系统能力（支持5G标准、硬件能力、软硬件结合、系统能力深度定制等）来强化竞争力，以及具有渠道和资源整合优势的手机厂商（华为、OPPO、小米、VIVO等），基于OS，不断打造更高效的应用，开疆拓土（UI、推送、商店、轻应用等），无不体现AndroidHAL对AndroidHAL的凝聚力和影响力。整个行业，间接弥补了Android本身的诸多不足。图3具有核心竞争力的厂商发展趋势1.2能力中枢：组件化如何组织和复用能力是架构最大的挑战，借鉴已有能力是发展的捷径。无论是Mircosoft的COM，还是OMG的CORBA，还是从EJB到Spring，从SOA到Serverless，随着网络、终端等基础设施的能力中心（总线）的重依赖到轻依赖的趋势。Android充分结合了各个领域的先进技术，基于移动终端资源有限的独特特点，形成了自己的技术特点：AIDL由复杂的CORBAIDL衍生而来，组件由SOA简化而来，各个独立的SystemService类似于微服务中，Binder可以看作是一个弱化了总线，性能更好，可以点对点通信的DBUS。UI布局系统受SWING的影响很大。Manifest其实是APP与系统通信所必需的。组件接口描述文件……上面提到的领域技术确实对Android的发展有益，但还远远不够。回顾一下我们之前讲的HAL和整体架构，我们看到Android其实是一个大杂烩，混合了很多技术。以往除了Palm等WebOS，无论是基于Linux/Unix的系统如Meego，还是Symbian、MTK、UCOS、WindowsCE，无论是实时系统还是非实时系统系统方面，这些移动终端系统主要基于C/C++和小型紧凑型，对内存的使用和要求非常讲究。虽然满足了资源受限设备的要求，但带来了门槛；WindowsPhone上的KJava和.NET等虚拟机平台在内存占用和能耗方面都比较慷慨。但其在研发效率和容错性方面表现出色，因此受到了众多开发者的欢迎。因此，选择混合架构不仅符合自身的技术理念，对于缺乏完整移动产业链支撑的谷歌来说也是最有胜算的。因此，量身定制的组件化能力就肩负着这一使命，让各个组件有机地组合应用。应用和系统之间的沟通更加清晰和约束，最终帮助整个系统灵活运行，能力快速放大。观察Android系统的启动运行过程（图4）和APP对系统能力的使用（图5），可以发现其各种能力已经按照组件标准和粒度进行了组织（能力注册发现，接口和通信标准化、操作空间隔离等），让手机硬件快速迭代，以最低的成本不断升级系统能力，在移动设备系统上体现和最大化复用价值，从而具有更高的灵活性和兼容性;其背后软件工程的意义在于搭建软件需求与设计之间的桥梁，解决系统结构与研发需求的平滑过渡问题。图4.Android系统流程架构概览图5.使用设备能力的典型调用路径当然，历史上其他公司在面对此类挑战时也有不同的想法。比如WindowsPhone8.0就选择了另一条路，无论是提供C#和VB.NET框架，还是基于SilverlightDependencyProperty+XAML的UI系统，甚至是C++/CX以及为支持C++而开发的一套运行时，似乎都无时无刻不标榜其系统技术的多样性和复杂性，堪称一场技术盛宴。Meego是另一个例子。它有望使诺基亚免于困境。它是由Intel联合推出的，通过Linux内核+QEMU模拟器+QT+QML接口等各种开源能力的结合来完成系统构建，但实际上是昙花一现。.1.3应用基础——界面层系统能力基本准备就绪，如何迎接更多的开发者对Android的长远发展至关重要。选择JAVA作为上层语言，既需要勇气，也足以彰显其雄心壮志；为了迎合移动领域过去、现在和未来资源受限这一最客观的事实，设计了基于寄存器架构、可执行文件更小的Dalvik。虚拟机通过无尘室工程高质量实现，并结合众多工具，对外提供流畅的JAVA编程方式，摆脱了像MTK功能机一样只能用KJava编写小游戏的局限，让Android开发既有JAVA的方便，又有好的性能。不幸的是，SUN在2009年4月被Oracle收购，距Android1.0发布不到一年。虽然一开始选择ApacheHarmony提供JAVAAPI是明智的，但遇到了技术上不支持JAVA7/8、Oracle的版权诉讼等诸多挑战。为了应对这一切，谷歌从AndroidN开始将对JAVA的支持改为OpenJDK。此外，Kotlin也因其相似的特性而被谷歌看好并收录，可以编译成class或dx字节码（图6）。图6.Android界面层的过去与未来其实Android之所以敢于这样做，是因为有其设计基础的支持。根据个人的一点理解，从AndroidAPI的调用环节（图7）可以发现线索：不管底层的依赖、实现、流程如何变化，上层的用法是不会变的。图7.Android中调用链接的三种实现。这意味着几乎所有系统能力的核心都已经在原生库中实现，并结合上层提供良好的屏蔽。这使得其他语言实现Framework成为可能，尤其是具有类似JAVA特性的语言。那么什么语言，kotlin只是事先设计规范下的一个合适的选择。图8.未来用kotlin替代java的一种极端可能性2.对于我们的象征意义和实践综上所述，Android从三个方面解决了其发展中的关键问题：硬件驱动：形成厂商合作的基础，而Thisin进而对整个行业产生影响。组件化：高效组织内部各种能力，寻求更快的自我发展。接口层：满足上层对系统和硬件能力的各种使用需求。由于起点和执行理念不同，移动互联网行业巨头的发展也不尽相同。Apple围绕其AppStore构建了整个系统，并对其进行了精心维护。领域走在前列；谷歌以Android为先导，需要维护和凝聚各个层面的不同力量，形成自己的发展特色。因此，Android为系统如何发展提供了另一种答案：除了关注系统自身能力的发展，如何维护系统持续发展的基础和前提，如何更好地暴露和允许外界使用系统功能也很重要（见图9）。图9Android设计对解决问题的启示回到我们自己，在强调用户、强调交互、手机就是人的今天，我们的产品有理由也需要用内涵来延伸和放大服务的价值.做到这一点并不容易。首先，业务迭代越来越快，各种应用层出不穷，这意味着对中间件的广泛需求；第二，环境在变，无论是运营硬件设备的多样性，还是对接集群的复杂性和多样性，都对阿里巴巴的原始端影响很大。第三，在基础技术发展放缓的今天，技术的价值需要不断放大。我们希望立足自身能力，打造泛连接的服务和业务基础，并以此作为我们的发展愿景。这就需要我们结合集团背景和核心APP开发的主要目标来综合思考这个开发问题（图10）。图10泛在连接能力建设的思考受Android启发，结合环境和现状，在满足业务目标的同时，从三个层面持续演进网络能力（图11）。首先，通过覆盖线上线下、各种场景、不同形态的设备，不断打造支持通用标准的高效私有协议，提供一些其他端侧网络无法或极难提供的特殊能力帮助我们为设备和服务、用户和企业建立一个泛连接的基础。其次，自下而上进行抽象，高效组织非阻塞IO多路复用、用户态网络栈支持、通道能力扩展、可支持混合集群的多实例架构，从而保证不同层次的数据流转和管理需求。***，基于SDK矩阵和接入能力的构建，我们实现了服务接入业务和业务向用户公开的目的，通过提供丰富的数据带来更多的价值。图11泛连接能力的体系化建设基于以上的不断沉淀，我们现在已经可以触达大量的设备和用户，成为阿里内外各种服务和平台的接入接口，屏蔽终端和服务集群多元化。以及设备的多样性，实现新零售系统能力与用户的通用连接（图12）。图12.团队能力在群体中的位置3.总结结合传统的C/S概念，服务器获取的信息来自各个网络终端，网络+协议屏蔽或规范外部服务输入的多样性，服务端过去以集群、高并发为主，现在无论是上云还是利用，都是受业务、成本规模、边际效应驱动，代际发展主题鲜明。但回到客户端，由于环境和交互多样性的直接影响，即使是动态技术也很难代表端侧的全部甚至主流。因此，在某些本土技术上比拼武林，成为过去的行业“趋势”。深入本地技术和单点，确实很有意义。作者也做了一些小技巧，比如非轮询的方式获取手机栈的topactivity，阿里巴巴特有的复杂集群SDK多实例设计，Sophix热修复和云产品等等。但是结合以往的经验和Android设计，我们可以更系统地看待这个现象：即除了满足业务的核心诉求（因为投入了大量的资源，必须而且必须成功，至少有一个smallsuccess），更应该关注技术如何更好地服务于业务，以及如何继续挖掘护城河的两端。因此，要构建和发展一个系统，除了构建系统的骨干能力外，还需要维护系统发展的前提条件，组织各种系统能力的内聚，满足外部对系统的需求。
