android源码分析（ZZ)

Android系统有很多C++代码，这些C++代码用到了很多智能指针，因此有必要了解一下Android系统在C/C++ Runtime Framework中提供的智能指针

Android系统的智能指针（轻量级指针、强指针和弱指针）的实现原理分析

2. 专用驱动 -- Proprietary Drivers -- 横线

这些专用驱动就是指Logger、Binder和Ashmem，它们整个Android系统的基石：

（1）Logger

浅谈Android系统开发中LOG的使用

Android日志系统驱动程序Logger源代码分析

Android应用程序框架层和系统运行库层日志系统源代码分析

Android日志系统Logcat源代码简要分析

（2）Binder

Android进程间通信（IPC）机制Binder简要介绍和学习计划

浅谈Service Manager成为Android进程间通信（IPC）机制Binder守护进程之路

浅谈Android系统进程间通信（IPC）机制Binder中的Server和Client获得Service Manager接口之路

Android系统进程间通信（IPC）机制Binder中的Server启动过程源代码分析

Android系统进程间通信（IPC）机制Binder中的Client获得Server远程接口过程源代码分析

Android系统进程间通信Binder机制在应用程序框架层的Java接口源代码分析

（3）Ashmem

Android系统匿名共享内存Ashmem（Anonymous Shared Memory）简要介绍和学习计划

Android系统匿名共享内存Ashmem（Anonymous Shared Memory）驱动程序源代码分析

Android系统匿名共享内存Ashmem（Anonymous Shared Memory）在进程间共享的原理分析

Android系统匿名共享内存（Anonymous Shared Memory）C++调用接口分析

3. 硬件抽象层 -- HAL -- 纵线

硬件抽层象最适合用作Android系统的学习入口，它从下到上涉及到了Android系统的各个层次：

Android硬件抽象层（HAL）概要介绍和学习计划

在Ubuntu上为Android系统编写Linux内核驱动程序

在Ubuntu上为Android系统内置C可执行程序测试Linux内核驱动程序

在Ubuntu上为Android增加硬件抽象层（HAL）模块访问Linux内核驱动程序

在Ubuntu为Android硬件抽象层（HAL）模块编写JNI方法提供Java访问硬件服务接口

在Ubuntu上为Android系统的Application Frameworks层增加硬件访问服务

在Ubuntu上为Android系统内置Java应用程序测试Application Frameworks层的硬件服务

4. 应用程序组件 -- Application Component -- 纵线

应用程序组件是Android系统的核心，为开发者提供了贴心的服务。应用程序组件有四种，分别是Activity、Service、Broadcast Receiver和Content Provider。围绕应用程序组件，又有应用程序进程、消息循环和安装三个相关模块。

（1）Activity

Android应用程序的Activity启动过程简要介绍和学习计划

Android应用程序启动过程源代码分析

Android应用程序内部启动Activity过程（startActivity）的源代码分析

Android应用程序在新的进程中启动新的Activity的方法和过程分析

解开Android应用程序组件Activity的"singleTask"之谜

（2）Service

Android系统在新进程中启动自定义服务过程（startService）的原理分析

Android应用程序绑定服务（bindService）的过程源代码分析

（3）Broadcast Receiver

Android系统中的广播（Broadcast）机制简要介绍和学习计划

Android应用程序注册广播接收器（registerReceiver）的过程分析

Android应用程序发送广播（sendBroadcast）的过程分析

（4）Content Provider

Android应用程序组件Content Provider简要介绍和学习计划

Android应用程序组件Content Provider应用实例

Android应用程序组件Content Provider的启动过程源代码分析

Android应用程序组件Content Provider在应用程序之间共享数据的原理分析

Android应用程序组件Content Provider的共享数据更新通知机制分析

（5）进程

Android系统进程Zygote启动过程的源代码分析

Android应用程序进程启动过程的源代码分析

（6）消息循环

Android应用程序消息处理机制（Looper、Handler）分析

Android应用程序键盘（Keyboard）消息处理机制分析

Android应用程序线程消息循环模型分析

（7）安装

Android应用程序安装过程源代码分析

Android系统默认Home应用程序（Launcher）的启动过程源代码分析

5. 用户界面架构 -- UI -- 纵线

大家对老罗现在还在写Android 2.3的UI架构意见最大，认为已经过时了。老罗认为持有这种观点的人，都是没有经过认真思考的。老罗承认，从Android 4.0开始，UI部分发生了比较大的变化。但是请注意，这些变化都是在Android 2.3的UI架构基础之上进行的，也就是说，Android 2.3的UI架构并没有过时。你不能说Android 4.0在Android 2.3之上增加了一些feature，就说Android 2.3过时了。

下面这张是从Android官网拿过来的最新UI渲染流程图，也就是4.2的UI渲染流程图：



图2 Android 4.2的UI渲染流程

从这张图可以看出关于Android的UI架构的三条主线：

（1）每一个Window的Surface都怎样渲染的？不管怎么样，最后渲染出来的都是一个Buffer，交给SurfaceFlinger合成到Display上。

（2）SurfaceFlinger是怎样合成每一个Window的Surface的？

（3）WindowManamgerService是怎么样管理Window的？

第（1）和第（2）两个点在2.3和4.2之间有变化，主要是因为增加了GPU的支持，具体就表现为Window的Surface在渲染的时候使用了GPU，而SurfaceFlinger在合成每一个Window的Surface的时候，也使用了GPU或者Overlay和Blitter这些硬件加速，但是主体流程都没有变，也就是说，Window的Surface渲染好之后，最终依然是交给SurfaceFlinger来合成。此外，虽然我还没有开始看4.2的代码，但是可以看得出，4.2里面的HWComposer，只不过是封装和抽象了2.3就有的Overlay和Blitter，而SurfaceTexture的作用与2.3的SurfaceComposerClient、SurfaceControl也是类似的。第（3）点基本上就没有什么变化，除非以后要支持多窗口。

通过上述对比，只想强调一点：Android 2.3的UI架构并没有过时，是值得去研究的，并且在2.3的基础上去研究4.2的UI架构，会更有帮助。

仁者见仁，智者见智，Android 2.3的UI架构的说明就到此为止，接下来它的分析路线，都是围绕上述三个点来进行的。

首先是以开机动画为切入点，了解Linux内核里面的驱动：

Android系统的开机画面显示过程分析

FB驱动抽象了显卡，上面的用户空间程序就是通过它来显示UI的。

HAL层的Gralloc模块对FB驱动进行了封装，以方便SurfaceFlinger对它进行访问：

Android帧缓冲区（Frame Buffer）硬件抽象层（HAL）模块Gralloc的实现原理分析

SurfaceFlinger负责合成各个应用程序窗口的UI，也就是将各个窗口的UI合成，并且通过FB显示在屏幕上。在对SurfaceFlinger进行分析之前，我们首先了解应用程序是如何使用的它的：

Android应用程序与SurfaceFlinger服务的关系概述和学习计划

Android应用程序与SurfaceFlinger服务的连接过程分析

Android应用程序与SurfaceFlinger服务之间的共享UI元数据（SharedClient）的创建过程分析

Android应用程序请求SurfaceFlinger服务创建Surface的过程分析

Android应用程序请求SurfaceFlinger服务渲染Surface的过程分析

万事俱备，可以开始分析SurfaceFlinger了：

Android系统Surface机制的SurfaceFlinger服务简要介绍和学习计划

Android系统Surface机制的SurfaceFlinger服务的启动过程分析

Android系统Surface机制的SurfaceFlinger服务对帧缓冲区（Frame Buffer）的管理分析

Android系统Surface机制的SurfaceFlinger服务的线程模型分析

Android系统Surface机制的SurfaceFlinger服务渲染应用程序UI的过程分析

SurfaceFlinger操作的对象是应用程序窗口，因此，我们要掌握应用程序窗口的组成：

Android应用程序窗口（Activity）实现框架简要介绍和学习计划

Android应用程序窗口（Activity）的运行上下文环境（Context）的创建过程分析

Android应用程序窗口（Activity）的窗口对象（Window）的创建过程分析

Android应用程序窗口（Activity）的视图对象（View）的创建过程分析

Android应用程序窗口（Activity）与WindowManagerService服务的连接过程分析

Android应用程序窗口（Activity）的绘图表面（Surface）的创建过程分析

Android应用程序窗口（Activity）的测量（Measure）、布局（Layout）和绘制（Draw）过程分析

应用程序窗口是由WindowManagerService进行管理的，并且也是WindowManagerService负责提供窗口信息给SurfaceFlinger的，因此，我们最后分析WindowManagerService：

Android窗口管理服务WindowManagerService的简要介绍和学习计划

Android窗口管理服务WindowManagerService计算Activity窗口大小的过程分析

Android窗口管理服务WindowManagerService对窗口的组织方式分析

Android窗口管理服务WindowManagerService对输入法窗口（Input Method Window）的管理分析

Android窗口管理服务WindowManagerService对壁纸窗口（Wallpaper Window）的管理分析

Android窗口管理服务WindowManagerService计算窗口Z轴位置的过程分析

Android窗口管理服务WindowManagerService显示Activity组件的启动窗口（Starting Window）的过程分析

Android窗口管理服务WindowManagerService切换Activity窗口（App Transition）的过程分析

Android窗口管理服务WindowManagerService显示窗口动画的原理分析

上述内容都研究清楚之后，Android系统的UI架构的骨架就清晰了。但是前面所研究的应用程序窗口还是太抽象了，我们有必要研究一下那些组成应用程序窗口内容的UI控件是怎么实现的，以TextView和SurfaceView为代表：

Android控件TextView的实现原理分析

Android视图SurfaceView的实现原理分析

最后，分析Android系统的UI架构，怎能不提它的资源管理框架？它有效地分离了代码和UI：

Android资源管理框架（Asset Manager）简要介绍和学习计划

Android应用程序资源的编译和打包过程分析

Android应用程序资源管理器（Asset Manager）的创建过程分析

Android应用程序资源的查找过程分析

分析这里，Android系统的UI架构就分析完成了，看出什么门道来没有？是的，我们以开机动画为切入点，从Linux内核空间的FB驱动，一直分析到用户空间中HAL层模块Gralloc、C/C++ Runtime Framework层的SurfaceFlinger、Java Runtime Framework层的WindowMangerService、Window、Widget，以及资源管理框架，从下到上，披荆斩棘。

6. Dalvik虚拟机 -- 横线

Android系统的应用程序及部分应用程序框架是使用Java语言开发的，它们运行在Dalvik虚拟机之上，还有另外一部分应用唾弃框架在使用C/C++语言开发的。使用Java语言开发的应用程序框架老罗称之为Java Runtime Framework，而使用C/C++语言开发的应用程序框架老罗称之为C/C++ Runtime Framework，它们被Dalvik虚拟机一分为二。通过前面的学习，其实我们都已经了解Android系统的Java Runtime Framework和C/C++ Runtime
Framework，因此，我们最后将注意力集中在Dalvik虚拟机上：

Dalvik虚拟机简要介绍和学习计划

Dalvik虚拟机的启动过程分析

Dalvik虚拟机的运行过程分析

Dalvik虚拟机JNI方法的注册过程分析

Dalvik虚拟机进程和线程的创建过程分析

学习完成“三横三纵”这六条主线之后，我们就可以自豪地说，从上到下地把Android系统打通，并且将它的骨架和脉络也理清了！