最近在做项目的过程中发现一个比较诡异的现象：生产环境中，在Android 4.x系统上Release版本上比较频繁的的出现ANR, 而Debug版本没有出现；同时，在Android 6.x系统上也有个别手机会出现此问题。根据问题发生的场景，进行了反复的测试，发现ANR的现象基本发生在固定两个页面。

采取了两个思路：
1、查看log与trace文件，Review两个页面的代码，看是否有出现耗时的操作
2、简化代码，去除其他模块的影响

措施1: Review代码及查看log与trace文件
— 查看简化相关模块的代码，没有发现特别耗时的操作
— 在出现ANR的地方查看日志，没有发现有价值的信息
— 获取到trace文件，查看文件中是否存在死锁、消息广播阻塞及线程的互相
等待，搜索关键字，查看对应的tid与pid，没有发现异常。

花了2-3天时间的，特别是对log文件的观察与学习trace文件的理解，还是挺花时间的，措施1基本没有什么发现。

措施2: 重写与简化代码
— 由于项目模块较多，并且模块间有一定的耦合性，简单的简化代码可能达不到预想的效果，因为采取重新创建工程的方式，移植并简化代码，保证出现问题的固定两个页面可用即可。

  -- 移植完毕后，反复测试，发现问题仍然存在。

  -- 继续简化代码，去掉应用中的一个自定义组件，加密键盘，发现问题消失

  -- 怀疑是否与键盘Java层代码的内存泄漏有关，查看管理部分的代码，并且结合集成LeakCandary内存泄漏检测工具，确实存在单例模式使用不当造成的内存泄漏，解决内存泄漏问题，问题仍然存在，因此判定不是Java层内存泄漏引起的。

  -- 既然与Java层内存泄漏没有关系，怀疑的重点就放在了底层JNI的加解密上，由于底层涉及到3次对密码进行加解密，猜测是否与加解密函数有关系，注释调加解密加解密部分代码，发现问题消失，因此确定问题可能与加解密部分代码有关系

  -- 通过多次注释与测试，问题代码缩小到登录密码加密部分的代码，经过不断的修改测试及代码Review，发现了一个严重的内存越界问题：malloc动态分配的内存大小为srcLen，但是在后续的使用过程有一个函数是将Hex字节数组转化为字符串，在最后一个字符串赋值时，char* 的数组下标引用为srcLen, 并赋值为\0结束符。

明显此处访问内存是出现了越界，总共分配了srcLen大小的内存，而在使用时却访问到了strLen +1长度的内存，而这个后果是不可预知的，修正后再测试，问题消失。

这个过程费时费力，前后花了差不多一周时间，还好总算是在正确的方向上。问题解决后，仍然带有一些疑问：

1、为什么问题在Debug版本反复测试没有出现，是不是因为在Release模式下内存的分配与检查更加的严格，而Debug模式下，内存的管理与Release不一样，可能分配的内存更加的充足？这样即使内存越界了，如果越界的内存是空闲内存，仍然不会触发整个应用的ANR, 为了进一步找原因，仔细查看了内存泄漏、内存越界、内存溢出的易发场景及C程序在运行是的内存分配，最后也没有找到原因。

2、为什么在Android 4.x的系统上频繁复现，而高版本的系统上出现概率不高？这个问题的也许可以这样解释：1、内存越界的问题本身就非常隐蔽，并且造成的后果页不可知，如果搞好越界的内存是空闲内存，问题可能就不会理解发生直到越界的内存被另外的程序分配了内存才会真正触发问题的产生 2、高版本的使用ART运行时编译器及Android底层内存管理更加优化

3、为什么内存越界会导致应用程序的ANR? 可能是因为内存越界导致的后果具有不确定性，当问题越界时引用其他代码分配的内存快，两段程序对内存资源的竞争导致应用程序的超时出现了ANR，这也只是猜测。

带着这些疑问，又把C程序中关于内存管理的基础知识复写了一遍，具体见链接：
1、C语言内存管理一本道来 https://www.jianshu.com/p/502a1919e189
2、42_内存操作经典问题分析二 https://www.jianshu.com/p/d998176f80f0

总结：
当遇到类似ANR的问题时，可以考虑使用以下的这些方法辅助定位：
1、根据业务场景查看log及trace文件
如何查看log
如何查看trace文件：是否有死锁、是否有明显的应用程序类
2、推翻重写或简化代码
3、集成第三方工具LeakCandary

当真的是没有什么头绪时，要跳出ANR的局限思维，猜测有没有可能是内存问题了。