讲给新手的一些话
相信有一定Android开发经验的朋友或多或少的都遇到过 Activity 中某些对象莫名其妙的出现了空指针的异常。这种异常通常发生在 Activity 切换到了后台，然后又做了其他一些内存开销比较大的事，比如玩游戏，比如打开了很多其他应用。因为在后台，所以这个 Activity 的优先级就降低了，在内存比较吃紧的时候极有可能被回收。还不熟悉这一套机制的朋友在这里可能就会遇到一些问题了。
虽然内存被回收了，但是由于这是系统的决定，而非代码触发的行为，当用户再启动这个应用的时候，并不会重新走启动流程，而是直接回到离开时候的 Activity。又因为 Activity 已经被回收了，所以理所当然的会重新创建、重走从 onCreate 开始的生命周期。
针对这种情况，Android 有 onSaveInstanceState、onRestoreInstanceState 这一对生命周期用来保存和取出来还原 Activity 至被回收之前的状态，具体详情可参考：
http://blog.csdn.net/initphp/article/details/11973651
正文
onSaveInstanceState、onRestoreInstanceState 真的可以解决所有问题了吗？
@Override
public void onCreate(Bundle savedInstanceState, PersistableBundle persistentState) {
super.onCreate(savedInstanceState, persistentState);
Data data = getIntent().getParcelableExtra("data");
if (data.type == 0) {
setContentView(R.layout.activity_to);
//TODO
} else {
setContentView(R.layout.activity_from);
//TODO
}
}
以上代码的意图很清晰，是根据上一个界面传递过来的参数 data 中的 type 来决定加载什么布局。这段代码合不合理暂且不考虑，想一下这种情景下内存被回收了会发生什么就很有意思了。
1.getIntent()无法再获取到上一界面传递过来的 bundle 数据，此时 data 对象必然为空；
2.onRestoreInstanceState 的执行时机是在 onCreate 之后的，也就是说，如果我用在 onCreate 的生命周期中用 getIntent() 方法获取上一个界面传递过来的参数，然后立即使用的话，其实 onRestoreInstanceState 是还没来得及调用的；
3.空指针呼之欲出 T_T
So ？
我曾经是这样做的
@Override
public void onCreate(Bundle savedInstanceState, PersistableBundle persistentState) {
super.onCreate(savedInstanceState, persistentState);
if (savedInstanceState == null) {
data = getIntent().getParcelableExtra("data");
} else {
data = savedInstanceState.getParcelable("data");
}
if (data.type == 0) {
setContentView(R.layout.activity_to);
//TODO
} else {
setContentView(R.layout.activity_from);
//TODO
}
}
savedInstanceState 是保存的 Activity 的状态，如果为 null，则代表是正常进入，否则即为我们考虑的内存被回收后重启的情况。
这段代码就是根据不同的情况，去从 getIntent() 或 savedInstanceState 中再去获取 data 对象。当然，前提条件是我有这样子做：
@Override
protected void onSaveInstanceState(Bundle outState) {
outState.putParcelable("data", data);
super.onSaveInstanceState(outState);
}
即在被回收前将 data 对象保存至 bundle 中。
整体看上去还算简单对吧？
我庆幸于我从此脱离了NullPointer的苦海，但这只是苦难的开始 T_T
真 · 正文
实际开发过程当中，bundle 中不一定只有 data 这么一个参数，有几个参数的情况也很常见，于是上述代码就会扩张开来。
代码行数约等于 参数数量*2（取） + 参数数量 *1（存）
也就是说，每增加一个传递的参数，我就要多写三行代码，毫无营养价值的三行代码。这是第一层意义上的重复劳动。
然后呢，每一个要接收 Bundle 参数的 Activity，我都要写这么几段代码，逻辑基本上完全相同，这是第二层意义上的重复劳动。
有一句话说得好：不在沉默中爆发，就在沉默中灭亡。终于有一天我忍无可忍，开始想办法怎么才能更优（偷）雅（懒）的去解决这个问题。
要避免每个 Activity 都写同样的逻辑代码，第一个想到的就是在基类中去写
private Bundle savedBundle;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
initBundle(savedInstanceState);
initData(savedBundle);
}
可以看到 onCreate 方法中除了执行父类的方法之外，就只执行了 initBundle 和 initData 这两个方法。
/**
* 传入 onCreate 中的 bundle，根据是否为空进行相应处理
* 如果为 null，代表 activity 还没有保存过 bundle
* @param savedInstanceState
*/
private void initBundle(Bundle savedInstanceState) {
if (savedInstanceState == null) {
savedBundle = getIntent().getExtras();
} else {
savedBundle = savedInstanceState.getBundle("savedBundle");
}
//如果没有任何参数，则初始化 savedBundle，避免调用时 null pointer
if (savedBundle == null) {
savedBundle = new Bundle();
}
}
/**
* 保存 bundle
* @param outState
*/
protected void onSaveInstanceState(Bundle outState) {
outState.putBundle("savedBundle", this.savedBundle);
super.onSaveInstanceState(outState);
}
是不是和之前的处理方式很像？唯一的区别就是在 getIntent() 的时候，我一股脑的把所有数据都取了出来，并赋值给 savedBundle，保存的时候也只保存 savedBundle 这么一个对象。
我并没有生产新的数据，我只是数据的搬运工
对了，还有一个 initData 方法是干嘛的？
/**
* 提供给子类取值的方法
* @param savedBundle
*/
protected void initData(Bundle savedBundle) {
}
原来什么都没做。。
How to use ?
在继承自基类的 Activity 中，覆写 initData 方法即可
@Override
protected void initData(Bundle savedBundle) {
super.initData(savedBundle);
int data = savedBundle.getInt("data");
Log.i("bundle", " data = " + data);
}
要什么参数直接从 initData 方法提供的 savedBundle 中去取，安全无污染，省力更省心。
