Android低版本上APP首次启动时间减少80%（二，自学Flutter

我们上一篇文章中已经介绍了 BoostMultiDex 的核心优化思路，即如何避免 ODEX，直接加载原始 DEX 完成启动。然而用这个方法加载 DEX 文件，相比于 ODEX 优化后的方式，其 Java 代码执行性能上还是有所损失的。我们也可以从前面方法的注释里面看出，虚拟机对于直接加载原始 DEX 的情况只是做了些基本优化：

The system will only perform “essential” optimizations on the given file.

所以，虽然第一次启动我们是加载了原始 DEX 来执行的，但从长远的角度考虑，后续的启动，还是应该尽量采用 ODEX 的方式来执行。因此，我们还需要在第一次启动完成后，在后台适当的时候做好 ODEX 优化。

一开始我们是做法也比较简单，在顺利加载 DEX 字节数组，完成启动之后，在后台开辟单独的线程执行DexFile.loadDex就可以了。这样当后台做完 ODEX 后，APP 第二次启动时，就可以直接加载之前做好的 ODEX，得到较好的执行性能。这种做法在线下测试的时候也很正常，然而在上线之后，我们遇到了这样一个问题……

SIGSTKFLT 问题

---

线上报上来一个 Native Crash，它的堆栈如下所示：

Signal 16(SIGSTKFLT), Code -6(SI_TKILL)

#00 pc 00016db4 /system/lib/libc.so (write+12) [armeabi-v7a]

#01 pc 000884a5 /system/lib/libdvm.so (sysWriteFully(int, void const*, unsigned int, char const*)+28) [armeabi-v7a]

#02 pc 00088587 /system/lib/libdvm.so (sysCopyFileToFile(int, int, unsigned int)+114) [armeabi-v7a]

#03 pc 00050d41 /system/lib/libdvm.so (dvmRawDexFileOpen(char const*, char const*, RawDexFile**, bool)+392) [armeabi-v7a]

#04 pc 00064a41 /system/lib/libdvm.so [armeabi-v7a]

#05 pc 000276e0 /system/lib/libdvm.so [armeabi-v7a]

#06 pc 0002b5c4 /system/lib/libdvm.so (dvmInterpret(Thread*, Method const*, JValue*)+184) [armeabi-v7a]

#07 pc 0005fc79 /system/lib/libdvm.so (dvmCallMethodV(Thread*, Method const*, Object*, bool, JValue*, std::__va_list)+272) [armeabi-v7a]

#08 pc 0005fca3 /system/lib/libdvm.so (dvmCallMethod(Thread*, Method const*, Object*, JValue*, …)+20) [armeabi-v7a]

#09 pc 0005481f /system/lib/libdvm.so [armeabi-v7a]

#10 pc 0000e3e8 /system/lib/libc.so (__thread_entry+72) [armeabi-v7a]

#11 pc 0000dad4 /system/lib/libc.so (pthread_create&