老罗的Android之旅_罗升阳_CSDN博客-老罗的Android之旅,Android领域博主

罗升阳

码龄13年

IT男，宅，80后

于 2008-04-13 加入CSDN

获得成就

博客专家认证
获得1,000次点赞
内容获得8,204次评论
获得3,410次收藏

荣誉勋章

TA的专栏

老罗的Android之旅
187篇
Android
177篇

进击的程序员

《Android系统源代码情景分析》一书正在进击的程序员网(http://0xcc0xcd.com)中连载，点击进入

Chromium网页渲染技术

Chromium网页渲染技术，更多信息点击进入：http://0xcc0xcd.com

发布资源于 4 年前

Android WebView硬件加速渲染网页UI的过程分析

Android WebView作为App UI的一部分，当App UI以硬件加速方式渲染时，它也是以硬件加速方式渲染的。Android WebView的UI来自于网页，是通过Chromium渲染的。Chromium渲染网页UI的机制与Android App渲染UI的机制是不一样的。不过，它们会一起协作完成网页UI的渲染。本文接下来就详细分析Android WebView硬件加速渲染网页UI的过程。

发布博客于 5 年前

Android WebView执行GPU命令的过程分析

Android WebView使用的Chromium引擎，虽然没有自己的GPU进程或者线程，但是却可以执行GPU命令。原来，Android WebView会给它提供一个In-Process Command Buffer GL接口。通过这个接口，Chromium引擎就可以将GPU命令提交给App的Render Thread执行。本文接下来就详细分析Android WebView执行GPU命令的过程。

发布博客于 5 年前

Android WebView启动Chromium渲染引擎的过程分析

Android WebView加载了Chromium动态库之后，就可以启动Chromium渲染引擎了。Chromium渲染引擎由Browser、Render和GPU三端组成。其中，Browser端负责将网页UI合成在屏幕上，Render端负责加载网页的URL和渲染网页的UI，GPU端负责执行Browser端和Render端请求的GPU命令。本文接下来详细分析Chromium渲染引擎三端的启动过程。

发布博客于 5 年前

Android WebView加载Chromium动态库的过程分析

Chromium动态库的体积比较大，有27M左右，其中程序段和数据段分别占据25.65M和1.35M。如果按照通常方式加载Chromium动态库，那么当有N个正在运行的App使用WebView时，系统需要为Chromium动态库分配的内存为(25.65 + N x 1.35)M。这是非常可观的。为此，Android使用了特殊的方式加载Chromium动态库。本文接下来就详细分析这种特殊的加载方式。

发布博客于 5 年前

Android WebView简要介绍和学习计划

我们通常会在App的UI中嵌入WebView，用来实现某些功能的动态更新。在4.4版本之前，Android WebView基于WebKit实现。不过，在4.4版本之后，Android WebView就换成基于Chromium的实现了。基于Chromium实现，使得WebView可以更快更流畅地显示网页。本文接下来就介绍Android WebView基于Chromium的实现原理，以及制定学习计划。

发布博客于 5 年前

Chromium插件（Plugin）执行3D渲染的过程分析

Chromium为网页的<embed>标签创建了Plugin之后，Plugin就负责渲染<embed>标签的内容。Chromium为Plugin提供了OpenGL接口，使得Plugin可在网页上渲染3D内容。当然，我们也可通过WebGL接口在网页上渲染3D内容。不过，前者渲染效率会更高些，因为它是Native接口，后者是JavaScript接口。本文接下来就详细分析Plugin执行3D渲染的过程。

发布博客于 5 年前

Chromium插件（Plugin）实例（Instance）创建过程分析

Chromium在解析网页时，每遇到一个<embed>标签，就会创建一个Plugin Instance。一般来说，Plugin Instance是在Plugin进程中创建和运行的。一个Plugin Module对应一个Plugin进程，同时可以创建多个不同的Plugin Instance。前面我们已经分析Plugin Module的加载过程了，本文继续分析Plugin Instance的创建过程。

发布博客于 5 年前

Chromium插件（Plugin）模块（Module）加载过程分析

在Chromium中，每一个Plugin都对应一个Module，称为Plugin Module。一个Plugin Module可创建多个Plugin Instance。每一个Plugin Instance对应于网页中的一个<embed>标签。在为<embed>标签创建Plugin Instance之前，先要加载其对应的Plugin Module。本文接下来分析Plugin Module的加载过程。

发布博客于 5 年前

Chromium插件（Plugin）机制简要介绍和学习计划

在Chromium中，除了可以使用Extension增强浏览器功能，还可以使用Plugin。两者最大区别是前者用JS开发，后者用C/C++开发。这意味着Plugin以Native Code运行，在性能上要优于Extension，适合执行计算密集型工作。不过，以Native Code运行，使得Plugin在安全上面临更大挑战。本文接下来对Chromium的Plugin机制进行简要介绍和制定学习计划。

发布博客于 5 年前

Chromium扩展（Extension）通信机制分析

Chromium的Extension由Page和Content Script组成。如果将Extension看作是一个App，那么Page和Content Script就是Extension的Module。既然是Module，就避免不了需要相互通信。也正是由于相互通信，使得它们形成一个完整的App。本文接下来就分析Extension的Page之间以及Page与Content Script之间的通信机制。

发布博客于 5 年前

Chromium扩展（Extension）的Content Script加载过程分析

Chromium的Extension由Page和Content Script组成。Page有UI和JS，它们加载在自己的Extension Process中渲染和执行。Content Script只有JS，这些JS是注入在宿主网页中执行的。Content Script可以访问宿主网页的DOM Tree，从而可以增强宿主网页的功能。本文接下来分析Content Script注入到宿主网页执行的过程。

发布博客于 5 年前

Chromium扩展（Extension）的页面（Page）加载过程分析

Chromium的Extension Page其实就是网页，因此它们的加载过程与普通网页相同。常见的Extension Page有Background Page和Popup Page。其中，Background Page在浏览器窗口初始化完成后自动加载，之后运行在后台中。Popup Page在用户点击地址栏右边的按钮时加载，并且显示在弹窗中。本文接下来就分析Extension Page的加载过程。

发布博客于 5 年前

Chromium扩展（Extension）加载过程分析

Chromium在启动的时候，会根据当前用户的Profile创建一个Extension Service。Extension Service在创建过程中，会加载当前已经安装的所有Extension，并且将它们注册在一个Extension Registry中。以后通过这个Extension Registry，就可以得到当前可用的Extension的信息了。本文接下来就分析Extension的加载过程。

发布博客于 5 年前

Chromium扩展（Extension）机制简要介绍和学习计划

Chromium提供了一种Extension机制，用来增强浏览器功能。我们可以将Extension看作是一种运行在Chromium中的应用。这种应用的开发语言是JavaScript，并且UI通过HTML描述。通过使用Chromium提供的API，Extension可以访问网络，修改浏览器行为，以及操作网页的内容等。本文接下来对Chromium的Extension机制进行简要介绍，以及制定学习计划。

发布博客于 5 年前

Chromium为视频标签

在Chromium中，

发布博客于 5 年前

Chromium为视频标签

在浏览器中，标签与普通标签有一个显著不同点，它们的内容不是由浏览器自己绘制出来，而是由第三方组件提供的。例如，在Android平台上，标签的内容来自于系统播放器MediaPlayer的输出。然而在非全屏模式下，标签的内容又需要像普通标签一样，嵌入在HTML页面中显示，也就是由浏览器进行渲染。本文接下来就分析Chromium渲染标签内容的原理。老罗的新浪微博：http://weibo.com/she

发布博客于 5 年前

Chromium为视频标签

Chromium是通过WebKit解析网页内容的。当WebKit遇到标签时，就会创建一个播放器实例。WebKit是平台无关的，而播放器实现是平台相关的。因此，WebKit并没有自己实现播放器，而仅仅是创建一个播放器接口。通过这个播放器接口，可以使用平台提供的播放器来播放视频的内容。这就简化了Chromium对视频标签的支持。本文接下来就分析Chromium为视频标签创建播放器的过程。老罗的新浪微博

发布博客于 5 年前

Chromium视频标签

随着互联网的发展，在网页上观看视频变得越来越流行，尤其是泛娱乐（手机直播）大行其道的今天。在HTML5之前，在网页上播放视频需要插件支持，例如Flash插件。有了HTML5之后，标签

发布博客于 5 年前

Chromium分发输入事件给WebKit处理的过程分析

Chromium的Render进程接收到Browser进程分发过来的输入事件之后，会在Compoistor线程中处理掉滑动和捏合手势这两种特殊的输入事件，其它类型的输入事件则交给Main线程处理。Main线程又会进一步将输入事件分发给WebKit处理。WebKit则根据输入事件发生的位置在网页中找到对应的HTML元素进行处理。本文接下来详细分析Chromium分发输入事件给WebKit处理的过程。

发布博客于 5 年前

Chromium网页滑动和捏合手势处理过程分析

从前面一文可以知道，Chromium的Browser进程从Touch事件中检测到滑动和捏合手势之后，就会将它们发送给Render进程处理。滑动手势对应于修改网页的Viewport，而捏合手势对应于设置网页的缩放因子。通常我们比较两个浏览器的流畅程度，就是比较它们的滑动和捏合性能。因此，浏览器必须要快速地响应用户的滑动和捏合手势。本文接下来就详细分析Chromium快速响应网页滑动和捏合手势的过程。

发布博客于 5 年前

Chromium网页输入事件捕捉和手势检测过程分析

连续的输入事件可能会产生一定的手势操作，例如滑动手势和捏合手势。在Chromium中，网页的输入事件是在Browser进程中捕捉的。Browser进程捕获输入事件之后，会进行手势操作检测。检测出来的手势操作将会发送给Render进程处理，因为它们需要应用在网页之上。与此同时，Browser进程也会将原始的输入事件发送给Render进程处理。本文接下来就分析Browser进程处理网页输入事件的过程。

发布博客于 5 年前

Chromium网页输入事件处理机制简要介绍和学习计划

用户在浏览网页的时候，需要与网页进行交互，常用的操作如滑动、捏合网页，以及点击网页中的链接等。这些交互操作也称为用户输入事件，浏览器需要对它们作出迅速的响应，例如及时更新网页内容或者打开新的网页等。浏览器能够对用户输入事件作出迅速的响应是至关重要的，因为这关乎到用户浏览网页时的体验，尤其是在用户滑动和捏合网页时。本文接下来就简要介绍Chromium对用户输入事件的处理机制，以及制定后续的学习计划。

发布博客于 5 年前

Chromium网页Pending Layer Tree激活为Active Layer Tree的过程分析

网页分块的光栅化操作完成后，CC Pending Layer Tree就会激活为CC Active Layer Tree。CC Active Layer Tree代表用户当前在屏幕上看到的网页内容，它可以快速响应用户输入，例如滚动和缩放。本文接下来就分析CC Pending Layer Tree激活为CC Active Layer Tree，以及CC Active Layer Tree的渲染过程。

发布博客于 5 年前

Chromium网页CPU光栅化原理分析

Chromium除了支持网页分块GPU光栅化，还支持CPU光栅化。GPU光栅化的特点是快，缺点是硬件之间可能会导差异性，以及不是所有的绘图操作硬件都能很好地支持。CPU光栅化的特点是通用，以及能够支持所有的绘图操作，缺点是较慢，特别是在网页使用硬件加速渲染的情况下，CPU的光栅化结果还需要上传到GPU去渲染。本文接下来将详细分析CPU光栅化的原理，着重描述它是如何快速地光栅化结果上传到GPU去的。

发布博客于 5 年前

Chromium网页GPU光栅化原理分析

在前面一篇文章中，我们分析了网页分块的光栅化过程。根据Chromium的启动选项，网页分块有可能使用GPU来执行光栅化操作，也有可能使用CPU来执行光栅化操作。不管是使用GPU，还是CPU，光栅化操作最终都是统一通过调用Skia图形库提供的绘图接口完成的。如果使用GPU来执行光栅化操作，那么当它在调用绘图接口的时候，实际上是在执行相应的OpenGL命令。本文接下来就详细分析GPU光栅化的实现原理。

发布博客于 5 年前

Chromium网页光栅化过程分析

在前面一篇文章中，我们分析了网页CC Layer Tree同步为CC Pending Layer Tree的过程。同步操作完成后，CC Pending Layer Tree中的每一个Layer都会被划分成一系列的分块，并且每一个分块都会被赋予一个优先级。接下来CC模块会根据优先级对分块进行排序。优先级越高的分块越排在前面，越排在前面的分块就越快得到光栅化。本文接下来就详细分析网页分块的光栅化过程。

发布博客于 5 年前

Chromium网页Layer Tree同步为Pending Layer Tree的过程分析

CC Layer Tree绘制完成后，会同步到一个新的CC Pending Layer Tree去。同步过程由Compositor线程执行，并且Main线程处于等待状态。所谓同步，就是将CC Layer Tree的内容拷贝到CC Pending Layer Tree去。同步完毕，Main线程就会被唤醒。本文接下来分析CC Layer Tree同步为CC Pending Layer Tree的过程。

发布博客于 5 年前

Chromium网页Layer Tree绘制过程分析

网页绘图表面创建完成之后，调度器就会请求绘制CC Layer Tree，这样网页在加载完成之后就能快速显示出来。通过CC Layer Tree可以依次找到Graphics Layer Tree、Render Layer Tree和Render Object Tree。有了Render Object Tree之后，就可以执行具体的绘制工作了。接下来我们就分析网页CC Layer Tree的绘制过程。

发布博客于 5 年前

Chromium网页绘图表面（Output Surface）创建过程分析

在Chromium中，Render进程在绘制网页之前，要为网页创建一个绘图表面。绘图表面描述的是网页经过渲染之后得到的输出。这个输出需要交给Browser进程处理，才能显示在屏幕上。在硬件加速渲染条件下，这个输出有可能是一个OpenGL纹理，也有可能是一系列需要进一步进行绘制的OpenGL纹理，取决于Render进程使用直接渲染器还是委托渲染器。本文接下来就对网页的绘图表面的创建过程进行详细分析。

发布博客于 5 年前

Chromium网页渲染调度器（Scheduler）实现分析

在采用线程化渲染方式渲染网页时，Chromium依赖一个调度器协调Main线程和Compositor线程的执行，同时也通过这个调度器决定它们什么时候该执行什么操作。调度器将Main线程和Compositor线程的当前状态记录在一个状态机中，然后通过这个状态机决定下一个要执行的操作。这个操作在满足当前设置条件下是最优的，因此可以使网页渲染更快更流畅。本文接下来就分析Chromium网页调度器的实现。

发布博客于 5 年前

Chromium网页Layer Tree创建过程分析

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

发布博客于 5 年前

Chromium网页渲染机制简要介绍和学习计划

作为一个浏览器，快速地将网页渲染出来是最重要的工作。Chromium为了做到这一点，费尽了心机，做了大量优化工作。这些优化工作是卓有成效的，代表了当今最先进的网页渲染技术。值得一提的是，这些渲染技术不仅适用于网页渲染，也可以应用在原生系统的UI渲染上。例如，在Android系统上，我们就可以看到两者在渲染技术上的相似之处。本文接下来就对Chromium的网页渲染机制进行简要介绍，并且制定学习计划。

发布博客于 5 年前

Chromium网页Graphics Layer Tree创建过程分析

在前面一文中，我们分析了网页Render Layer Tree的创建过程。在创建Render Layer的同时，WebKit还会为其创建Graphics Layer。这些Graphics Layer形成一个Graphics Layer Tree。Graphics Layer可看作是一个图形缓冲区，被若干Render Layer共用。本文接下来就分析Graphics Layer Tree的创建过程。

发布博客于 5 年前

Chromium网页Render Layer Tree创建过程分析

在前面一文中，我们分析了网页Render Object Tree的创建过程。在创建Render Object Tree的同时，WebKit还会创建Render Layer Tree，但不是每一个Render Object都有对应的Render Layer。Render Layer是一个最小渲染单元，被若干Render Object共用。本文接下来就分析Render Layer Tree的创建过程。

发布博客于 5 年前

Chromium网页Render Object Tree创建过程分析

在前面一文中，我们分析了网页DOM Tree的创建过程。网页DOM Tree创建完成之后，WebKit会根据它的内容创建一个Render Object Tree。Render Object Tree是和网页渲染有关的一个Tree。这意味着只有在DOM Tree中需要渲染的节点才会在Render Object Tree中有对应节点。本文接下来就分析网页Render Object Tree的创建过程。

发布博客于 5 年前

Chromium网页DOM Tree创建过程分析

在Chromium中，Render进程是通过Browser进程下载网页内容的，后者又是通过共享内存将下载回来的网页内容交给前者的。Render进程获得网页内容之后，会交给WebKit进行处理。WebKit所做的第一个处理就是对网页内容进行解析，解析的结果是得到一棵DOM Tree。DOM Tree是网页的一种结构化描述，也是网页渲染的基础。本文接下来就对网页DOM Tree的创建过程进行详细分析。

发布博客于 5 年前

Chromium网页URL加载过程分析

Chromium在Browser进程中为网页创建了一个Frame Tree之后，会将网页的URL发送给Render进程进行加载。Render进程接收到网页URL加载请求之后，会做一些必要的初始化工作，然后请求Browser进程下载网页的内容。Browser进程一边下载网页内容，一边又通过共享内存将网页内容传递给Render进程解析，也就是创建DOM Tree。本文接下来就分析网页URL的加载过程。

发布博客于 5 年前

Chromium网页Frame Tree创建过程分析

Chromium在加载一个网页之前，需要在Browser进程创建一个Frame Tree。Browser进程为网页创建了Frame Tree之后，再请求Render进程加载其内容。Frame Tree将网页抽象为Render Frame。Render Frame是为实现Out-of-Process iframes设计的。本文接下来就分析Frame Tree的创建过程，为后面分析网页加载过程打基础。

发布博客于 5 年前

Chromium网页加载过程简要介绍和学习计划

Chromium加载网页的过程，需要Browser进程和Render进程协作完成。加载网页的过程由Browser进程发起，向服务器请求网页内容的过程也是由Browser进程完成。Render进程负责对下载回来的网页内容进行解析，解析之后得到一个DOM Tree。有了这个DOM Tree之后，Render进程就可以对网页进行渲染了。本文接下来就对上述过程涉及到的重要概念进行简要介绍以及制定学习计划。

发布博客于 5 年前

Chromium硬件加速渲染的UI合成过程分析

在Chromium中，Render端和WebGL端绘制出来的UI最终是通过Browser端显示在屏幕上的。换句话说，就是Browser端负责合成Render端和WebGL端的UI。这涉及到不同OpenGL上下文之间的资源传递和同步问题。其中，资源传递问题通过Mailbox机制解决，同步问题通过Sync Point机制解决。本文接下来就分析Browser端合成Render端和WebGL端UI的过程。

发布博客于 6 年前

Chromium硬件加速渲染的OpenGL上下文调度过程分析

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

发布博客于 6 年前

Chromium硬件加速渲染的GPU数据上传机制分析

在Chromium中，WebGL端、Render端和Browser端通过命令缓冲区将GPU命令发送给GPU进程执行。GPU命令携带的简单参数也通过命令缓冲区发送给GPU进程，但复杂参数，例如纹理数据，有可能太大，以致于命令缓冲区无法容纳，因此要通过其它机制传递给GPU进程。本文接下来就主要以纹理数据上传为例，分析WebGL端、Render端和Browser端将GPU命令数据传递给GPU进程的机制。

发布博客于 6 年前

Chromium硬件加速渲染的OpenGL命令执行过程分析

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

发布博客于 6 年前

Chromium硬件加速渲染的OpenGL上下文创建过程分析

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

发布博客于 6 年前

Chromium硬件加速渲染的OpenGL上下文绘图表面创建过程分析

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

发布博客于 6 年前

Chromium硬件加速渲染机制基础知识简要介绍和学习计划

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

发布博客于 6 年前

Chromium的Plugin进程启动过程分析

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

发布博客于 6 年前

Chromium的GPU进程启动过程分析

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

发布博客于 6 年前

Chromium的IPC消息发送、接收和分发机制分析

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

发布博客于 6 年前

Chromium的Render进程启动过程分析

在配置多进程的情况下，Chromium的网页渲染和JS执行在一个单独的进程中进行。这个进程称为Render进程，由Browser进程启动。在Android平台中，Browser进程就是Android应用程序的主进程，而Render进程就是Android应用程序的Service进程，它们通过UNIX Socket进行通信。本文就详细分析Chromium的Browser进程启动Render进程的过程。

发布博客于 6 年前

Chromium多进程架构简要介绍和学习计划

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

发布博客于 6 年前

Chromium多线程模型设计和实现分析

Chromium除了远近闻名的多进程架构之外，它的多线程模型也相当引人注目的。Chromium的多进程架构是为了解决网页的稳定性问题，而多线程模型则是为了解决网页的卡顿问题。为了达到这个目的，Chromium的多线程模型是基于异步通信的。也就是说，一个线程请求另外一个线程执行一个任务的时候，不需要等待该任务完成就可以去做其它事情，从而避免了卡顿。本文就分析Chromium的多线程模型的设计和实现。

发布博客于 6 年前

Chromium多线程通信的Closure机制分析

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

发布博客于 6 年前

Chromium和WebKit的智能指针实现原理分析

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

发布博客于 6 年前

Android Chromium WebView学习启动篇

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

发布博客于 6 年前

Android应用程序UI硬件加速渲染的动画执行过程分析

通常我们说一个系统不如另一个系统流畅，说的就是前者动画显示不如后者流畅，因此动画显示流畅程度是衡量一个系统流畅性的关键指标。为什么这样说呢？这是因为流畅的动画显示需要60fps的UI刷新速度，然而这却不是一个容易达到的速度。Android 5.0通过引入Render Thread尽最大努力提升动画显示流畅性。本文就分析Render Thread显示动画的过程，以便了解它是如何提高动画显示流畅性的。

发布博客于 6 年前

Android应用程序UI硬件加速渲染的Display List渲染过程分析

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

发布博客于 6 年前

Android应用程序UI硬件加速渲染的Display List构建过程分析

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

发布博客于 6 年前

Android应用程序UI硬件加速渲染的预加载资源地图集服务（Asset Atlas Service）分析

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

发布博客于 6 年前

Android应用程序UI硬件加速渲染环境初始化过程分析

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

发布博客于 6 年前

Android应用程序UI硬件加速渲染技术简要介绍和学习计划

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

发布博客于 6 年前

ART运行时Foreground GC和Background GC切换过程分析

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

发布博客于 6 年前

ART运行时Mark-Compact（ MC）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的执行过程。

发布博客于 6 年前

ART运行时Semi-Space（SS）和Generational Semi-Space（GSS）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的执行过程分析进行详细分析。

发布博客于 6 年前

ART运行时Compacting GC为新创建对象分配内存的过程分析

在引进Compacting GC后，ART运行时优化了堆内存分配过程。最显著特点是为每个ART运行时线程增加局部分配缓冲区（Thead Local Allocation Buffer）和在OOM前进行一次同构空间压缩（Homogeneous Space Compact）。前者可提高堆内存分配效率，后者可解决内存碎片问题。本文就对ART运行时引进Compacting GC后的堆内存分配过程进行分析。

发布博客于 6 年前

ART运行时Compacting GC堆创建过程分析

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

发布博客于 6 年前

ART运行时Compacting GC简要介绍和学习计划

在前面一个系列文章中，我们学习了Android 4.4 ART的Mark-Sweep（MS）GC。到了Android 5.0，ART增加了对Compacting GC的支持，包括Semi-Space（SS）、Generational Semi-Space（GSS）和Mark-Compact（MC）三种。本文对Android 5.0 ART的Compacting GC进行简要介绍以及制定学习计划。

发布博客于 6 年前

Linking:Computer Systems--A Programmer_s Perspective

Linking:Computer Systems--A Programmer_s Perspective

发布资源于 6 年前

ART运行时垃圾收集（GC）过程分析

ART运行时与Dalvik虚拟机一样，都使用了Mark-Sweep算法进行垃圾回收，因此它们的垃圾回收流程在总体上是一致的。但是ART运行时对堆的划分更加细致，因而在此基础上实现了更多样的回收策略。不同的策略有不同的回收力度，力度越大的回收策略，每次回收的内存就越多，并且它们都有各自的使用情景。这样就可以使得每次执行GC时，可以最大限度地减少应用程序停顿。本文就详细分析ART运行时的垃圾收集过程。

发布博客于 6 年前

ART运行时为新创建对象分配内存的过程分析

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

发布博客于 6 年前

ART运行时Java堆创建过程分析

与Dalvik虚拟机一样，ART运行时内部也有一个Java堆，用来分配Java对象。当这些Java对象不再被使用时，ART运行时需要回收它们占用的内存。在前面一文中，我们简要介绍了ART运行时的垃圾收集机制，从中了解到ART运行时内部使用的Java堆是由四种Space以及各种辅助数据结构共同描述的。为了后面可以更好地分析ART运行时的垃圾收集机制，本文就对它内部使用的Java堆的创建过程进行分析。

发布博客于 6 年前

ART运行时垃圾收集机制简要介绍和学习计划

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

发布博客于 6 年前

Dalvik虚拟机垃圾收集（GC）过程分析

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

发布博客于 7 年前

Dalvik虚拟机为新创建对象分配内存的过程分析

在前面一文中，我们分析了Dalvik虚拟机创建Java堆的过程。有了Java堆之后，Dalvik虚拟机就可以在上面为对象分配内存了。在Java堆为对象分配内存需要解决内存碎片和内存不足两个问题。要解决内存碎片问题，就要找到一块大小最合适的空闲内存分配给对象使用。而内存不足有可能是内存配额用完引起的，也有可能是垃圾没有及时回收引起的，要区别对待。本文就详细分析Dalvik虚拟机是如何解决这些问题的。

发布博客于 7 年前

Dalvik虚拟机Java堆创建过程分析

使用C/C++开发应用程序最令头痛的问题就是内存管理。慎不留神，要么内存泄漏，要么内存破坏。虚拟机要解决的问题之一就是帮助应用程序自动分配和释放内存。为了达到这个目的，虚拟机在启动的时候向操作系统申请一大块内存当作对象堆。之后当应用程序创建对象时，虚拟机就会在堆上分配合适的内存块。而当对象不再使用时，虚拟机就会将它占用的内存块归还给堆。Dalvik虚拟机也不例外，本文就分析它的Java堆创建过程。

发布博客于 7 年前

Dalvik虚拟机垃圾收集机制简要介绍和学习计划

伴随着“Dalvik is dead，long live Dalvik“这行AOSP代码提交日志，在Android5.0中，ART运行时取代了Dalvik虚拟机。虽然Dalvik虚拟机不再使用，但是它曾经的作用是不可磨灭的。因此，在研究ART运行时的垃圾收集机制之前，先理解Dalvik虚拟机的垃圾收集机制也是很重要和有帮助的。因此，本文就对Dalvik虚拟机的垃圾收集机进行简要介绍和制定学习计划。

发布博客于 7 年前

Android运行时ART执行类方法的过程分析

在前面一篇文章中，我们分析了ART运行时加载类以及查找其方法的过程。一旦找到了目标类方法，我们就可以获得它的DEX字节码或者本地机器指令，这样就可以对它进行执行了。在ART运行时中，类方法的执行方式有两种。一种是像Dalvik虚拟机一样，将其DEX字节码交给解释器执行；另一种则是直接将其本地机器指令交给CPU执行。在本文中，我们就将通过分析ART运行时执行类方法的过程来理解ART运行时的运行原理。

发布博客于 7 年前

Android运行时ART加载类和方法的过程分析

在前一篇文章中，我们通过分析OAT文件的加载过程，认识了OAT文件的格式，其中包含了原始的DEX文件。既然ART运行时执行的都是翻译DEX字节码后得到的本地机器指令了，为什么还需要在OAT文件中包含DEX文件，并且将它加载到内存去呢？这是因为ART运行时提供了Java虚拟机接口，而要实现Java虚拟机接口不得不依赖于DEX文件。本文就通过分析ART运行时加载类及其方法的过程来理解DEX文件的作用。

发布博客于 7 年前

Android运行时ART加载OAT文件的过程分析

在前面一文中，我们介绍了Android运行时ART，它的核心是OAT文件。OAT文件是一种Android私有ELF文件格式，它不仅包含有从DEX文件翻译而来的本地机器指令，还包含有原来的DEX文件内容。这使得我们无需重新编译原有的APK就可以让它正常地在ART里面运行，也就是我们不需要改变原来的APK编程接口。本文我们通过OAT文件的加载过程分析OAT文件的结构，为后面分析ART的工作原理打基础。

发布博客于 7 年前

Android运行时ART简要介绍和学习计划

Android在4.4就已推出新运行时ART，准备替代用了有些时日的Dalvik。不过当时尚属测试版，主角仍是Dalvik。直到今年的Google I/O大会，ART才正式取代Dalvik。这个消息在科技界引起不小轰动，也吸引不少技术人员对它的“技术分析”。可惜这些“技术分析”不过是引用了官方的数据和图表而已。这一系列文章将对ART进行真正的技术分析。老规矩，分析前先进行简要介绍和制定学习计划。

发布博客于 7 年前

SEAndroid安全机制对Binder IPC的保护分析

在SEAndroid安全机制中，除了文件和属性，还有Binder IPC需要保护。Binder IPC是Android系统的灵魂，使用得相当广泛又频繁。例如，应用程序都是Binder IPC请求访问系统服务和资源。因此，SEAndroid安全机制必须要为Binder IPC保驾护航，阻止一个进程非法访问其它进程的服务和资源。本文就详细分析SEAndroid安全机制对Binder IPC提供的支持。

发布博客于 7 年前

SEAndroid安全机制对Android属性访问的保护分析

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

发布博客于 7 年前

SEAndroid安全机制中的进程安全上下文关联分析

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

发布博客于 7 年前

SEAndroid安全机制中的文件安全上下文关联分析

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

发布博客于 7 年前

SEAndroid安全机制框架分析

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

发布博客于 7 年前

SEAndroid安全机制简要介绍和学习计划

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

发布博客于 7 年前

从CM刷机过程和原理分析Android系统结构

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

发布博客于 7 年前

Android系统镜像文件的打包过程分析

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

发布博客于 7 年前

Android源代码编译命令m/mm/mmm/make分析

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

发布博客于 7 年前

Android编译系统环境初始化过程分析

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

发布博客于 7 年前

Android编译系统简要介绍和学习计划

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

发布博客于 7 年前

APK防反编译技术PPT

我们的APK实际上就是一个ZIP压缩文件，里面包含有一个classes.dex，我们编译后生成的程序代码就全部在那里了，通过apktool等工具可以轻松地将它们反编译成smali代码。有了这些反编译出来的smali代码之后，我们就可以轻松地了解别人的APK使用的一些技术或者直接修改别人的APK。由于这些APK反编译工具的存在，我们迫切地希望能有方法去防止别人来反编译我们的APK，从而保护自己的商业机密和利益。

发布资源于 7 年前

Android安全机制 PPT版本

Android应用程序是运行在一个沙箱中。这个沙箱是基于Linux内核提供的用户ID（UID）和用户组ID（GID）来实现的。Android应用程序在安装的过程中，安装服务PackageManagerService会为它们分配一个唯一的UID和GID，以及根据应用程序所申请的权限，赋予其它的GID。有了这些UID和GID之后，应用程序就只能限访问特定的文件，一般就是只能访问自己创建的文件。此外，Android应用程序在调用敏感的API时，系统检查它在安装的时候会没有申请相应的权限。如果没有申请的话，那么访问也会被拒绝。对于有root权限的应用程序，则不受上述沙箱限制。此外，有root权限的应用程序，还可以通过Linux的ptrace注入到其它应用程序进程，以及系统进程，进行各种函数调用拦截。

发布资源于 7 年前

Android源代码仓库及其管理工具Repo分析

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

发布博客于 7 年前

Android ART运行时无缝替换Dalvik虚拟机的过程分析

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

发布博客于 7 年前

从NDK在非Root手机上的调试原理探讨Android的安全机制

最近忙着研究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呢？借这两问题正好可以介绍一

发布博客于 8 年前

Android硬件抽象层(HAL)

Android硬件抽象层从开发到使用有一个清晰的层次。这个层次恰好对应了Android系统的架构层次，它向下涉及到Linux内核，向上涉及到应用程序框架层的服务，以及应用程序层对它的使用。Android硬件抽象层模块的开发本身也遵循一定的规范。有了这个规范之后，系统就可以对它进行自动加载，方便上层的使用。这个PPT通过一个具体的实例来分析Android硬件抽象层的开发、测试和使用，它在帮助我们理解Android系统架构的同时，也能教会我们如何在Android源代码环境中开发C/C++代码。

发布资源于 8 年前

Android应用程序输入事件处理机制

在Android应用程序中，有一类特殊的消息，是专门负责与用户进行交互的，它们就是触摸屏和键盘等输入事件。触摸屏和键盘事件是统一由系统输入管理器InputManager进行分发的。也就是说，InputManager负责从硬件接收输入事件，然后再将接收到的输入事件分发当前激活的窗口处理。此外，InputManager也能接收模拟的输入事件，用来模拟用户触摸和点击等事件。当前激活的窗口所运行在的线程接收到InputManager分发过来的输入事件之后，会将它们封装成输入消息，然后交给当前获得焦点的控件处理。这个PPT讲Android应用程序输入事件的分发和处理过程，主要涉及到输入管理InputManager、输入事件监控线程InputReader、输入事件分发线程InputDispatcher，以及应用程序主线程消息循环。

发布资源于 8 年前

Dalvik虚拟机 PPT版

Android应用程序是运行在Dalvik虚拟机里面的，并且每一个应用程序对应有一个单独的Dalvik虚拟机实例。Android应用程序中的Dalvik虚拟机实例实际上是从Zygote进程的地址空间拷贝而来的，这样就可以加快Android应用程序的启动速度。Dalvik虚拟机与Java虚拟机共享有差不多的特性，例如，它们都是解释执行，并且支持即时编译（JIT）、垃圾收集（GC）、Java本地方法调用（JNI）和Java远程调试协议（JDWP）等，差别在于两者执行的指令集是不一样的，并且前者的指令集是基本寄存器的，而后者的指令集是基于堆栈的。这个PPT讲Dalvik虚拟机的内存管理、垃圾收集、即时编译、Java本地调用、进程和线程管理等。理解Dalvik虚拟机的上述实现细节，有助于在运行时修改程序的行为，例如，拦截Java函数的调用。

发布资源于 8 年前