分析Android问题时，经常会遇到一些稳定性问题。什么是稳定性问题呢，我归结有以下特点，
非必现问题，或没有找到复现路径的问题。其实没有非必现问题，只有找不到复现方法。系统越复杂这类问题越多，因为软件路径太多了。
应用的死机重启。这类问题不能简单的归结为应用问题，毕竟应用是跑在系统上的。当应用开发人员无法分析出问题时，可能就会认为是稳定性问题。
系统死机重启。Android开发还是偏重应用的，这样导致系统开发人员较少。很多时候碰到这类问题就找不到分析方法，也就归到稳定性上。起始这类问题与Linux系统上的分析方法并没有太大却别，只不过深入底层的人越来越少了。
原生代码的问题。Android原生代码也是有bug的，因为这部分代码没人动，也就很少有人研究。最后又归到稳定性上。
性能问题。有时性能问题也会归到稳定性上，例如正常情况下某应用启动很快，在某种情况下启动很慢，这很可能就是性能导致的。我认为性能问题和稳定性问题不能混为一谈，二者的分析方法有很大差别。
没人愿意深入研究的问题。各模块都不承认是自己的问题，相互扯皮。因为没有人从系统角度上来分析问题，也不进行深入研究，觉得还是归到稳定性好些。
简单来说就是其他模块解决不了的或不愿意解决的就是稳定性问题。有真正的稳定性问题吗？我觉得严格来说时没有的，问题最终的根本原因总会落在一个模块上，也就是有主的。但是，Android系统真的是一个非常复杂的系统，不能要求每个开发人员都能了解整个系统。所以这类复杂的系统性问题还是交给一些资深的开发人员解决更好些。这也就对分析稳定性问题的人员要求较高，需要对系统有整体的概念，并且对许多模块有深入研究。我认为将稳定性问题改为系统问题会更加准确，解决稳定性问题的开发人员也应该是系统工程师。
成为一名Android系统工程师
我建议分析稳定性问题最好由资深工程师或系统工程师来进行，成为一个合格的Android系统工程师需要掌握以下知识点，
Linux Kernel基本的工作机制，如进程调度，进程空间，内存管理，文件系统等等。
Linux应用开发，如系统调用，IPC通信，多线程开发，常用的库等等。
Linux Kernel常用的调试手段，如crash，ftrace，kmemleak，kprobe，kgdb，trace32，perf，procfs，sysfs，debugfs等等
Linux应用常用的调试手段，如gdb，strace，ltrace，Valgrind，gprof，mtrace，iperf，blktrace，fio等等。
辅助系统的工作原理，如Bootloader，Recovery，DTB，busybox等等。
Android框架和基本原理。
Android Framework中主要模块的工作机制，包括Activity，Window，Package，Input，Storage，Audio，Media，Surface等等。
Android IPC通信（Binder）的原理和实现。
Android中日志收集手段的原理，包括logcat，ANR，Tombstones，Watchdog，GC等等。
Android中常用的调试手段，如Bionic的内存检测，LMK机制，Asan，Systrace，oatdump，dumpsys，dumpstate等等。
Android Studio中常用的调试工具，如Profiler，Systrace，TraceView，Heap Viewer，Allocation Tracker，Memory Monitor，Layout Inspector，MAT等等。
了解编译相关的工具，如LLVM，Makefiel，Android Make，Soong，Gradle，工具链，镜像制作，ota打包等等。
上面这么多，我感觉还没有好多没提到，目前只能想到这些。不需要全部精通，那是神人要做的。凡人要做到都有基本的了解，精通其中几个模块，否则给人一知半解的感觉，但做到这样也是不容易。掌握了上述的知识（这个要求有点高），就可以成为一名Android系统工程师了。但这离优秀的系统工程师还差很远，要想成为优秀必须有以下的品质。
三心：细心，耐心，恒心。复杂问题可能需要很长时间才能解决，要耐得住寂寞，并且不放过任何一个线索。
敢于挑战困难。复杂的问题一定经过了许多人的分析还没有结论，害怕了就一步也迈不出去。
快速的学习能力。稳定性问题遍布整个系统，可能经常会分析到陌生的模块，学习能力差就会影响问题解决。要不有一张快速的嘴到处问问，也不失为一种方法。
较强的逻辑思维。很多问题都是绕来绕去，很容易晕菜。
不走寻常路。遇到困难时，跳出来，换一种方法也许就解决了。
运气。这东西在哪里都很重要，有些问题就是碰出解决方案的，实际上并不不是完全的运气，但运气真的很重要。
写完这些，我想很少人想成为Android系统工程师了，我也想找一个三板斧就能混个高薪水的工作。
稳定性问题分析方法 稳定性问题千奇百怪，而且大部分都很难定位。我这里试图去总结一下各类问题的分析流程，这些不是标准，只是我的经验。先根据问题的表现分下类，
有稳定复现路径的问题。
偶现问题，且Debug信息足够。
偶现问题，且Debug信息不足。
不能复现的问题。
关于Debug信息，一部分是标准Android带有的logcat输出，ANR日志，tombstone日志，watchdog日志等。另一部分是系统开发商附加的。好的系统开发商能提供丰富的Debug信息，在问题发生时一同抓取上报。这些信息可能包括kernel log，dumpsys中的部分信息，Binder信息，详细的CPU内存信息，IO信息，调度信息，corefile，vmcore等等。厂商的不同，这些信息也会不同。下面根据问题的不同分别讲述一下。
有稳定复现路径的问题：
如果一个问题能有稳定的复现路径，解决问题就变得容易很多。
这类问题不论Debug信息的多少，都能找根本原因。因为能复现，就可以不断的增加Debug信息。
严格来说这类问题不能称为稳定性问题，但依然占据稳定性问题的多数。
偶现问题，且Debug信息足够：
仅使用Android标准的Debug信息就可以定位问题时，都比较容易解决，也不会太复杂。对系统有很好的理解，并且会分析栈信息可能就够用了。但可能需要分析源码来确定根本原因。
需要借助厂商附加的Debug信息定位问题时，问题会相对复杂。
面对复杂问题时，可能需要仔细分析不同的Debug信息，在它们之间找到关联。尽可能的搜索相关线索，这样才能找到根本原因。
有时可能能根据Debug信息定位到代码段，但真正的根本原因还需要分析代码逻辑才能确定。不要轻易下手修改代码，尤其是原生代码。
定位到原生代码出问题时，先在网上找一下是否有人给出Patch，相信你不可能是第一个碰到这种问题的人。
编写测试代码来验证你的解决方案。
偶现问题，且Debug信息不足：
Debug信息不够用时就麻烦了，这也是我认为最难解决的问题。
试图寻找复现路径，让问题变为有稳定复现路径的问题。
在怀疑点增加Debug信息，等待下一次复现。
根据怀疑点分析代码逻辑，试图使用测试代码来复现该问题。
根据core文件中的内存镜像来获取更多的有用信息。
仔细分析现有的Debug信息，往往一小句话就有很大的惊喜。
注意CPU，Memory，IO的状态对系统的影响。
怀疑内存问题时可以使用内存检测工具来检查一遍当前系统隐含的内存问题。
有时代码检查工具也能规避很多问题，提交前没有检查的最好检查一下。
问题很可能不是第一现场，先解决系统之前的错误，后面的错误可能就跟随解决。
同样的，在网上搜索是否有类似问题的解决方案。
总体来说，这类问题就是尝试各种方法来解决目前无法解决的问题。
不能复现的问题：
此类问题既然无法复现，也就不重要了。
如果可以根据Debug信息解决固然很好，不能解决时可以先降低优先级。
等待该问题变成偶先问题时，就可以根据上述方法分析了
