厂商定制的Android系统为什么也要解耦？

Hi，我是阿昌，今天学习记录的是关于厂商定制的Android系统为什么也要解耦？的内容。

一、Android 系统架构

AOSP，全称是 Android Open Source Project，中文译为“Android 开放源代码项目”。

厂商每年会基于 Google 开放的最新代码进行适配定制，开发属于自己的 OS 版本。

首先，根据 Android 的架构图来看看 Android 系统架构的设计。

在这里插入图片描述

对照架构图，从上到下来看。

在应用框架层上面应该还有一层，就是诸多的应用。

这些应用可以分为 2 类：

一类是系统应用，拥有高的系统权限，可以调用系统提供的高权限接口，例如打电话、短信、设置等应用；
另外一类就是非系统应用，与第三方应用一样，例如定制一些便签、运动健康、视频播放等应用。

第一层就是应用框架层，应用框架最常被应用开发者使用，对应用提供标准的 API 来调用系统的能力，从而实现相关的业务功能。我们在代码编译时，通常会依赖 Android SDK 的 android.jar 空包，保证能通过编译。但需要注意的是 android.jar 具体的实现都在框架层中，实际运行时调用的都是系统中的类。
第二层是 Binder IPC。有了 Binder 进程间通信 (IPC) 机制，应用框架就能跨越进程边界并调用 Android 系统服务代码。由于系统的很多服务都是运行在 System Server 进程，但是集成到应用的 SDK 代码是运行在应用的进程，所以需要通过 Binder 的方式来实现跨进程间的通信。
第三层是系统服务层。系统服务专注于特定功能的模块化组件，例如窗口管理器、搜索服务或通知管理器。例如熟悉的 AMS、WMS、PMS 等，都运行在系统服务层。
第四层是硬件抽象层 (HAL)。Google 在 Android 8.0 里一个名为“Treble”的项目中设计了 HAL 层，目的是让制造商能够以更低成本、更轻松快速地将设备更新到新版 Android 系统。在这种新架构中，HAL 接口定义语言指定了 HAL 和其用户之间的接口，让用户无需重新构建 HAL，就能替换 Android 框架。
最后一层是 Linux 内核层。Google 在官网介绍的开发 Android 设备驱动程序与开发典型的 Linux 设备驱动程序类似。但 Android 使用的 Linux 内核版本包含一些特殊的补充功能，例如低内存终止守护进程、唤醒锁定、Binder IPC 驱动程序等，对于移动嵌入式平台，这些是非常重要的功能。

二、对 Anroid 系统的“魔改”

既然 Android 系统已经有了规范的架构设计，为什么定制 Android 系统还会产生耦合的问题呢？

由于手机产品涉及软硬结合，所以一般会采用 IPD 产品开发流程，研发一款手机的时间通常需要 3 - 12 个月的时间，并按

1、应用之间的耦合

理论上来说，应用之间都是相对独立的。但是在定制系统中，有一些应用在运行时存在相互依赖，例如桌面与负一屏（基于桌面向右滑动后的快捷入口）。

这里应用 A 在运行时可能需要调用应用 B 提供的某些方法，才能保证功能正常运行，如下图所示。

在这里插入图片描述

这里看起来似乎合理，编译上没有依赖，运行时也是通过标准的 API 调用。但关键的问题是不同项目上的功能有差异，依赖的 API 会有变化，并且应用之间并没有做好兼容性的处理，这样导致应用 B 不存在时，应用 A 无法正常运行。

结合下图来理解：

在这里插入图片描述

2、应用与框架之间的耦合

应用与框架之间的耦合。做过应用开发的同学应该知道，我们需要依赖 Android 的 SDK 来开发。因为 Google 会保持 SDK 接口的稳定及兼容，所以基于标准 SDK 开发的应用，才能运行在各个大版本的 Android 系统中。但是在框架里面还有一些类被标识了 @hide，或者有些类属于 com.android.internal 中的类，这些都是标准的 SDK 不会提供的。但是，厂商可以编译生成完整的 android.jar 包，这样应用就可以调用到这些非公开的接口，以便实现更加丰富的功能。

当然还有一些应用采用另外一种方法，就是使用反射的形式。

可以结合后面的示意图来理解。

在这里插入图片描述