浅谈Android应用的退出

最近在做公司的Android项目，在和用户交流需求时，对方提出：菜单中务必有“退出程序”一项。理由很简单，我要用别的程序，你老占着我内存干嘛。

说实话，我是不想做这个的。但这肯定跟客户解释不通，只好硬着头皮做。既然做了，当然不能给个空方法了事。下面先给出解决方案，最后讨论下为什么不愿意退出，仅作个人观点，欢迎各位指点。

思路

关于Android的退出，网络上的方法很多，总结起来大概有以下几种：

• 使用java.lang.System类的exit(int code)方法；

• 更暴力的，使用android.os.Process.killProcess(myPid())；

• 使用系统服务ActivityManager,killBackgroudProcesses()；

• 习惯异常编程的可能会喜欢制造FATAL ERROR，利用Android强制退出；

• 一些更为熟悉反射机制的，强制调用forceStopPackage()方法；

• 自行维护一个Activity集合，在退出的时候逐一finish掉它们。

这些方法各有利弊，简单分析如下：

• 直接的System.exit()方法:这会清理当前进程占用的所有资源，结束运行的线程并杀死当前进程，但在应用占用资源比较多的时候会出现短暂黑屏现象，影响用户体验。注意，如果我们的Service指定了android:process，即运行在其他线程，使用System.exit()是不会干掉这些新进程的。

• killProcess()/killBackgroundProcess()方法，很明显地，强行中止进程而不允许其保存必要的状态信息，这是不符合Android设计的，并且即使在传统桌面应用，也不推荐吧？

• 使用反射机制的淫才，我就不想吐槽了，分明Google做API的时候已经隐藏掉了，你非要挖出来调用，为什么呐？显示自己看过源码？

• 自行维护一个Activity集合的方法看似比较温和和可信，但是弊端也很明显：a.每次启动一个Activity必须调用一次工具类，否则将导致程序留下一些让用户莫名其妙的Activity；b.这种方法只维护了Activity，但如果程序启动了长时间执行的后台线程，这些线程将一直运行，成为名副其实的精灵线程；c.与System.exit()一样的，对于远程进程没有处理。

解决方案

综合以上各类方法的优缺点，我最后决定采用自行维护一个Activity集合的方式。

package org.flyingcat.common.os;
import java.util.ArrayList;
import android.app.Activity;
/**
 * @author Flyingcat
 * @create 2014-3-11
 * @version 1.0
 */
public class ExitAppManager {
                                                                                                    
    private static ArrayList<Activity> activities;    //①
                                                                                                    
    private static final void check(){                    //②
        if (activities==null){
            activities = new ArrayList<Activity>();
        }
    }
    public static final void record(Activity act){  //③
        check();
        activities.add(act);
    }
    public static final void exit(){
        for (int i=0; i<activities.size(); i++){ //④
            activities.get(i).finish();
        }
        activities = null;
        System.exit(0);                             //⑤
    }
}

几点注释：很多类似的实现使用了单例模式，但我比较懒，不愿意增加一个额外的单例变量，使用static来替代了。

① 这里声明保存Activity的ArrayList集合，之所以使用List而不是Stack，是因为按照FIFO原则清理Activity时会最后清理当前Activity，不至于让用户看到频繁的Activity退出动画。

② 这里使用了一个额外的方法进行检查，这是和最后的null处理方法对应的。在某些情形下，如果用户频繁开关应用，可能造成类还没有被卸载就再次运行，静态的List未被重新初始化。总之，这样是为了增加健壮性。

③ 这个方法用于记录Activity，很显然，每个Activity启动时都应该调用这个方法。

④ 逐个销毁Activity，这个没什么好解释的。

⑤ 这里还是使用了System.exit(0)。因为实际上前面已经解释过了，exit(0)的方法其实清理得还是比较干净的，加上这一句可以避免因为疏忽忘记添加Activity导致的bug。而且比较占用资源的Activity已经被清理完毕，这里主要是清理线程和服务的工作。执行这行代码后，程序就关闭了。但是，如果有远程进程还需要关闭，就需要增加额外的代码了，这里不再赘述。

个人看法：为什么不用退出？

首先，这些内存并没有被浪费。Android使用Linux内核，采用了类似于Linux的内存管理机制，将当前空闲的物理内存用于存储可能再次使用的进程。Android在官方文档中已经给出了说明：这样的设计是为了下次打开这个程序时启动速度更快。作为一个程序员，应该理解和支持Android这一优秀的特性，而不是违背这个思想去设计程序。

其次，驻留在内存的后台程序并不总会增加耗电量。不活动的后台进程只是在内存中保留了一些信息，但并不进行任何计算（被“暂停”掉了），不占用CPU，也就可以视为不耗电。既然这样，我们也没有必要继续杀死程序来省电。但是，有一些应用后台操作确实是要耗电的，这是因为它们启动了Service或后台线程，执行了额外的计算操作。

再次，系统已有应对内存紧缺的解决方案。Android在活动进程内存紧张时会以既定的算法杀死不活动的后台进程。而当用户真正对内存有大量需求时（比如，用户想来一把大型3D游戏），可以通过最近任务列表（4.0以上版本）手动清理内存。这两种途径其实都不需要任何一个应用层应用程序的设计者干预。

以上是我的一点小小看法，欢迎大家批评指正。