02 | 崩溃优化（下）：应用崩溃了，你应该如何去分析？

疑难杂症的解决确实能够带来难以比拟的兴奋和荣耀感，但付出的精力可能也不亚于一次需求开发的周期。其实大部分问题的根源都在于前期开发过程的不规范编码导致，如果能够从技术方案选型->编码时静态检查->编码后review->测试&灰度问题解决，很多问题都能扼杀在摇篮里了。 这里推荐一篇早期 gityuan 大佬解决崩溃问题的案例文章，对于解决问题的基本流程和思路应该有一定帮助：http://gityuan.com/2018/02/03/log-fc/

补充一下获得logcat和Jave堆栈的方法： 一. 获取logcat logcat日志流程是这样的，应用层 --> liblog.so --> logd，底层使用ring buffer来存储数据。 获取的方式有以下三种： 1. 通过logcat命令获取。 优点：非常简单，兼容性好。 缺点：整个链路比较长，可控性差，失败率高，特别是堆破坏或者堆内存不足时，基本会失败。 2. hook liblog.so实现。通过hook liblog.so 中__android_log_buf_write 方法，将内容重定向到自己的buffer中。 优点：简单，兼容性相对还好。 缺点：要一直打开。 3. 自定义获取代码。通过移植底层获取logcat的实现，通过socket直接跟logd交互。 优点：比较灵活，预先分配好资源，成功率也比较高。 缺点：实现非常复杂 二. 获取Java 堆栈 native崩溃时，通过unwind只能拿到Native堆栈。我们希望可以拿到当时各个线程的Java堆栈 1. Thread.getAllStackTraces()。 优点：简单，兼容性好。 缺点： a. 成功率不高，依靠系统接口在极端情况也会失败。 b. 7.0之后这个接口是没有主线程堆栈。 c. 使用Java层的接口需要暂停线程 2. hook libart.so。通过hook ThreadList和Thread的函数，获得跟ANR一样的堆栈。为了稳定性，我们会在fork子进程执行。 优点：信息很全，基本跟ANR的日志一样，有native线程状态，锁信息等等。 缺点：黑科技的兼容性问题，失败时可以用Thread.getAllStackTraces()兜底 获取Java堆栈的方法还可以用在卡顿时，因为使用fork进程，所以可以做到完全不卡主进程。这块我们在后面会详细的去讲。

老师可能还不了解学生的水平，读者都是做应用层程序的你讲这么深入恐怕没什么效果

张老师好，我想问一下，感觉学习这些课有点理解不了，不知道为什么，应该怎么入手呢？

之前遇到过一个输入法的内存泄露，但是自己完全没有调用过输入法，后面查了一下 网上说是系统的一个bug 张老师 这种应该怎么解决呢？

感觉可以由浅入深的讲，这一脚下去有点深呀，可能很多人3，4年经验，没做过这方面，学完了这一章一脸蒙圈，也没太大帮助呀

张老师，看到你解决一些棘手的崩溃，会去翻看源码，然后对比版本的差异，然后寻找hook点去解决，这个要考虑机型适配吧？毕竟国产机型rom差异化严重。

TimeoutException 直接调用stop存在什么安全问题？请大神指教一二。

pthread_create (1040KB stack) failed: Out of memory老师这个有没有好的解决方法？

请问有没有native崩溃后成功获取java堆栈的例子， 是只能用hook libart.so实现吗？ 这边参考实现了native崩溃获取， 但是在native崩溃时， 信号处理函数去唤醒之前等待的线程，去回调java或者抛出异常给java处理都没有反应。