本文探讨了在Android M及以上版本中，当用户禁用应用的runtime权限时，进程被杀后Activity如何恢复的问题。重点分析了三种不同恢复机制的特点及注意事项。
设备M或者M以上，当用户手动在系统设置中disable掉应用任何runtime permission时，运行的应用process会被kill掉，重回前台的时候，系统会恢复应用的task。但是这里需要注意Activity恢复的相关处理：
1. 如果你的页面是通过onSaveInstanceState和onRestoreInstanceState记录状态并恢复的。那么恭喜你，你不需要做额外的工作。
2. 如果你是基于onRetainNonConfigurationInstance和getLastNonConfigurationInstance的，那么你有事了。重新恢复时getLastNonConfigurationInstance始终为null。Crash会让你想办法处理。
3. 如果你是基于Retained Fragment记录状态并恢复的，那么你哭吧。重新恢复时，你的Retained Fragment不会为null，但是它却是个全新的Retained Fragment，数据都是初始默认值。这种情况更容易造成潜在的bug。
所以，最好使用onSaveInstanceState，考虑使用Parcelable或者Serializable记录复杂的对象。 如果onSaveInstanceState有实在不能记录的内容或者记录代价很大的情况，根据业务逻辑，考虑恢复成初始状态吧。 对Retained Fragment的情形得小心了，你得考虑到它可能是个dummy的对象，需要额外的逻辑处理这种情况。
那怎么能够确定碰上了这种情况呢？ 始终实现onRetainNonConfigurationInstance，return一个非null的对象，然后在recreate的时候检查savedInstanceState != null && getLastNonConfigurationInstance == null
1. 如果你的页面是通过onSaveInstanceState和onRestoreInstanceState记录状态并恢复的。那么恭喜你，你不需要做额外的工作。
2. 如果你是基于onRetainNonConfigurationInstance和getLastNonConfigurationInstance的，那么你有事了。重新恢复时getLastNonConfigurationInstance始终为null。Crash会让你想办法处理。
3. 如果你是基于Retained Fragment记录状态并恢复的，那么你哭吧。重新恢复时，你的Retained Fragment不会为null，但是它却是个全新的Retained Fragment，数据都是初始默认值。这种情况更容易造成潜在的bug。
所以，最好使用onSaveInstanceState，考虑使用Parcelable或者Serializable记录复杂的对象。 如果onSaveInstanceState有实在不能记录的内容或者记录代价很大的情况，根据业务逻辑，考虑恢复成初始状态吧。 对Retained Fragment的情形得小心了，你得考虑到它可能是个dummy的对象，需要额外的逻辑处理这种情况。
那怎么能够确定碰上了这种情况呢？ 始终实现onRetainNonConfigurationInstance，return一个非null的对象，然后在recreate的时候检查savedInstanceState != null && getLastNonConfigurationInstance == null
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
