- 博客(187)
- 资源 (18)
- 收藏
- 关注
原创 Chromium网页DOM Tree创建过程分析
在Chromium中,Render进程是通过Browser进程下载网页内容的,后者又是通过共享内存将下载回来的网页内容交给前者的。Render进程获得网页内容之后,会交给WebKit进行处理。WebKit所做的第一个处理就是对网页内容进行解析,解析的结果是得到一棵DOM Tree。DOM Tree是网页的一种结构化描述,也是网页渲染的基础。本文接下来就对网页DOM Tree的创建过程进行详细分析。
2016-02-01 01:01:53 19708 14
原创 Chromium网页URL加载过程分析
Chromium在Browser进程中为网页创建了一个Frame Tree之后,会将网页的URL发送给Render进程进行加载。Render进程接收到网页URL加载请求之后,会做一些必要的初始化工作,然后请求Browser进程下载网页的内容。Browser进程一边下载网页内容,一边又通过共享内存将网页内容传递给Render进程解析,也就是创建DOM Tree。本文接下来就分析网页URL的加载过程。
2016-01-25 01:00:01 36287 9
原创 Chromium网页Frame Tree创建过程分析
Chromium在加载一个网页之前,需要在Browser进程创建一个Frame Tree。Browser进程为网页创建了Frame Tree之后,再请求Render进程加载其内容。Frame Tree将网页抽象为Render Frame。Render Frame是为实现Out-of-Process iframes设计的。本文接下来就分析Frame Tree的创建过程,为后面分析网页加载过程打基础。
2016-01-11 00:59:55 26659 22
原创 Chromium网页加载过程简要介绍和学习计划
Chromium加载网页的过程,需要Browser进程和Render进程协作完成。加载网页的过程由Browser进程发起,向服务器请求网页内容的过程也是由Browser进程完成。Render进程负责对下载回来的网页内容进行解析,解析之后得到一个DOM Tree。有了这个DOM Tree之后,Render进程就可以对网页进行渲染了。本文接下来就对上述过程涉及到的重要概念进行简要介绍以及制定学习计划。
2016-01-04 00:59:53 29257 11
原创 Chromium硬件加速渲染的UI合成过程分析
在Chromium中,Render端和WebGL端绘制出来的UI最终是通过Browser端显示在屏幕上的。换句话说,就是Browser端负责合成Render端和WebGL端的UI。这涉及到不同OpenGL上下文之间的资源传递和同步问题。其中,资源传递问题通过Mailbox机制解决,同步问题通过Sync Point机制解决。本文接下来就分析Browser端合成Render端和WebGL端UI的过程。
2015-12-21 00:58:58 22883 18
原创 Chromium硬件加速渲染的OpenGL上下文调度过程分析
Chromium的每一个WebGL端、Render端和Browser端实例在GPU进程中都有一个OpenGL上下文。这些OpenGL上下文运行在相同线程中,因此同一时刻只有一个OpenGL上下文处于运行状态。这就引发出一个OpenGL上下文调度问题。此外,事情有轻重缓急,OpenGL上下文也有优先级高低之分,优先级高的要保证它的运行时间。本文接下来就分析GPU进程调度运行OpenGL上下文的过程。
2015-12-07 01:02:07 16090 20
原创 Chromium硬件加速渲染的GPU数据上传机制分析
在Chromium中,WebGL端、Render端和Browser端通过命令缓冲区将GPU命令发送给GPU进程执行。GPU命令携带的简单参数也通过命令缓冲区发送给GPU进程,但复杂参数,例如纹理数据,有可能太大,以致于命令缓冲区无法容纳,因此要通过其它机制传递给GPU进程。本文接下来就主要以纹理数据上传为例,分析WebGL端、Render端和Browser端将GPU命令数据传递给GPU进程的机制。
2015-11-23 01:01:05 16292 15
原创 Chromium硬件加速渲染的OpenGL命令执行过程分析
在Chromium中,由于GPU进程的存在,WebGL端、Render端和Browser端的GPU命令是代理给GPU进程执行的。Chromium将它们要执行的GPU命令进行编码,然后写入到一个命令缓冲区中,最后传递给GPU进程。GPU进程从这个命令缓冲区读出GPU命令之后,就进行解码,然后调用对应的OpenGL函数。本文就详细分析WebGL端、Render端和Browser端执行GPU命令的过程。。
2015-11-09 01:00:19 19249 5
原创 Chromium硬件加速渲染的OpenGL上下文创建过程分析
在Chromium中,WebGL端、Render端和Browser端的GPU命令都是通过GPU进程中的一个GPU线程来执行的。这三端的GPU命令是独立执行的,不能相互发生影响。为了达到这个目的,GPU线程分别为它们创建不同的OpenGL上下文,并且使得它们的GPU命令在各自的OpenGL上下文中执行。本文接下来就详细分析WebGL端、Render端和Browser端的OpenGL上下文的创建过程。
2015-11-02 01:00:27 13923 7
原创 Chromium硬件加速渲染的OpenGL上下文绘图表面创建过程分析
GPU命令需要在OpenGL上下文中执行。每一个OpenGL上下文都关联有一个绘图表面,GPU命令就是作用在绘图表面上的。不同用途的OpenGL上下文关联的绘图表面不一样,例如用于离屏渲染的OpenGL上下文关联的绘图表面可以用Pbuffer描述,而用于屏幕渲染的OpenGL上下文的绘图表面要用本地窗口描述。本文接下来就分析Chromium硬件加速渲染涉及到的OpenGL上下文的绘图表面创建过程。
2015-10-19 01:00:34 18824 7
原创 Chromium硬件加速渲染机制基础知识简要介绍和学习计划
Chromium支持硬件加速渲染网页,即使用GPU渲染网页。在多进程架构下,Browser、Render和Plugin进程的GPU命令不是在本进程中执行的,而是转发给GPU进程执行。这是因为GPU命令是硬件相关操作,不同平台的实现不一样,从而导致不稳定,而将不稳定操作放在独立进程中执行可以保护主进程的稳定性。本文对Chromium硬件加速渲染机制的基础知识进行简要介绍和制定学习计划。
2015-10-12 01:01:05 19726 12
原创 Chromium的Plugin进程启动过程分析
前面我们分析了Chromium的Render进程和GPU进程的启动过程,它们都是由Browser进程启动的。在Chromium中,还有一类进程是由Browser进程启动的,它们就是Plugin进程。顾名思义,Plugin进程是用来运行浏览器插件的。浏览器插件的作用是扩展网页功能,它们由第三方开发,安全性和稳定性都无法得到保证,因此运行在独立的进程中。本文接下来就详细分析Plugin进程的启动过程。
2015-09-21 01:00:39 18219 3
原创 Chromium的GPU进程启动过程分析
Chromium除了有Browser进程和Render进程,还有GPU进程。GPU进程负责Chromium的GPU操作,例如Render进程通过GPU进程离屏渲染网页,Browser进程也是通过GPU进程将离屏渲染好的网页显示在屏幕上。Chromium之所以将GPU操作运行在独立进程中,是考虑到稳定性问题。毕竟GPU操作是硬件相关操作,硬件的差异性会引发一定的不稳性。本文分析GPU进程的启动过程。
2015-09-14 01:01:24 28569 8
原创 Chromium的IPC消息发送、接收和分发机制分析
由于Chromium采用多进程架构,因此会涉及到进程间通信问题。通过前面一文的学习,我们知道Browser进程在启动Render进程的过程中会建立一个以UNIX Socket为基础的IPC通道。有了IPC通道之后,接下来Browser进程与Render进程就以消息的形式进行通信。我们将这种消息称为IPC消息,以区别于线程消息循环中的消息。本文就分析Chromium的IPC消息发送、接收和分发机制。
2015-08-31 01:01:13 28954 10
原创 Chromium的Render进程启动过程分析
在配置多进程的情况下,Chromium的网页渲染和JS执行在一个单独的进程中进行。这个进程称为Render进程,由Browser进程启动。在Android平台中,Browser进程就是Android应用程序的主进程,而Render进程就是Android应用程序的Service进程,它们通过UNIX Socket进行通信。本文就详细分析Chromium的Browser进程启动Render进程的过程。
2015-08-24 01:06:51 31897 12
原创 Chromium多进程架构简要介绍和学习计划
Chromium以多进程架构著称,它主要包含四类进程,分别是Browser进程、Render进程、GPU进程和Plugin进程。之所以要将Render进程、GPU进程和Plugin进程独立出来,是为了解决它们的不稳定性问题。也就是说,Render进程、GPU进程和Plugin进程由于不稳定而引发的Crash不会导致整个浏览器崩溃。本文就对Chromium的多进程架构进行简要介绍,以及制定学习计划。
2015-08-10 01:04:40 26526 12
原创 Chromium多线程模型设计和实现分析
Chromium除了远近闻名的多进程架构之外,它的多线程模型也相当引人注目的。Chromium的多进程架构是为了解决网页的稳定性问题,而多线程模型则是为了解决网页的卡顿问题。为了达到这个目的,Chromium的多线程模型是基于异步通信的。也就是说,一个线程请求另外一个线程执行一个任务的时候,不需要等待该任务完成就可以去做其它事情,从而避免了卡顿。本文就分析Chromium的多线程模型的设计和实现。
2015-07-27 00:59:08 34911 19
原创 Chromium多线程通信的Closure机制分析
为了充分利用CPU多核特性,Chromium在启动时会创建很多线程,来负责执行不同的操作。这样就涉及到了多线程通信问题。Chromium为每一个线程都创建了一个消息队列。当一个线程需要另一个线程执行某一操作时,就向该线程的消息队列发送一个Callback。这个Callback最终在目标线程中得到执行。这种基于Callback的多线程通信方式在Chromium中很普通,因此本文就对它的实现进行分析。
2015-07-13 01:01:05 27505 11
原创 Chromium和WebKit的智能指针实现原理分析
C++不像Java一样,由虚拟机负责对象分配和释放。也就是说,开发人员使用C++编写代码时,要自己负责对象分配和释放。WebKit和Chromium都是使用C++开发的,因此它们也面临上述问题。在解决对象释放问题时,要做到在对象不需要时自动释放,因为手动释放会带来忘记释放或者释放后又继续使用的隐患。智能指针是实现对象自动释放的有效技术手段。本文就分析Chromium和WebKit的智能指针的实现。
2015-07-06 01:01:53 26501 23
原创 Android Chromium WebView学习启动篇
Android从4.4起提供基于Chromium实现的WebView。此前WebView基于WebKit实现。WebKit提供网页解析、布局和绘制以及JS运行等基础功能。Chromium在WebKit基础上为WebView提供进程、线程和渲染等基础构架。因此基于Chromium实现的WebView更好地提供了网页浏览功能。从本文开始我们启动对Android Chromium WebView的学习。
2015-06-29 01:01:09 52989 46
原创 Android应用程序UI硬件加速渲染的动画执行过程分析
通常我们说一个系统不如另一个系统流畅,说的就是前者动画显示不如后者流畅,因此动画显示流畅程度是衡量一个系统流畅性的关键指标。为什么这样说呢?这是因为流畅的动画显示需要60fps的UI刷新速度,然而这却不是一个容易达到的速度。Android 5.0通过引入Render Thread尽最大努力提升动画显示流畅性。本文就分析Render Thread显示动画的过程,以便了解它是如何提高动画显示流畅性的。
2015-06-23 01:00:40 28380 16
原创 Android应用程序UI硬件加速渲染的Display List渲染过程分析
在硬件加速渲染环境中,Android应用程序窗口的UI渲染是分两步进行的。第一步是构建Display List,发生在应用程序进程的Main Thread中;第二步是渲染Display List,发生在应用程序进程的Render Thread中。Display List的渲染不是简单地执行绘制命令,而是包含了一系列优化操作,例如绘制命令的合并执行。本文就详细分析Display List的渲染过程。
2015-06-15 01:01:12 39411 23
原创 Android应用程序UI硬件加速渲染的Display List构建过程分析
在硬件加速渲染环境中,Android应用程序窗口的UI渲染是分两步进行的。第一步是构建Display List,发生在应用程序进程的Main Thread中;第二步是渲染Display List,发生在应用程序进程的Render Thread中。Display List是以视图为单位进行构建的,因此每一个视图都对应有一个Display List。本文详细分析这些Display List的构建过程。
2015-06-01 01:00:59 34407 18
原创 Android应用程序UI硬件加速渲染的预加载资源地图集服务(Asset Atlas Service)分析
我们知道,Android系统在启动的时候,会对一些系统资源进行预加载。这样不仅使得应用程序在需要时可以快速地访问这些资源,还使得这些资源能够在不同应用程序之间进行共享。在硬件加速渲染环境中,这些预加载资源还有进一步优化的空间。Android系统提供了一个地图集服务,负责将预加载资源合成为一个纹理上传到GPU去,并且能够在所有的应用程序之间进行共享。本文就详细分析这个预加载资源地图集服务的实现原理。
2015-05-25 00:58:30 19426 7
原创 Android应用程序UI硬件加速渲染环境初始化过程分析
在Android应用程序中,我们是通过Canvas API来绘制UI元素的。在硬件加速渲染环境中,这些Canvas API调用最终会转化为Open GL API调用(转化过程对应用程序来说是透明的)。由于Open GL API调用要求发生在Open GL环境中,因此在每当有新的Activity窗口启动时,系统都会为其初始化好Open GL环境。这篇文章就详细分析这个Open GL环境的初始化过程。
2015-05-18 00:59:05 40238 14
原创 Android应用程序UI硬件加速渲染技术简要介绍和学习计划
Android系统的流畅性一直被拿来与iOS比较,并且认为不如后者。这一方面与Android设备硬件质量参差不齐有关,另一方面也与Android系统的实现有关。例如在3.0前,Android应用程序UI绘制不支持硬件加速。不过从4.0开始,Android系统一直以“run fast, smooth, and responsively”为目标对UI进行优化。本文对这些优化进行简要介绍和制定学习计划。
2015-05-11 01:00:33 44504 21
原创 ART运行时Foreground GC和Background GC切换过程分析
通过前面一系列文章的学习,我们知道了ART运行时既支持Mark-Sweep GC,又支持Compacting GC。其中,Mark-Sweep GC执行效率更高,但是存在内存碎片问题;而Compacting GC执行效率较低,但是不存在内存碎片问题。ART运行时通过引入Foreground GC和Background GC的概念来对这两种GC进行扬长避短。本文就详细分析它们的执行过程以及切换过程。
2015-05-04 00:57:34 17077 13
原创 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的执行过程。
2015-04-27 01:00:54 10204 7
原创 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的执行过程分析进行详细分析。
2015-04-20 01:01:30 11748 13
原创 ART运行时Compacting GC为新创建对象分配内存的过程分析
在引进Compacting GC后,ART运行时优化了堆内存分配过程。最显著特点是为每个ART运行时线程增加局部分配缓冲区(Thead Local Allocation Buffer)和在OOM前进行一次同构空间压缩(Homogeneous Space Compact)。前者可提高堆内存分配效率,后者可解决内存碎片问题。本文就对ART运行时引进Compacting GC后的堆内存分配过程进行分析。
2015-04-13 00:57:26 24461 8
原创 ART运行时Compacting GC堆创建过程分析
引进了Compacting GC之后,ART运行时的堆空间结构就发生了变化。这是由于Compacting GC和Mark-Sweep GC的算法不同,要求底层的堆具有不同的空间结构。同时,即使是原来的Mark-Sweep GC,由于需要支持新的同构空间压缩特性(Homogeneous Space Compact),也使得它们要具有与原来不一样的堆空间结构。本文就对这些堆空间创建过程进行详细的分析。
2015-04-07 01:00:32 9928 4
原创 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进行简要介绍以及制定学习计划。
2015-03-23 00:59:48 16938 21
原创 ART运行时垃圾收集(GC)过程分析
ART运行时与Dalvik虚拟机一样,都使用了Mark-Sweep算法进行垃圾回收,因此它们的垃圾回收流程在总体上是一致的。但是ART运行时对堆的划分更加细致,因而在此基础上实现了更多样的回收策略。不同的策略有不同的回收力度,力度越大的回收策略,每次回收的内存就越多,并且它们都有各自的使用情景。这样就可以使得每次执行GC时,可以最大限度地减少应用程序停顿。本文就详细分析ART运行时的垃圾收集过程。
2015-01-26 00:58:26 65288 19
原创 ART运行时为新创建对象分配内存的过程分析
ART运行时和Dalvik虚拟机一样,在堆上为对象分配内存时都要解决内存碎片和内存不足问题。内存碎片问题可以使用dlmalloc技术解决。内存不足问题则通过垃圾回收和在允许范围内增长堆大小解决。由于垃圾回收会影响程序,因此ART运行时采用力度从小到大的进垃圾回收策略。一旦力度小的垃圾回收执行过后能满足分配要求,那就不需要进行力度大的垃圾回收了。本文就详细分析ART运行时在堆上为对象分配内存的过程。
2015-01-22 00:59:22 18722 7
原创 ART运行时Java堆创建过程分析
与Dalvik虚拟机一样,ART运行时内部也有一个Java堆,用来分配Java对象。当这些Java对象不再被使用时,ART运行时需要回收它们占用的内存。在前面一文中,我们简要介绍了ART运行时的垃圾收集机制,从中了解到ART运行时内部使用的Java堆是由四种Space以及各种辅助数据结构共同描述的。为了后面可以更好地分析ART运行时的垃圾收集机制,本文就对它内部使用的Java堆的创建过程进行分析。
2015-01-12 00:59:53 24378 12
原创 ART运行时垃圾收集机制简要介绍和学习计划
为了学习ART运行时的垃圾收集机制,我们先把Dalvik虚拟机的垃圾收集机制研究了一遍。这是因为两者都使用到了Mark-Sweep算法,因此它们在概念上有很多一致的地方。然而在实现上,Dalvik虚拟机的垃圾收集机制要简单一些。这样我们就可以先从简单的Dalvik虚拟机垃圾收集机制入手,然后再逐步深入地学习复杂的ART运行时垃圾收集机制。本文就对ART运行时垃圾收集机制进行简要介绍和制定学习计划。
2015-01-05 01:01:17 32816 24
原创 Dalvik虚拟机垃圾收集(GC)过程分析
前面我们分析了Dalvik虚拟机堆的创建过程,以及Java对象在堆上的分配过程。这些知识都是理解Dalvik虚拟机垃圾收集过程的基础。垃圾收集是一个复杂的过程,它要将那些不再被引用的对象进行回收。一方面要求Dalvik虚拟机能够标记出哪些对象是不再被引用的。另一方面要求Dalvik虚拟机尽快地回收内存,避免应用程序长时间停顿。本文就将详细分析Dalvik虚拟机是如何解决上述问题完成垃圾收集过程的。
2014-12-22 01:00:40 52964 21
原创 Dalvik虚拟机为新创建对象分配内存的过程分析
在前面一文中,我们分析了Dalvik虚拟机创建Java堆的过程。有了Java堆之后,Dalvik虚拟机就可以在上面为对象分配内存了。在Java堆为对象分配内存需要解决内存碎片和内存不足两个问题。要解决内存碎片问题,就要找到一块大小最合适的空闲内存分配给对象使用。而内存不足有可能是内存配额用完引起的,也有可能是垃圾没有及时回收引起的,要区别对待。本文就详细分析Dalvik虚拟机是如何解决这些问题的。
2014-12-08 01:00:57 23748 19
原创 Dalvik虚拟机Java堆创建过程分析
使用C/C++开发应用程序最令头痛的问题就是内存管理。慎不留神,要么内存泄漏,要么内存破坏。虚拟机要解决的问题之一就是帮助应用程序自动分配和释放内存。为了达到这个目的,虚拟机在启动的时候向操作系统申请一大块内存当作对象堆。之后当应用程序创建对象时,虚拟机就会在堆上分配合适的内存块。而当对象不再使用时,虚拟机就会将它占用的内存块归还给堆。Dalvik虚拟机也不例外,本文就分析它的Java堆创建过程。
2014-12-01 01:03:35 25841 37
原创 Dalvik虚拟机垃圾收集机制简要介绍和学习计划
伴随着“Dalvik is dead,long live Dalvik“这行AOSP代码提交日志,在Android5.0中,ART运行时取代了Dalvik虚拟机。虽然Dalvik虚拟机不再使用,但是它曾经的作用是不可磨灭的。因此,在研究ART运行时的垃圾收集机制之前,先理解Dalvik虚拟机的垃圾收集机制也是很重要和有帮助的。因此,本文就对Dalvik虚拟机的垃圾收集机进行简要介绍和制定学习计划。
2014-11-24 01:01:29 30978 24
Linking:Computer Systems--A Programmer_s Perspective
2015-02-28
APK防反编译技术PPT
2014-01-27
Android硬件抽象层(HAL)
2013-10-23
Android应用程序输入事件处理机制
2013-10-23
Dalvik虚拟机 PPT版
2013-10-23
Android应用程序资源管理框架 PPT
2013-10-23
Android应用程序UI架构 高清PTT
2013-10-23
Android应用程序消息处理机制
2013-10-23
Android应用程序进程管理
2013-10-23
Android专用驱动
2013-10-23
Android硬件抽象层
2013-10-23
Android系统架构概述PPT
2013-10-23
Android源代码开发和调试环境搭建完整版PPT
2013-10-23
Android组件设计思想
2013-10-23
交互式人机对战五子棋
2011-07-06
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人