收藏
回答

同样是扫码,打开webview的速度为何优于原生小程序?

你好,

请问扫码打开“小程序内webview” 优于扫码打开“小程序原生页面”的打开时间么(scan 到 onload 的时间)?前提:在包整体体积几乎一样的情况下。

Appid: wxfe8bad70675a5fd2


具体情况如下:

我们在线下有很多支付二维码,用户扫码后会打开我们的小程序键盘页。

该页面是小程序内的webview(普通分包),后来我们打算新写一个原生页面代替webview。时间线如下:

10月19号中午,上线一个“新的原生页面”,但是没有切换扫码路径,所以用户扫码依旧到达老的webview。这个小程序包内是包含新老页面的。

10月22号上午,切换扫码路径至原生页面。


我们一直有监控键盘页的扫码到调用生命周期onLoad 的时长,这个指标为“scan_to_load”。下图为 "scan_to_load" 的时长图。

我们发现,在10月19号上新代码那会儿页面scan_to_load 时长都是比较平稳的,但是22号切换二维码路径之后,scan_to_load 激增:Top 95线上升 5-6s,Top 90线上升3s左右。




小程序包体积情况:我们的总包压缩之后体积为900多K,其中 主包体积占总体积的90%。webview(2K左右) 和后来的原生键盘页(压缩后 50K +)使用普通分包。所以两者在体积上应该相差不大。

所以变换二维码路径产生的数据差异,令我很费解。期待你们的回复~~~

最后一次编辑于  11-27
回答关注问题邀请回答
收藏

1 个回答

  • 小程序技术专员-binnie
    小程序技术专员-binnie
    星期三 21:45

    这个是不是得算onReady的时间?

    星期三 21:45
    赞同
    回复 6
    • Emily
      Emily
      星期四 11:16
      所以可能是  “分包上的原生页面”有不少时间 花在 “onReady”上,是么?这个我们也可以追加在打点统计看看。
      星期四 11:16
      回复
    • Emily
      Emily
      星期四 11:29
      哦 不对,我这里是纯粹的  扫码到 “onLoad”生命周期的时长统计,没有涉及到 “onReady”。但是这里到 onLoad 就是不同的时间长度,其实挺奇怪的~
      星期四 11:29
      回复
    • Emily
      Emily
      星期四 11:35
      我原来理解,onLoad 仅仅是 “包体积下载”~~ 还望请教 @binnie
      星期四 11:35
      回复
    • 小程序技术专员-binnie
      小程序技术专员-binnie
      星期四 14:29回复Emily
      你这里要算的应该是页面渲染完的时间
      星期四 14:29
      回复
    • Emily
      Emily
      星期四 14:39
      对的呢,我们还有几个指标,其中包括“完整渲染完毕”的时间。
      但是目前我们正拆步骤在看,看到第一个步骤 “onLoad”这里的时间比较奇怪,所以发出来 问下~~
      星期四 14:39
      回复
    查看更多(1)
问题标签