Android Index

最新推荐文章于 2022-12-01 15:10:28 发布

置顶 CCJHDOPC

最新推荐文章于 2022-12-01 15:10:28 发布

阅读量3.7k

点赞数 2

分类专栏： 6. Android 理解 11. Todo

本文链接：https://blog.csdn.net/CCJHDOPC/article/details/54316154

版权

6. Android 理解同时被 2 个专栏收录

83 篇文章 2 订阅

订阅专栏

11. Todo

62 篇文章 0 订阅

订阅专栏

前言：

在看android code的过程中，结合网络上的一些分析，进行总结。

有的内容来自网络，不想重复造轮子，所以给出引用，但是会给出源链接。

主要是为了整体上理个思路。

Android架构

Android VS Linux

(https://sujaiantony.files.wordpress.com/2012/06/image.png)

静态架构

常用的架构图说明

2017 google io updated 架构说明

Archecture设计 -- 基于Binder的全局概貌

2个参考文档：

http://www.kandroid.org/board/data/board/conference/file_in_body/1/4HistoryOfAndroidTechnology.pdf

http://www.kandroid.org/board/data/board/conference/file_in_body/1/14th_kandroid_minmax_v11.pdf

Archecture设计 -- Binder是Android的根基

Archecture设计 -- 消息处理和4大组件&回调

Archecture设计 -- 事件循环和IPC 线程的综合运用

动态架构

Boot Sequence 1

（图片来自：http://gityuan.com/images/android-process/android-boot.jpg）

Boot Sequence 2

（图来自：http://www.opersys.com/downloads/cc-slides/android-debug/slides-main-150423.html#/18 ）

Boot Sequence 3

Boot Sequence 4

http://www.cs.unibo.it/~ghini/didattica/sistemimobili/BergamiGiacomo/main.pdf

Android /Java 的设计模式

IPC主板模式

参考：http://www.bubuko.com/infodetail-1170268.html

IPC proxy-stub模式

MPV

反射、回调

understand-plugin-framework -- (深入理解插件化框架)

认识接口类设计

http://8204129.blog.51cto.com/8194129/1697862

http://8204129.blog.51cto.com/8194129/1594542

UI架构

-- View体系的Composite设计模式

-- 处理事件的Observer设计模式

-- 远端服务的Proxy设计模式

-- ListView里的Template设计模式

-- SurfaceFlinger里的设计模式

进程与线程

-- IBinder的Fcatory、Delegation及Adaptor设计模式

-- VM的线程安全设计模式

-- JNI里的常用设计模式

数据内容

-- ContentProvider的Faade及Iterator设计模式
底层服务

-- Android Service的Faade及State设计模式

-- Native Service的常用设计模式

-- HAL里的Stub设计模式

Android 的通信方式 -- 1 binder 是Android的脊梁

这一块，很多参考gityuan的博文，分析的不错。

还有其他网友的一些分析；

Binder --（静态分析）

设计理念1（CS结构）

http://blog.csdn.net/yangzhiloveyou/article/details/14043801

Binder是什么？它可以叫作：IPC、RPC、线程迁移、远程对象访问，本文中理解它为远程对象访问更贴切些，简而言之就是一个进程能访问另一个进程中的对象，调用该对象的方法，就好像对象在自己的进程中一样，这种访问是同步的访问，当然Binder也能实现异步的通信。

Binder基于C/S架构：

设计理念2（分层设计）

Binder架构也是采用分层架构设计, 每一层都有其不同的功能:

（图源：http://gityuan.com/images/binder/binder_start_service/binder_ipc_arch.jpg）

Java应用层: 对于上层应用通过调用AMP.startService, 完全可以不用关心底层,经过层层调用,最终必然会调用到AMS.startService.
Java IPC层: Binder通信是采用C/S架构, Android系统的基础架构便已设计好Binder在Java framework层的Binder客户类BinderProxy和服务类Binder;
Native IPC层: 对于Native层,如果需要直接使用Binder(比如media相关), 则可以直接使用BpBinder和BBinder(当然这里还有JavaBBinder)即可, 对于上一层Java IPC的通信也是基于这个层面.
Kernel物理层: 这里是Binder Driver, 前面3层都跑在用户空间,对于用户空间的内存资源是不共享的,每个Android的进程只能运行在自己进程所拥有的虚拟地址空间, 而内核空间却是可共享的. 真正通信的核心环节还是在Binder Driver.

简略的工作机制

Service设计思想 64

Binder分层看

整体代码层次 -- (基于6.0)

App层

------------------------------------------------------------------------------------------------------------
FWK层

包含在framework.jar
frameworks/base/core/Java/android/os/ServiceManager.java
frameworks/base/core/java/android/os/ServiceManagerNative.java

frameworks/base/core/java/android/os/IInterface.java
frameworks/base/core/java/android/os/IServiceManager.java
frameworks/base/core/java/android/os/IBinder.java

frameworks/base/core/java/android/os/Binder.java
frameworks/base/core/java/android/os/Parcel.java
frameworks/base/core/java/android/os/Parcelable.java

frameworks/base/core/java/com/android/internal/os/BinderInternal.java
------------------------------------------------------------------------------------------------------------
JNI层：
frameworks/base/core/jni/android_os_Parcel.cpp
frameworks/base/core/jni/AndroidRuntime.cpp
frameworks/base/core/jni/android_util_Binder.cpp
-------------------------------------------------------------------------------------------------
Native层：

/framework/av/media/libmedia/IMediaDeathNotifier.cpp？

binderclient/server (libbinder.so):
frameworks/native/libs/binder/IServiceManager.cpp
frameworks/native/libs/binder/IInterface.cpp
frameworks/native/libs/binder/ProcessState.cpp
frameworks/native/libs/binder/IPCThreadState.cpp
frameworks/native/libs/binder/BpBinder.cpp
frameworks/native/libs/binder/Binder.cpp

frameworks/native/include/binder/IServiceManager.h
frameworks/native/include/binder/IInterface.h
frameworks/native/include/binder/ProcessState.h
frameworks/native/include/binder/IPCThreadState.h
frameworks/native/include/binder/BpBinder.h
frameworks/native/include/binder/Binder.h

(/system/bin/service_manager)
frameworks/native/cmds/service_manager.c
frameworks/native/cmds/binder.c
------------------------------------------------------------------------------------------------------------
System Call层：      
_open/_mmap/_ioctl
------------------------------------------------------------------------------------------------------------
Kernel/Driver层：

/kernel/drivers/android/binder.c
/kernel/include/uapi/linux/android/binder.h
------------------------------------------------------------------------------------------------------

Binder类分层

(图源：http://gityuan.com/images/binder/java_binder_framework.jpg）

Binder整体启动过程

步骤：
1.      Kernel 启动时加载binder驱动
2.      Init进程（1号进程）fork出30多个native的systemservices, 包括: binder大管家 service_manager
3.      其他native service注册到servicemanager
4.      Zygote进程和binder建立connection,后面fork的所有进程，都有这个binder连接
5.      Zygote 启动system server进程（第1个java进程），准备加载javasystem services（80多个），这些services是以线程的形式，寄居于system server中。（systemserver有80多个线程？）
6.      这些java system services也注册到servicemanager(通过java层的servicemanager)
7.      Activity manager services是继承binder的机制的
8.      应用层面：activity/service/provider/broadcastreceiver 都是在用binder的分层通讯机制

下面的binder分析系列，是gityuan的大作，我这里会引用图和概要的说明。

并且给出原文链接。

App层

Binder系列10 -- 总结

请参考：http://gityuan.com/2015/11/28/binder-summary/

从IPC角度来说：Binder是Android中的一种跨进程通信方式，该通信方式在linux中没有，是Android独有；
从Android Driver层：Binder还可以理解为一种虚拟的物理设备，它的设备驱动是/dev/binder；
从Android Native层：Binder是创建Service Manager以及BpBinder/BBinder模型，搭建与binder驱动的桥梁；
从Android Framework层：Binder是各种Manager（ActivityManager、WindowManager等）和相应xxxManagerService的桥梁；
从Android APP层：Binder是客户端和服务端进行通信的媒介，当bindService的时候，服务端会返回一个包含了服务端业务调用的 Binder对象，

通过这个Binder对象，客户端就可以获取服务端提供的服务或者数据，这里的服务包括普通服务和基于AIDL的服务。

（图源：http://7u2hy4.com1.z0.glb.clouddn.com/android/Binder-system-service/2.png）

稍微说明下：

图中一共三条线；第一条 SS（ProcA）通过 addService 向 SM 注册，

第二条 ProcB 通过 getService 向 SM 取 ProcA 的 binder 对象；

第三条 ProcB 取回 ProcA 的 binder 对象后，通过其发起 IPC 调用）

（http://coderlin.coding.me/2016/07/28/Android-%E6%BA%90%E7%A0%81%E5%88%86%E6%9E%90%E4%B9%8BBinder/2.png）

http://javanote.files.wordpress.com/2012/05/binder-framework-java.png

Binder系列9 -- 如何使用AIDL

请参考：http://gityuan.com/2015/11/23/binder-aidl/

FWK层

Binder系列8 -- 如何使用Binder(app/fwk/native层分别如何使用)

请参考：http://gityuan.com/2015/11/22/binder-use/

参考另外几个例子：

如何定制自己的native service： example (C++)

如何定制自己的native service： example2 (C++)

Android Service Framework （Native层的一个例子）

如何定制自己的java service: example

Binder系列7 -- framework层分析

请参考：http://gityuan.com/2015/11/21/binder-framework/

来自gityuan的blog:

(图引自： http://gityuan.com/images/binder/java_binder/java_binder.jpg）

ServiceManager和IBinder的扮演角色

JNI 层

http://wiki.jikexueyuan.com/project/deep-android-v1/jni.html

JNI，是Java Native Interface的缩写，中文为Java本地调用。通俗地说，JNI是一种技术，通过这种技术可以做到以下两点：

· Java程序中的函数可以调用Native语言写的函数，Native一般指的是C/C++编写的函数。

· Native程序中的函数可以调用Java层的函数，也就是在C/C++程序中可以调用Java的函数。

在平台无关的Java中，为什么要创建一个和Native相关的JNI技术呢？这岂不是破坏了Java的平台无关特性吗？本人觉得，JNI技术的推出可能是出于以下几个方面的考虑：

· 承载Java世界的虚拟机是用Native语言写的，而虚拟机又运行在具体平台上，所以虚拟机本身无法做到平台无关。然而，有了JNI技术，就可以对Java层屏蔽具体的虚拟机实现上的差异了。这样，就能实现Java本身的平台无关特性。其实Java一直在使用JNI技术，只是我们平时较少用到罢了。

· 早在Java语言诞生前，很多程序都是用Native语言写的，它们遍布在软件世界的各个角落。Java出世后，它受到了追捧，并迅速得到发展，但仍无法对软件世界彻底改朝换代，于是才有了折中的办法。既然已经有Native模块实现了相关功能，那么在Java中通过JNI技术直接使用它们就行了，免得落下重复制造轮子的坏名声。另外，在一些要求效率和速度的场合还是需要Native语言参与的。

在Android平台上，JNI就是一座将Native世界和Java世界间的天堑变成通途的桥，来看图，它展示了Android平台上JNI所处的位置：

Native层 --（ServiceManager -- 是Binder的大管家）

(图引自：http://hi.csdn.net/attachment/201104/12/0_1302586870XXcI.gif)

（图引自：http://hi.csdn.net/attachment/201104/12/0_1302586875vjBC.gif）

Native层和驱动层之间传输数据小结

从客户端到服务端整个数据流的过程：

现在我们来总结一下整个数据传输的过程：（http://blog.csdn.net/u010961631/article/details/20922145）
1、一个Service向ServiceManager注册自己的时候，需要向ServiceManager传递2个数据：name+BnXXXService
这个BnXXXService是双继承结构，同时继承了IXXXService和BBinder
ServiceManager会针对该Service生成一个ID，也就是handle值
2、客户端向ServiceManager申请Service代理对象的时候，将会得到目标Service的BpBinder对象
ServiceManager只负责把相应Service的handle值返回出来
BpServiceManager得到handle之后，经过Parcel的解析，调用到ProcessState的getStrongProxyForHandle()
而ProcessState将会在getStrongProxyForHandle()中利用得到的handle创建目标Service的BpBinder(handle)对象
如果要得到的目标Service就是ServiceManager，那么其handle值就是0
3、然后客户端用interface_cast<IXXXService>的模版将BpBinder对象转换为BpXXXService对象
interface_cast的函数模版转换的原理是在内部调用IMediaPlayerService的asInterface()方法
而asInterface()方法的结果就是用得到的BpBinder对象作为参数，去创建BpXXXService的对象
而BpXXXService的构造函数中会把BpBinder暂存在其祖先类BpRefBase的mRemote变量中
4、客户端拿到BpXXXService对象之后，可以调用IXXXService中的各种方法
客户端无论调用哪个方法，都会调用到remote()->transact()方法，只是参数不同而已
而remote()所返回的就是BpXXXService祖先类中暂存的BpBinder对象
调用BpBinder的transact()方法将会调用到IPCThreadState的transact()方法
IPCThreadState的transact()调用writeTransactionData()将客户端的请求封装到mOut中，然后经过waitForResponse()和talkWithDriver()最终调用ioctl()将请求发送到Binder驱动中
5、服务端的IPCThreadState通过内部建立的joinThreadPool()循环机制不断检测客户端请求
得到请求后调用executeCommand()和BR_TRANSACTION的case分支，将请求发送到服务侧所注册的BBinder对象的transact()方法
调用BBinder的transact()将会在内部调用到onTransact()方法，并且这个方法是在BBinder的子类BnXXXService所实现
BnXXXService内部的onTransact()构建了switc语句来处理各种请求，而各个请求所调用的方法，都会在子类中实现
而BnXXXService的子类就是XXXService本身

Binder系列6 -- 获取服务(getService)

请参考：http://gityuan.com/2015/11/15/binder-get-service/

另外，参考：http://blog.csdn.net/u010961631/article/details/20922145

getService()整个过程和addService()的类型是极其相似的，
不同的是，在调用remote()的transact()时发送的是CHECK_SERVICE_TRANSACTION命令。
而且在transact()函数之后，我们从reply中读取了返回值。
而这个返回值就是我们要得到的远程Service的IBinder对象。

        下面我们小节一下通过BpServiceManager对象调用ServiceManager对象方法的过程：
        1、在BpServiceManager中的各项操作均转换为remote()->transact()方法，然后标记不同的命令，比如add、check、get等。
        2、remote()得到的其实就是mRemote变量，而这个变量就是当初构建BpServiceManager时传递进来的BpBinder(0)。
        3、在BpBinder对象的transact函数中，将会调用IPCThreadState的transact()方法，并且标明目标Service的handle(当前为0)
        4、在IPCThreadState的transact中先通过writeTransactionData把数据封装，封装的内容包括目标Service（当前就是0号Service），最后把封装后的数据放入mOut中
        5、在IPCThreadState的transact中接着逐步调用waitForResponse()和talkWithDriver()最终调用ioctl()将数据发送到远程的ServiceManager进程
        下面我们用图来小结一下本节的要点：

Binder系列5 -- 注册服务 AddService

请参考：http://gityuan.com/2015/11/14/binder-add-service/

(图片来自：http://hi.csdn.net/attachment/201004/15/0_1271340108RMXP.gif）

（图来自：http://gityuan.com/images/binder/addService/media_player_service_ipc.png）

Binder系列4 -- 获取ServiceManager

请参考：http://gityuan.com/2015/11/08/binder-get-sm/

defaultServiceManager 等价于 new BpServiceManager(new BpBinder(0));
ProcessState::self()主要工作：
调用open()，打开/dev/binder驱动设备；
再利用mmap()，创建大小为1M-8K的内存地址空间；
设定当前进程最大的最大并发Binder线程个数为16。

BpServiceManager巧妙将通信层与业务层逻辑合为一体，
通过继承接口IServiceManager实现了接口中的业务逻辑函数；
通过成员变量mRemote= new BpBinder(0)进行Binder通信工作。
BpBinder通过handler来指向所对应BBinder, 在整个Binder系统中handle=0代表ServiceManager所对应的BBinder。

Native层的Binder架构,通过如下两个宏,非常方便地创建了new Bp##INTERFACE(obj):

#define DECLARE_META_INTERFACE(INTERFACE)

#define IMPLEMENT_META_INTERFACE(INTERFACE, NAME)

这里巧妙地关系，要明白，是今后各种Native服务的基础：

参考：http://m.blog.csdn.net/article/details?id=50002101　

另外请参考： http://blog.csdn.net/u010961631/article/details/20922145

严格来说，我们通过defaultServiceManager()方法得到的并不是ServiceManager对象本身，而是得到了BpServiceManager对象，但是通过这个对象我们可以调用ServiceManager所暴露出来的各个方法，整个过程就像是直接调用ServiceManager一样，因此BpServiceManager对象的作用就是建立ServiceManager的“代理”，所有客户端对ServiceManager的请求，都需要通过BpServiceManager来“转达”。
那么，为了得到BpServiceManager，我们经历了哪些步骤呢？
首先，我们通过ProcessState::self()->getContextObject(NULL)得到了BpBinder(0)对象。
然后，我们用interface_cast<IServiceManager>(BpBinder(0))这个模版，将BpBinder(0)转换为IServiceManager类型的BpServiceManager对象。

Binder系列3 -- 启动ServiceManager

请参考：http://gityuan.com/2015/11/07/binder-start-sm/

ServiceManager启动流程：

1. 打开binder驱动，并调用mmap()方法分配128k的内存映射空间：binder_open();
2. 通知binder驱动使其成为守护进程：binder_become_context_manager()；
3. 验证selinux权限，判断进程是否有权注册或查看指定服务；

4. 进入循环状态，等待Client端的请求：binder_loop()。

ServiceManger意义：
ServiceManger集中管理系统内的所有服务，通过权限控制进程是否有权注册服务；
ServiceManager能通过字符串名称来查找对应的Service，操作方便；

当Server进程异常退出，只需告知ServiceManager，每个Client通过查询ServiceManager可获取Server进程的情况，

降低所有Client进程直接检测会导致负载过重。

System Call层

Binder Dirver是字符驱动设备，通过调用open()或者ioct1()函数即可访问。如下图，显示了系统调用与Binder Dirver中文件运算符函数之间的连接关系。例如：系统调用open()函数与Binder Dirver的binder_open函数连接在一起。

应用程序在通过Binder尝试RPC操作时，会进行open()系统调用，获取Binder Dirver的文件描述符。而后，通过mmap()系统调用，在内核中开辟一块区域，以便存放IPC数据。最后，调用ioct1()函数，将IPC数据作为参数传递给Binder Dirver。

Driver（Kernel）层

Binder系列2 -- Binder Driver再探

请参考：http://gityuan.com/2015/11/02/binder-driver-2/

Binder系列1 -- Binder Driver初探

请参考：http://gityuan.com/2015/11/01/binder-driver/

http://blog.csdn.net/yangzhiloveyou/article/details/14043801 (分析的不错！）

Binder的运作机制

参考： http://www.programgo.com/article/40261572850/

Step-1. 手機啟動時，ServiceManager先向Binder Driver登記(就像將CPU插到MB一樣)。

Step-2. Binder Driver將它(即ServiceManager)視為第0個服務，於是誕生一個服務Handle #0 來對應到它。

Step-3. Service A向Binder Driver取得Handle #0的中介：IServiceManager（ServiceManager的经纪人）。

Step-4. Service A呼叫IServiceManager中介的addService()，將自己登錄進去。此時，Binder Driver會誕生一個新Handle #1來對應它；並且告知ServiceManager。

Step-5. Service P呼叫IServiceManager介面的getService()函數，要求連結(Connect or Bind)到特定的Service。此時，ServiceManager就將Handle #1傳給Service P，如下：

Step-6. 於是，Service P與Service A就連結起來了。

基于Public IInterface/BpInterface/BnInterface派生的Server/Client模式的接口类

80多个类C/S模式的类，这些是基础的native services C/S interface和类
比如：AudioFlinger
Camera
MediaPlayer
SurfaceFlinger

基于extends IInterface/extends Binder体系派生的一些重要的interface和class

IServiceManager相关类

参考此图：

https://www.processon.com/view/link/5885a7f3e4b098bf4d08e5ef

IApplicationThread相关类
IActivityManager相关类
IContentProvider类

binder 如何使用（从动起来的角度）

kernel 启动时，加载binder驱动
init进程fork出native service manager进程, binder的大管家生出
native services注册到native service manager
Zygote_init时和binder建立联系
启动system server时binder相关工作 (java services注册到java service manager)
4大组件用binder进行通信 (startxxx, etc.)

（图源：http://7u2hy4.com1.z0.glb.clouddn.com/android/Binder-transaction/1.png）

AIDL

http://www.chopiter.com/binder_aidl/

Intent -- 信使

http://blog.csdn.net/21cnbao/article/details/8086619

Parcel -- 携带数据的包裹

Parcelable 实现数据的封装和开封

(开封：反序列化/Unflatten)

(装包：序列化/Flatten）

Parcelable和Serializable的区别：

android自定义对象可序列化有两个选择一个是Serializable和Parcelable

一、对象为什么需要序列化
      1.永久性保存对象，保存对象的字节序列到本地文件。
      2.通过序列化对象在网络中传递对象。
      3.通过序列化对象在进程间传递对象。

二、当对象需要被序列化时如何选择所使用的接口
      1.在使用内存的时候Parcelable比Serializable的性能高。
      2.Serializable在序列化的时候会产生大量的临时变量，从而引起频繁的GC（内存回收）。
      3.Parcelable不能使用在将对象存储在磁盘上这种情况，因为在外界的变化下Parcelable不能很好的保证数据的持续性。

http://blog.csdn.net/21cnbao/article/details/8087291

通过Parcelable实现的Intent

Intent的发送 --- IActiivtyManager接口类

Android 的通信方式 -- 2 socket 和 epoll

Android那些进程用socket进行通信？

adbd
cryptd
cs_socket
dir_enc_report
dnsproxyd
epm
frigate
fwmarkd
imsd
installd
lmkd
mdns
mtp
netd
netmgr
perfd
ppm
property_service
qmux_audio
qmux_bluetooth
qmux_gps
qmux_radio
rild
sap_uim_socket1
sdp 
 uibc 
vold
 wpa_wlan0 
zygote 
zygote_secondary

Zygote and socket

http://www.programering.com/a/MTO3gzMwATM.html

Android 的通信方式 -- 3 Thread和Looper和MessageQueue和Message和Handler

戏谑说法

关系图

( https://realm.io/kr/news/android-thread-looper-handler/ )

Message：消息，其中包含了消息ID，消息处理对象以及处理的数据等，由MessageQueue统一列队，终由Handler处理。

Handler：处理者，负责Message的发送及处理。使用Handler时，需要实现handleMessage(Messagemsg)方法来对特定的Message进行处理，例如更新UI等。

MessageQueue：消息队列，用来存放Handler发送过来的消息，并按照FIFO规则执行。当然，存放Message并非实际意义的保存，而是将Message以链表的方式串联起来的，等待Looper的抽取。

Looper：消息泵，不断地从MessageQueue中抽取Message执行。因此，一个MessageQueue需要一个Looper。

Thread：线程，负责调度整个消息循环，即消息循环的执行场所。

线程的魔法师 Looper

异步处理大师 Handler

封装任务 Message

http://www.cnblogs.com/codingmyworld/archive/2011/09/12/2174255.html

Android消息机制1-Handler(Java层)

用一张图，来表示整个消息机制

https://medium.com/@jagsaund/android-handler-internals-b5d49eba6977#.hv23svn7x

http://gityuan.com/2015/12/26/handler-message-framework/

图解：

Handler通过sendMessage()发送Message到MessageQueue队列；
Looper通过loop()，不断提取出达到触发条件的Message，并将Message交给target来处理；
经过dispatchMessage()后，交回给Handler的handleMessage()来进行相应地处理。
将Message加入MessageQueue时，处往管道写入字符，可以会唤醒loop线程；如果MessageQueue中没有Message，并处于Idle状态，则会执行IdelHandler接口中的方法，往往用于做一些清理性地工作。

消息分发的优先级：

Message的回调方法：message.callback.run()，优先级最高；
Handler的回调方法：Handler.mCallback.handleMessage(msg)，优先级仅次于1；
Handler的默认方法：Handler.handleMessage(msg)，优先级最低。

Android消息机制2-Handler(Native层)

http://gityuan.com/2015/12/27/handler-message-native/

图解：

红色虚线关系：Java层和Native层的MessageQueue通过JNI建立关联，彼此之间能相互调用，搞明白这个互调关系，也就搞明白了Java如何调用C++代码，C++代码又是如何调用Java代码。
蓝色虚线关系：Handler/Looper/Message这三大类Java层与Native层并没有任何的真正关联，只是分别在Java层和Native层的handler消息模型中具有相似的功能。都是彼此独立的，各自实现相应的逻辑。
WeakMessageHandler继承于MessageHandler类，NativeMessageQueue继承于MessageQueue类

另外，消息处理流程是先处理Native Message，再处理Native Request，最后处理Java Message。理解了该流程，也就明白有时上层消息很少，但响应时间却较长的真正原因。

Android消息机制3-Handler(实战)

Android的Thread类

Android的启动过程（7个阶段）

(参考： http://www.bozhiyue.com/anroid/wenzhang/2016/0503/50662.html）

1 ini进程在解析完init.rc文件之后启动了一个非常重要的守护服务zygote，它是android的第一个虚拟机

2 zygote创建一个socket，和AMS进行通信

3 zygote通过fork创建进程system_server进程

4 system_server中的init1启动native system service，init2阶段启动java system_service

5 系统服务启动之后注册到servicemanager中

6 AMS进入systemReady状态

7 AMS和zygote创建的socket进行socket通信，请求启动HOME

8 zygote收到AMS的请求之后执行runSelectLoopMode处理请求

9 通过forkAndSepcialize启动新进程，最终启动Home应用

http://mutsughost1.github.io/2015/01/28/android-booting-process/

Step 1 -- Boot Room

Step 2 -- BootLoader

Step 3 -- Kernel

Step 4 -- Init进程

Android Init进程源码分析 (f非常细致）

http://gityuan.com/2016/02/05/android-init/

init是Linux系统中用户空间的第一个进程，进程号为1。Kernel启动后，在用户空间，启动init进程，并调用init中的main()方法执行init进程的职责。对于init进程的功能分为4部分：

分析和运行所有的init.rc文件;
生成设备驱动节点; （通过rc文件创建）
处理子进程的终止(signal方式);
提供属性服务。

Step 5 -- Zygote 进程

http://gityuan.com/2016/02/13/android-zygote/

Zygote启动过程的调用流程图：

解析init.zygote.rc中的参数，创建AppRuntime并调用AppRuntime.start()方法；
调用AndroidRuntime的startVM()方法创建虚拟机，再调用startReg()注册JNI函数；
通过JNI方式调用ZygoteInit.main()，第一次进入Java世界；
registerZygoteSocket()建立socket通道，zygote作为通信的服务端，用于响应客户端请求；
preload()预加载通用类、drawable和color资源、openGL以及共享库以及WebView，用于提高ap启动效率；
zygote完毕大部分工作，接下来再通过startSystemServer()，fork得力帮手system_server进程，也是上层framework的运行载体。
zygote功成身退，调用runSelectLoop()，随时待命，当接收到请求创建新进程请求时立即唤醒并执行相应工作。

另外参考：Zygote进程启动过程源代码分析

Step 6 -- System Server进程

http://gityuan.com/2016/02/14/android-system-server/

SystemServer的在Android体系中所处的地位，SystemServer由Zygote fork生成的，进程名为system_server，该进程承载着framework的核心服务。Android系统启动-zygote篇中讲到Zygote启动过程中会调用startSystemServer()，可知startSystemServer()函数是system_server启动流程的起点，启动流程图如下：

system_server_boot_process

上图前4步骤（即颜色为紫色的流程）运行在是Zygote进程，从第5步（即颜色为蓝色的流程）ZygoteInit.handleSystemServerProcess开始是运行在新创建的system_server，这是fork机制实现的（fork会返回2次）。下面从startSystemServer()开始讲解详细启动流程。

http://gityuan.com/2016/02/20/android-system-server-2/

SystemServer.main
    SystemServer.run
        createSystemContext
            ActivityThread.systemMain
                ActivityThread.attach
                    LoadedApk.makeApplication
            ActivityThread.getSystemContext
                ContextImpl.createSystemContext
        startBootstrapServices();
        startCoreServices();
        startOtherServices();
        Looper.loop();

system_server进程，从源码角度划分为引导服务、核心服务、其他服务3类。

引导服务(7个)：ActivityManagerService、PowerManagerService、LightsService、DisplayManagerService、PackageManagerService、UserManagerService、SensorService；
核心服务(3个)：BatteryService、UsageStatsService、WebViewUpdateService；
其他服务(70个+)：AlarmManagerService、VibratorService等。

合计总大约80个系统服务：

做个清单，哪些需要掌握？

ActivityManagerService	PackageManagerService	WindowManagerService
PowerManagerService	BatteryService	BatteryStatsService
DreamManagerService	DropBoxManagerService	SamplingProfilerService
UsageStatsService	DiskStatsService	DeviceStorageMonitorService
SchedulingPolicyService	AlarmManagerService	DeviceIdleController
ThermalObserver	JobSchedulerService	AccessibilityManagerService
DisplayManagerService	LightsService	GraphicsStatsService
StatusBarManagerService	NotificationManagerService	WallpaperManagerService
UiModeManagerService	AppWidgetService	LauncherAppsService
TextServicesManagerService	ContentService	LockSettingsService
InputMethodManagerService	InputManagerService	MountService
FingerprintService	TvInputManagerService	DockObserver
NetworkManagementService	NetworkScoreService	NetworkStatsService
NetworkPolicyManagerService	ConnectivityService	BluetoothService
WifiP2pService	WifiService	WifiScanningService
AudioService	MediaRouterService	VoiceInteractionManagerService
MediaProjectionManagerService	MediaSessionService
DevicePolicyManagerService	PrintManagerService	BackupManagerService
UserManagerService	AccountManagerService	TrustManagerService
SensorService	LocationManagerService	VibratorService
CountryDetectorService	GestureLauncherService	PersistentDataBlockService
EthernetService	WebViewUpdateService	ClipboardService
TelephonyRegistry	TelecomLoaderService	NsdService
UpdateLockService	SerialService	SearchManagerService
CommonTimeManagementService	AssetAtlasService	ConsumerIrService
MidiServiceCameraService	TwilightService	RestrictionsManagerService
MmsServiceBroker	RttService	UsbService

Step 7 -- BOOT_COMPLETE

启动SystemUI

SystemUI是一个系统的apk，它主要包括几个部分， status bar 、navigation bar，以及将status bar拉下来之后呈现在用户眼前的，quick settings， notification list等等。

frameworks\base\packages\SystemUI\src\com\android\systemui

http://blog.csdn.net/ccjhdopc/article/details/71440455

启动Launcher

Android系统启动的最后一步是启动一个Home应用程序，这个应用程序用来显示系统中已经安装的应用程序，这个Home应用程序就叫做Launcher。

应用程序Launcher在启动过程中会请求PackageManagerService返回系统中已经安装的应用程序的信息，

并将这些信息封装成一个快捷图标列表显示在系统屏幕上，这样用户可以通过点击这些快捷图标来启动相应的应用程序。

packages/apps/Launcher3

Android系统默认Home（Launcher）的启动过程小结

Android7.0 启动Launcher流程

android7.x Launcher3源码解析（1）---启动流程

android7.x Launcher3源码解析（2）---框架结构

android7.x Launcher3源码解析（3）---workspace和allapps加载流程

Android Launcher全面剖析

Android Native Services (系统服务）

Android启动后，加载的2类service (Native 系统Service, Java 系统Service）

来自： http://www.itread01.com/articles/1476617118.html

https://www.processon.com/diagraming/58d085efe4b018a2366bf6d3 (Native Service启动，图)

class core类的service

大部分代码位于/system/core/目录下面

ueventd

进程：/sbin/ueventd （一个链接文件）

源码：/system/core/init
首先，watchdog和uevent命令已经集成到了init。/sbin/ueventd和/sbin/watchdogd是一个链接文件，它直接链接到/init，所以当执行/sbin/eventd或/sbin/watchdogd时，将会进入相应的ueventd_main或watchdogd_main入口点。ueventd伺服程序将解析/ueventd.rc文件，并创建相应的设备结点。watchdogd伺服程序是一个看门狗程序，它的任务就是定期向看门狗设备文件执行写操作，以判断系统是否正常运行。

watchdogd

进程：/sbin/watchdogd

源码：system/core/init

logd

进程：/system/bin/logd

源码：

debuggerd

进程：/system/bin/debuggerd

源码：system/core/debuggerd

debuggerd64

进程：/system/bin/debuggerd64
源码：system/core/debuggerd

adbd

进程：

源码：/system/core/adbd

bootanim

进程：/system/bin/bootanimation

源码：/framework/base/cmds/bootanimation

console

进程：/system/bin/sh

源码：

flash_recovery

进程：/system/bin/install-recovery.sh

源码：

healthd

进程：/sbin/healthd

源码：/system/core/healthd

lmkd

进程：/system/bin/lmkd

源码：/system/core/lmkd

ServiceManager -- binder大管家

进程：/system/bin/servicemanager

源码：/framework/native/cmds/servicemanager

SurfaceFlinger

进程：/system/bin/surfaceflinger

源码：/framework/native/services/surfaceflinger

rild

class main类的service

AudioServer--含AudioFlinger等5个service

MediaLogService, AudioFlinger, AudioPolicyService, RadioService, SoundTriggerHwService,

CameraServer

CameraService,

drmServer

/system/bin/drmserver进程中：（main_drmserver.cpp）

dumpstate

/system/bin/dumpstate

dumpstatez

/system/bin/dumpstate

inputflinger

/system/bin/inputflinger

installd

mdnsd

MediaCodec

MediaCodecService,

MediaDrmServer

MediaDrmService,

MediaExtractor

/system/bin/mediaextractor (main_extractorservice.cpp)

MediaExtractorService

MediaServer

MediaPlayerService, ResourceManagerService

zygote

service zygote /system/bin/app_process64 -Xzygote /system/bin --zygote --start-system-server

class late_start 类的service

crash_reporter

crash_sender

gatekeeperd

/system/bin/gatekeeperd

logcatd

metricsd

metricscollector

debuggerd进程

/system/bin/debuggerd64

logd进程

SensorService进程？

Android Framework 的Server层（系统服务）

System Service 和 SystemServiceManager 先搞明白

按照加载顺序看看启动了些什么android Services--9张图顺序表示

part2

part3

part4

part5

part6

part7

part8

part9

Android service List --xls 小结

Android Service list (Server/Client API)

ActivityManagerService--AMS

AMS主要干3个事情--1. 管理Activity 2. 管理进程 3. 管理内存

整体关系图

Android Context 上下文你必须知道的一切

Android Context完全解析，你所不知道的Context的各种细节

Android Context 是什么？

应用进程与系统进程的通信设计(IActivityManager & IApplicationThread）

(App进程和 System Server进程：建立 binder双向沟通渠道) ：

AMS 如何管理内存的？

TODO

AMS 如何管理Activity的？

Android ActivityManagerService（AMS）的Activity管理

AMS 如何管控 Android 四大组件的-- startActivity or StartService or SendBroadcast？

AMS 如何管控 Activity/Service/Broadcast的？

AMS 管控process, 而Process有4大组件：

startActivity启动过程分析

ActivityManagerService Part 2: Activity Start Procedure

ActivityStack

PackageManagerService

PowerManagerService

整体架构：

http://www.ituring.com.cn/book/miniarticle/178319 (写的很好)

移动设备的电量主要由两种元件消耗：CPU和显示屏，因此设法降低这两种元件的耗电量就是电源管理的关键，为移动设备设计的CPU大多有两种工作频率，为了省电，大部分时间内cpu都工作在降低频率下，只有进行密集计算时，如视频解码才会切换到高频状态，而显示屏省电的方法是尽量减少亮屏时间，但是显示屏的开关和应用有很大的关系，因此系统中需要有一套机制来控制显示屏

的开关和亮度，这也是电源管理的主要工作。

http://www.cnblogs.com/jamboo/articles/6003835.html

逐步分析：

Android7.0 PowerManagerService(1) 启动过程

Android7.0 PowerManagerService(2) WakeLock的使用及流程

Android7.0 PowerManagerService(3) 核心函数updatePowerStateLocked的主要流程

Android7.0 PowerManagerService(4) Power按键流程

Android7.0 BatteryService

Android7.0 BatteryStatsService

Android7.0 Doze模式

睡眠、唤醒机制

Android睡眠唤醒机制--系统架构

Android睡眠唤醒机制--HAL-->Kernel

亮、灭屏

Android7.0 PowerManagerService亮灭屏分析(一)

Android7.0 PowerManagerService亮灭屏分析(二)

Android7.0 PowerManagerService亮灭屏分析(三)

WindowManagerService

http://www.360doc.com/content/13/0106/00/9462341_258470654.shtml

http://www.cnblogs.com/samchen2009/p/3364327.html

BlueTooth Service

Android FWK client层 -- 给App提供APIs

和Andriod Framework 的Server层，搭配起来看：

ActivityManager

ApplicationThread

UI主线程ActivityThread

Task

一、概念：Activity是安卓组件中最基本也是最为常用的组件，在一个android应用中，一个Activity通常就是一个单独的屏幕。

二、Android应用程序模型：应用程序，任务，进程和线程

大多数操作系统中，应用程序所寄存的可执行程序映像、它所运行的进程以及用户交互的图标之间有对应的1对1的关系。而在Android系统中，这些关联不是那么严格。

1. .apk ：包含应用程序代码和资源的压缩包。

2. Task ：一个Task就是用户体验上的一个“应用”。它将相关的Activity组合在一起，以stack的方式管理（就是前面提到的Activity Stack），这就是Task。在Android平台上可以将task简单的理解为幽多个Activity共同协作完成某项应用，而不管Activity具体属于哪个Application.

3. 进程：在安装Android应用程序的时候，Android会为每个程序分配一个Linux用户ID，并设置相应的权限，这样其它应用程序就不能访问此应用程序所拥有的数据和资源了。
在 Linux 中，一个用户ID 识别一个给定用户；在 Android 上，一个用户ID 识别一个应用程序。应用程序在安装时被分配用户 ID，应用程序在设备上的存续期间内，用户ID 保持不变。
默认情况下，每个apk运行在它自己的Linux进程中。当需要执行应用程序中的代码时，Android会启动一个jvm，即一个新的进程来执行，因此不同的apk运行在相互隔离的环境中。

4. Activity Task: Android用来管理Activity的一个堆栈。

5. Android的单线程模型：当一个程序第一次启动时，Android会同时启动一个对应的主线程（Main Thread），主线程主要负责处理与UI相关的事件，如：用户的按键事件，用户接触屏幕的事件以及屏幕绘图事件，并把相关的事件分发到对应的组件进行处理。所以主线程通常又被叫做UI线程。
在开发Android 应用时必须遵守单线程模型的原则： Android UI操作并不是线程安全的并且这些操作必须在UI线程中执行。

App层

Launcher如何启动的？

Android系统默认Home应用程序（Launcher）的启动过程源代码分析

点击Home上面的图标，如何启动一个App？

Android 应用程序启动过程分析

onClick 到 Display ：分析的范围定位于从 Launcher 点击应用图标到应用显示在屏幕上这一过程。这里以 Calculator 应用为例。

启动过程概况:

Launcher 接收到点击事件，获取应用的信息，向 SystemServer(ActivityManagerService 简称AMS 运行在里面) 发起启动应用的请求。
SystemServer(AMS) 请求 Launcher Pause （Launcher 需要保存状态进入后台）
Launcher Pause ，向 SystemServer(AMS) 发送 Pause 完毕
SystemServer(AMS) 向 Zygote 请求启动一个新进程(calculator)
Zygote fork 出新进程(calculator) , 在新进程中执行 ActivityThread 类的 main 方法
calculator 向 SystemServer(AMS) 请求 attach 到 AMS
SystemServer(AMS) 请求 calculator launch
calculator 调用 onCreate ， onResume 回调
calculator 界面显示自屏幕上(还需细分)

（https://raw.githubusercontent.com/androidzhibinw/androidzhibinw.github.io/master/images/app-process.png）

点击事件如何传递的？

App没有响应了，如何处理？

Android Sample

Handler/Message/Messagequeue/Looper

179 Android Handler Tutorial Part 1

180 Android Handler Example

181 Android Handler Example Post Runnable Messages

182 Android Looper Example

183 Android AsyncTask Tutorial

工具

如何抓Log

Systrace

adb

logcat

参考资料：

Kandroid.org (很多高质量的分析文档，且图画的比较专业）

http://www.kandroid.org

gityuan的个人blog, 分析的非常有水平！

http://gityuan.com/

Android Internals: 不错
http://www.cs.unibo.it/~ghini/didattica/sistemimobili/BergamiGiacomo/main.pdf

History Of Android (设计思路)

http://www.kandroid.org/board/data/board/conference/file_in_body/1/4HistoryOfAndroidTechnology.pdf

Android Architecture and Platform Initilization

http://madhusudhanrc.blogspot.kr/2013/04/android-architecture-and-platform.html

Android IPC Mechanism

http://elastos.org/elorg_files/FreeBooks/android/android-binder-ipc.pdf

Deep Dive into Android Binder

https://events.linuxfoundation.org/images/stories/slides/abs2013_gargentas.pdf

Service Manager：

http://www.programering.com/a/MzN2UzMwATE.html

Android Binder 分析——系统服务 Binder 对象的传递

Android IPC Binder: (图画的形象）

http://www.android100.org/html/201611/01/259957.html

高焕唐的blog

http://8204129.blog.51cto.com/8194129/1697862

Explore Android InternalsJim Huang ( 黃敬群 )

http://www.slideshare.net/jserv/android-internals-30176596?from_action=save

分析的比较透彻的一些积累：

https://edwardlu0904.wordpress.com/category/android/

CCJHDOPC

关注

2
点赞
踩
4

收藏

觉得还不错? 一键收藏
0
评论
Android Index

Android架构静态架构Archecture设计（Binder，Android的根基）Archecture设计（消息处理和4大组件&回调）Archecture设计（事件循环和IPC 线程的综合运用） Archecture设计 (基于Binder, 全局概貌) 动态架构（启动过程） 13Android Boot sequence 1 13A
复制链接

扫一扫