【Android】【内存管理】Activity在回收和恢复时，究竟发生了什么

首先，安卓系统对于应用的回收方式有两种策略

• 一种是只回收Activity（活动）
• 另一种回收整个Process（进程）

在日常开发中，回收场景并不是经常出现，可能要在后台挂很久才会出现
一些高配手机甚至可能都很少遇到回收情景，这给我们测试观察带来了麻烦

不过好在，我们可以在开发者选项中，更改安卓内置的内存回收策略，使得Activity回收和Process回收百分百触发，这样我们就很容易去观察，Activity的回收和恢复到底是如何进行的

首先介绍下两种回收策略的触发条件

不保留活动
只要切换到其它Activity，当前Activity立刻被消耗，但销毁前可以手动去保存界面状态>

不允许后台进程
只要切换到其它应用，当前进程立刻被结束，但结束前可以保存Activity的界面状态

现在我们通过实际的代码测试，来讲解应用是如何被回收和恢复的
测试情景：Application => 启动SplashActivity => 启动A => 回到系统桌面 => 重新打开应用

总结这个流程，我们可以得到以下要点

进程恢复时，只会重新执行Application和最近的Activity的生命周期方法，其它的数据都将会丢失
这包括：其它Activity创建的静态变量，其它Activity在Application中保存的值，用户手动在界面中输入的值

Activity恢复时，可以原样拿到回收之前的Intent数据

用户可以手动在回收之前，调用onSaveInstanceState保存自己想要保存的数据
在Activity恢复时，再通过调用onRestoreInstanceState来还原数据
对于复杂的对象类型数据，可以通过序列化的方式来保存，虽然比较麻烦

比起电脑端桌面软件开发，安卓应用的组件通信和内存管理机制相当麻烦
而且进程回收带有不确定性，开发者必须手动去处理这种情况，指定应用如何重新恢复

为什么安卓系统要回收Activity和进程
手机硬件的性能远低于电脑，特别是安卓系统刚出来的时候，难以同时处理过多的程序，所以只能将一部分Activity销毁，将其数据保存起来，下次启动时再恢复

为什么会有Intent，广播这些机制
正因为安卓系统有着应用回收的机制，其它组件是否存活，其它组件的数据是否存在，都是未知的，这样不同组件之间，就不能以对象的方式相互访问。
安卓组件之间，必须是完全独立的，因为其它组件的数据是否存在都是不确定性的，不能依赖其它组件。
如果一定要以对象的方式访问其它组件，就会违背安卓的回收机制。要么会造成组件无法回收，带来性能问题，要么就是进程被回收，造成某些变量值丢失，引发未知错误。
而组件之间，传递数据往往又是必须的功能，所以就有了Intent，广播，SavedInstanceState这些机制，这些机制实际上是以操作系统为中介来转发和保存数据，这样就可以保证组件之间相互独立，互不依赖。
这些机制保证了组件之间的独立关系，但同时也给传递数据，组件通信，数据保存带来了麻烦。
要知道，如果是编写一个电脑端的桌面软件的话，不同窗口之间完全可以以对象的方式相互调用，任何复杂对象都可以直接访问，而在安卓开发中，复杂对象必须通过序列化，文件，数据库等方式来传递，还要考虑应用回收时的备份还原问题，非常之麻烦。

标准的安卓应用开发方式
不能让任意静态变量或者Application持有组件对象的引用，否则会影响组件回收
尽量少使用静态变量，除非确定这个静态变量，能够在应用被回收后，仍然能正常还原
组件之间通过Intent来传递数据，通过广播来通信，复杂的对象可以以序列化的方式存储到本地数据库，然后将对象id通过Intent或广播传递给其它组件
Activity被回收时，要保存界面上的数据，并在Activity恢复时，还原界面数据
一些第三方的服务和SDK，在进程被回收再恢复时，要记得重新初始化

开发成本与标准规范的取舍
前面已经提到，标准的开发方式，虽然符合安卓系统的设计理念，但是也会大幅增加开发的复杂度。对于一些界面复杂，组件之间交互频繁的应用，考虑到开发成本，我们可能牺牲一点规范程度，来换取高效的开发速度。
由于现在的手机性能，已经比安卓系统刚诞生时提升了很多，很多高配手机进行应用回收的频率其实已经很低了，偶尔出现应用回收的情况，我们可以让用户重新输入，或者重新登录，这样就省去了大量界面恢复，进程恢复的工作，而且大多应用都是在后台闲置很久后才会被回收，这时用户往往也可以接受重新登录。
由于手机性能的不断提升，不排除以后安卓的内存管理理念会更改的可能，或者以提醒的方式，让用户手动去关闭应用，而不是在不告知的情况下自动回收，这些一旦成真，都会给开发者带来极大的便利。