zoukankan      html  css  js  c++  java
  • ActivityManager

    引用:http://blog.sina.com.cn/s/blog_8984d3f301011peb.html

    1.ActivityManagerandroid框架的一个重要部分,它负责一新ActivityThread进程创建,Activity生命周期的维护,本blog就是着手对ActivityManager框架作一个整体的了解
            2.
    先看一个静态类结构图:

    ActivityManager讲解

            上图很清楚地描述了ActivityManager框架的几个主要类之间的关系,我们做应用开发接触很多的其实就是ActivityManager类,该类也在SDK中公布,应用可以直接访问,它提供了我们管理Activity的一些基本的方法
    如下:
            public void testgetRecentTasks()
                    //
    获取最近的应用,最后启动的排前
            public void testgetRunningTasks()
                    //
    获取当前运行的Activity应用
            public void testgetRunningServices()
                    //
    获取当前运行的service应用
            public void testgetRunningAppProcesses()
                    //
    获取所用系统运行的进程
           
     而这些操作都依赖于ActivityManagerProxy代理类的实现,IActivitManager接口定义了所有ActivityManager框架的操作,ActivityManagerProxy实现了接口IActivitManager,但并不真正实现这些方法,它只是一个代理类,真正动作的执行为StubActivityManagerService,ActivityManagerService对象只有一个并存在于system_process进程中,ActivityManagerService继承于ActivityManagerNative存根类。
            3.
    从前面分析知,ActivityManager存在于用户进程中,由用户进程调用获取Activity管理的一些基本信息,但是ActivityManager类并不真正执行这些操作,操作的真正执行在system_process进程中的ActivityManagerService,ActivityManagerService作为一个服务在system_process启动时被加载,关于ActivityManagerService如何被加载这里不展开讨论,后面在讨论android系统启动时在探讨,那么从ActivityManagerActivityManagerService中间经过一个环节,那就是进程通信,而IActivityManager以及实现接口的代理类ActivityManagerProxy,存根类ActivityManagerNative起着负责进程通信的作用,我在前面的blog aidl实现机制浅析中有对进程通信作了较深入的分析,虽然这里没有使用aidl文件定义进程通信接口IActivityManager,其实是一样的,我们可以把它看做是自己手动编译的aidl进程通信java类实现,ActivityManagerProxy是代理类,ActivityManagerNativeStub类,IActivityManageraidl接口,这样就很容易理解了。
            4.ActivityManager
    提供了很少的方法,要能够使用IActivityManager接口提供的其他方法我们可以直接使用ActivityManagerProxy对象,如何获取?
    return ActivityManagerNative.getDefault()
           
     不要被方法名称所迷惑,由于我们在用户进程调用,是不可能获取一个ActivityManagerNative对象的(再说ActivityManagerNative是一个abstract),我们实际获取的是一个ActivityManagerProxy对象
           
     理解以上ActivityManager框架基本结构,后面深入研究它就要容易许多了

     

     

    Android FrameWork——PackageManager框架

     

    1.接着前面讲的ActivityManager框架,继续说一下系统另一个重要的框架,PackagerManager
    同样先看一下静态类结构图:

     

    大部分情况我们是在Activity中使用getPackageManager方法获取一个ApplicationPackageManager的对象,ApplicationPackageManager实际上是包装了一个IPackageManager.Stub.Proxy的对象
    IPackageManager.Stub.Proxy代理执行PackageManager相关操作,IPackageManager.Stub.Proxy实际代理的是PackageManagerService,
    2.
    看了前面说的,可能你有点晕,我们再来重新理一下:
           
     首先是IPackageManager是通过IPackageManager.aidl文件生成,同时生成了存根类IPackageManager.Stub,代理类:IPackageManager.Stub.Proxy
    这个是packageManager进程通信的基本框架,我前面blog有说,不多加说明了
           
     然后PackageManagerService,它继承了IPackageManager.Stub,它作为PackageManager动作的实际执行者,在system_process中存在
           
     再是我们用户应用程序中的ApplicationPackageManager,先看它如何被获取的:
    ContextImpl.java
    中有一个方法:
        public PackageManager getPackageManager() {
            if (mPackageManager != null) {
                return mPackageManager;
            }

            IPackageManager pm = ActivityThread.getPackageManager();
            if (pm != null) {
                // Doesn't matter if we make more than one instance.
                return (mPackageManager = new ApplicationPackageManager(this, pm));
            }

            return null;
        }
    ApplicationPackageManager
    实际上是包装了一个IPackageManager对象(IPackageManager.Stub.Proxy),当我们调用queryIntentActivities时,实际通过代理对象去执行:
        public List<ResolveInfo> queryIntentActivities(Intent intent,
                    int flags) {
                try {
                    return mPM.queryIntentActivities(//mPM
    IPackageManager.Stub.Proxy对象
                        intent,
                        intent.resolveTypeIfNeeded(mContext.getContentResolver()),
                        flags);
                } catch (RemoteException e) {
                    throw new RuntimeException("Package manager has died", e);
                }
            }
    进过进程通信,在PackageManagerService执行对应操作:
    3.PackageManagerService
    的构建与获取
    --PackageManagerService
    的构建:在system_process进程加载时,PackageManagerService被构建,在SystemServer.ServerThread.run中有如下一段代码,它就是加载  PackageManagerService的:
                Slog.i(TAG, "Package Manager");
                pm = PackageManagerService.main(context,
                        factoryTest != SystemServer.FACTORY_TEST_OFF);//
    启动PackageManagerService
    ///////////////////////PackageManagerService///////////////////////////////////////////////////////////////////////////
        public static final IPackageManager main(Context context, boolean factoryTest) {
            PackageManagerService m = new PackageManagerService(context, factoryTest);
            ServiceManager.addService("package", m);
            return m;
        }
        --PackageManagerService
    获取:      
       
     先看前面在ContextImpl.java->getPackagerManager中:   
           IPackageManager pm = ActivityThread.getPackageManager();
    /////////////////////ActivityThread////////////////
            public static IPackageManager getPackageManager() {
            if (sPackageManager != null) {
                //Slog.v("PackageManager", "returning cur default = " + sPackageManager);
                return sPackageManager;
            }
            IBinder b = ServiceManager.getService("package");
            //Slog.v("PackageManager", "default service binder = " + b);
            sPackageManager = IPackageManager.Stub.asInterface(b);
            //Slog.v("PackageManager", "default service = " + sPackageManager);
            return sPackageManager;
        }
        
     ServiceManager中获取的服务pakager,该服务在.PackageManagerService的构建时被注册到ServiceManager中的,ServiceManager机制暂时没有深入了解,后面再发blog专门说一下ServiceManager

  • 相关阅读:
    mysql报错:java.sql.SQLException: The server time zone value 'Öйú±ê׼ʱ¼ä' is unrecognized or represents more than one time zone.
    MD5登陆密码的生成
    15. 3Sum、16. 3Sum Closest和18. 4Sum
    11. Container With Most Water
    8. String to Integer (atoi)
    6. ZigZag Conversion
    5. Longest Palindromic Substring
    几种非线性激活函数介绍
    AI初探1
    AI初探
  • 原文地址:https://www.cnblogs.com/sode/p/2652026.html
Copyright © 2011-2022 走看看