Android体系与系统架构

Android系统构架

如下图，这是一张讲解Android系统架构的经典示意图。它将Android大致分为了四层，即Linux内核层，库和运行时，Framwork层和应用层。Android的系统架构鼓励系统组建重用，共享组件间的数据，并且定义组件间的访问权限控制。可以说，这些层次结构既相互独立又是互相关联的。

有人说，Android是一个用于连接设备的软件集合，下图就代表了一个最抽象的Android系统架构。

Linux

Linux层，Android最底层最核心的部分。当我们打开手机Setting，选择about phone选项，这一选项所显示的内核版本，就是我们所用的Linux内核的版本。Linux层包含了Android系统的核心服务，包括硬件驱动丶进程管理丶安全系统，等等。

Dalvik与ART

Dalvik包含了一整套的Android运行环境虚拟机，每个App都会分配Dalvik虚拟机来保证互相之间不受干扰，并保持独立。它的特点是在运行时编译。打个比方，就好比你买了一辆折叠自行车，平时是折叠的，只有在骑得时候，才需要组装起来用。而在Android5.X版本开始，ART模式已经取代了Dalvik，ART采用的是安装时就进行编译，以后运行时就不用编译了，这就好比你买了辆组装好了的自行车，装好了就可以骑了。当然，对在其虚拟机环境中运行的大部分App来说，它们都运行着同样的代码。

Framework

如下图为Android App Framework 的详细版。它包含了整个Android Framework的重点，如果以后要研究Framework的具体流程，基本就是在和它们打交道。

Standard Libraries

如下图为Standard Libraries的详细版，这里包含的是Android中的一些标准库，所谓标准，就是开发者在开源环境中可以使用的开发库。

Application

如下两图分别表示了使用NDK开发和Java开发的App的主要构成。可以看出，不管那种App，它们都有Android Manifest 文件，Dalvik Classes，Resource Bundle这几个东西，相信解压过Apk的朋友应该注意到了，这些就是我们解压Apk后的文件。

对于开发者来说，与Android系统最直接的接触就是SDK，应用开发者应当关注每个版本的SDK修改，从而提高应用的兼容性，如果站在Android设计者的角度上来看整个Android的架构，设计者希望Android的架构层能够起到承上启下的功能，让应用的各个组件之间解耦，并通过框架来进行统一的调度，管理。

Android App 组件架构

在应用层，Android的App组件架构，痛就是我们所说的四大组件，指的是Activity，BroadCastReciver,ContentProvider和Service，它们是构成一个AndroidApp的最基本元素。

Android四大组件如何协同工作

Activity作为人机交互的第一界面，负责向用户展示信息和处理结果，而这些信息的来源，可以是通过资源获取，也可以是通过Conten Provider 来获取其他应用的信息，或是Service从后台计算，下载，处理的结果，当然也可以是通过BroadCast Reciver获取到的广播信息。同时，Android系统还提供了要给信使——Intent，作为信息传递的载体。组件与组件之间通过Intent来通信，传递信息，交换数据，正式通过这样要给方式，四大组件形成了各自独立而又紧密联系的关系，让整个Android系统“活”了起来。

应用运行上下文对象

Android系统中的上下文对象，即在Context中，为我们封装了这样一个“语境”。Activity，Service，Application都是继承自Context。

Android应用程序会在如下所示的几个时间点创建上下文Context。

• 创建 Application
• 创建Activity

• 创建Service

  　　不难发现，创建Context的时机就是创建Context的实现类的时候。当应用程序第一次启动时，Android系统都会创建一个Application对象，同时创建Application Conetext，所有的组件都共同拥有这个Context对象，这个应用上下文对象贯穿了整个应用进程的生命周期，为应用全局提供了功能和环境支持。

  　　而创建Activity和Service组件时，系统也会给他们提供运行时的上下文环境，即创建Activity实例，Service实例的Context对象。所以在Activity中获取Context对象时，可以直接使用this，而在匿名内部类中，就必须指定XXXActivity.this 才可以获得该Activity的Context对象。

  　　当然也可以通过getApplicationContext()方法来获取整个App的Context，但是通过getApplicationContext()方法获得的是整个应用的上下文引用，这与某个组件的上下文应用，在某些时候还有有区别的。
  　　

Android系统源代码目录与系统目录

Android系统源代码目录

对于大部分人来说，我们只需要了解他的框架结构，除了问题知道从哪里着手解决就可以了。

作者推荐了一个查看Android源代码的网站：www.androidxref.com

整个结构关系图如下所示：

- Makefile
- bionic                （bionic C 库）
- bootable          （启动引导相关代码）
- build             （存放系统编译规则等基础开发包配置）
- cts               （Google 兼容性测试标准）
- dalvik            （dalvik虚拟机）
- development       （应用程序开发相关）
- external          （android 使用的一些开源的模块）
- framework         （Framework框架核心）
- hardware          （厂商硬件适配层HAL代码）
- out               （编译完成后的代码输出目录）
- packages          （应用程序包）
- prebuilt          （x86和arm架构下预编译资源）
- sdk                (sdk及模拟器）
- system                （底层文件系统库，应用及组件）
- vendor                （厂商定制代码）

不过需要注意的是，并不是所有的源代码结构都是这样。之后AOSP的Android项目才是这样一个结构，有些芯片厂商如MTK，他们的目录结构就与此不同。

Android引入了Makefile机制，源码的编译需要通过Makefile机制。

Makefile解释：一个像Andoid这样的大型工程，它的源文件不计其数，不同的功能，模块，按类型分别放置在不同的目录中，这些模块通常会有一个叫Makefile的文件来进行管理。它定义了一系列的规则来制定模块，哪些文件需要编译，以及这些文件该按照怎样的顺序去编译。甚至它还可以配置更复杂的功能操作，比如定义编译规则，打包规则等，因为Makefile就像一个shell脚本，不仅可以使用自己的语法，也能调用操作系的命令。

Makefile最大的好处就是自动化编译，同时还可以做到可控制的编译，Android通过Makefile来描述各个组件间的联系并指导它们内进行自动化编译。Makefile的语法，指定了各个源代码该如何连接并生成相应的可执行程序。在每一个最小的功能单位目录下都会有一个Makefile文件，将整个源代码联系在一起。

Android系统目录

　　在Android手机里，系统的目录结构与源代码目录结构还是有所不同的，我们通过ADB连接Android设备，通过Linux的ls命令查看Android系统的根目录，其中/system和/data是开发者非常关心的两个目录。

目录/文件	放置内容
/system/app/	系统app
/system/bin/	主要是Linux自带的组件
/system/build.prop	系统的属性信息
/system/fonts/	系统字体
/system/framework/	系统核心文件，框架层
/system/lib/	几乎所有的共享库（.so）文件
/system/media/	系统提示音，系统铃声等
/system/usr/	用户的配置文件
/data/app/	用户安装或者升级的app
/data/data/	App的数据信息，文件信息，数据库信息等
/data/syste/	设备的各项系统信息
/data/misc/	大部分的Wifi，VPN信息

Android app文件目录

下图就是以Android Studio IDE为开发环境，Android Application的文件目录结构。