Android系统在5.0时，对进程内的内存管理做了一个优化，但并没有明确的文档说明这个优化。
这个优化为解决Android应用的内存问题，提供了一个新的思路。但如果开发者习惯于单Task的应用开发，或者从来不考虑SaveState，那开发者可能根本无法体会这个新机制的好处。
本文首先从SaveState讲起，对于了解SaveState的同学，可以直接跳过
什么是SaveState
要了解什么是SaveState必须要先知道Activity的两个关键方法
onSaveInstanceStateonRestoreInstanceState
onSaveInstanceState时系统做了些什么
在Activity被回收之前，系统会调用onSaveInstanceState(Bundle outState)来保存View的状态，并到传入的outState对象中。
- 保存Window
- 保存Fragment
- 调用外部注册的回调方法
protected void onSaveInstanceState(Bundle outState) {
outState.putBundle(WINDOW_HIERARCHY_TAG, mWindow.saveHierarchyState());
Parcelable p = mFragments.saveAllState();
if (p != null) {
outState.putParcelable(FRAGMENTS_TAG, p);
}
getApplication().dispatchActivitySaveInstanceState(this, outState);
}
onRestoreInstanceState时系统做了些什么
在Activity被重新创建时，会通过onCreate(Bundle savedInstanceState)和onRestoreInstanceState(Bundle savedInstanceState)传入保存的状态信息并恢复View的状态。
- onCreate重建Fragment
- onRestoreInstanceState恢复Window状态
protected void onCreate(@Nullable Bundle savedInstanceState) {
if (DEBUG_LIFECYCLE) Slog.v(TAG, "onCreate " + this + ": " + savedInstanceState);
if (mLastNonConfigurationInstances != null) {
mFragments.restoreLoaderNonConfig(mLastNonConfigurationInstances.loaders);
}
if (mActivityInfo.parentActivityName != null) {
if (mActionBar == null) {
mEnableDefaultActionBarUp = true;
} else {
mActionBar.setDefaultDisplayHomeAsUpEnabled(true);
}
}
if (savedInstanceState != null) {
Parcelable p = savedInstanceState.getParcelable(FRAGMENTS_TAG);
mFragments.restoreAllState(p, mLastNonConfigurationInstances != null
? mLastNonConfigurationInstances.fragments : null);
}
mFragments.dispatchCreate();
getApplication().dispatchActivityCreated(this, savedInstanceState);
if (mVoiceInteractor != null) {
mVoiceInteractor.attachActivity(this);
}
mCalled = true;
}
protected void onRestoreInstanceState(Bundle savedInstanceState) {
if (mWindow != null) {
Bundle windowState = savedInstanceState.getBundle(WINDOW_HIERARCHY_TAG);
if (windowState != null) {
mWindow.restoreHierarchyState(windowState);
}
}
}
Window在save和restore时对View的处理
- Save时，遍历View的树状结构调用
Parcelable onSaveInstanceState() - 以View的id为key在Window的
SparseArray<Parcelable>中保存这些Parcelable - Restore时，Window从
savedInstanceState获取View的savedStates - 遍历View的树状结构调用
onRestoreInstanceState(Parcelable state) - View根据id获取自己的state并恢复
小结
- Save和Restore的机制主要是用于保存和恢复View的
- 没有id的View是不会被保存状态的
- 如果id重复，则View的状态会被覆盖
- 被保存的Fragment会在onCreate中被自动创建和添加到FragmentActivity中
- 被保存的View不会被自动创建，只是通过id获取savedInstance用于更新View
关于SaveState的详细介绍可以参考文章Android中SaveState原理分析
为什么开始使用SaveState
为什么很多人不重视SaveState
我们先了解下会用到Restore机制的地方
-
FragmentStatePagerAdapter用于在ViewPager中使用可回收和重建的Fragment - 应用Crash时，当前页面被销毁，前一个页面被Restore
- 在4.0之前，系统不会自动重启应用
- 在4.0之后，系统会自动重启，并通过Restore机制恢复Crash的页面。
FragmentStatePagerAdapter中考虑SaveState是必须的，所以大家都会被迫处理SaveState的问题。
大多数开发者不会考虑Crash重建的问题，所以SaveState很少被开发者重视。而认真考虑过Crash重建的开发者一定不会对SaveState陌生。
5.0的新机制
在5.0中，SaveState有了新的作用，稍加利用，它会帮你解决OutOfMemory。而根据Google的统计，到今年下半年，Android5.0及以上的系统占比将超过50%。
要触发这个新机制，你的应用必须是多Task结构的。关于Task，那又是一个很大的话题，下面我只用一个简单的例子看看这个新机制。
演示代码可以通过git仓库下载
这里看看关键的ActivivtyOne.java
- ActivityOne是standard
- ActivityTwo是singleInstance，所以他会在单独的新的Task中
- AcitivyOne可以启动ActivityTwo
- ActivityOne可以不断消耗内存
public class ActivityOne extends BaseActivity {
boolean forceOom = false;
List<Bitmap> memory = new ArrayList<>();
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_one);
}
public void launchTwo(View view) {
ActivityTwo.launch(this);
}
/**
* 第一次点击使内存接近进程能获取的内存上限,再次点击触发OOM
* @param view
*/
public void consumeMem(View view) {
new Thread(new Runnable() {
@Override
public void run() {
while (true) {
if (!forceOom && isLowMemory()) {
forceOom = true;
break;
}
memory.add(Bitmap.createBitmap(1000, 1000, Bitmap.Config.ARGB_8888));
try {
Thread.sleep(100);
} catch (InterruptedException e) {
}
}
}
}).start();
}
/**
* 判断已使用的内存是否接近了单进程的内存上限
*
* @return
*/
public boolean isLowMemory() {
ActivityManager activityManager = (ActivityManager) getSystemService(ACTIVITY_SERVICE);
long total = Runtime.getRuntime().totalMemory() / (1024l * 1024l);
int max = activityManager.getMemoryClass();
Log.w(getClass().getSimpleName(), total + "/" + max);
if (total > activityManager.getMemoryClass() * 0.85) return true;
return false;
}
public static void launch(Activity activity) {
activity.startActivity(new Intent(activity, ActivityOne.class));
}
}
操作步骤：
- ActivityOne启动ActivityTow
- ActivityTwo启动ActivityOne，从而切换到老的Task中，ActivityTwo不会被销毁
- ActivityOne不断消耗内存，直到接近进程使用内存的上限（Android系统对每个进程使用的最大内存有一个限制）
这时通过logcat你会看到5.0的不同：
- 5.0之前：不会有什么事情发生。再次点击消耗内存，会OOM，整个进程被杀。
- 5.0及之后：
ActivityTwo#OnDestroy会被调用，这时再启动ActivityTwo，可以看到ActivityTwo#onRestoreInstanceState的调用。
W/ActivityOne: 83571877-onCreate: TaskId-7551
W/ActivityTwo: 128141518-onCreate: TaskId-7552
W/ActivityOne: 83571877-onSaveInstanceState
W/ActivityOne: 219591424-onCreate: TaskId-7551
W/ActivityTwo: 128141518-onSaveInstanceState
W/ActivityOne: 23/192
W/ActivityOne: 42/192
W/ActivityOne: 88/192
W/ActivityOne: 111/192
W/ActivityOne: 157/192
以下是5.0系统上才会出现的
W/ActivityTwo: 128141518-onDestroy
W/ActivityOne: 176/192
W/ActivityTwo: 80252517-onCreate: TaskId-7552
W/ActivityTwo: 80252517-onRestoreInstanceState
W/ActivityTwo: 80252517-onNewIntent
W/ActivityOne: 219591424-onSaveInstanceState
因此我们可以得出结论：
5.0之后，Android进程在遇到内存瓶颈时，会通过主动销毁进程中的Acitivty来释放内存。这些被销毁的Activity都属于后台Task，当被销毁的Activity需要重新出现时，会触发Restore机制
当然，这个结论又会引起很多疑问。
- 为什么不销毁当前Task中的后台Activity？
- 如果后台Task中有多个Activity是一起销毁吗？如果后台Task中的多个Activity是属于不同的进程呢？
- ......
关于这些问题，需要分析源码才能找到答案，但我不希望这篇文章变成对Android源码的一次分析。我将在下篇文章，继续介绍怎么处理SaveState。
当然，即使没有SaveState在5.0上带来的好处，正确处理页面的SaveState也是保证Android应用程序健壮性的一个重要部分。
怎么处理SaveState，请看下篇文章
- 原文链接
- 我的主页：www.huangyifei.info
- 微信订阅号：tech_galaxy
