uni-app uni.getSystemInfo 同一部手机获取的数据多次不一样

uni-app uni.getSystemInfo 同一部手机获取的数据多次不一样

开发环境 版本号 项目创建方式
Windows win 10 专业版 HBuilderX

示例代码：

uni.getSystemInfo({  
    success: (res) => {  
        console.log('h5 getSystemInfo', res);  
    }  
})

操作步骤：

statusBarHeight 和 safeArea.top
有时候都是0 有时候都是20
ipone se2 ios14.4

预期结果：

感觉是有时候以小程序本身h5 打包 为依据返回的 有时候是以宿主app 云闪付 为判断 返回的结果？
statusBarHeight 在h5 固定为 0嘛

实际结果：

statusBarHeight 和 safeArea.top
有时候都是0 有时候都是20

bug描述：

小程序项目 以h5打包部署的方式 在云闪付app 上打开小程序
uni.getSystemInfo 同一部手机获取的数据多次不一样


更多关于uni-app uni.getSystemInfo 同一部手机获取的数据多次不一样的实战教程也可以访问 https://www.itying.com/category-93-b0.html

2 回复

h5 端使用的 https://github.com/zhetengbiji/safeAreaInsets 获取，其内部利用 css 推断。
如果不同时机获取的值不同，可能与 webview 环境有关，比如宿主环境动态设置了 webview 属性。
可以尝试一下延迟获取。

更多关于uni-app uni.getSystemInfo 同一部手机获取的数据多次不一样的实战教程也可以访问 https://www.itying.com/category-93-b0.html


在云闪付App内打开H5打包的小程序，uni.getSystemInfo获取的statusBarHeight和safeArea.top值不稳定，这通常是由于混合环境（Hybrid）的渲染时机问题导致的。

核心原因分析：

  1. H5与原生容器通信延迟：在云闪付这类App内，H5页面运行在WebView中。uni.getSystemInfo需要从原生容器（云闪付）获取系统信息（如状态栏高度）。这个通信过程可能存在延迟，或者WebView在初始渲染时，原生容器的布局尚未完全稳定。
  2. 页面渲染时机影响：如果在页面生命周期过早调用（如onLoad），此时WebView可能尚未与原生环境完全同步，导致获取到不准确的值（如0）。稍后（如页面渲染完成或用户交互后）再次调用，可能获取到正确的值（如20）。
  3. 云闪付App自身实现：第三方App对WebView的支持和API暴露方式可能存在差异，这会影响uni.getSystemInfo获取数据的准确性和一致性。

针对H5环境的说明： 在标准浏览器或纯H5环境中，statusBarHeight通常固定为0，因为浏览器没有原生状态栏的概念。但在云闪付这类App内，H5页面被嵌入原生容器，此时statusBarHeight反映的是云闪付App自身状态栏的高度（如果云闪付暴露了该值）。因此，值可能为0（未获取到）或20（实际高度），这取决于通信时机和云闪付的实现。

建议的解决方案：

  1. 延迟获取：在onReady或onShow生命周期中调用，或使用setTimeout短暂延迟（如100ms），确保WebView与原生环境同步完成。
  2. 异常处理：对获取到的statusBarHeight进行判断，若为0，可尝试重新获取或使用默认值（如20）作为降级方案。
  3. 缓存机制：首次获取到非零值后，可存储在本地（如uni.setStorageSync），后续直接使用缓存值，避免重复调用。

示例代码调整：

onReady() {
  setTimeout(() => {
    uni.getSystemInfo({
      success: (res) => {
        const statusBarHeight = res.statusBarHeight || 20; // 降级默认值
        console.log('稳定获取的值:', statusBarHeight);
        // 存储或使用该值
      }
    });
  }, 100);
}
回到顶部