是时候使用SaveState了

发表于

是时候使用SaveState了

Android系统在5.0时，对进程内的内存管理做了一个优化，但并没有明确的文档说明这个优化。

这个优化为解决Android应用的内存问题，提供了一个新的思路。但如果开发者习惯于单Task的应用开发，或者从来不考虑SaveState，那开发者可能根本无法体会这个新机制的好处。

本文首先从SaveState讲起，对于了解SaveState的同学，可以直接跳过

什么是SaveState

要了解什么是SaveState必须要先知道Activity的两个关键方法

  • onSaveInstanceState
  • onRestoreInstanceState

onSaveInstanceState时系统做了些什么

在Activity被回收之前，系统会调用onSaveInstanceState(Bundle outState)来保存View的状态，并到传入的outState对象中。

  1. 保存Window
  2. 保存Fragment
  3. 调用外部注册的回调方法
1
2
3
4
5
6
7
8
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的状态。

  1. onCreate重建Fragment
  2. onRestoreInstanceState恢复Window状态
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
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;
}
1
2
3
4
5
6
7
8
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的处理

  1. Save时，遍历View的树状结构调用 Parcelable onSaveInstanceState()
  2. 以View的id为key在Window的SparseArray<Parcelable>中保存这些 Parcelable
  3. Restore时，Window从savedInstanceState获取View的savedStates
  4. 遍历View的树状结构调用 onRestoreInstanceState(Parcelable state)
  5. View根据id获取自己的state并恢复

小结

  1. Save和Restore的机制主要是用于保存和恢复View的
  2. 没有id的View是不会被保存状态的
  3. 如果id重复，则View的状态会被覆盖
  4. 被保存的Fragment会在onCreate中被自动创建和添加到FragmentActivity中
  5. 被保存的View不会被自动创建，只是通过id获取savedInstance用于更新View

关于SaveState的详细介绍可以参考文章Android中SaveState原理分析

为什么开始使用SaveState

为什么很多人不重视SaveState

我们先了解下会用到Restore机制的地方

  1. FragmentStatePagerAdapter用于在ViewPager中使用可回收和重建的Fragment

  2. 应用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可以不断消耗内存
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
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));
    }
}

操作步骤：

  1. ActivityOne启动ActivityTow
  2. ActivityTwo启动ActivityOne，从而切换到老的Task中，ActivityTwo不会被销毁
  3. ActivityOne不断消耗内存，直到接近进程使用内存的上限（Android系统对每个进程使用的最大内存有一个限制）

这时通过logcat你会看到5.0的不同：

  • 5.0之前：不会有什么事情发生。再次点击消耗内存，会OOM，整个进程被杀。
  • 5.0及之后：ActivityTwo#OnDestroy会被调用，这时再启动ActivityTwo，可以看到ActivityTwo#onRestoreInstanceState的调用。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
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机制

当然，这个结论又会引起很多疑问。

  1. 为什么不销毁当前Task中的后台Activity？
  2. 如果后台Task中有多个Activity是一起销毁吗？如果后台Task中的多个Activity是属于不同的进程呢？
  3. ……

关于这些问题，需要分析源码才能找到答案，但我不希望这篇文章变成对Android源码的一次分析。我将在下篇文章，继续介绍怎么处理SaveState。

当然，即使没有SaveState在5.0上带来的好处，正确处理页面的SaveState也是保证Android应用程序健壮性的一个重要部分。