Android 应用点击图标到Activity界面显示的过程分析

2019年4月12日 285次阅读 来源: ActivityManagerService

分析这个过程不是单纯为跟一遍函数调用的流程，而是更好的理解平常用到的一些方法、对象的初始化时间，对象创建的个数，方法的先后顺序，以及每个类，方法背后的作用和目的。主要是一下几个问题：

  1. Application是什么时候创建的，每个应用程序有几个Application
  2. 应用的资源路径什么时候初始化的
  3. 应用中ContextImpl的个数
  4. Application.attach(),Activity.attach()的调用时机及作用
  5. Instrumentation的重要性及具体作用
  6. 点击Launcher启动Activity和应用内部启动Activity的区别

启动过程

应用安装的时候,通过PMS解析apk的AndroidManifest.xml文件,提取出这个apk的信息写入到packages.xml文件中，这些信息包括：权限、应用包名、icon、APK的安装位置、版本、userID等等。packages.xml文件位于系统目录下/data/system/packages.xml。

系统的会在启动时也可以认为开机时启动常用的服务,如ActivityManagerService(AMS),PackageManagerService(PMS),WindowManagerService(WMS),以及ServiceManager(SM),用于管理各种服务,详细的管理方式见理解Binder框架。

同时桌面Launcher会为安装过的应用生成不同的应用入口,对应桌面上的应用图标，下面分析点击应用图标的到应用启动的过程。这里主要是应用端的过程,服务端也就是AMS少量涉及,同时以大体框架为主,不深入代码细节。主要分为Launcher进程，AMS进程，应用程序进程。

  • Instrumentation： 用于管理应用程序和系统（主要与应用程序内的Activity）的交互过程，Instrumentation将在任何应用程序运行前初始化，每个进程只会存在一个Instrumentation对象，且每个Activity都有此对象的引用，可以通过它监测系统与应用程序之间的所有交互，主要是内部交互。
  • ActivityThread: App的真正入口,通过调用main()App开始真正运行，同时开启消息循环队列，虽然不是一个真正的线程,但一般所在的线程被称为UI线程或主线程。ActivityThread就是专门与AMS的进行外部交互。
  • ApplicationThread: 应用需要和远程服务AMS等通信,而Binder是单向提供服务的,而AMS等服务想控制应用需要应用程序提供一个Binder接口,ApplicationThread就是这个Binder接口,用于通过远程服务调用本地的方法。
  • ActivityManagerProxy: AMS远程服务在本地的代理。
  • ApplicationThreadProxy: ApplicationThread在远程服务AMS的代理。

其实Launcher本身也是一个Activity，我们不考虑Launcher的创建过程，只分析用户的应用程序的从点击到Activity启动的过程。上面的这些每个进程只存在一个，如果应用存在多个进程，就会有多个实例。

Launcher所在进程，Launcher通过Binder与ActivityManagerService与通信。

Launcher.startActivitySafely
|
Launcher.startActivity  
|
Activity.startActivity
|   
Activity.startActivityForResult
| 
Instrumentation.execStartActivity
|
ActivityManagerNative.getDefault().startActivity
|  
ActivityManagerProxy.startActivity

上面的这些都是在一条调用链上，ActivityManagerProxy是AMS的本地代理，实际的工作是在远程AMS完成的，下面是AMS进程。

借助binder驱动
ActivityManagerService.startActivity-> (AMS)  
...
//一系类AMS的调用链和一些与Launcher通过Binder的互相调用过程，此时仍然未创建应用程序的进程。
...
* AMS创建一个新的进程，用来启动一个ActivityThread实例， 
* 即将要启动的Activity就是在这个ActivityThread实例中运行 
Process.start("android.app.ActivityThread",...)->    
// 通过zygote机制创建一个新的进程    
Process.startViaZygote->调用新进程的main()
ActivityThread.main->

创建新进程的时候，AMS会保存一个ProcessRecord信息，Activity应用程序中的AndroidManifest.xml配置文件中，我们没有指定Application标签的process属性，系统就会默认使用package的名称。每一个应用程序都有自己的uid，因此，这里uid + process的组合就可以为每一个应用程序创建一个ProcessRecord。每次在新建新进程前的时候会先判断这个ProcessRecord是否已存在，如果已经存在就不会新建进程了,这就属于应用内打开Activity的过程了。

AMS通过开启新的进程并调用ActivityThread.main后，接下来就是应用程序进程了：

public static void main(String[] args)  {
    Looper.prepareMainLooper();
    //新建一个ActivityThread并调用attach(false)
    ActivityThread thread = new ActivityThread();
    thread.attach(false);
    if (sMainThreadHandler == null) {    
        sMainThreadHandler = thread.getHandler();
    }
}

thread.attach(false)主要是为了将ApplicationThread通过Binder驱动”传递”到远程AMS,也就是绑定，主要是为了让AMS能通过ApplicationThread的代理ApplicationThreadProxy来调用ApplicationThread的方法，而本地应用程序通过ActivityManagerProxy来调用远程ActivityManagerService的方法，相当于应用程序与AMS的通信窗口。

注意: 此时只创建了应用程序的ActivityThread和ApplicationThread,和开启了Handler消息循环机制，其他的都还未创建, ActivityThread.attach(false)又会最终到AMS的attachApplication，这个工程其实是将本地的ApplicationThread传递到AMS。然后AMS就可以通过ApplicationThread的代理ApplicationThreadProxy来调用应用程序ApplicationThread.bindApplication，通知应用程序的ApplicationThread已和AMS绑定，可以不借助其他进程帮助直接通信了。此时Launcher的任务也算是完成了。过程如下：

应用进程：
ActivityThread.attach
|    
IActivityManager.attachApplication(mAppThread)
| 
ActivityManagerProxy.attachApplication(mAppThread)   
    
AMS进程:
ActivityManagerService.attachApplication
|
ApplicationThreadProxy.bindApplication
应用进程:
ApplicationThread.bindApplication
| Handler通信
AplicationThread.handlerBindApplication

ApplicationThreadProxy.bindApplication(…)会传来这个应用的一些信息，如ApplicationInfo，Configuration等,在ApplicationThread.bindApplication里会待信息封装成AppBindData,通过

sendMessage(H.BIND_APPLICATION, data)

将信息放到应用里的消息队列里，通过Handler消息机制，在ActivityThread.handleMeaasge里处理H.BIND_APPLICATION的信息，调用AplicationThread.handleBindApplication。

AplicationThread.handleBindApplication

handleBindApplication(AppBindData data) {
    Process.setArgV0(data.processName);//设置进程名
    ...
    //初始化mInstrumentation
    if(data.mInstrumentation!=null) {
        mInstrumentation = (Instrumentation)    cl.loadClass(data.instrumentationName.getClassName()).newInstance();
    }else {
        mInstrumentation = new Instrumentation();
    }
    //创建Application，data.info是个LoadedApk对象。
    Application app = data.info.makeApplication(data.restrictedBackupMode, null);
    mInitialApplication = app;
    //调用Application的onCreate()方法。
    mInstrumentation.callApplicationOnCreate(app);
}

LoadedApk

public Application makeApplication(boolean forceDefaultAppClass,Instrumentation instrumentation) {
    
    if (mApplication != null) {   
       return mApplication;
    }
    
    String appClass = mApplicationInfo.className;
    java.lang.ClassLoader cl = getClassLoader();
    
    //此时新建一个Application的ContextImpl对象，
    ContextImpl appContext = ContextImpl.createAppContext(mActivityThread, this);
    
    //通过在handleBindApplication创建的mInstrumentation对象新建一个Application对象，同时进行attach。
    app = mActivityThread.mInstrumentation.newApplication(cl, appClass, appContext);
    appContext.setOuterContext(app);
}

Instrumentation：

public Application newApplication(ClassLoader cl, String className, Context context) {    
    return newApplication(cl.loadClass(className), context);
}
Instrumentation类：
static public Application newApplication(Class<?> clazz, Context context)  {
    //实例化Application
    Application app = (Application)clazz.newInstance();     
    
    // Application和context绑定
    app.attach(context);    
    return app;
}
//attach就是将新建的ContextImpl赋值到mBase,这个ContextImpl对象就是所有Application内Context的具体
//实现，同时赋值一些其他的信息如mLoadedApk。
final void attach(Context context) {    
    mBase = base;  
    mLoadedApk = ContextImpl.getImpl(context).mPackageInfo;
}

这时Application就创建好了，这点很重要，很多博客里说Application是在performLaunchActivity里创建的，因为performLaunchActivity也有mInstrumentation.newApplication这个调用,newApplication函数中可看出会先判断是否以及创建了Application，如果之前已经创建，就返回已创建的Application对象。

ApplicationThreadProxy.bindApplication完成后，同时在AMS进程，调用realStartActivityLocked，接着就通过ApplicationThreadProxy调用到应用程序进程

//AMS进程：
ActivityManagerService.realStartActivityLocked
|
ApplicationThreadProxy.scheduleLaunchActivity
    
//应用程序进程
ApplicationThread.scheduleLaunchActivity
|  Handler通信
sendMessage(H.LAUNCH_ACTIVITY, r);
|  handleMassage
ActivityThread.handleLaunchActivity
|
ActivityThread.performLaunchActivity {
    //类似Application的创建过程，通过classLoader加载到activity.
    activity = mInstrumentation.newActivity(classLoader, 
               component.getClassName(), r.intent);
    //因为Activity有界面，所以其Context是ContextThemeWrapper类型，但实现类仍是ContextImpl.
    Context appContext = createBaseContextForActivity(r, activity);
    activity.attach(context,mInstrumentation,application,...);
    
    //attach后调用activity的activity方法。
    mInstrumentation.callActivityOnCreate(activity,...)
    
}
    
在ActivityThread.handleLaunchActivity里，接着调用
|
ActivityThread.performResumeActivity
|
activity.performResume
|
mInstrumentation.callActivityOnResume(this);
|
this.onResume;

activity.onResume就是和Window，View之类的绑定相关了，此时界面就显示出来了。

总结

现在来对开篇的问题进行总结。

1 . Application是在ActivityThread.handleBindApplication中创建的，一个线程只会创建一个Application，但一个应用程序如果有多个进程将会创建多个Application对象。

2 . 应用资源是在Application初始化的时候,也就是创建Application ContextImpl的时候，ContextImpl就包含这个路径，主要就是对就是ResourcesManager这个单例的引用。

3 . 可以看出每次创建Application和Acitvity以及Service时就会有一个ContextImpl实例，ContentProvider和BroadcastReceiver的Context是其他地方传入的。所以Context数量=Application数量+Activity数量+Service数量，单进程情况下Application数量就是1。

4 . attach是依附、贴上的意思，可以理解为将两种事物联系在一起，上面分析的过程主要涉及3个attach，ActivityThread.attach可以理解为将应用程序进程的ApplicationThread依附到AMS，和AMS联系起来，用于整个AMS和应用程序的通信，Application.attach和Activity.attach主要是将新创建的ContextImpl对象与Application，Activity，Service等组件联系起来，对组件中其中的Context mBase变量赋值，以及一些初始化工作，比如MainHandler的赋值，mWindow的初始化（如果存在）等。ContextImpl包含资源信息、对Context的一些函数的实现等。
可以很好的理解，attach需要在Application，Activity等组件调用onCreat之前调用，因为需要先完成组件的初始化工作。

5 . 管理着组件Application,Activity，Service等的创建，生命周期调用，很重要的一个类。例如：

//创建Application
mActivityThread.mInstrumentation.newApplication(cl, appClass, appContext);
//调用Application的onCreate()方法。    
mInstrumentation.callApplicationOnCreate(app);
//创建Activity,实际生命周期的管理。
mInstrumentation.newActivity(classLoader, component.getClassName(), r.intent);
mInstrumentation.callActivityOnCreate(activity);
mInstrumentation.callActivityOnOnResume(activity);
...

6 . 点击Launcher时会创建一个新进程来开启Activity，而应用内打开Activity,如果Activity不指定新进程，将在原来进程打开，是否开启新进程实在AMS进行控制的，上面分析得到，每次开启新进程时会保存进程信息，默认为应用包名+应用UID,打开Activity时会检查请求方的信息来判断是否需要新开进程。Launcher打开Activity默认ACTIVITY_NEW_TASK，新开一个Activity栈来保存Activity的信息。

参考：【Android应用程序启动过程源代码分析】

    原文作者：ActivityManagerService
    原文地址: https://juejin.im/entry/5a0d02086fb9a045263b2387
    本文转自网络文章，转载此文章仅为分享知识，如有侵权，请联系博主进行删除。
点赞