Android体系与系统架构
目录：
1.1 Google生态系统
1.2 Android系统架构
1.2.1 Linux
1.2.2 Dalvik与ART
1.2.3 Framework
1.2.4 Standard libraries
1.2.5 Application
1.3 Android App组件架构
1.3.1 Android四大组件如何协同工作
1.3.2 应用运行上下文对象
1.1 Google 生态系统
Android底层通过最快的C语言保证效率，上层使用Java简单、快速进行开发。
现在，Google正利用其搜索、移动、web的各个入口，来逐渐掌握互联网的控制权。而Android有了Google这样一个“干爹”支持，更是如鱼得水，不仅在搜索上利用Google Now的优势，更利用Google Map这样一个强有力的工具，将移动系统与Web系统紧密的联系在了一起。
1.2 Android 系统架构
Android到底是什么？从宏观上讲，Android是一个移动操作系统，但这是一个很宽泛的概念。我们来具体“解剖”一下Android。
如下图所示，这是一张讲解Android系统架构的经典示意图（后附对应的中文图片）。
它将Android大致分为了四层，即：
（1）Linux内核层
（2）库和运行时
（3）Framework层
（4）应用层。
Android的体系架构鼓励系统组件重用，共享组件间的数据，并且定义组件间的访问控权限控制。可以说，这些层次结构既是相互独立，又是相互关联的。
Android系统架构：
下面我们继续“开刀”。有人说，Android是一个用于连接设备的软件集合，下图就代表了一个最抽象的Android系统架构。
Android架构总揽：
1.2.1 Linux
Linux层，Android最低层最核心的部分。当我们打开手机Setting，选择about phone选项，这一选项所显示的内核版本，就是我们所用的Linux内核的版本。Linux层包含了Android系统的核心服务，包括硬件驱动、进程管理、安全系统，等等。
1.2.2 Dalvik与ART
Dalvik包含了一整套的Android运行环境虚拟机，每个App都会分配Dalvik虚拟机来保证互相之间不受干扰，并保持独立。它的特点是在运行时编译。打个比方，就好比你买了一辆可折叠的自行车，平时是折叠的，只有骑的时候，才需要组装起来用。而在Android 5.X版本开始，ART模式已经取代了Dalvik，ART采用的是安装时就进行编译，以后运行时就不用编译了，这就好比你买了辆组装好了的自行车，装好就可以骑了。当然，对在其虚拟机环境中运行的大部分App来说，它们都运行着同样的代码。
1.2.3 Framework
如下图所示，为上图(Android架构总揽)中Android App Framework的详细版。它包含了整个Android Framework的重点，如果以后要研究Framework的具体流程，基本就是在和它们打交道。
Android App Framework:
1.2.4 Standard libraries
如下图所示，为上文（Android架构总揽）图中Standard libraries的详细版，这里包含的是Android中的一些标准库，所谓标准，就是开发者在开源环境中可以使用的开发库。
Standard libraries:
下面两张图分别表示了使用NDK开发和Java开发的App的主要构成。可以看出，不管是哪种App,它们都有Android Manifest文件、Dalvik Classes、Resource Bundle这几个东西，相信解压过Apk的朋友应该注意到了，这些就是我们解压Apk后的文件。
Android NDK App:
Android SDK App:
对于开发者来说，与Android系统最直接的接触就是SDK，应用开发者应当关注每个版本的SDK修改，从而提高应用的兼容性。如果站在Android设计者的角度上来看整个Android的架构，设计者希望Android的框架层能够起到承上启下的功能，让应用的各个组件之间解耦，并通过框架来进行统一的调度、管理。
Android的系统架构，说简单点，可以只用一张图展示，说复杂点，可以写几千页的书，Android系统架构就像人心一样，有时候看似简单，却蕴藏着难以捉摸的东西，要想真搞清楚，也绝非一朝一夕之功。所以，初学者首先只需要对这些有一个大概的认识就可以了，等掌握了使用方法后，就可以慢慢的了解它的运行原理，到时候，自然而然，就会看清楚Android的系统架构。
1.3 Android App 组件架构
前面了解了Android的系统架构，而在应用层，Android的App组件架构，通常就是我们所说的Android四大组件，指的是Activity、BroadCastReceiver、ContentProvider和Service，它们是组成一个Android App的最基本元素。
1.3.1 Android 四大组件如何协同工作
Android中的四大组件的使用方式与适用场景都各不相同，但它们之间也保持着紧密的联系，你中有我，我中有你，紧密而不可分。
Activty作为人机交互的第一界面，负责向用户展示信息和处理结果，而这些信息的来源，可以是通过资源获取，也可以通过Content Provider来获取其他应用的信息，或是Service从后台计算、下载、处理的结果，当然也可以是通过BroadCast Receiver获取到的广播信息。同时，Android系统还提供了一个信使——Intent，作为信息传递的载体。组件与组件之间通过Intent来通信、传递信息、交换数据，正是通过这样一种方式，四大组件形成了各自独立而又紧密联系的关系，让整个Android系统活了起来。
Android的四大组件在开发者的调度下，共同完成着开发者赋予它们的使命，它们之间没有孰优孰劣，所有的组件存在的道理就是为了让程序能够更好地实现开发者的功能。当然，熟知每个组件的功能、特点，才能在使用时运筹帷幄。在对四大组件的协同工作模式有了基本的概念后，再去慢慢掌握这些组件的使用技巧。
1.3.2 应用运行上下文对象
"上下文“是指什么意思？在语文中，我们可以理解为语境，在程序中，我们可以理解为当前对象在程序中所处的一个环境，一个与系统交互的过程。
Android系统的上下文对象，即在Context中，为我们封装了这样一个”语境“。Activity、Service、Application都是继承自Context。
Android应用程序会在如下所示的几个时间点创建应用上下文Context。
（1）创建Application
（2）创建Activity
（3）创建Service
不难发现，创建Context的时机就是在创建Context的实现类的时候。当应用程序第一次启动时，Android系统都会创建一个Application对象，同时创建Application Context，所有的组件都共同拥有这样一个Context对象，这个应用上下文对象贯穿整个应用进程的生命周期，为应用全局提供了功能和环境支持。而创建Activity和Service组件时，系统也会给它们提供运行的上下文环境，即创建Activity实例、Service实例的Context对象。所有在Activity中获取Context对象时，可以直接使用this，而在匿名内部类中，就必须指定XXXXActivity.this才可以获得该Activity的Context对象。当然，你也可以通过getApplicationContext（）方法来获取整个App的Context，但是通过getApplicationContext（）方法获得的是整个应用的上下文引用，这与某个组件的上下文引用，在某些时候还是有区别的。