捋一捋 Android 启动应用进程的前因后果

点击桌面应用图标后

前面(Android 进阶解密阅读笔记2)已经知道启动应用程序进程是由 AMS 向 zygote 进程发起申请，后面由 zygote 进程监听处理。但一般场景下，用户只有点了桌面应用图标才会打开应用，可见 AMS 也是收到了某种响应才会发起申请。在 Android 进阶解密阅读笔记3 中我们知道启动根 Activity 最终会走到 ActivityStackSupervisor 的 startSpecificActivityLocked 方法，而这个方法中的逻辑也包含着启动应用进程，这就是比 AMS 发起创建应用进程请求更早的地方。（以下代码基于 API 28）

void startSpecificActivityLocked(ActivityRecord r,boolean andResume, boolean checkConfig) {
    ProcessRecord app = mService.getProcessRecordLocked(r.processName, r.info.applicationInfo.uid, true);
    //省略...
    if(app != null && app.thread != null) {
        //省略...
        realStartActivityLocked(r, app, andResume, checkConfig);
        return;
    }
    mService.startProcessLocked(r.processName,r.info.applicationInfo, true, 0,"activity", r.intent.getComponent(), false, false,true);
}

大致可见，AMS 根据应用进程的一些信息去获取 ProcessRecord。如果启动根 Activity 时，发现 app 为 null 的话就会调用 AMS 启动应用进程。那在应用进程启动后并调用 ActivityThread 的 main，这个 main 具体又做了什么呢？

ActivityThread 的 main 方法做了什么

public static void main(String[] args) {
    //简单来说 main 方法里创建了主线程的消息循环
    Looper.prepareMainLooper();
    //另外一件事就在这里
    ActivityThread thread = new ActivityThread();
    thread.attach(false, startSeq);
    
    if(sMainThreadHandler == null) {
        sMainThreadHandler = thread.getHandler();
    }
    
    Looper.loop();
}

private void attach(boolean system, long startSeq) {
    final IActivityManager mgr = ActivityManager.getService();
    try {
        //通过 AMS 代理类去绑定应用
        mgr.attachApplication(mAppThread, startSeq);
    } catch(RemoteException ex) {
        throw ex.rethorwFromSystemServer();
    }
}

在 AMS 做了一些逻辑后，又会交还给 Activit