Android系统从init进程到Launcher（五）

一、 Launcher 概述

系统启动的最后一部是启动 Launcher 应用程序来显示系统中已经安装的应用程序。Launcher 在启动过程中会请求 PackageManagerService 返回系统中已经安装的应用程序的信息，并将这些信息封装成一个快捷图标列表显示在系统屏幕上，这样用户可以通过点击这些快捷图标来启动相应的应用程序。

主要作用如下：

1. 作为 Android 系统的启动器，用于启动应用程序
2. 作为 Android 系统的桌面，用于显示和管理应用程序的快捷图标或者其他桌面组件

二、Launcher启动过程

这里需要说明的是 Launcher 本身也是一个 APK ，也是一个应用程序，那么在启动的时候同样会先判断该应用程序所需要的进程是否存在，若是不存在就需要先创建进程。

2.1 时序图

Launcher启动创建进程时序图

上图中关于创建了 Launcher 应用程序所需要的进程，接下来就是如何启动 Launcher 的 Activity 界面了。关于 Process 如何到达 ActivityThread 的详细过程同 AMS发送启动应用程序进程请求 相同不再赘述，此处仅仅从 ActivityThread 到 Activity 的方向分析。

frameworks/base/core/java/android/app/ActivityThread.java

  public static void main(String[] args) {
        
        Looper.prepareMainLooper();

        //创建ActicityThread对象实例,当new ActivityThread()进行时，其成员变量ApplicationThread同时被创建
        
        ActivityThread thread = new ActivityThread();

        /**进行attach回调，调用栈如下：
            mgr.attachApplication(mAppThread); 
            这里走的是binder通信->call AMS:attachApplication->attachApplicationLocked
        */
        thread.attach(false, startSeq);

        if (sMainThreadHandler == null) {
            sMainThreadHandler = thread.getHandler();
        }

        if (false) {
            Looper.myLooper().setMessageLogging(new
                    LogPrinter(Log.DEBUG, "ActivityThread"));
        }

        // End of event ActivityThreadMain.
        Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
        Looper.loop();

    }

ActivityThread的main函数主要做了两件事：

1. 调用attach，告诉AMS进程应启动完毕，可以进行其他事情了。
2. 初始化主线程的looper并loop。

主线程所做的任何事情都是通过往 MainThreadHandler 中发送消息来完成的，所以说 Android 系统是基于消息驱动的。接下来就是 注册进程到 system_server 中，这个过程是通过 ActivityThread.attah 函数完成：

frameworks/base/core/java/android/app/ActivityThread.java

    ActivityThread.attah(...)
      final IActivityManager mgr = ActivityManager.getService();
      mgr.attachApplication(mAppThread, startSeq);
        AMS.attachApplication(...)
          AMS.attachApplicationLocked(...)
            final ProcessRecord pending = mPendingStarts.get(startSeq);
            AppDeathRecipient adr = new AppDeathRecipient(app, pid, thread); // 绑定死亡通知
            thread.asBinder().linkToDeath(adr, 0);
            mHandler.removeMessages(PROC_START_TIMEOUT_MSG, app); // 移除进程启动超时消息
            ApplicationThread.bindApplication(..)
            ASS.attachApplicationLocked(...)  // 检查有没有待启动的activity
           ActiveServices.attachApplicationLocked(...) // 检查有没有待启动的service
           AMS.sendPendingBroadcastsLocked // 检查有没有待启动的receiver

这里需要说明的是，进程一般都是由 AMS 请求的，所以这相当于一个回调，为了防止其他进程非法 attach 到 AMS ，保证安全，需要验证身份。这个验证就是通过 startSeq 来完成，这个 startSeq 其实是由 AMS 传过去的，现在它在Zygote和APP进程中转了一圈又回来了。AMS会根据startSeq从mPendingStarts取出待启动的进程的ProcessRecord ，如果ProcessRecord 为空，那么说明进程启动有误或者这个进程不是由AMS启动的，AMS会马上杀死该进程。在验证进程启动没问题之后，AMS会做一下3件事情：

1. 为进程绑定死亡通知AppDeathRecipient，当进程被杀的时候，AMS会通过AppDeathRecipient来进行清理
2. 通知APP执行bindApplication，即创建Application
3. 检查有没有四大组件等待着在该进程中运行，如果有，继续执行四大组件。不过这里只有Activity、Service和BroadCastReceiver三种组件，ContentProvider的发布会在bindApplication的时候进行

在上述 ApplicationThread.bindApplication 过程中会发送消息 sendMessage(H.BIND_APPLICATION, data)，接着调用 ActivityThread.handleBindApplication 创建 application：

frameworks/base/core/java/android/app/ActivityThread.java#handleBindApplication()

    Process.setStartTimes(...)
    mConfiguration = new Configuration(data.config);
    //获取该应用的packageInfo
    data.info = getPackageInfoNoCheck(data.appInfo, data.compatInfo);
    ImageDecoder.sApiLevel = data.appInfo.targetSdkVersion;
    //dpi相关
    mCurDefaultDisplayDpi = data.config.densityDpi;
    Bitmap.setDefaultDensity(DisplayMetrics.DENSITY_DEFAULT); 
     // 设置时间格式
    DateFormat.set24HourTimePref(is24Hr);
    // 设置strictMode相关的东西
    StrictMode.initThreadDefaults(data.appInfo); 
      penaltyDeathOnNetwork(...)
    StrictMode.initVmDefaults(data.appInfo);
      penaltyDeathOnFileUriExposure(...)
    app = data.info.makeApplication(...)
    installContentProviders(app, data.providers); // 发布所有ContentProvider
    mInstrumentation.callApplicationOnCreate(app); // 回调Application.onCreate

创建application的过程主要是初始化APP的Context，各种资源的初始化，包括设定显示相关的configuration、初始化packageInfo、设置默认的Dpi、设置时间格式、设置strictMode，设置字体资源等等，为以后四大组件的运行提供运行环境.

其中packageInfo包括app的所有资源，例如data目录，res的目录，lib目录的。而strictMode会设定不能在主线程中访问网络，也不能在Uri中显式加入file。然后创建Application，用它去发布所有的ContentProvider，才回调Application.onCreate，所以不要惊讶，ContentProvider发布是比Application的回调都要早。至此，APP的运行所需要的所有资源已经准备完毕，四大组件可以运行了。

参考

[ 1 ]：https://blog.csdn.net/hongchi110/article/details/82890180
[ 2 ]：https://xiaozhuanlan.com/topic/7502314698
[ 3 ]：https://blog.csdn.net/qq_39037047/article/details/88066589