uni.onNetworkStatusChange原理

业务层 uni-app 代码 → uni 框架层 → 各平台适配层 → 平台原生 API → 系统底层网络服务

一、微信小程序端 完整调用链路

1. 开发者写法

js

uni.onNetworkStatusChange(res=>{})

2. uni 框架内部执行逻辑

uni-app 内置平台环境判断，检测当前运行环境为微信小程序

直接转发绑定微信原生 API：uni.onNetworkStatusChange = wx.onNetworkStatusChange

uni 只做参数格式统一、回调包装，无额外监听逻辑

3. wx.onNetworkStatusChange 底层实现（微信客户端层面）

微信 APP 宿主（微信本体）提前向手机系统注册网络监听

微信客户端内部封装系统网络监听能力，对外暴露 JSAPI

小程序运行在微信渲染引擎里，调用wx.onNetworkStatusChange

微信 JS 引擎订阅微信客户端内部网络状态事件

不直接调用系统 API，由微信主 App 中转

4. 微信宿主如何监听手机系统网络

安卓微信：微信 APP 自身调用安卓系统 ConnectivityManager注册网络状态广播监听 android.net.conn.CONNECTIVITY_CHANGE

iOS 微信：微信 APP 使用苹果系统 NWPathMonitor / SCNetworkReachability监听系统网络链路变化

5. 事件传递全流程

系统网络变化 → 手机系统发出网络广播 → 微信主 APP 捕获 →微信内部触发事件 → 推送给对应小程序 JS 线程 →执行小程序wx.onNetworkStatusChange → 最终走到 uni 回调

6. 特点

监听生命周期依附小程序页面

切换 WiFi / 流量 / 断网，微信统一整理isConnected、networkType下发

小程序无权直接调用安卓 /iOS 系统底层，全靠微信壳层代理

二、支付宝小程序端 调用链路

1. 层级

uni.onNetworkStatusChange → 支付宝 uni 适配层 → my.onNetworkStatusChange

2. 底层逻辑

uni 识别支付宝环境，映射为支付宝原生my.onNetworkStatusChange

支付宝 APP 宿主同样提前监听手机系统网络

安卓支付宝：监听ConnectivityManager网络广播

iOS 支付宝：使用苹果网络框架监听链路状态

网络变动 → 支付宝客户端捕获 → 推送至支付宝小程序运行环境

支付宝封装自有返回字段，uni 再统一格式化输出

3. 差异点

支付宝原生字段命名、网络类型枚举和微信不一致，uni 做了字段抹平兼容

三、uni-app 安卓 App 端（原生安卓打包）

完整分层：

uni 前端 JS → uni-app JS 引擎 → uni 原生安卓插件 → 安卓系统 Framework 层 → Linux 内核网络层

1. JS 层调用

js

uni.onNetworkStatusChange()

2. uni 安卓原生桥接逻辑

uni-app 安卓基座（APK 内置原生代码）

初始化时主动创建系统网络监听管理者

调用安卓官方核心类：android.net.ConnectivityManagerNetworkCallback（高版本安卓推荐）

3. 安卓系统底层监听流程

App 申请权限：ACCESS_NETWORK_STATE

向系统网络服务 (NetworkStatsService) 注册网络变化回调

系统 WIFI 服务、移动数据服务发生切换 / 断开 / 重连

系统服务主动回调 App 注册的 NetworkCallback

uni 安卓原生层拿到网络类型、连通状态

4. 原生 → JS 通信

uni 安卓原生通过 JSBridge 桥把 isConnected、networkType 组装成 JS 对象抛回 uni 前端 JS 执行回调函数

5. 触发源头

开关 WiFi

开关移动数据

网络掉线、重连

切换 VPN、以太网、热点全部由安卓系统网络服务第一时间感知，再逐层上报

四、uni-app iOS App 端（苹果打包）

分层：

uni JS → uni iOS 原生引擎 → iOS 系统网络框架 → 系统网络栈

1. uni iOS 原生底层采用两套监听方案

旧方案：SCNetworkReachability（兼容低版本 iOS）

新方案：NWPathMonitor（iOS12+ 主流稳定方案）

2. 具体执行流程

uni iOS 基座启动后，初始化NWPathMonitor网络监视器

设置监听队列，常驻后台监听网络路径状态

系统网络发生任意变动：

WiFi 连接 / 断开

蜂窝网络切换 5G/4G

无网络、飞行模式

NWPathMonitor 立刻捕获状态变更

uni 原生 OC/Swift 代码解析：

是否连通

网络类型 (wifi/cellular/none)

通过 iOS JSBridge 把数据传回 uni 前端 JS，执行 onNetworkStatusChange 回调

3. iOS 系统限制

后台挂起状态下，系统会冻结部分监听

切前台后自动恢复监听

严格权限管控，无法私自抓取更多网络底层信息

五、H5 网页端 uni.onNetworkStatusChange 最底层

无任何 APP 宿主，纯浏览器标准 API 映射

uni 判断环境为 H5

拆分绑定两个浏览器原生事件

在线离线：window.ononline / window.onoffline

网络类型：navigator.connection.addEventListener('change')

无系统级权限，只能浏览器层面监听

无法获取精准 5G/4G，只能粗略判断

全程不调用安卓 /iOS 系统 API，完全依赖浏览器内核

六、全网统一总结（最简记忆版）

所有小程序（微信 / 支付宝 / 抖音）uni → 平台自有 JSAPI (wx/my) → 平台 APP 宿主 → 宿主调用手机系统网络 API核心：必须经过 APP 壳层中转，JS 不能直连系统

uni 安卓 Appuni JS → uni 安卓原生插件 → 安卓 ConnectivityManager → 安卓系统网络服务

uni iOS Appuni JS → uni iOS 原生引擎 → NWPathMonitor → iOS 系统网络框架

H5uni → 浏览器原生 online/connection 事件 → 无系统底层调用

七、最关键底层真相

uni.onNetworkStatusChange 本身不具备任何监听能力它只是统一转发器 + 格式转换器

真正干活监听网络的：

小程序：微信 / 支付宝 APP

App 安卓 /iOS：uni 打包后的原生基座

H5：浏览器

所有平台都是事件驱动，没有轮询，系统主动推送状态，性能极低耗