深入理解Android卷I

深入理解Android卷I

 

第4章    深入理解zygote

 

Zygote总结

       zygote是在Androidt系统中创建java世界的盘古  ，它创建了第一个java虚拟机，同时它又是女娲，它成功繁殖了framework的核心system_server进程。做为java语言的受益者，我们理应回顾一下zygote创建java世界的步骤：

      第一天：创建AppRuntime对象，并调用它的start。此后的活动则由AppRuntime来控制。

      第二天：调用startVm创建虚拟机，然后调用startReg来注册JNI函数。

      第三天：通过JNI调用com.android.internal.os.ZygoteInit类的main函数，从此进入了Java世界。然而在这个世界刚开创的时候，什么东西都没有。

      第四天：调用registerZygoteSocket。通过这个函数，它可以响应子孙后代的请求。同时zygote调用preloadClass和preloadResources，为Java世界添砖加瓦。

      第五天：zygote觉得自己的工作压力太大，便通过调用startSystemServer分裂一个子进程system_server来为Java世界服务：

      第六天：zygote完成了Java世界的初创工作，它已经很满足了。下一步该做的就是调用runSelectLoopMode后，便沉沉地睡去了。

      以后的日子：zygote随时守护在我们的周围，当接收到子孙后代的请求时，它会随时醒来，为它们工作。

第8章  深入理解Surface系统

 

Surface系统提供了三种属性，一共四种不同的显示，简单介绍一下：

第一种属性是eFXSurfaceNormal属性，大多数的UI界面使用的就是这种属性。它有两种模式：

        1）Normal模式，这种模式的数据，是通过前面的mView.draw(canvas)画上去的。这也是绝大多数UI所采用的方式

        2）PushBuffer模式，这种模式对应于视频播放、摄像机摄录/预览等应用场景。以摄像机为例，当摄像机运行时，来自Camera的预览数据将直接push到Buffer中，无须应用层自己再去draw了。

第二种属性是eFXSurfaceBlur属性，这种属性的UI有点朦胧美，看起来很像隔着一层毛玻璃。

第三种属性是eFXSurfaceDime属性，这种属性的UI看起来有点暗，好像隔了一层深色玻璃，从视觉上讲，虽然它的UI看起来有点暗，但并不模糊。而eFXSurfaceBlur不仅暗，还有些模糊。

 

ViewRoot的你问我答

ViewRoot是Surface系统甚至UI系统中一个非常关键的类，下面关于ViewRoot的问题做个总结：

ViewRoot和View类的关系是什么？

ViewRoot是View视图体系的根。每一个Window(注意是Window，比如PhoneWindow)有一个ViewRoot，它的作用是处理layout和view视图体系的绘制工作。那么视图体系又是什么呢？它包括Views和ViewGroups。也就是SDK中能看到的View类都属于视图体系。根据前面的分析可知，这些View是需要通过draw画出来的。而ViewRoot就是用来draw它们的，ViewRoot本身没有draw/onDraw函数。

ViewRoot和它所控制的View及其子View使用同一个Canvas吗？

我们在ViewRoot的performTraversals中见过。ViewRoot提供Canvas给它控制的View，所以它们使用同一个Canvas。但Canvas使用的内存却不是固定的，而是通过Surface的lockCanvas得到的。

View、Surface和Canvas之前的关系是怎么样的？

一个Window将和一个Surface绑定在一起，绘制前ViewRoot会从Surface中lock出一个Canvas。

Canvas有一个bitmap，那么绘制UI时，数据是画在Canvas的这个bitmap中吗？

答案是肯定的，bitmap实际上包括了一块内存，绘制的数据最终都在这块内存上。

同一个ViewRoot下，不同类型的View（不同类型指不同的UI单元，例如按钮、文本框等）使用同一个Surface吗？

是的，但是SurfaceView要除外，因为SurfaceView的绘制一般在单独的线程上，并且由应用层主动调用lockCanvas、draw和unlockCanvasAndPost来完成绘制流程，应用层相当于抛开了ViewRoot的控制直接和屏幕打交道，这在camera、video方面用得最多。

 

第9章    深入理解Vold和Rild

 

本章将分析Android系统中两个比较重要的程序，它们分别是：

Vold：Vold Daemon(守护进程)，用于管理的控制Android平台外部存储设备的后台进程，这些管理和控制，包括SD卡的插拔事件检测、SD卡挂载、卸载、格式化等。

Rild：Radio Interface Layer Daemon，用于智能手机的通信管理和控制的后台进程，所有和手机通信相关的功能，例如接打电话、收发短信/彩信、GPRS等都需要Rild的参与。

 

Vold和Rild都是Native的程序，另外Java世界还有和它们交互的模块，它们分别是：

MountService和Vold交互，一方面它可以接收来自Vold的消息，例如，在应用程序中经常监听到的ACTION_MEDIA_MOUNTED(通知系统扫描SD卡)/ACTION_MEDIA_EJECT(SD卡插拔广播)等广播，就是由MountService根据Vold的信息而触发的。另一方面，它可以向Vold发送控制命令，例如挂载SD卡为磁盘驱动器的操作，就是由MountService发送命令给Vold来执行的。

Phone和Rild交互，它是一个比较复杂的应用程序。简单来说，Phone拨打电话时需要发送对应的命令给Rild执行。后面在Rild的实例分析中会有相关介绍。

本章小结

    本章对Vold和Rild两个重要的daemon程序进行了分析。其中：

1、Vold负责Android平台上存储系统的管理和控制。重点关注Vold两方面的内容，一是它如何接收和处理来自内核Uevent事件，二是如何处理来自Java层MountService的请求。

2、Rild是Android平台上的射频通信控制中枢，接打电话、收发短信等都需要Rild的参与。本章对Rild的架构进行了重点分析，尤其对异步请求/响应的知识进行了较详细的介绍。另外，还分析了Phone中拨打电话的处理流程。

 

第10章        深入理解MediaScanner

概述：

        多媒体系统，是Android平台中非常庞大的一个系统。不过由于篇幅所限，本章只介绍多媒体中的重要一员MediaScanner，MediaScanner有什么用呢？可能有些读者还不是很清楚。MediaScanner和媒体文件扫描有关，例如，在Music应用程序中见到的歌曲专辑名、歌曲时长等信息，都是通过它扫描对应的歌曲而得到的。另外，通过MediaScanner接口查询媒体数据库，从而得到系统中所有媒体文件的相关信息也和MediaScanner有关，因为数据库的内容就是由MediaScanner添加的。所以MediaScanner是多媒体系统中很重要的一部分。