崩溃堆栈
首先，崩溃上报的堆栈：
09-22 15:41:59.245 9040 9040 V ActivityThread: callActivityOnCreate
09-22 15:41:59.311 9040 9040 E AndroidRuntime: FATAL EXCEPTION: main
09-22 15:41:59.311 9040 9040 E AndroidRuntime: Process: com.XXXX.android, PID: 9040
09-22 15:41:59.311 9040 9040 E AndroidRuntime: android.util.SuperNotCalledException: Activity {com..XXXX.android/com..XXXX.activity.XXXXActivity} did not call through to super.onCreate()
09-22 15:41:59.311 9040 9040 E AndroidRuntime: at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:3875)
09-22 15:41:59.311 9040 9040 E AndroidRuntime: at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:4081)
09-22 15:41:59.311 9040 9040 E AndroidRuntime: at android.app.servertransaction.LaunchActivityItem.execute(LaunchActivityItem.java:91)
09-22 15:41:59.311 9040 9040 E AndroidRuntime: at android.app.servertransaction.TransactionExecutor.executeCallbacks(TransactionExecutor.java:149)
09-22 15:41:59.311 9040 9040 E AndroidRuntime: at android.app.servertransaction.TransactionExecutor.execute(TransactionExecutor.java:103)
09-22 15:41:59.311 9040 9040 E AndroidRuntime: at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2462)
09-22 15:41:59.311 9040 9040 E AndroidRuntime: at android.os.Handler.dispatchMessage(Handler.java:110)
09-22 15:41:59.311 9040 9040 E AndroidRuntime: at android.os.Looper.loop(Looper.java:219)
09-22 15:41:59.311 9040 9040 E AndroidRuntime: at android.app.ActivityThread.main(ActivityThread.java:8393)
09-22 15:41:59.311 9040 9040 E AndroidRuntime: at java.lang.reflect.Method.invoke(Native Method)
09-22 15:41:59.311 9040 9040 E AndroidRuntime: at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:513)
09-22 15:41:59.311 9040 9040 E AndroidRuntime: at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1055)
这是我们app升级androidx之后，第一次外灰时发现的线上问题。来自线上的偶现bug，主要分布在10的机器以及少部分9的机器上。收集到的crash堆栈，都是显示的super.onCreate()未被调用，而且是很多个不同的activity都在上报，那基本确认是base类的问题。
但是在我们封装的BaseActivity类里都是加了tryCatch逻辑，不会因为业务代码崩了就不去调用super.onCreate().
后来随着继续翻找console log，我们发现这个崩溃由一个BadParcelableException引起，说白了是android内部的onCreate()方法crash后没有走完：
09-22 12:47:36.940 E/Parcel (31316): Class not found when unmarshalling: androidx.fragment.app.FragmentManagerState
09-22 12:47:36.940 E/Parcel (31316): java.lang.ClassNotFoundException: androidx.fragment.app.FragmentManagerState
09-22 12:47:36.940 E/Parcel (31316): at java.lang.Class.classForName(Native Method)
09-22 12:47:36.940 E/Parcel (31316): at java.lang.Class.forName(Class.java:454)
09-22 12:47:36.940 E/Parcel (31316): at android.os.Parcel.readParcelableCreator(Parcel.java:3028)
09-22 12:47:36.940 E/Parcel (31316): at android.os.Parcel.readParcelable(Parcel.java:2978)
09-22 12:47:36.940 E/Parcel (31316): at android.os.Parcel.readValue(Parcel.java:2880)
09-22 12:47:36.940 E/Parcel (31316): at android.os.Parcel.readArrayMapInternal(Parcel.java:3258)
09-22 12:47:36.940 E/Parcel (31316): at android.os.BaseBundle.initializeFromParcelLocked(BaseBundle.java:297)
09-22 12:47:36.940 E/Parcel (31316): at android.os.BaseBundle.unparcel(BaseBundle.java:241)
09-22 12:47:36.940 E/Parcel (31316): at android.os.Bundle.getParcelable(Bundle.java:951)
09-22 12:47:36.940 E/Parcel (31316): at androidx.fragment.app.FragmentActivity$2.onContextAvailable(FragmentActivity.java:148)
09-22 12:47:36.940 E/Parcel (31316): at androidx.activity.contextaware.ContextAwareHelper.dispatchOnContextAvailable(ContextAwareHelper.java:99)
09-22 12:47:36.940 E/Parcel (31316): at androidx.activity.ComponentActivity.onCreate(ComponentActivity.java:322)
09-22 12:47:36.940 E/Parcel (31316): at androidx.fragment.app.FragmentActivity.onCreate(FragmentActivity.java:273)
09-22 12:47:36.940 E/Parcel (31316): at com..XXXX.android.commonui.component.BaseActivity.onCreate(BaseActivity.java:93)
09-22 12:47:36.940 E/Parcel (31316): at com..XXXX.android.app.ui.filmdetail.FilmDetailActivity.onCreate(FilmDetailActivity.java:50)
09-22 12:47:36.940 E/Parcel (31316): at android.app.Activity.performCreate(Activity.java:7872)
09-22 12:47:36.940 E/Parcel (31316): at android.app.Activity.performCreate(Activity.java:7861)
09-22 12:47:36.940 E/Parcel (31316): at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1353)
09-22 12:47:36.940 E/Parcel (31316): at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:3500)
09-22 12:47:36.940 E/Parcel (31316): at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:3664)
09-22 12:47:36.940 E/Parcel (31316): at android.app.servertransaction.LaunchActivityItem.execute(LaunchActivityItem.java:83)
09-22 12:47:36.940 E/Parcel (31316): at android.app.servertransaction.TransactionExecutor.executeCallbacks(TransactionExecutor.java:135)
09-22 12:47:36.940 E/Parcel (31316): at android.app.servertransaction.TransactionExecutor.execute(TransactionExecutor.java:95)
09-22 12:47:36.940 E/Parcel (31316): at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2246)
09-22 12:47:36.940 E/Parcel (31316): at android.os.Handler.dispatchMessage(Handler.java:107)
09-22 12:47:36.940 E/Parcel (31316): at android.os.Looper.loop(Looper.java:230)
09-22 12:47:36.940 E/Parcel (31316): at android.app.ActivityThread.main(ActivityThread.java:7768)
09-22 12:47:36.940 E/Parcel (31316): at java.lang.reflect.Method.invoke(Native Method)
09-22 12:47:36.940 E/Parcel (31316): at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:508)
09-22 12:47:36.940 E/Parcel (31316): at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1034)
09-22 12:47:36.940 E/Parcel (31316): Caused by: java.lang.ClassNotFoundException: androidx.fragment.app.FragmentManagerState
09-22 12:47:36.940 E/Parcel (31316): at java.lang.Class.classForName(Native Method)
09-22 12:47:36.940 E/Parcel (31316): at java.lang.BootClassLoader.findClass(ClassLoader.java:1358)
09-22 12:47:36.940 E/Parcel (31316): at java.lang.BootClassLoader.loadClass(ClassLoader.java:1418)
09-22 12:47:36.940 E/Parcel (31316): at java.lang.ClassLoader.loadClass(ClassLoader.java:312)
09-22 12:47:36.940 E/Parcel (31316): ... 30 more
09-22 12:47:36.940 E/Parcel (31316): Caused by: java.lang.NoClassDefFoundError: Class not found using the boot class loader; no stack trace available
他山之石
这些都是网上搜到的问题及解决方案：
- 错误处理Class not found when unmarshalling: android.support.v4.app.FragmentManagerState
- 异常处理-android.os.BadParcelableException: ClassNotFoundException when unmarshalling
-
ClassNotFoundException when unmarshalling: androidx.fragment.app.FragmentManagerState 问题分析
综合这些问题，和我们收集的错误信息还是能对的上，所以我们加上了一个FragmentStateFixer来修复这个问题，调用时机在onCreate()中走到super.onCreate()之前。
object FragmentStateFixer {
private val modelListStr = "all" //这里可以搞成可配置机型
fun fixState(context: Context, bundle: Bundle?) {
if (bundle != null && checkCondition(context)) {
bundle.classLoader = context.javaClass.classLoader
}
}
private fun checkCondition(context: Context): Boolean {
if (Build.VERSION.SDK_INT != 29 && Build.VERSION.SDK_INT != 28) {
// 只对9和10的机器进行修正
return false
}
if (modelListStr == "all") {
return true
}
val modelList = modelListStr.split(",")
return modelList.contains(Build.MODEL)
}
}
但是带着这个改动，再次灰度的时候发现问题并没有解决，还是报同样的错误。后面就进入了漫长的弯路，直到找到了复现机器的全日志以及路径。
复现路径
找到复现路径这一点很关键，这个bug一开始来自于平台上报，不知道如何复现。查了网上的文章之后，大概猜测和重建有关，但是使用开发者选项中的“不保存活动”，也不能复现这个crash。
只能通过找很多台9或者10的手机，跑monkey test来进行稳定性测试，来复现该问题。这就导致验证成本极高，而且没有现场信息，只有上报上来的一大堆log，调查的难度很高。
最后是在测试同学协助下，发现一台测试机上的崩溃都是由一个二级或者三级页面中的crash，导致前面几个页面会报这个错误。由此想到这种crash导致的页面重建可能正是一种符合的场景，因此在一个层级比较深的页面手动触发一个崩溃来造成类似的场景，果然复现了这个crash！
找到复现路径，就可以压缩验证的时间成本，而且还可以debug（需要打开开发者选项中的"等待调试器"，然后在触发崩溃后进入debug），因为是android源码的崩溃，很多地方加不了log，可以debug之后对定位问题非常有帮助。
问题定位
根据崩溃堆栈，结合debug信息，找到最终崩溃的位置：
就像网上链接所说，这个地方的classloader是BootClassLoader，所以在解析时会跑错误。而正确的是什么样的呢？可以对比一下Android 11的机器走到这里的信息：
我们可以发现，11走到这里的时候，ClassLoader是PathClassLoader，所以是可以正常解析的，不会崩溃。（正常Android中我们解析类都是用PathClassLoader，这部分ClassLoader的知识可以查看其它文章）
所以通过debug，定位到了位置，的确是ClassLoader在捣鬼，但是这个位置又不是网上链接所定位和修改的地方，所以之前的改法是没有用的。那这个地方的savedInstanceState又是怎么来的呢？和我们在onCreate中拿到的savedInstanceState又是什么关系呢？
此外，这里我在debug时发现一个有趣的现象，就是这个savedInstanceState被取出来之后，无论调用任何方法，都会抛出异常BadParcelableException，而且只要是在debug时调用某个方法让它“释放”了这个异常，ClassLoader就会变成正确的PathClassLoader，后面都可以正确运行。
上图就是我调用了一个keySet()方法。这里也会抛出异常应该是因为Bundle的很多方法，包括keySet()，get()的第一句都是unparcel()，所以是崩在unparcel()里面。但是为啥这里崩了一次之后，ClassLoader就变了，后面程序就能正常运行，这是我没能理解的地方。
我们先回过头看一下，在重建activity时传给onCreate的savedInstantceState参数是什么。
可以看到这里面有4个参数，其中有一个android:fragment，但其实你要按照之前文章里的说法去remove或者想给它设置ClassLoader，也是没有用的。因为其实并不是用的这里。还得继续从堆栈处找。
回到刚刚崩溃处，可以发现那里用的savedInstanceState是从savedSateRegistry中用consumeRestoreStateForKey取出来的，然后看看这个方法的内容：
这里传入的key是"android:support:fragments"，简单来说是这个叫作mRestoreState的Bundle中取了一个key为"android:support:fragments"的Bundle，而这个Bundle的classloader是BootClassLoader，所以导致了现在的崩溃。那这个mRestoreState是怎么来的呢？接着找源码，发现了赋值的地方在另一个方法performRestore()中。
这里使用的这个SAVED_COMPONENTS_KEY，它的值是：
private static final String SAVED_COMPONENTS_KEY =
"androidx.lifecycle.BundlableSavedStateRegistry.key";
而这个performRestore方法正是在FragmentActivity的onCreate()里第一句调用的
所以代码追踪到这里，问题基本就定位到了，其实就是在activity重建时，传入的savedInstanceState本身ClassLoader是没问题的，问题出在它的子Bundle的子Bundle上，层级结构如下：
savedInstanceState.getBundle("androidx.lifecycle.BundlableSavedStateRegistry.key").getBundle("android:support:fragment")
问题是出在这个bundle的ClassLoader上，这里在android 10和9的机器上使用的是BootClassLoader，然后在解parcel的时候就崩溃了。
解决方案
根据上面的分析结果，现在只要在我们的FragmentStateFixer上加上俩句话即可：
fun fixState(context: Context, bundle: Bundle?) {
if (bundle != null && checkCondition(context)) {
bundle.classLoader = context.javaClass.classLoader
// 9.22新增：需要修改的是bundle下androidx.lifecycle.BundlableSavedStateRegistry.key中子项的classloader
bundle.getBundle("androidx.lifecycle.BundlableSavedStateRegistry.key")?.let {
it.keySet()?.forEach { key ->
(it.get(key) as? Bundle)?.classLoader = context.javaClass.classLoader
}
}
}
}
这里为了保险起见，首先之前给savedInstanceState本身设置ClassLoader的代码我没有去掉；
并且我将androidx.lifecycle.BundlableSavedStateRegistry.key所对应Bundle下的所有子Bundle都设置了一遍ClassLoader。
总结
- 这个问题首先是android本身的一个bug，在之前网上的文章里也有提到，在Android 10 的preview版本上（国内的手机部分9的机器也会有这个问题）这里的ClassLoader使用的不对;
- 网上目前提到的解法并没有解决我们的问题，不确定是不是androidx不同版本源码不一样；
- 因为上传的log不完整，走了很多弯路，在按照网上方案修改后，一度以为是解决了FragmentManagerState这个问题，追查了很久其它原因。后来是在测试的协助下，找到了真正的原因和复现手段，这对最终问题解决非常重要；
- 最后的解决方案保留了网上的改法，并在其基础上扩展，可以参考上面的解决方案段落；
