冷启动时间需从 native 层埋点开始、webview 渲染完成结束：android 在 application/splashactivity 记 system.currenttimemillis()，ios 在 appdelegate.m 的 didfinishlaunchingwithoptions 打时间戳，js 层用 onlaunch + onready 手动打点，禁用 usb 调试与开发者模式，真机测 5 次取 p90。
uni-app 冷启动时间怎么测，plus.runtime.launcher 不可靠
冷启动时间不能靠 plus.runtime.launcher 判断——它返回的是「应用进程被系统拉起」的时间点，不是用户点击图标到首屏渲染完成的全过程。真实冷启动必须从 native 层埋点开始，webview 渲染完成才算结束。
uni-app 官方没提供开箱即用的冷启耗时 API，得自己搭链路：
- Android：在
main/AndroidManifest.xml的 Application 或 SplashActivity 中记录System.currentTimeMillis()为起点 - iOS：在
AppDelegate.m的application:didFinishLaunchingWithOptions:里打时间戳 - JS 层：监听
uni.$on('appLaunchEnd')（需自定义事件）或用uni.getSystemInfoSync().platform === 'app'+performance.now()粗略估算首屏就绪时间
用 performance.timing 测 H5 启动不准，App 里压根没这个对象
performance.timing 是浏览器标准，uni-app 打包成 App 后运行在 WebView 中（iOS WKWebView / Android X5 或系统 WebView），多数版本不支持完整 Navigation Timing API，调用会返回 undefined 或空对象。
替代方案是手动打点：
- 在
App.vue的onLaunch钩子第一行写const start = Date.now() - 在页面
onReady或关键 DOM 挂载后（如uni.$nextTick）记结束时间：console.log('cold launch:', Date.now() - start) - 注意：这个值只是「JS 执行+首屏渲染」耗时，不含 native 启动、WebView 初始化、资源加载等环节，偏乐观
真机测冷启必须关掉「USB 调试」和「开发者模式」
开启 USB 调试时，Android 系统会强制启用 ART 解释执行、禁用 JIT 编译，App 启动慢 2–3 倍；iOS 开发者模式下 WebKit 也会降级渲染策略。实测数据严重失真。
正确做法：
- 打包正式版（
release模式）APK/IPA，用adb install或 TestFlight 安装 - 卸载旧版，重启手机，清空后台，再点击图标启动
- 用手机自带录屏+秒表人工计时（最准），或用 Android Studio 的
Logcat过滤ActivityManager日志看Displayed时间
uni.setStorageSync 存启动时间会拖慢冷启，别在 onLaunch 里写
冷启动阶段写本地存储（尤其 uni.setStorageSync）会阻塞 JS 主线程，且 iOS 上可能触发沙盒同步锁，导致白屏延长 100–400ms。这不是优化点，是性能雷区。
如果真要持久化启动耗时用于后续分析：
- 改用异步
uni.setStorage，并加setTimeout延迟到onShow或空闲时执行 - 或者只存内存变量（
window.__launchTime = Date.now()），上报时再组合拼装 - 更推荐直接通过
uni.reportAnalytics上报原始时间戳，后端聚合计算
冷启动时间受渠道包、签名方式、是否启用 X5 内核、iOS 的 bitcode 设置影响极大，同一份代码在不同设备上波动常超 ±300ms。别迷信单次测量，至少跑 5 次取中位数，重点看 P90 分位值。
