项目笔记-从一个BUG的解决到谈谈人生

现象

今天遇到两个诡异的APP Crash的BUG，具体现象是：

1. 反复进入、退出APP进程，偶现APP进程启动之后很快就Crash。
2. APP进入美颜相关页面的时候，经过9秒钟后Crash。

下面我将用一些轻松愉快的方式来说明我解决这个问题的过程和解决思路。

解决过程以及分析思路

按照我已有的经验来看，这个很简单啊，一般的套路方法就是：

1. 解压Log压缩包。
2. 找到Crash_Log，分析Crash信息。

好了，稳得一批，你可以关闭本文章了，What a f××king article...

老哥稳

打开Crash_Log瞄了一眼，发现这是一个Native Crash：

06-12 09:51:20.747344  5295  5660 F zygote  : java_vm_ext.cc:534] JNI DETECTED ERROR IN APPLICATION: fid == null
06-12 09:51:20.747435  5295  5660 F zygote  : java_vm_ext.cc:534]     in call to SetObjectField

...省略一些调用栈

啪啪啪打脸

百度、Google无果，内心一万只草泥马奔腾而过，日常老司机翻车，装个逼也不容易啊！于是再一次开启装逼模式，分析Crash的调用栈吧：

1. 发现两个现象都是同一个问题
2. 通过分析调用栈，APP最终是调用到虹软美颜SDK的Native方法

好吧，接下来开始甩锅了：

甩锅

具体的甩锅思路是这样子的（老哥，稳！）：

1. 通过分析Log以及Debug跟踪，APP调用so中的Native方法的时候，参数都确保过无误了
2. 既然现象跟Log都很明显了，那就直接甩锅给虹软SDK的开发吧

想了一下这样做不太厚道啊，这么大个SDK厂商，SDK开发出来怎么可能没有经过严格的测试呢？何况贸然甩给人家，人家也不一定鸟你。既然如此，那就去翻阅一下官方文档吧！

1. 查看SDK的相关文档，发现并没有相关的Crash的章节。
2. 于是去查看有关JNI DETECTED ERROR IN APPLICATION（JNI Exception）的Android NDK官方文档

如下图所示，首先映入眼帘的就是那几个加粗的大字！You must not call most JNI functions while an exception is pending.

Android NDK官方文档

好吧，我的渣渣英语也终于可以排上战场了！这段话的大概意思就是，Android5.0之后，ART虚拟机比DVM虚拟机更加严格，当你的代码发生异常而且没有被捕获等处理的时候，是不允许调用某些JNI方法的（以下罗列出来的除外）。

终于搞明白是怎么一回事了，原来啊，这个Native Crash只是假象，真正的锅，是APP中的其他Exception！重新翻看Log，发现其他Exception。（笔者注：至于为什么这个Exception没有出现在Crash_Log里面，还有待进一步研究，估计要深入Android的Log系统了）

其他Exception

总结

BUG总算是解决了，APP更加健康了，但是我们程序员也是需要进步的，总结必不可少：

1. 做人与解决BUG一样，永远不要只关注一个点，有时候放开思维，多考虑各方因素，换位思考，可能会豁然开朗，找到不一样的人生！
2. 细心的读者已经发现了，我日常解决问题的思路都在上面的正文当中用加粗的字体来明示了。下面放上一张我画的解决问题的流程图。

问题解决思路流程图

Tips：

1. 从我的问题解决思路流程图中可以看到，我解决问题的时候，一开始并不是直接就把问题扔到各种交流群里面问大家。反而我把“请教他人”这个项目放到很靠后的地方。
2. 在请教他人之前，我会尝试着自己去用最快速的方法解决这个问题，其中当然包括百度、Google等各种途径。因为互联网发展到现在，很多问题肯定是有人遇到过的，懂得使用搜索引擎才是王道！尤其是各种搜索语法。
3. 另外，我会尝试着去阅读相关源码，因为学习提高能力往往比解决问题本身更加重要！
4. 流程图是死的，人的思维的活的，不要被条条框框束缚你的人生，怎么解决问题最快就怎么来。
5. 对于应届毕业生，如果面试官问你是否有相关工作经验，尤其是被问到“你平时遇到问题的时候是怎么解决的”，想考验一下你是否真的从事过相关行业的时候，可以参考上面的流程图进行回答。