背景

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

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

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

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

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

 

  1. 分析网络类型

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

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

        当前网络连接WiFi:

        I     HandleWifiConnectStateChanged, isWifiConnected=1

        当前网络未连接WiFi:

        I     HandleWifiConnectStateChanged, isWifiConnected=0
      2. 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 
I     Call wifi func: IsConnected (start) 
I     Call wifi func: IsConnected (end), time cost:718us, 0ms 
I     Call wifi func: GetWifiDetailState (start) 
I     Call wifi func: GetWifiDetailState (end), time cost:824us, 0ms 
I     Call wifi func: IsConnected (start) 
I     Call wifi func: IsConnected (end), time cost:753us, 0ms 
I     Call wifi func: GetScanInfoList (start) 
I     Call wifi func: GetScanInfoList (end), time cost:6991us, 6ms 
I     Call wifi func: GetLinkedInfo (start) 
I     Call wifi func: GetLinkedInfo (end), time cost:435us, 0ms 
I     Call wifi func: GetLinkedInfo (start) 
I     Call wifi func: GetLinkedInfo (end), time cost:73us, 0ms 
I     Call wifi func: wifiDevicePtr->GetLinkedInfo (start) 
I     Call wifi func: wifiDevicePtr->GetLinkedInfo (start) 
I     Call wifi func: wifiDevicePtr->GetLinkedInfo (end), time cost:5910us, 5ms 
I     Call wifi func: wifiDevicePtr->GetLinkedInfo (end), time cost:9480us, 9ms 
I     Call wifi func: GetLinkedInfo (start) 
I     Call wifi func: GetLinkedInfo (end), time cost:40us, 0ms 
I     Call wifi func: wifiDevicePtr->GetLinkedInfo (start) 
I     Call wifi func: wifiDevicePtr->GetLinkedInfo (end), time cost:6612us, 6ms

        wlan0 state： 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 
I     [net_monitor.cpp:339]create data_share helper, ret=0 
I     [net_monitor.cpp:341]create data_share helper success 
I     [net_monitor.cpp:345]release data_share helper, releaseRet=1 
I     [net_monitor.cpp:380]is need add suffix (1) 
D     [net_monitor.cpp:314]Get net detection http url:[http://connectivitycheck.platform.hicloud.com/generate_204_16179966166510756961], https url:[https://connectivitycheck.platform.hicloud.com/generate_204], fallback http url:[http://connectivitycheck.cbg-app.huawei.com/generate_204], fallback https url:[https://connectivitycheck.cbg-app.huawei.com/generate_204] 
D     [net_monitor.cpp:91]Start net[117] monitor in 
I     [net_monitor.cpp:166]start net detection 
I     [net_monitor.cpp:190]https detect result: success 
I     [net_monitor.cpp:190]https detect result: success 
I     [net_monitor.cpp:120]Net[117] probe success

      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和蜂窝质量，可判断应用当前问题点是否因为弱网环境导致，从而进行优化。

         a.WiFi质量

    1. 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
  • rssi：信号强度通常以分贝毫瓦（dBm）为单位来衡量，数值越小表示信号越强。一般而言，-30 dBm到-50 dBm之间的信号强度被认为是良好的，-50 dBm到-70 dBm之间的信号强度可以接受，而低于-70 dBm的信号强度则较差。
  • snr：信噪比是信号强度与背景噪声强度的比值，通常以分贝（dB）为单位。SNR值越高，表示信号越纯净，噪声干扰越小。一般而言，SNR值在30 dB以上被认为是优秀的，20 dB到30 dB之间可以接受，低于20 dB则信号质量较差。
  • chload：通道占用比, 可用于表征WiFi信道的繁忙度。chload越高代表网络状态越差, chload 500以上为中网，会卡顿，800以上不可上网。
  • SSID：wifi名称，有些beta用户使用的是公司wifi，从名字就可以看出来，网络不一定稳定。
  • noise：-80为干扰环境，到-60以上就是强干扰。
  • txLinkSpeed和rxLinkSpeed：网速。单位：除10之后是Mbps。

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

I     [nodict][cellular_general.cpp] AdaBoostPredict# Ada,index:0,NisPsSlow:0,NProba:380,rsrp:-71,rsrq:-8,rtt:51,BFH:0,BFC:0,Real:-71,-8,51,0,0,dlBler:0,ulBler:0 
I     [nodict][app_general.cpp] AdaBoostPredict# Ada_app,index:0,NisPsSlow:0,NProba:380,rsrp:-71,rsrq:-8,rtt:52,BFH:0,BFC:0,Real:-71,-8,52,0,0

          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. 查找网络错误

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

a.关键字搜索

网络请求阶段耗时日志搜索：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

参数说明：

  • taskid：请求ID。
  • size：上传或者下载的数据大小。
  • dns：DNS域名解析耗时。
  • connect：TCP握手耗时。
  • tls：TLS握手（加密鉴权）耗时。
  • firstSend：从加密鉴权结束到传输即将开始的耗时。
  • firstRecv：从传输开始到第一个字节被接收的耗时。
  • total：端云交互总耗时。
  • redirect：重定向耗时。
  • errCode：Network Kit错误码。
  • RespCode：请求响应码。
  • httpVer：本次交互使用的HTTP协议版本。
  • method：请求方法。
  • osErr：内核错误码。

b.常见案例

  1. 问题现象：应用某个功能在等待一定时间后提示“网络断开连接” 
    I C015B0/com.**.**/NETSTACK: [http_exec.cpp:401] taskid=-2147483546, size:0, dns:0.317, connect:260.453, tls:68.560, firstSend:0.996, firstRecv:0.000, total:10001.271, redirect:0.000, errCode:2300028, RespCode:0, httpVer:0, method:GET

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

  2. 问题现象：应用某个功能提示网络错误，但其他应用能正常联网。 
    I C015B0/com.**.**/NETSTACK:[http_exec.cpp:401] taskid=-2147483576, size:0, dns:0.000, connect:0.000,tls:0.000, firstSend:0.000, firstRecv:0.000, total:0.000,redirect:0.000, errCode:2300006, RespCode:0, httpVer:0, method:POST

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

  3. 问题现象：应用某个页面开始正常，后续使用过程中提示“网络未连接”，页面数据异常。 
    I C015B0/com.**.**/NETSTACK: [http_exec.cpp:401] taskid=-2147421469, size:873, dns:0.146, connect:0.000, tls:0.000, firstSend:1.228, firstRecv:52.131, total:53.519, redirect:0.000, errCode:0, RespCode:418, httpVer:3, method:POST

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

4.分析网络业务

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

a.提示网络异常

分析过程：

  1. 问题时间点为19:05附近，根据问题时间锁定hilog日志文件。
  2. 打开应用首页，网络连接过程会打印日志"Connecting to sso"，日志关键字锁定过程：先过滤应用日志，然后看19:05分的日志，看到tcp connect、ip地址和端口等跟网络强相关的打印，可以在tcpdump追踪这条流。

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

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

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

b.启动等待时间长

分析过程：

  1. 确认问题时间点14:13附近，且为WiFi环境，根据问题时间锁定hilog日志文件。
  2. 搜索netstack，看到有请求成功但耗时超过1000ms，影响冷启动完成时延。

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

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

c.图片不加载

分析过程：

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

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

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

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

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

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

d.视频播放卡顿

分析过程：

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

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

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

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

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

e.Web页面不显示

分析过程：

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

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

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

  4. 查看url在浏览器中能正常加载
  5. 分析web组件异常点，日志可正则搜索nweb_handle|commitNavigation|event_message，发现web组件报错：event_message: FailedProvisionalLoad source_id: 353，与web组件确认为组件加载异常，与网络无关。

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

f.音乐停止播放

分析过程：

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

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

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

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

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

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

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

Logo
HarmonyOS开发者社区

讨论HarmonyOS开发技术，专注于API与组件、DevEco Studio、测试、元服务和应用上架分发等。

更多推荐

交互归一开发指导

概述 在移动应用开发中，悬浮、点击、双击、长按、上下文菜单、拖拽、轻扫、滚动/平移、缩放和旋转这10种交互事件，在不同的移动端设备上可以分别由触控屏、触控板或鼠标这三类输入设备的不同操作方式触发。开发多设备项目时，必须考虑不同输入设备的交互方式。而使用交互归一组件，保证不同交互场景下的体验一致性，开发者只需要调用归一后的交互事件接口，无需为每个输入设备单独适配，从而大幅简化开发流程。 如下图为不同

avatar HarmonyOS开发者社区

HarmonyOS特性在Flutter侧的适配

一、引言 1.1 概述 欢迎您关注并在Flutter工程中使用HarmonyOS特性功能（意图分享和碰一碰传输）。以下是可参考代码： 1、Flutter侧Sample代码仓库； 2、Flutter侧一镜到底依赖库； 3、Flutter侧意图框架依赖库； 4、Flutter侧碰一碰依赖库。 1.2 场景使用说明 本文档旨在向开发者清晰地传达以下关键信息： 1. 理解一镜到底、意图框架和碰一碰分享。

avatar HarmonyOS开发者社区

HarmonyOS特性在RN侧的适配

9.1 引言9.2 效果演示9.3 意图框架介绍9.4 手机碰一碰分享介绍9.5 一镜到底介绍9.6 代码实现 9.1引言 9.1.1欢迎使用 在 React Native 工程中使用 HarmonyOS 特性功能，包括 意图分享、一镜到底 和 碰一碰传输。这些特性可显著提升用户交互体验，实现更加便捷和自然的跨设备数据传输方式。 为了帮助您快速上手，我们提供了以下资源供参考： Sample代码碰一

avatar HarmonyOS开发者社区