老罗的Android之旅

在Chromium中，WebKit会创建一个Graphics Layer Tree描述网页。Graphics Layer Tree是和网页渲染相关的一个Tree。网页渲染最终由Chromium的CC模块完成，因此CC模块又会根据Graphics Layer Tree创建一个Layer Tree，以后就会根据这个Layer Tree对网页进行渲染。本文接下来就分析网页Layer Tree的创建过程。

Chromium的每一个WebGL端、Render端和Browser端实例在GPU进程中都有一个OpenGL上下文。这些OpenGL上下文运行在相同线程中，因此同一时刻只有一个OpenGL上下文处于运行状态。这就引发出一个OpenGL上下文调度问题。此外，事情有轻重缓急，OpenGL上下文也有优先级高低之分，优先级高的要保证它的运行时间。本文接下来就分析GPU进程调度运行OpenGL上下文的过程。

在Chromium中，由于GPU进程的存在，WebGL端、Render端和Browser端的GPU命令是代理给GPU进程执行的。Chromium将它们要执行的GPU命令进行编码，然后写入到一个命令缓冲区中，最后传递给GPU进程。GPU进程从这个命令缓冲区读出GPU命令之后，就进行解码，然后调用对应的OpenGL函数。本文就详细分析WebGL端、Render端和Browser端执行GPU命令的过程。。

在Chromium中，WebGL端、Render端和Browser端的GPU命令都是通过GPU进程中的一个GPU线程来执行的。这三端的GPU命令是独立执行的，不能相互发生影响。为了达到这个目的，GPU线程分别为它们创建不同的OpenGL上下文，并且使得它们的GPU命令在各自的OpenGL上下文中执行。本文接下来就详细分析WebGL端、Render端和Browser端的OpenGL上下文的创建过程。

GPU命令需要在OpenGL上下文中执行。每一个OpenGL上下文都关联有一个绘图表面，GPU命令就是作用在绘图表面上的。不同用途的OpenGL上下文关联的绘图表面不一样，例如用于离屏渲染的OpenGL上下文关联的绘图表面可以用Pbuffer描述，而用于屏幕渲染的OpenGL上下文的绘图表面要用本地窗口描述。本文接下来就分析Chromium硬件加速渲染涉及到的OpenGL上下文的绘图表面创建过程。

前面我们分析了Chromium的Render进程和GPU进程的启动过程，它们都是由Browser进程启动的。在Chromium中，还有一类进程是由Browser进程启动的，它们就是Plugin进程。顾名思义，Plugin进程是用来运行浏览器插件的。浏览器插件的作用是扩展网页功能，它们由第三方开发，安全性和稳定性都无法得到保证，因此运行在独立的进程中。本文接下来就详细分析Plugin进程的启动过程。

Chromium除了有Browser进程和Render进程，还有GPU进程。GPU进程负责Chromium的GPU操作，例如Render进程通过GPU进程离屏渲染网页，Browser进程也是通过GPU进程将离屏渲染好的网页显示在屏幕上。Chromium之所以将GPU操作运行在独立进程中，是考虑到稳定性问题。毕竟GPU操作是硬件相关操作，硬件的差异性会引发一定的不稳性。本文分析GPU进程的启动过程。

由于Chromium采用多进程架构，因此会涉及到进程间通信问题。通过前面一文的学习，我们知道Browser进程在启动Render进程的过程中会建立一个以UNIX Socket为基础的IPC通道。有了IPC通道之后，接下来Browser进程与Render进程就以消息的形式进行通信。我们将这种消息称为IPC消息，以区别于线程消息循环中的消息。本文就分析Chromium的IPC消息发送、接收和分发机制。

Chromium以多进程架构著称，它主要包含四类进程，分别是Browser进程、Render进程、GPU进程和Plugin进程。之所以要将Render进程、GPU进程和Plugin进程独立出来，是为了解决它们的不稳定性问题。也就是说，Render进程、GPU进程和Plugin进程由于不稳定而引发的Crash不会导致整个浏览器崩溃。本文就对Chromium的多进程架构进行简要介绍，以及制定学习计划。

为了充分利用CPU多核特性，Chromium在启动时会创建很多线程，来负责执行不同的操作。这样就涉及到了多线程通信问题。Chromium为每一个线程都创建了一个消息队列。当一个线程需要另一个线程执行某一操作时，就向该线程的消息队列发送一个Callback。这个Callback最终在目标线程中得到执行。这种基于Callback的多线程通信方式在Chromium中很普通，因此本文就对它的实现进行分析。

Chromium支持硬件加速渲染网页，即使用GPU渲染网页。在多进程架构下，Browser、Render和Plugin进程的GPU命令不是在本进程中执行的，而是转发给GPU进程执行。这是因为GPU命令是硬件相关操作，不同平台的实现不一样，从而导致不稳定，而将不稳定操作放在独立进程中执行可以保护主进程的稳定性。本文对Chromium硬件加速渲染机制的基础知识进行简要介绍和制定学习计划。

C++不像Java一样，由虚拟机负责对象分配和释放。也就是说，开发人员使用C++编写代码时，要自己负责对象分配和释放。WebKit和Chromium都是使用C++开发的，因此它们也面临上述问题。在解决对象释放问题时，要做到在对象不需要时自动释放，因为手动释放会带来忘记释放或者释放后又继续使用的隐患。智能指针是实现对象自动释放的有效技术手段。本文就分析Chromium和WebKit的智能指针的实现。

在硬件加速渲染环境中，Android应用程序窗口的UI渲染是分两步进行的。第一步是构建Display List，发生在应用程序进程的Main Thread中；第二步是渲染Display List，发生在应用程序进程的Render Thread中。Display List的渲染不是简单地执行绘制命令，而是包含了一系列优化操作，例如绘制命令的合并执行。本文就详细分析Display List的渲染过程。

在硬件加速渲染环境中，Android应用程序窗口的UI渲染是分两步进行的。第一步是构建Display List，发生在应用程序进程的Main Thread中；第二步是渲染Display List，发生在应用程序进程的Render Thread中。Display List是以视图为单位进行构建的，因此每一个视图都对应有一个Display List。本文详细分析这些Display List的构建过程。

在Android应用程序中，我们是通过Canvas API来绘制UI元素的。在硬件加速渲染环境中，这些Canvas API调用最终会转化为Open GL API调用（转化过程对应用程序来说是透明的）。由于Open GL API调用要求发生在Open GL环境中，因此在每当有新的Activity窗口启动时，系统都会为其初始化好Open GL环境。这篇文章就详细分析这个Open GL环境的初始化过程。

我们知道，Android系统在启动的时候，会对一些系统资源进行预加载。这样不仅使得应用程序在需要时可以快速地访问这些资源，还使得这些资源能够在不同应用程序之间进行共享。在硬件加速渲染环境中，这些预加载资源还有进一步优化的空间。Android系统提供了一个地图集服务，负责将预加载资源合成为一个纹理上传到GPU去，并且能够在所有的应用程序之间进行共享。本文就详细分析这个预加载资源地图集服务的实现原理。

Android从4.4起提供基于Chromium实现的WebView。此前WebView基于WebKit实现。WebKit提供网页解析、布局和绘制以及JS运行等基础功能。Chromium在WebKit基础上为WebView提供进程、线程和渲染等基础构架。因此基于Chromium实现的WebView更好地提供了网页浏览功能。从本文开始我们启动对Android Chromium WebView的学习。

Android系统的流畅性一直被拿来与iOS比较，并且认为不如后者。这一方面与Android设备硬件质量参差不齐有关，另一方面也与Android系统的实现有关。例如在3.0前，Android应用程序UI绘制不支持硬件加速。不过从4.0开始，Android系统一直以“run fast, smooth, and responsively”为目标对UI进行优化。本文对这些优化进行简要介绍和制定学习计划。

通过前面一系列文章的学习，我们知道了ART运行时既支持Mark-Sweep GC，又支持Compacting GC。其中，Mark-Sweep GC执行效率更高，但是存在内存碎片问题；而Compacting GC执行效率较低，但是不存在内存碎片问题。ART运行时通过引入Foreground GC和Background GC的概念来对这两种GC进行扬长避短。本文就详细分析它们的执行过程以及切换过程。

Semi-Space（SS）GC和Generational Semi-Space（GSS）GC是ART运行时引进的两个Compacting GC。它们的共同特点是都具有一个From Space和一个To Space。在GC执行期间，在From Space分配的还存活的对象会被依次拷贝到To Space中，这样就可以达到消除内存碎片的目的。本文就将SS GC和GSS GC的执行过程分析进行详细分析。

除了Semi-Space（SS）GC和Generational Semi-Space（GSS）GC，ART运行时还引入了第三种Compacting GC：Mark-Compact（MC）GC。这三种GC虽然都是Compacting GC，不过它们的实现方式却有很大不同。SS GC和GSS GC需两个Space来压缩内存，而MC GC只需一个Space来压缩内存。本文就详细分析MC GC的执行过程。

引进了Compacting GC之后，ART运行时的堆空间结构就发生了变化。这是由于Compacting GC和Mark-Sweep GC的算法不同，要求底层的堆具有不同的空间结构。同时，即使是原来的Mark-Sweep GC，由于需要支持新的同构空间压缩特性（Homogeneous Space Compact），也使得它们要具有与原来不一样的堆空间结构。本文就对这些堆空间创建过程进行详细的分析。

Android系统通过属性暴露设备和运行时信息，并且可以通过设置属性来控制系统行为。因此，属性也像文件一样，是一种需要保护的资源。在启用SEAndroid之前，敏感属性只能被预先设定的进程进行设置。启用SEAndroid之后，敏感属性会进一步被SEAndroid安全策略保护。这样就可以更有效地保护系统属性了。在本文中，我们就详细分析SEAndroid安全机制对Android属性设置保护提供的支持。

ART运行时和Dalvik虚拟机一样，在堆上为对象分配内存时都要解决内存碎片和内存不足问题。内存碎片问题可以使用dlmalloc技术解决。内存不足问题则通过垃圾回收和在允许范围内增长堆大小解决。由于垃圾回收会影响程序，因此ART运行时采用力度从小到大的进垃圾回收策略。一旦力度小的垃圾回收执行过后能满足分配要求，那就不需要进行力度大的垃圾回收了。本文就详细分析ART运行时在堆上为对象分配内存的过程。

前面一篇文章分析了文件安全上下文关联过程。但是在SEAndroid中，除了要给文件关联安全上下文外，还需要给进程关联安全上下文，因为只有当进程和文件都关联安全上下文之后，SEAndroid安全策略才能发挥作用。也就是说，当一个进程试图访问一个文件时，SEAndroid会将进程和文件的安全上下文提取出来，根据安全策略规则，决定是否允许访问。本文就详细分析SEAndroid的进程安全上下文的关联过程。

前面一篇文章提到，SEAndroid是一种基于安全策略的MAC安全机制。这种安全策略实施在主体和客体的安全上下文之上。这意味着安全策略在实施之前，SEAndroid安全机制中的主休和客体是已经有安全上下文的。在SEAndroid安全机制中，主体一般就是进程，而客体一般就是文件。文件的安全上下文的关联有不同的方式。本文主要分析文件安全上下文的设置过程，接下来的一篇文章再分析进程安全上下文的设置过程。

我们知道，Android系统基于Linux实现。针对传统Linux系统，NSA开发了一套安全机制SELinux，用来加强安全性。然而，由于Android系统有着独特的用户空间运行时，因此SELinux不能完全适用于Android系统。为此，NSA针对Android系统，在SELinux基础上开发了SEAndroid。本文就对SEAndroid安全机制框架进行分析，以便后面可以更好地分析其实现细节。

与iOS相比，Android最被人诟病的是其流畅性和安全性。然而，从4.0开始，Android不遗余力地改善其流畅性。特别是在即将发布的L版本中，用ART替换了Dalvik，相信会越来越流畅。至于安全性，Android也没有遗忘。从4.3开始，Android引入了一套基于SELinux的安全机制，称为SEAndroid，来加强系统安全性。接下来我们就对SEAndroid进行简要介绍和制定学习计划。

前面101篇文章都是分析Android系统源码，似乎不够接地气。如果能让Android系统源码在真实设备上跑跑看效果，那该多好。这不就是传说中的刷ROM吗？刷ROM这个话题是老罗以前一直避免谈的，因为觉得没有全面了解Android系统前就谈ROM是不完整的。写完了101篇文章后，老罗觉得第102篇文章该谈谈这个话题了，并且选择CM这个有代表性的ROM来谈，目标是加深大家对Android系统的了解。

在前文中，我们分析了Android编译环境的初始化过程。Android编译环境初始化完成后，我们就可以用m/mm/mmm/make命令编译源代码了。当然，这要求每一个模块都有一个Android.mk文件。Android.mk实际上是一个Makefile脚本，用来描述模块编译信息。Android编译系统通过整合Android.mk文件完成编译过程。本文就对Android源代码的编译过程进行详细分析。

Android源代码在编译之前，要先对编译环境进行初始化，其中最主要就是指定编译的类型和目标设备的型号。Android的编译类型主要有eng、userdebug和user三种，而支持的目标设备型号则是不确定的，它们由当前的源码配置情况所决定。为了确定源码支持的所有目标设备型号，Android编译系统在初始化的过程中，需要在特定的目录中加载特定的配置文件。接下来本文就对上述的初始化过程进行详细分析。

为了学习ART运行时的垃圾收集机制，我们先把Dalvik虚拟机的垃圾收集机制研究了一遍。这是因为两者都使用到了Mark-Sweep算法，因此它们在概念上有很多一致的地方。然而在实现上，Dalvik虚拟机的垃圾收集机制要简单一些。这样我们就可以先从简单的Dalvik虚拟机垃圾收集机制入手，然后再逐步深入地学习复杂的ART运行时垃圾收集机制。本文就对ART运行时垃圾收集机制进行简要介绍和制定学习计划。

在前面一篇文章中，我们分析了Android模块的编译过程。当Android系统的所有模块都编译好之后，我们就可以对编译出来的模块文件进行打包了。打包结果是获得一系列的镜像文件，例如system.img、boot.img、ramdisk.img、userdata.img和recovery.img等。这些镜像文件最终可以烧录到手机上运行。在本文中，我们就详细分析Android系统的镜像文件的打包过程。

在Android源码环境中，我们开发好一个模块后，再写一个Android.mk文件，就可通过m/mm/mmm/make等命令进行编译。此外，通过make命令还可制作各种系统镜像文件，例如system.img、boot.img和recovery.img等。这一切都得益于Android编译系统，它为我们处理了各种依赖关系，以及提供各种有用工具。本文对Android编译系统进行简单介绍以及制定学习计划。

软件工程由于需要不断迭代开发，因此要对源代码进行版本管理。Android源代码工程（AOSP）也不例外，它采用Git来进行版本管理。AOSP作为一个大型开放源代码工程，由许许多多子项目组成，因此不能简单地用Git进行管理，它在Git的基础上建立了一套自己的代码仓库，并且使用工具Repo进行管理。工欲善其事，必先利其器。本文就对AOSP代码仓库及其管理工具repo进行分析，以便提高我们日常开发效率。

Android 4.4发布了一个ART运行时，准备用来替换掉之前一直使用的Dalvik虚拟机，希望籍此解决饱受诟病的性能问题。老罗不打算分析ART的实现原理，只是很有兴趣知道ART是如何无缝替换掉原来的Dalvik虚拟机的。毕竟在原来的系统中，大量的代码都是运行在Dalvik虚拟机里面的。开始觉得这个替换工作是挺复杂的，但是分析了相关代码之后，发现思路是很清晰的。本来就详细分析这个无缝的替换过程。

前面我们分析了Dalvik虚拟机堆的创建过程，以及Java对象在堆上的分配过程。这些知识都是理解Dalvik虚拟机垃圾收集过程的基础。垃圾收集是一个复杂的过程，它要将那些不再被引用的对象进行回收。一方面要求Dalvik虚拟机能够标记出哪些对象是不再被引用的。另一方面要求Dalvik虚拟机尽快地回收内存，避免应用程序长时间停顿。本文就将详细分析Dalvik虚拟机是如何解决上述问题完成垃圾收集过程的。

最近忙着研究Android的安全技术，好长时间没有写博客了，准备回归老本行：Read the funcking android source code。这两天看NDK文档时，看到一句“Native debugging ... does not require root or privileged access, aslong as your application is debuggable”。咦，NDK调试不是通过ptrace实现的么？在非Root的手机上是怎么进行ptrace呢？借这两问题正好可以介绍一

我们知道，在Android系统中，Dalvik虚拟机是运行Linux内核之上的。如果我们把Dalvik虚拟机看作是一台机器，那么它也有进程和线程的概念。事实上，我们的确是可以在Java代码中创建进程和线程，也就是Dalvik虚拟机进程和线程。那么，这些Dalvik虚拟机所创建的进程和线程与其宿主Linux内核的进程和线程有什么关系呢？本文将通过Dalvik虚拟机进程和线程的创建过程来回答这个问题。

在前面一篇文章中，我们分析了Dalvik虚拟机在Zygote进程中的启动过程。Dalvik虚拟机启动完成之后，也就是在各个子模块初始化完成以及加载了相应的Java核心类库之后，就是可以执行Java代码了。当然，Dalvik虚拟机除了可以执行Java代码之外，还可以执行Native代码，也就是C和C++代码。在本文中，我们就将继续以Zygote进程的启动过程为例，来分析Dalvik虚拟机的运行过程。