写在前面
今天在开发中，有设计新的模块和功能。
需求是这样的：在项目产品中会增加一种新的模块，叫做精选套餐（项目类似于美团，大众点评，不过更加专注于精品餐吧和套餐的推送，也专注于夜生活相关的内容，叫做《夜夜》app，感兴趣可以去应用市场下载了解下）。这一个模块会涉及到支付， 也就是购买。在这一个项目中只是集成支付宝支付和微信支付这两种比较主流的线上支付方式。
然而我在完成精选套餐模块的编写之后，模拟了用户购买套餐，向服务器发起了创建订单的请求，并得到了response，当我把获得的charge交付给Ping++之后，我发现了一个神奇的想象，就是：
在调起第三方支付的一瞬间，app被kill掉了！被kill了！kill了！
what？what the hell ?what is happening?
这完全是不予许发生的事情好么？而且，更加神奇的是，app被kill之后，第三方支付竟然还很正常的调起了，也可以很正常的支付！！！
这么诡异的现象，生平仅见啊！不过稀奇归稀奇，问题总是还得解决的。
重启app之后，去到了订单中心，发现订单真的是支付成功了，正安安静静的躺在已支付列表里面呢！也就是说支付这一个流程并没有错，请求服务器生成回来的订单以及支付的凭证charge也貌似没有问题，不然是不会支付成功的。但是app的确是在调起支付的一瞬间被kill的，这无论怎么看都跟支付流程脱不了嫌疑。
竟然在怀疑支付流程，那么就来试一下：
//startActivityForResult（payIntent）;
我把发起支付的最后一句代码注释了一下，运行之后，发现app很正常，并没有被kill，当然同时并没有调起支付。
好吧，确实是跟支付有关系。
那么，到底又是有什么关系呢？
回去翻了一下Ping++的文档，方向文档写着服务端生成的charge是有一定的规格的，例如title不能超过30Unicode字符，content也有限制，description也有限制。那么难道是这一个套餐的中文名字太长然后引发的血案？
但我把支付的凭据charge log出来之后发现，其实都没有超过限制。也就是说，这个锅，ping++不背。
然后仔细梳理了一下思绪，想起app被kill是在调起第三方支付的一瞬间发生，也就是说这一瞬间一定发生了什么事情，到时app挂掉了。但是调起支付的一瞬间无非就是app暂时进入后台，然后调起第三方支付界面，支付完成支付又回到app。那么就是说调起支付一瞬间，app要暂时的进入后台，之后又要回来，也就是说会调用onSaveInstanceState（）对app activity当前的状态进行保存，app又在这一瞬间被kill，那么问题就出现在onSaveInstanceState（）的这一个环节上。
真相已经很接近了
由于想到是在精选套餐的支付环节上才会出现的问题，精选套餐又是新增的模块，那么问题就很可能出现这上面。
由于项目中也有其他的模块有支付的动作，于是就去测试了一下。果然，其他所有的支付流程都是正常的。那么罪魁祸首就是精选套餐模块了。
通过对精选套餐的分析，以及在onSaveInstanceState()进行debug，发现在保存当前activity的时候，保存到变量 mealDetail 终于报错了同时app挂掉了。在报错信息总看到，原来是mealDetail 继承于Serializable，得以可以序列化。然而mealDetail的一个内部类Recommend却没有继承于Serializable。因此在app退入后台，进行事件状态保存的一瞬间，对局部变量进行序列化保存时遇到不能序列化的对象从而导致的crash。
所以当我把mealDetail的内部类Recommend继承于Serializable之后，精选套餐的支付流程果然很正常的执行了。
关于onSaveInstanceState可以点击查看说明。
基本作用就是
Activity的 onSaveInstanceState() 和 onRestoreInstanceState()并不是生命周期方法，它们不同于 onCreate()、onPause()等生命周期方法，它们并不一定会被触发。当应用遇到意外情况（如：内存不足、用户直接按Home键）由系统销毁一个Activity时，onSaveInstanceState() 会被调用。但是当用户主动去销毁一个Activity时，例如在应用中按返回键，onSaveInstanceState()就不会被调用。因为在这种情况下，用户的行为决定了不需要保存Activity的状态。通常onSaveInstanceState()只适合用于保存一些临时性的状态，而onPause()适合用于数据的持久化保存。
在activity被杀掉之前调用保存每个实例的状态,以保证该状态可以在onCreate(Bundle)或者onRestoreInstanceState(Bundle) (传入的Bundle参数是由onSaveInstanceState封装好的)中恢复。这个方法在一个activity被杀死前调用，当该activity在将来某个时刻回来时可以恢复其先前状态。
例如，如果activity B启用后位于activity A的前端，在某个时刻activity A因为系统回收资源的问题要被杀掉，A通过onSaveInstanceState将有机会保存其用户界面状态，使得将来用户返回到activity A时能通过onCreate(Bundle)或者onRestoreInstanceState(Bundle)恢复界面的状态。
关于onSaveInstanceState ()，是在函数里面保存一些View有用的数据到一个Parcelable对象并返回。在Activity的onSaveInstanceState(Bundle outState)中调用View的onSaveInstanceState ()，返回Parcelable对象，
接着用Bundle的putParcelable方法保存在Bundle savedInstanceState中。
当系统调用Activity的的onRestoreInstanceState(Bundle savedInstanceState)时， 同过Bundle的getParcelable方法得到Parcelable对象，然后把该Parcelable对象传给View的onRestoreInstanceState (Parcelable state)。在的View的onRestoreInstanceState中从Parcelable读取保存的数据以便View使用。
这就是onSaveInstanceState() 和 onRestoreInstanceState() 两个函数的基本作用和用法。
总结
到最后才发现，原来所谓的bug还是自己的粗心造成的，只是忽略了onSaveInstanceState（）函数对于变量的要求从而导致的一系列问题的出现。同时也是自己偷懒，在创建mealDetail 这一个数据model的时候用了AndroidStudio的插件GsonFormat直接进行生成然后却没有认真地检查。（GsonFormat确实是很吊的一款插件，很推荐使用，可以省下大量的时间，当然也要细心的使用，例如我这次的例子）
by the way，撸代码是一件严肃，细致，一丝不苟的事情，真的马虎不得。这次把这么蠢的crash事件码了出来，就是让大家嘲笑一下我，这是对我很好的一个鞭策。同时也帮助一下那些可能也遇到这个问题的童鞋们。
好吧，以后我要认真啦，哈哈
