Android 进阶——解密笔记，flutter 人脸识别模块
作为 Android 系统的启动器，用于启动应用程序。
作为 Android 系统的桌面，用于显示和管理应用程序的快捷图标或其他桌面组件。
时序图
[](
)总结：Android 系统启动流程
启动电源以及系统启动。（引导芯片从固化在 ROM 的预定义地方执行，加载主引导 BootLoader 到 RAM）
引导程序 BootLoader。（把系统 OS 拉起来）
Linux 内核启动。（设置缓存、被保护存储器、计划列表、加载驱动。内核完成时，首先在系统文件中寻找 init.rc 文件，并启动 init 进程）
init 进程启动。（初始化和启动属性服务，并启动 Zygote 进程）
Zygote 进程启动。（创建 Java 虚拟机并为 Java 虚拟机注册 JNI 方法，创建服务端 Socket，启动 SystemServer 进程。）
SystemServer 进程启动。（启动 Binder 线程池和 SystemServiceManager，并且启动各种系统服务。）
Launcher 启动。（被 SystemServer 进程启动的 AMS 会启动 Launcher，Launcher 启动后会将已安装的应用程序快捷方式图标展示到桌面。）
图示：
[](
)应用程序启动过程
如果启动一个应用程序，AMS 会检测该应用程序进程是否存在，如果不存在则向 Zygote 进行请求创建。
我们知道 Zygote 的 Java 框架层中创建了一个服务端的 Socekt，用于等待 AMS 创建新的应用进程请求。AMS 发起请求后，Zygote 会 fock 自身进程来创建应用程序，这样应用程序进程在启动时就拥有了虚拟机实例，同时也创建了 Binder 线程池和消息循环，这样运行在应用程序进程中的应用程序就可以进行进程间通信以及消息处理了。
[](
)1. AMS 发送启动应用进程请求时序图
[](
)2. Zygote 接收请求并创建应用程序进程时序图
我们看到该时序图和上文提到的 SystemServer 启动过程时序图有相似之处。共同点都是从 ZygoteInit 调用 RuntimeInit 的 applicationInit 开始，后续执行流程一样。
注：为什么 Android 会选择抛出 MethodArgsCall 异常的方式来调用方法而不是直接调用 SystemService 的 main 方法或 ActivityThread 的 main 方法？
是因为抛出异常的处理会清除所有的设置过程需要的堆栈帧（内存优化）
[](
)3.消息循环创建过程
ActivityThread 是用于管理当前应用程序进程的主线程。其部分关键源码如下：
public static void main(String[] args){
...
// 创建主线程 Looper
Looper.prepareMainLooper();
ActivityThread thread = new ActivityThread();
thread.attach(false);
if(sMainThreadHandler == null){
// 创建主线程 H 类
sMainThreadHandler = thread.getHandler();
}
if(false){
Looper.myLooper().setMessageLogging(new LogPrinter(Log.DEBUG, "ActivityThread"));
}
Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
// Looper 开始工作
Looper.loop();
throw new RuntimeException("Main thread loop unexpectedly exited");
}
[](
)四大组件工作过程
[](
)1. 根 Activity 启动过程
Activity 启动分为：根 Activity 启动和普通 Activity 启动。而普通 Activity 与根 Activity 启动方式类似，根 Activity 启动更具有代表性。
根 Activity 启动过程比较复杂，大致分为 3 个部分：Launcher 请求 AMS 过程、AMS 到 ApplicationThread 调用过程、ActivityThread 启动 Activity。
Launcher 请求 AMS 时序图：
注：IActivityManager 为 AMS 的代理对象，它是在 Instrumentation 中通过 ActivityManager.getService()方法获取的。见下文 ActivityManager 源码：
public static IActivityManager getService(){
return IActivityManagerSingleton.get();
}
private static final Singleton<IActivityManager> IActivityManagerSingleton = new Singleton<IActivityManager>(){
@Override
protected IActivityManager create(){
// Binder 类型的 AMS 引用
final IBinder b = ServiceManager.getService(Context.ACTIVITY_SERVICE);
// 所以此处的 IActivityManager 实则是 AMS 的代理对象
final IActivityManager am = IActivityManager.Stub.asInteface(b);
return am;
}
}
// Android8.0 使用的 AIDL 的形式来与 AMS 进程间通信的，Android7.0 则是使用类似于 AIDL 的 ActivityManagerProxy 代理对象来实现的。
AMS 到 ApplicationThread 的调用时序图：
注：ApplicationThread 是 ActivityThread 的内部类，它继承自 IApplicationThread.Stub。它用于和 AMS 进行进程间通信
AMS 与应用程序进程通信图示：
ActivityThread 启动
Activity 的过程：
*** 注：H 类为 ActivityThread 的内部类，它继承 Handler。由于 ApplicationThread 的代码是运行在 Binder 线程池中的，所以通过 H 类将代码切回到主线程中执行后续操作**
还未添加个人签名 2021.10.31 加入
还未添加个人简介
评论