美文网首页Android Framework源码分析Android笔记翻译·译文
Android 应用点击图标到Activity界面显示的过程分析

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

作者: SilenceDut | 来源:发表于2016-08-12 17:30 被阅读3604次

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

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

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

    2. 系统启动开启的服务

    系统的会在启动时也可以认为开机时启动常用的服务,如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。

    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之类的绑定相关了,此时界面就显示出来了。
    
    3. 总结
    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应用程序启动过程源代码分析

    相关文章

      网友评论

      • 东之城:有问题 AplicationThread.handleBindApplication 应该是调用 ActivityThread.handleBindApplication
      • and_pu:写的很好,找个时间,好好看下源码

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

      本文链接:https://www.haomeiwen.com/subject/pwsssttx.html