android 无死角调试计划

多年前曾沐浴在windows的荣光下，体验着visual studio提供的完美开发体验，不知其他平台开发工具的险恶。怀揣美好的向往，投入到android的怀抱，才发现世事艰辛。对于调试而言，android平台是个残暴的世界。对于native程序，曾操起gdb，寻找windbg的身影，确发现等价命令臃肿的可怕，它看起来就不是给人用的，很像个二次开发的api，当我想专注于调试时，我确不得不先专注于这个复杂的接口，让他更好用一些。windbg把用户当上帝，gdb把用户当小弟。话说android studio调试native模块它不香吗？ 对于一个经常查看汇编指令的调试者而言，它确实不香，源码调试不能切换asm视图，还有何用？何况它还不能调execute程序。

windows之下，vs加持，或创，或编，或调，想写c就写c，想嵌asm就嵌asm，想调只需一键f5，想看源码就看源码，想切汇编视图只需点个右键按个D，想看函数f12，另外内存视图，变量监视，调用栈统统扑面而来。想调内核也仅是配置稍多一点而已，windbg体验也很不错。

而反观android，一切百废待兴。android脱胎于linux，linux工具本来就差劲，再加上移植过程中的各种水土不服，使得情况更糟了。

android下追求c代码在widows平台的开发调试体验，注定是个坎坷的过程。

理想中的调试工具满足三个需求：

第一：针对开发，开发调试循环的过程尽量减少用户不必要的操作。

第二：调试源码，对于拥有源码的工程，调试的目的在于学习软件，因为相比只看源码，调试更容易搞清内部逻辑。

第三：针对闭源软件，必须能调试汇编。

android 官方开发工具android studio显然仅能满足第一条。

从android的调试需求来看，比较合理的调试需求如下：

1. 正常开发app的so，这个android studio可满足。

2. 面向安全领域的开发，android studio就不能满足，最多就是编译链接集成，因为调试能力不能支持asm。vs目前支持native开发，不过在调试上不如visualgdb，但二者都能很好的满足这一需求。当然你用命令行在ndk和gdb下甘愿受虐，当我没说。

3. 调试aosp的native代码探索android内部实现，gdb可以，但体验极差。visualgdb提供了这种可能，但是需要很多配置，官方也没有指导，即便如此，我认为这也是现实可行的最好方案了。我成功的探索了这个方案，是确实可行的。

4.  调试android内核，由于是由linux修改而来，所以kdb，kgdb是支持的，需要重新配置并编译内核，曾经探索过这个这个方案，太麻烦了，真机调试android内核需要魔改usb驱动，还需要焊接android串口调试线，我最终载在gdb的bug上，险些就成功了。

5.  调试--不可调的--代码，在调试机制建立之前的系统代码天然具有不可调试性，比如用户态直接调试真实启动的init，由于init是第一个进程，调试基础如adbd尚未启动，连通信机制都尚未建立，显然是不能调试的，adbd也是不可调的，原因略有不同，因为调试adbd会引发海森堡效应。同样的在内核态，在调试机制建立之前，以及调试系统的初始化过程，运行相关例程也是不可调试的。更底层的bootloader，乃至芯片固件。怎么办呢，有两个思路，第一种建立模拟环境做调试，如chroot一个根目录树启动init来模拟init真实启动时的环境。第二种用更底层的调试工具，如纯硬件的如：jtag， 纯软件的如系统级模拟器qemu，软硬结合的如vmware或kvm提供的调试接口，这种调试非常强大，完全消除了海森堡效应，因为调试机制是被调试目标不可见的。有时间聊聊我曾踩过的坑。

6. 最极端的情况，没有任何可用工具，只有人肉调试了。说是极端，其实也是个普遍情况，当android启动中发生某种错误时，你通过已有知识，判断错误发生的阶段，模块时，你就在用人肉调试。人肉调试是没有任何方便工具的情况下的选择。叫不叫人肉调试，是个认知问题。也许只有把调试概念抽象化，才能发现调试的本质。所以你头脑中的任何根据现有知识做的演绎得出结果的过程都可看做人肉调试。

以上都是个人浅见，希望抛砖引玉，欢迎探讨交流。