浅谈Android应用的退出

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

成都创新互联公司专注为客户提供全方位的互联网综合服务,包含不限于网站设计、成都网站设计、滁州网络推广、微信平台小程序开发、滁州网络营销、滁州企业策划、滁州品牌公关、搜索引擎seo、人物专访、企业宣传片、企业代运营等,从售前售中售后,我们都将竭诚为您服务,您的肯定,是我们最大的嘉奖;成都创新互联公司为所有大学生创业者提供滁州建站搭建服务,24小时服务热线:028-86922220,官方网址:www.cdcxhl.com

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


思路

关于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 activities;    //①
                                                                                                    
    private static final void check(){                    //②
        if (activities==null){
            activities = new ArrayList();
        }
    }
    public static final void record(Activity act){  //③
        check();
        activities.add(act);
    }
    public static final void exit(){
        for (int i=0; i

几点注释:很多类似的实现使用了单例模式,但我比较懒,不愿意增加一个额外的单例变量,使用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以上版本)手动清理内存。这两种途径其实都不需要任何一个应用层应用程序的设计者干预。


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


文章名称:浅谈Android应用的退出
网页URL:http://bzwzjz.com/article/pphesh.html

其他资讯

Copyright © 2007-2020 广东宝晨空调科技有限公司 All Rights Reserved 粤ICP备2022107769号
友情链接: 成都网站建设 成都网站建设流程 成都网站制作 温江网站设计 重庆企业网站建设 成都网站建设 手机网站制作 成都网站制作 成都网站制作 手机网站制作 成都网站建设公司 高端网站设计 营销网站建设 成都做网站建设公司 手机网站建设 成都网站建设 网站建设 成都企业网站制作 手机网站建设 成都网站建设 手机网站设计 成都网站建设