在上一篇文章中，我们分析了Android系统进程间通信机制Binder中的Server在启动过程使用Service Manager的addService接口把自己添加到Service Manager守护过程中接受管理。在这一篇文章中，我们将深入到Binder驱动程序源代码去分析Client是如何通过Service Manager的getService接口中来获得Server远程接口的。Client

前面我们在分析Activity启动过程的时候，看到同一个应用程序的Activity一般都是在同一个进程中启动，事实上，Activity也可以像Service一样在新的进程中启动，这样，一个应用程序就可以跨越好几个进程了，本文就分析一下在新的进程中启动Activity的方法和过程。        在前面Android进程间通信（IPC）机制Binder简要介绍和学习计划一文中，我们提到，在Andro

在前一个系列文章中，我们从个体的角度来分析了Android应用程序窗口的实现框架。事实上，如果我们从整体的角度来看，Android应用程序窗口的实现要更复杂，因为它们的类型和作用不同，且会相互影响。在Android系统中，对系统中的所有窗口进行管理是窗口管理服务WindowManagerService的职责。在本文中，我们就将简要介绍WindowManagerService的职能以及制定学习计划。

在前面一个系列的文章中，我们以窗口为单位，分析了WindowManagerService服务的实现。同时，在再前面一个系列的文章中，我们又分析了窗口的组成。简单来说，窗口就是由一系列的视图按照一定的布局组织起来的。实际上，每一个视图都是一个控件，这些控制可以将自己的UI绘制在窗口的绘图表面上，同时还可以与用户进行交互，即获得用户的键盘或者触摸屏输入。在本文中，我们就详细分析窗口控件的上述实现原理。

前面我们介绍了Android系统的广播机制，从本质来说，它是一种消息订阅/发布机制，因此，使用这种消息驱动模型的第一步便是订阅消息；而对Android应用程序来说，订阅消息其实就是注册广播接收器，本文将探讨Android应用程序是如何注册广播接收器以及把广播接收器注册到哪里去的。        在Android的广播机制中，ActivityManagerService扮演着广播中心的角色，负责系统

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

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

上一篇文章Android进程间通信（IPC）机制Binder简要介绍和学习计划简要介绍了Android系统进程间通信机制Binder的总体架构，它由Client、Server、Service Manager和驱动程序Binder四个组件构成。本文着重介绍组件Service Manager，它是整个Binder机制的守护进程，用来管理开发者创建的各种Server，并且向Client提供查询Serve

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

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