export default {
onLaunch() {
setInterval(() => {
uni.getNetworkType({})
}, 20)
}
}
a***@lanxiniu.com
- 发布：18 分钟前
- 更新：15 分钟前
- 阅读：16
产品分类： uniapp/App
PC开发环境操作系统： Mac
PC开发环境操作系统版本号： 26.3.1
HBuilderX类型： 正式
HBuilderX版本号： 5.07.2026041006
手机系统： iOS
手机系统版本号： iOS 26
手机厂商： 苹果
手机机型： iPhone 14 至 iPhone 17 Pro Max
页面类型： vue
vue版本： vue2
打包方式： 云端
项目创建方式： HBuilderX
示例代码：
操作步骤：
- 新建经典 uni-app（vue2）工程，云端发行到 App。
- 在 onLaunch 里用定时器调用 uni.getNetworkType。代码见代码示例。
- 冷启动后划到后台。
- 新建经典 uni-app（vue2）工程，云端发行到 App。
- 在 onLaunch 里用定时器调用 uni.getNetworkType。代码见代码示例。
- 冷启动后划到后台。
预期结果：
getCommandInstance:HtmlID: 在帧已销毁、引擎重建、App 不在 Active 时返回空，不要把已释放实例交给后面的 objc_msgSend。
execSync: / callNativeModuleSyncWithPayload:inWeexInstance: 与异步路径一致：实例已销毁则直接返回。异步路径已有 instance already destroyed, task ignored。
uni-stat 的 applicationHide 不要在进后台时同步写存储，也不要再调 uni.getNetworkType。
请在经典版运行时修复，不要只排进 uni-app x。
getCommandInstance:HtmlID: 在帧已销毁、引擎重建、App 不在 Active 时返回空，不要把已释放实例交给后面的 objc_msgSend。
execSync: / callNativeModuleSyncWithPayload:inWeexInstance: 与异步路径一致：实例已销毁则直接返回。异步路径已有 instance already destroyed, task ignored。
uni-stat 的 applicationHide 不要在进后台时同步写存储，也不要再调 uni.getNetworkType。
请在经典版运行时修复，不要只排进 uni-app x。
实际结果：
4.10.3 / 1.9.9.81739 / UUID 2AF6B4C3-DF9A-3C61-BF7A-193FB1F2F515 上，11 月 14 日这 20 条仍全部是 com.taobao.weex.bridge 野指针。
4.10.3 / 1.9.9.81739 / UUID 2AF6B4C3-DF9A-3C61-BF7A-193FB1F2F515 上，11 月 14 日这 20 条仍全部是 com.taobao.weex.bridge 野指针。
bug描述：
应用：蓝犀牛搬家
AppID：__UNI__D16EB90
Bundle ID：cn.bluerhino.housemoving
版本：4.10.3（271）。同一指纹在 4.9.9 / 4.10.1 / 4.10.2 上已经存在
HBuilderX：5.07.2026041006（正式版），开发机 macOS 26.3.1
运行时：4.10.3 为 1.9.9.81739，DCUniBase UUID 2AF6B4C3-DF9A-3C61-BF7A-193FB1F2F515
4.10.2 为 1.9.9.81714，UUID 271C0EAD-5D91-334B-B539-1885E8FFB277
uniStatistics.version = 2，打进包的是 uni-cloud-stat.es.js
页面类型以 vue 为主，工程里同时有 nvue。崩溃日志的页面字段为空，对不上具体页面。
机型：iPhone 14 至 iPhone 17 Pro Max。系统：iOS 16.3 到 27.2.1，iOS 26、27 居多。
现象
11 月 13 日导出 60 条，57 条是同一条。11 月 14 日 19:02–23:57 再导出 20 条，20 条仍是这一条。4.10.2、4.10.3 各 10 条，20 台设备。
20 条全部是：
- EXC_BAD_ACCESS (SIGSEGV)，KERN_INVALID_ADDRESS
- Attempted to dereference garbage pointer
- 崩溃线程 com.taobao.weex.bridge
- 栈从 JavaScriptCore 进入 DCUniBase，停在 objc_msgSend
- 没有 SIGKILL，没有 JETSAM
19 条崩溃时 application_in_foreground=false 且 application_active=false。其中 12 条是进后台不到 1 秒。7 条是已经在后台超过 1 秒，最长约 3 小时。1 条在前台，4.10.3，启动约 2 秒。
业务侧已经拿掉的调用
- 不再调用 uni.getNetworkType，不再注册 uni.onNetworkStatusChange
- plus.ios.import、进后台发通知、登录凭证和设备号，都改成前台才打同步桥
这些改动已在 4.10.3 中。4.10.3 仍占这 20 条里的 10 条。
线上不需要代码示例里的轮询。进后台时 uni-stat 的 applicationHide 会 uni.setStorageSync(_STAT_LAST_PAGE_ROUTE)，随后上报。新包源码里这条上报还会经过 gateSend 再到 uni.getNetworkType。这段由编译器注入，业务侧包不到。
1 个回复
Ask小助手 - Ask社区AI助手
这条反馈整体质量很高，下面从反馈完整性和问题成立性两方面进行评审。
一、反馈完整性评审
标题与问题描述：完整且专业。给出了 AppID、Bundle ID、四个版本的对照（4.9.9–4.10.3）、运行时版本与 DCUniBase UUID、崩溃异常类型/崩溃线程/栈位置、两批日志的同指纹占比、前后台状态分布（19 条后台、12 条进后台 1 秒内、7 条后台最长约 3 小时、1 条前台），以及业务侧已摘除的调用清单和“4.10.3 仍占 10 条”的验证结果。这些是定位竞态类崩溃所需的关键信息，官方人员可以直接看懂，无需再追问基础环境。
代码示例：属于“拉高竞态概率”的最小触发代码，本身可运行（放入 App.vue 的 onLaunch 即可），建议在正文中注明放置位置。同时应保留你已说明的关键一点：线上真实触发链路是 uni-stat 编译器注入的 applicationHide → uni.setStorageSync('_STAT_LAST_PAGE_ROUTE') → gateSend → uni.getNetworkType，业务侧无法摘除——这正是本反馈区别于普通业务误用、必须由运行时侧处理的核心依据。需要说明：uni-stat 该内部链路在公开文档中没有对应记载，需官方研发结合源码核实。
复现步骤：步骤清晰（新建 vue2 经典工程 → 云端发行 → onLaunch 定时器调 uni.getNetworkType → 冷启动后划到后台）。但这类崩溃是概率性竞态，建议补充：按此步骤重复多少次可触发一次（复现概率/次数统计）；有条件时补一组断网对照——ask 社区同类崩溃反馈中有“关掉 WiFi 的情况下几乎是必现”的实测描述，可作对照参考；另外那条前台崩溃（4.10.3、启动约 2 秒）与“进后台”主线不符，建议补充它的完整日志以界定触发条件。
预期结果：三条运行时层面的预期（getCommandInstance:HtmlID: 对已销毁帧返回空、execSync 与异步路径 "instance already destroyed, task ignored" 行为对齐、uni-stat applicationHide 不在进后台时同步写存储/不再调 getNetworkType）在防御性修复方向上合理且自洽，尤其“与异步路径对齐”有现成行为可参照。但能否实现、是否排期属于官方研发决策，知识库中无法确认相关承诺。最后一条“请在经典版运行时修复，不要只排进 uni-app x”是诉求而非结论，需注意官方现有公开口径（见下文第二部分第 2 条）。
实际结果：不是误报。20/20 条同指纹、跨 20 台设备、跨 iOS 16.3–27.2.1、跨 4.9.9–4.10.3 四个版本持续存在，且与 ask 社区已有同类崩溃的指纹一致（com.taobao.weex.bridge 线程、objc_msgSend、DCUniBase 同步桥路径、EXC_BAD_ACCESS KERN_INVALID_ADDRESS）。
分类信息：基本完整（Mac 26.3.1、HBuilderX 5.07.2026041006 正式版、iOS 26、Vue2、苹果、机型范围、云端打包），并已说明崩溃日志页面字段为空、无法对应具体页面。当前“平台分类”为空，建议提交时补选 iOS/uni-app 相关分类，便于分发到对应研发。
二、问题成立性（基于知识库）
同一应用在 2026-05-12 已就同类底层崩溃提交过反馈（当时版本 4.9.6，EXC_BAD_ACCESS KERN_INVALID_ADDRESS，DCUniBase，非 JS 线程），见 【报Bug】uni-admin 后台崩溃率统计到的报错日志，uniapp底层调用报错。本次反馈可视为该问题的延续与深化：版本推进到 4.10.3，补充了前后台分布、版本对照和规避验证，反馈价值更高。
ask 社区另有同类崩溃反馈：iOS 云打包 App 终止时 destoryEngine 与 com.taobao.weex.bridge 线程竞态导致 EXC_BAD_ACCESS，崩溃栈同样是 objc_msgSend → DCUniBase 同步桥执行路径（-[WXSDKInstance(DCPlusBridge) execSync:] → -[PlusWeexModule execSync:] → PDRCoreAppFrame/PDRCoreFeature/handleCmds:），复现方式同样是在 onLaunch 里以 20ms 间隔高频调用同步桥接口。官方人员在该帖的回复口径为：“还是建议尽快升级 uni-app x 吧，weex 已经没有维护人员了”。该反馈场景是 App 终止（destoryEngine），你这次是进后台/引擎重建，触发时机不完全相同，但崩溃机制（同步桥线程访问已释放对象）高度相似，可互相印证现象真实存在。
结论：现象成立，非误报，属于经典 uni-app iOS 运行时（DCUniBase/weex bridge）层面的竞态崩溃。但知识库与发行说明中未检索到针对 getCommandInstance:HtmlID: / execSync 野指针崩溃的修复记录，无法确认修复计划；官方目前公开的建议口径是升级 uni-app x（weex 已无维护人员）。你的诉求“在经典版修复”与该口径存在出入，建议在反馈中保留该诉求，由官方研发/产品侧回应排期决策，我这边无法替官方承诺。
三、建议补充的内容（有助于研发定位）
四、结论
该反馈要素齐全、数据翔实、已排除业务侧因素并验证了 4.10.3 仍复现，属于高质量、可受理的 bug 反馈，非误报。建议按第三部分补充崩溃日志文本与复现概率后提交或继续跟进。修复排期与“经典版与 uni-app x”的取舍需以官方研发的正式答复为准；现有公开口径是建议升级 uni-app x。
要回复问题请先登录或注册
公告
更多>相关问题