HarmonyOS鸿蒙Next三方应用网络问题定位指导

HarmonyOS鸿蒙Next三方应用网络问题定位指导 背景

现网大部分应用为网络应用，网络报错和与网络相关的业务异常非常影响用户体验，在这些以网络为入口的问题中，可大致分为两个场景：

1. 网络环境异常导致报错。主要体现在网络质量差，服务器异常等。
2. 网络环境正常且无报错，但以网络为入口的功能异常。主要体现在白屏、卡顿、停播等。

本文以网络为入口，结合两个场景通过 hilog、tcpdump 日志分析定位网络相关问题。辅助工具：Notepad++ 查看 hilog 日志、Wireshark 查看 tcpdump 日志。

分析网络问题可以从以下几个维度进行综合分析：

1. 分析网络类型，是否联网？
2. 检查网络质量，是否信号差等弱网环境？
3. 查找网络错误，是否有明确错误码？
4. 分析相关业务，是否业务侧异常表现为网络异常？

1、分析网络类型

应用出现网络相关异常，首先需要确认问题时间点手机网络环境是否存在异常。

(1)、判断当前网络连接:

当前连接网络可能是 WiFi、蜂窝，也可能出现网络切换场景。通过分析网络连接类型，可以辅助定位应用网络问题是否为特有网络连接下的问题，还是共性问题，以便进一步分析。

a. 判断是否 WiFi 环境关键字：isWifiConnected

当前网络连接 WiFi：

I     HandleWifiConnectStateChanged, isWifiConnected=1

当前网络未连接 WiFi：

I     HandleWifiConnectStateChanged, isWifiConnected=0

b. WiFi 连接过程关键字（正则匹配）：Call wifi func|wlan0 state。

Call wifi func：wifi 扫描和 wifi 连接耗时可辅助分析网络问题时间点的 WiFi 连接过程是否异常。

I     Call wifi func: EnableWifi (start)  
I     Call wifi func: EnableWifi (end), time cost:3846us, 3ms  
I     Call wifi func: GetWifiDetailState (start)  
I     Call wifi func: GetWifiDetailState (end), time cost:740us, 0ms  
...

WiFi 连接状态变化：4| 连接成功; 6| 断开连接。

WiFi 开关从开-关状态变化：

I     OnWifiConnectEventProcess received wlan0 state: 6

WiFi 开关从关-开状态变化：

I     OnWifiConnectEventProcess received wlan0 state: 1  
I     OnWifiConnectEventProcess received wlan0 state: 3  
I     OnWifiConnectEventProcess received wlan0 state: 4  
I     OnWifiConnectEventProcess received wlan0 state: 4

(2)、 网络连接是否发生变化

网络变化搜索关键字：net_monitor，表示网络状态有变化或被探测：

I     [net_monitor.cpp:106]Stop net[117] monitor in  
D     [net_monitor.cpp:109]Stop net[117] monitor out  
...

WiFi 切到蜂窝：oldSupplier|newSupplier

I C015B0/netmanager/NetConnManager: [net_conn_service.cpp:1379]oldSupplier[0, null], newSupplier[1011, simId4], old equals new is [0]

2、检查网络质量

当前网络连接网络质量差可能会导致网络请求超时等错误，通过分析 WiFi 和蜂窝质量，可判断应用当前问题点是否因为弱网环境导致，从而进行优化。

(1)、WiFi 质量

WiFi 信号强度较差或者干扰较强，信道负载高均可能导致 HTTP 请求失败。

WiFi 信号强度日志过滤：WifiFrameWork: SignalPoll

I     SignalPoll,bssid:38:eb:**:**:**:b0,ssid:PCt****13F,networkId:0,band:2,freq:5180,rssi:-48,noise:-93,chload:134,snr:42,ulDelay:1,txLinkSpeed:4000,rxLinkSpeed:4000,txBytes:2953003,rxBytes:12179192,txFailed:0,
txPackets:8420,rxPackets:13469,GetWifiStandard:5,rxmax:400,txmax:400,connState:4,detState:10,lastSignal:4,chloadSelf:0,c0Rssi:0,c1Rssi:0

(2)、蜂窝质量

【必看】蜂窝网络信号差会导致数据请求时间过长，造成卡顿、白屏，无法加载图片等问题。蜂窝网络日志过滤关键词：BoosterNet

index：为零表示是蜂窝网络。其他值表示非蜂窝网络。

NisPsSlow：为 0，表示网络正常，即可以上网。

rsrp：网络信号强度。rsrp<-95，表示网络信号覆盖差，易断线。-95<rsrp<-85 表示网络信号覆盖一般，有时也会断线；-85<rsrp<-75 表示网络信号覆盖较好，rsrp>-75，表示网络信号覆盖强。

rsrq：信号接收质量。表示当前信道质量的信噪比和干扰水平。其取值范围是-20 dB ~ -3 dB，值越大越好。rsrq<-10，表示网络差，-10<rsrq<-7，表示网络一般。rsrq>-7，表示网络质量好，无干扰。

3、查找网络错误

应用提示出现网络问题，一般可以在日志中捕捉到响应错误码，我们可以通过错误码判定是否出现网络错误。再结合上述的网络环境和网络质量联合分析，得出结论。

(1)、关键字搜索

网络请求阶段耗时日志搜索：NETSTACK|http_exec.cpp 可根据改日志分析 HTTP 请求各阶段耗时，结合日志时间，推导请求发起时间和错误原因。errCode 为 Network Kit 错误码可参考官方文档排查：错误码 RespCode 为请求响应码可参考 http 状态码和应用服务排查。

请求成功示例：

I     [http_exec.cpp:401] taskid=-2147483593, size:632, dns:0.133, connect:0.000, tls:0.000, firstSend:1.214, firstRecv:50.458, total:52.287, redirect:0.000, errCode:0, RespCode:200, httpVer:3, method:POST

请求错误示例：

I     [http_exec.cpp:401] taskid=-2147483548, size:0, dns:0.077, connect:0.000, tls:0.000, firstSend:0.000, firstRecv:0.000, total:1.381, redirect:0.000, errCode:2300007, RespCode:0, httpVer:0, method:POST

(2)、常见案例

a. 问题现象：应用某个功能在等待一定时间后提示“网络断开连接”

异常点：firstsend 和 dns 都很快，但是 firstreceive 为 0，errcode：2300028，服务器未响应。total 耗时 10001.271，达到请求设置超时时间 10s，一般为响应超时问题。

b. 问题现象：应用某个功能提示网络错误，但其他应用能正常联网。

异常点：errcode：2300006，dns 未解析，报错域名解析失败，无法连接服务器。一般为应用切后台导致冻结网络不可用，可搜索切后台关键字确认：OnRequestSceneSessionBackground。

c. 问题现象：应用某个页面开始正常，后续使用过程中提示“网络未连接”，页面数据异常。

异常点：respCode：418，为防爬虫标准错误码，应用频繁请求触发服务器防爬返回错误码 418。一般为应用侧操作在某个时间段内频繁进出某个页面触发服务端防爬虫，导致相关请求被服务端拒绝。

4、分析网络业务

应用提示出现网络问题，也可能在日志中未捕捉到响应错误码，无网络相关异常，由于应用自身业务逻辑或者其他非网络系统模块问题导致，这种问题则需要结合业务侧日志联合分析。

(1)、提示网络异常

分析过程：

a. 问题时间点为 19:05 附近，根据问题时间锁定 hilog 日志文件。

b. 打开应用首页，网络连接过程会打印日志 “Connecting to sso”，日志关键字锁定过程：先过滤应用日志，然后看 19:05 分的日志，看到 tcp connect、ip 地址和端口等跟网络强相关的打印，可以在 tcpdump 追踪这条流。

c. 打开 tcpdump，过滤 ip.addr==157.148.54.20，发现这条流建连失败，耗时超过 5s。

d. 建连失败后，应用换了另外一个 ip 地址去建连，重复之前的过程，快速连接成功。

结论：非网络问题，需要应用排查建连 IP 是否可用。

(2)、启动等待时间长

分析过程：

a. 确认问题时间点 14:13 附近，且为 WiFi 环境，根据问题时间锁定 hilog 日志文件。

b. 搜索 netstack，看到有请求成功但耗时超过 1000ms，影响冷启动完成时延。

c. 请求耗时大，可先分析当前 WiFi 网络质量，搜索 WifiFrameWork: SignalPoll，发现 chload 超过 800 网络基本不可用，导致网络请求耗时过久。

结论：非网络问题，实际网络环境不好，导致高时延。

(3)、图片不加载

分析过程：

a. 根据提供截图初步确认问题时间点为 15:19 附近。

b. 此应用使用系统 image 组件，加载图片需要先下载资源，图片未显示可能是下载失败，有打印关键字是“Download image failed”，图片下载失败开始时间点为 15:11:17.538。

c. 从时间点上看相差 8 分钟，则需要确认应用打开的时间，因为图片只在应用打开时下载一次。搜索应用到前台的时间关键字“ABILITY_ONFOREGROUND”，时间点 15:11:12.475。

d. 切前台 15:11:12.475 到下载失败 15:11:17.538 大约 5s，先分析这段时间附近的网络情况，看 wifi 信号强度搜索关键字“WifiFrameWork: SignalPoll”，rssi 为 -90 信号强度差网络不好。根据搜索日志返现只打印了两条信号日志，正常情况应用在前台每隔 3s 会打印一次，由此可推断网络连接可能从弱 wifi 环境切成蜂窝。

e. 继续搜索关键字“oldSupplier|newSupplier”，可以确认发生了网络切换。

结论：非网络问题，打开应用处在 WiFi 信号差的网络环境，导致网络发生切换图片下载失败，建议应用做网络监听和网络重试机制优化因弱网导致加载失败问题。

(4)、视频播放卡顿

分析过程：

a. 视频卡顿时间点 08:56 左右。

b. 应用起播一个视频，会打印关键字 tcp_openedip。查看日志问题时间点，可以锁定在卡顿之前 08:53:34 时间点：tcp_openedip->122.228.230.115 和 112.5.19.161。

c. wareshark 打开 tcpdump 日志，搜索 ip.addr == 122.228.230.115，wareshark 标黑色和红色的部分一般是有异常，重点看 ip==122.228.230.115 这条流最接近问题时间点，然后看 tcpdump 跟踪这条流。

d. 分析发现这条流在 09:56 时有 tcp 0 窗口，对应时间点视频的现象也是卡顿，基本可以确认造成卡断的原因是 0 窗口；tcp 0 窗口的解释是本条 socket 链路分配的缓存被用完，服务端不会再发送新的数据，除非应用把缓存区的数据取走。

结论：非网络问题，应用没有及时取走下载的视频流数据，导致 0 窗口，服务器不再下发数据，播放卡顿。建议应用优化视频播放逻辑。

(5)、Web 页面不显示

分析过程：

a. 锁定问题时间点为 9:51 附近。

b. 查看问题时间点为加载 web 页面加载异常

c. 查看问题时间点附近网络请求成功

d. 查看 url 在浏览器中能正常加载

e. 分析 web 组件异常点，日志可正则搜索 nweb_handle|commitNavigation|event_message，发现 web 组件报错：event_message: FailedProvisionalLoad source_id: 353，与 web 组件确认为组件加载异常，与网络无关。

结论：非网络问题，web 组件问题。

(6)、音乐停止播放

分析过程：

a. 歌曲不播放首先想到要排查资源是否下载成功，下载歌曲日志关键字是 DoDownload（为啥是这个关键字，通过 DevEco 查看实时日志可以发现），发现下载失败 08:20:23.544

b. 看 08:20:23.544 时间点附近 tcpdump 日志，发现本机 ip 地址从 192.168.1.34 变成 10.232.123.23，明显是从 wifi 换成蜂窝，怀疑有网络自动切换，且 192 的网络链路被 RST。

c. 确认网络切换，搜索 oldSupplier|newSupplier，看到在 08:20:24.627 网络从 wifi 切成蜂窝

d. 确认打开应用时间，搜索 start ability, ability com.xxx.xxx（应用 BundleName），无结果可以判断应用应该打开了很久，有可能一直在后台，搜索 OnRequestSceneSessionBackground，可判断 08:17:07.211 退后台。

e. 确认应用切前台，搜索 ABILITY_ONFOREGROUND，08:22:10.514 切前台。

f. 通过第 4 步和第 5 步，发现应用是在后台播放自动切歌，网络发生切换后，下载歌曲失败停止播放。

结论：非网络问题，网络发生切换导致歌曲下载失败，应用没有监听网络切换事件做失败重连。建议应用主动监听网络切换事件，一旦发生切换，把之前的网络连接断开，新建一个链路重新下载。