标签：android 4.0   frameworks   persistent   

说说Android应用的persistent属性

侯 亮

1 启动persistent应用

    在Android系统中，有一种永久性应用。它们对应的AndroidManifest.xml文件里，会将persistent属性设为true，比如：

<applicationandroid:name="PhoneApp"
android:persistent="true"
android:label="@string/dialerIconLabel"
android:icon="@drawable/ic_launcher_phone">

    在系统启动之时，AMS的systemReady()会加载所有persistent为true的应用。

publicvoid systemReady(finalRunnable goingCallback) 
{
    . . . . . .
    . . . . . .
    try{
        List apps = AppGlobals.getPackageManager().
                        getPersistentApplications(STOCK_PM_FLAGS);
        if(apps != null)
        {
            intN = apps.size();
            inti;
             
            for(i=0; i<N; i++) 
            {
                ApplicationInfo info = (ApplicationInfo)apps.get(i);
                if(info != null&&
                        !info.packageName.equals("android"))
                {
                    addAppLocked(info,false);
                }
            }
        }
    }
    catch(RemoteException ex) {
        // pm is in same process, this will never happen.
    }

其中的STOCK_PM_FLAGS的定义如下：

// The flags that are set for all calls we make to the package manager.
staticfinal int STOCK_PM_FLAGS = PackageManager.GET_SHARED_LIBRARY_FILES;

上面代码中的getPersistentApplications()函数的定义如下：

     从代码里可以看出，带persistent标志的系统应用（即flags中设置了FLAG_SYSTEM）是一定会被选上的，但如果不是系统应用的话，则要进一步判断当前是否处于“安全模式”，一旦处于安全模式，那么就算应用设置了persistent属性，也不会被选中。

     随后systemReady()开始遍历选中的ApplicationInfo，并对包名不为“android”的结点执行addAppLocked()。addAppLocked()的代码如下：

    现在，我们就清楚了，那些persistent属性为true的应用，基本上都是在系统启动伊始就启动起来的。

    因为启动进程的过程是异步的，所以我们需要一个缓冲列表（即上面代码中的mPersistentStartingProcesses列表）来记录那些“正处于启动状态，而又没有启动完毕的”ProcessRecord结点。一旦目标进程启动完毕后，目标进程会attach系统，于是走到AMS的attachApplicationLocked()，在这个函数里，会把目标进程对应的ProcessRecord结点从mPersistentStartingProcesses缓冲列表里删除。

2 如何保证应用的持久性（persistent）

    我们知道，persistent一词的意思是“持久”，那么persistent应用的意思又是什么呢？简单地说，这种应用会顽固地运行于系统之中，从系统一启动，一直到系统关机。

    为了保证这种持久性，persistent应用必须能够在异常出现时，自动重新启动。在Android里是这样实现的。每个ActivityThread中会有一个专门和AMS通信的binder实体——final ApplicationThread mAppThread。这个实体在AMS中对应的代理接口为IApplicationThread。

    当AMS执行到attachApplicationLocked()时，会针对目标用户进程的IApplicationThread接口，注册一个binder讣告监听器，一旦日后用户进程意外挂掉，AMS就能在第一时间感知到，并采取相应的措施。如果AMS发现意外挂掉的应用是persistent的，它会尝试重新启动这个应用。

    注册讣告监听器的代码如下：

其中的thread就是IApplicationThread代理。

    AppDeathRecipient的定义如下：

当其监听的binder实体死亡时，系统会回调AppDeathRecipient的binderDied()。这个回调函数会辗转重启persistent应用，调用关系如下：

    一般情况下，当一个应用进程挂掉后，AMS当然会清理掉其对应的ProcessRecord，这就是cleanUpApplicationRecordLocked()的主要工作。然而，对于persistent应用，cleanUpApplicationRecordLocked()会尝试再次启动对应的应用进程。代码截选如下：

    现在我们可以画一张关于“启动persistent应用”的示意图：

3 补充知识点

3.1 persistent应用可以在系统未准备好时启动

    在AMS中，有一个isAllowedWhileBooting()函数，其代码如下：

    从这个函数可以看到，将persistent属性设为true的应用，是允许在boot的过程中启动的。我们可以查看前文提到的startProcessLocked()函数：

其中的最后几句可以改写为以下更易理解的形式：

    也就是说，当系统已经处于以下几种情况时，多参数的startProcessLocked()会进一步调用另一个只有三个参数的startProcessLocked()：
1）系统已经处于ready状态；
2）想要启动persistent应用；
3）参数中明确指定可以在boot过程中启动应用。

    补充说一下，一般情况下，当AMS调用startProcessLocked()时，传入的allowWhileBooting参数都为false。比如说，当系统需要启动“某个content provider或者某个service或者某个特定activity”时，此时传给startProcessLocked()的allowWhileBooting参数是写死为false的。只有一种特殊情况下会在该参数中传入true，那就是当系统发出的广播intent中携带有Intent.FLAG_RECEIVER_BOOT_UPGRADE标记时，此时允许在系统未ready时，启动接受广播的目标进程。

4 结束

    有关Android应用的persistent属性，我们就先说这么多。希望对大家有点儿帮助。

说说Android应用的persistent属性

标签：android 4.0   frameworks   persistent   

原文地址：http://blog.csdn.net/codefly/article/details/42339981