关于android回收问题

Activity的回收

之前知道Activity是可能被系统回收的。实际测试了下,当打开过多的活动后,部分之前打开的Activity映像就消失了。

Activity被回收的处理方法一般是实现onSaveInstance,把需要保存的变量持久化到本地,当跳转到Activity时,加载这些变量。

被回收的Activity有普通的Activity,通过onCreate中判断输入参数savedInstanceState来判断是否被回收。

还有如launchMode为singleTask模式的Activity,这些Activity需要实现onNewIntent方法,在onCreate中,判断当前活动如果为被回收的,则与onNewIntent共同调用一个入口方法进行初始化工作。


Application被回收

在实际中,Application被回收的情况也是很多的,特别是内存比较低的手机,又或者发生在不习惯清内存的用户手机上。实际当中也要考虑Application数据的持久化问题。

之前总是认为Application被回收,长按home键中的其Activity映像理应被回收,其实这是错误的,两者是不影响的。

android的设计允许应用被回收后,依然能够跳转到之前的界面,不影响用户的使用,用户不会感知到这点,所以实际开发中,这点是要被考虑到的。

全局的信息的初始化可以覆写Application类,在onCreate中实现初始化工作。

一些非全局的、Activity相关的业务、lazy-loading的业务,比如一个业务类,在某个活动的onCreate中才进行初始化,需要设置一个标志位来确认Application是否被回收,在Activity的onCreate中,先判断标志位确认是否被回收,才进行初始化,并使能标志位,以防止重复加载。

需要注意的是,如果一个Activity和它的下级Activity公用一个非全局业务类(即不再Application中初始化),那么两个Activity的入口都需要判断回收标志位并执行初始化。原因如下:回收前,如果停在2级Activity,回收并跳转回来后,1级Activity的onCreate并不会被执行。


一个ViewPager的回收问题

项目中,在ViewPager的onPageSelected监听方法中尝试通知fragment去做一些事情。

正常情况下,是没有问题的,fragment实例化之后,对应的fragment的onPageSeleted才会被调用。

当Application被回收时,如果选中的是第一个fragment,这时跳转回到app,也没有问题。

如果被回收时,选中的不是第一个fragment,跳转回到app,ViewPager控件会首先回调onPageSelected方法,此时fragment实例化还没有执行,执行fragment的方法就不可行了。

回收后跳转到app,执行顺序是这样的(比如当前停在item1):

onPageSelected1
instantiateItem 1
instantiateItem 0
instantiateItem 2
onPageScrolled1/0.0/0
还能不能愉快地玩耍了?


关于模拟Application被回收

其实Application被回收很好模拟:杀掉进程,保留app的映像,就OK,各种清理大师、360都能达到清理后台进程的效果。

如果自己写代码,遍历以下列表,对包名执行am的killBackgroundProcesses方法就OK了:

ActivityManager am = (ActivityManager) ctx.getSystemService(Context.ACTIVITY_SERVICE);
        List<RunningAppProcessInfo> infoList = am.getRunningAppProcesses();

你可能感兴趣的:(关于android回收问题)