关于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();