17、Logcat 与网络调试：Wifi、Bluetooth、Telephony 日志分析
网络调试，说实话，是Android开发里最让人头疼的环节之一。
Wifi连不上、蓝牙配对失败、电话打不通……这些问题一旦出现，你很难靠肉眼看出问题在哪。这时候，Logcat就是你的“照妖镜”。
我个人习惯，遇到网络相关bug，第一件事不是翻代码，而是先拉日志。因为网络协议栈太复杂了，从上层Framework到底层驱动，任何一个环节出问题，都会导致功能异常。日志里往往藏着最直接的线索。
核心观点：网络调试的本质，是追踪“状态机”的流转。Wifi、蓝牙、电话，各自都有清晰的状态迁移路径。日志分析，就是沿着这条路径，找到卡住的那一步。
17.1 Wifi 日志分析：从扫描到连接
Wifi连接，说白了就是三个步骤：扫描、认证、获取IP。每一步都有对应的日志标签。
关键日志标签：
| 标签 | 作用 |
|---|---|
WifiManager |
应用层调用，比如开启Wifi、发起扫描 |
WifiStateMachine |
核心状态机，记录连接过程中的状态切换 |
WifiNative |
与驱动交互的底层接口，能看到扫描结果和认证帧 |
DhcpClient |
DHCP过程，获取IP地址 |
我遇到过一个问题：手机能扫描到Wifi，但就是连不上。看日志发现，WifiStateMachine一直在AUTHENTICATING和DISCONNECTED之间来回跳。这说明认证阶段出了问题。进一步看WifiNative的日志，发现驱动返回了EAP_FAILURE。嗯，原来是企业级Wifi的证书过期了。
我的小技巧：抓Wifi日志时，记得加上-b all参数。因为Wifi相关的日志可能分散在main、system、events等多个缓冲区里。只抓一个buffer，容易漏掉关键信息。
17.2 蓝牙日志分析：配对与连接
蓝牙调试，我个人觉得比Wifi更麻烦。因为蓝牙协议栈分层多，而且很多厂商会修改底层驱动。
关键日志标签：
BtAdapter：应用层操作，比如开启蓝牙、开始扫描BtDevice：设备信息，比如MAC地址、配对状态BluetoothA2dp/BluetoothHfp：音频相关的profile连接bt_stack：蓝牙协议栈内部日志，能看到HCI命令和事件
我曾经调试过一个蓝牙耳机连接问题。耳机能配对，但连上后没声音。看BluetoothA2dp日志，发现STATE_CONNECTED之后，马上又变成了STATE_DISCONNECTED。这说明A2DP连接建立后，又被断开了。再往下看bt_stack日志，发现底层返回了一个HCI_ERROR_CONN_TIMEOUT。原来是耳机进入了省电模式，把连接断开了。
注意：蓝牙日志量非常大。如果你直接logcat -s bt_stack，可能会被刷屏。我建议先抓全量日志到文件，然后用grep慢慢过滤。命令示例：logcat -b all -d > bt_log.txt，然后grep -i "bt_stack\|BluetoothA2dp" bt_log.txt。
17.3 Telephony 日志分析：通话与数据
Telephony，也就是电话和移动数据，是Android里最底层的网络功能。它的日志标签非常固定，因为大部分代码来自AOSP。
关键日志标签：
| 标签 | 作用 |
|---|---|
PhoneApp |
电话应用层，比如拨号、接听 |
GsmCdmaPhone |
与基带通信的接口，能看到网络注册状态 |
RILJ |
RIL（Radio Interface Layer）的Java层，发送AT命令和接收响应 |
DataConnection |
数据连接管理，比如建立PDP上下文 |
举个例子，用户反馈说“手机显示有信号，但上不了网”。看DataConnection日志，发现STATE_CONNECTING之后，一直没有进入STATE_CONNECTED。再查RILJ日志，发现基带返回了ERROR_UNSPECIFIED。这说明APN配置可能有问题。让用户检查一下APN，果然填错了。
避坑指南：我曾经被Telephony日志坑过一次。当时看到RILJ里返回了ERROR_RADIO_NOT_AVAILABLE，以为是基带挂了。折腾了半天，最后发现是SIM卡没插好。所以，遇到Telephony问题，先检查物理层——SIM卡、天线、飞行模式。别一上来就扎进代码里。
17.4 网络调试的通用思路
说了这么多，其实网络调试有个通用套路。我总结了一下，大概分四步：
- 确认问题现象：是连不上？连上没数据？还是数据断断续续？
- 定位问题层级：是应用层？Framework层？还是驱动/基带层？
- 抓取对应日志：根据层级，选择对应的日志标签。
- 追踪状态机：找到状态迁移的日志，看它卡在哪一步。
你想想看，大部分网络问题，其实都是状态机卡住了。只要找到卡住的那一步，问题就解决了一半。
17.5 知识体系图：网络调试日志分析框架
下面这张图，是我自己整理的网络调试日志分析框架。它把Wifi、蓝牙、电话三个模块的日志层级和关键标签都串起来了。你调试的时候，可以对照着看。
这张图里，每个模块都分了五层。从上到下，依次是应用层、Framework层、协议栈层、连接管理层、驱动/基带层。你调试的时候，就按这个顺序，一层一层往下看日志。哪一层出了问题，日志里一定有异常。
最后说一句：网络调试，耐心比技术更重要。有时候一个Wifi问题，日志可能有上万行。别慌，先过滤出关键标签，然后盯着状态机看。状态机不会骗人，它卡在哪，问题就在哪。
公众号:蓝海资料掘金营，微信deep3321