Activity基类实现保存Bundle数据，避免空指针及重复劳动

讲给新手的一些话

相信有一定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 中去取，安全无污染，省力更省心。

后记

其实没什么技术含量，我本人也没什么太厉害的技术可以吹嘘。但和最初的 NullPointer 比起来，和为了处理 NullPointer 一次又一次的做重复工作比起来，还是好多了吧？

另外安利一下我和一个朋友才起步的开源项目，里面收录了、也打算收录更多的能够帮助开发者提高一点工作效率的代码，本文的代码也在其中，并且有优化。

https://github.com/neverwoodsS/zy-open