Unix下Android调试卡壳？三步定位环境配置顽疾

文章配图，仅供参考

　　第一步先查网络。Unix下adb connect失败，十有八九是端口没通。我原以为直接telnet 5555就能测，结果发现某些小版本的adb server会偷偷占5554-5557的端口，而公司的防火墙规则只放了5555。用netstat -tulnp看了半天，发现adb server在后台开了两个进程，一个占5555，另一个占5554——可logcat还是连不上。后来才发现，是Android设备的USB调试模式没开全，某些旧版本系统得先在开发者选项里勾"仅充电模式下允许ADB"，这选项藏得比UI走查时的bug还深。

　　第二步看日志。logcat没输出，别急着怀疑设备，先看Unix主机的dmesg。我碰到过最离谱的案例是，USB驱动冲突导致内核直接把设备识别成了"unknown device"，logcat的输出全被丢进了/dev/null。用lsusb看了半天，发现设备ID是18d1:4ee2，可驱动只认18d1:4ee1——这差别就最后一位，驱动直接罢工。后来手动加载了google的usb_driver模块，重启adb server，logcat才咕嘟咕嘟冒数据。这时候地铁上掏手机复现问题，发现同事在群里@我："你上次说的那个logcat命令，我照着打怎么没输出？" 我回："先查dmesg，再看lsusb，最后看驱动版本——对了，你用的Unix是哪个发行版？" 他回："Ubuntu某个小版本。" 我心里一沉——这坑，又得重新踩一遍。

　　第三步盯编译。NDK编译报错，别看错误信息，先看Makefile。我碰到过最狠的案例是，Android.mk里写了LOCAL_MODULE := libtest，可实际生成的.so文件叫libtest.so.1——这多出来的".1"是版本号，由编译器的-Wl,--soname参数控制。而项目的自动化脚本里，硬编码了"libtest.so"的路径，导致链接时找不到文件。改Makefile？不行，得改编译脚本；改编译脚本？不行，得改CI配置；改CI配置？不行，得找运维——这一圈下来，凉了的外卖都热了三回。最后发现，是NDK版本从r17升到r21时，默认的编译选项变了，而项目里没人注意到这个"兼容性警告"。这个我敢打包票，90%的Android开发者都没看过NDK的release note——包括我，直到踩了这坑。

　　说回"三步定位环境配置顽疾"，我觉得它站得住的地方是"优胜劣汰"。Unix下的Android调试，环境配置的坑多到能写本《九阴真经》，可真正能活下来的调试方法，一定是被坑过无数次后总结出来的。比如"先查网络"——这步能筛掉80%的adb connect失败；"再看日志"——这步能筛掉90%的logcat没输出；"最后盯编译"——这步能筛掉99%的NDK报错。剩下的1%，是那些真·玄学问题，比如"设备突然断连""logcat输出乱码""编译时内存不足"——这些问题，三步法解决不了，但至少能让你知道，该找谁背锅。

　　上周跟测试组吵架，他们说"你的接口测试用例在Unix下跑不通"，我反问："是adb connect失败？logcat没输出？还是NDK编译报错？" 他们愣了一下："你怎么知道的？" 我笑："因为这三步，我踩了半年。" 他们不服："那剩下的1%怎么办？" 我指了指桌上的测试机："凉拌——先重启设备，再重启adb server，最后重启Unix主机——如果还不行，那就不是环境配置的问题，是Android本身的bug。" 他们沉默了三秒，然后说："那你赶紧写个文档，把这三步贴墙上。" 我摇头："文档没用，得让他们自己踩一遍——踩过坑的，才记得住。"

　　现在我的Unix主机上，贴着三张便签：第一张写"adb connect前先telnet 5555"；第二张写"logcat没输出先看dmesg"；第三张写"NDK编译报错先看Makefile"。产品经理路过又瞥了一眼："就这么点东西，贴三张？" 我头也不抬："对，就这么点东西，坑了你半年。" 他走了，我继续调试——桌上排成一排的测试机，终于全亮着屏了。

（编辑：站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!