开发者社区 > 博文 > Taro小程序开发性能优化实践
分享
  • 打开微信扫码分享

  • 点击前往QQ分享

  • 点击前往微博分享

  • 点击复制链接

Taro小程序开发性能优化实践

  • 朔方****
  • 2024-11-28
  • IP归属:北京
  • 100浏览

    我们团队在利用Taro进行秒送频道小程序的同时,一直在探索性能优化的最佳实践。随着需求的不断迭代,项目中的性能问题难免日积月累,逐渐暴露出来影响用户体验。适逢双十一大促,我们趁着这个机会统一进行了Taro性能优化实践,现总结如下,希望能为大家在日程的开发中提供借鉴,助力大促。

    优化前性能表现

    性能表现主要从两方面进行衡量,第一个是页面加载时间,其次是页面流畅程度。

    页面加载时间我们通过两个维度进行量化,其一是关键点位打点记录时长,具体的点位有:

    点位列表
    点击tab
    进入秒送频道分包
    定位接口开始
    定位接口结束
    cms接口 开始
    cms接口 结束
    渲染cms 开始
    渲染cms 结束
    渲染入口球开始
    渲染入口球结束
    整体耗时

    记录点位并计算时间间隔,统计出的量化时间表如下:

    冷启动(初次加载小程序包)

    热启动(已安装小程序包,退出微信后重新进入)

    其二,实际上通过代码log打点存在很多问题,比如有些关键时间点没有时机进行上报,无法真实地反映出用户体验的实际情况,所以最真实的使用场景还是亲自掐表进行时间统计。

    掐秒表:分段1(分包加载),分段2(缓存占位获取定位,发起cms请求),分段3(cms加载完成),总时长。

    设备:中端(iPhone11)

    冷启动:热启动:

    问题分析

    根据统计结果,很可以看出容易,目前秒送频道页存在的主要问题主要集中于以下几个方面:

    1.分包加载速度慢,导致首屏耗时

    2.接口请求时长过长。

    3.feeds渲染耗时偏长。

    需要根据存在的问题,针对性地采取对应处理方案。

    优化实践

    1.切换Skyline渲染引擎

    为了解决首屏耗时较长的问题,我们经过调研,决定采用Skyline引擎来进行优化。

    Skyline是微信官方提供的渲染引擎,目标是进一步优化小程序性能,提供更为接近原生的用户体验。其使用更精简高效的渲染管线,并带来诸多增强特性,让 Skyline拥有了更接近原生渲染的性能体验。

    Skyline 创建了一条渲染线程来负责渲染任务,并在 AppService 中划出一个独立的上下文,来运行之前 WebView 承担的 JS 逻辑、DOM 树创建等逻辑。

    这种新的架构相比原有的 WebView 架构,有以下特点:

    • 界面更不容易被逻辑阻塞,进一步减少卡顿
    • 无需为每个页面新建一个 JS 引擎实例(WebView),减少了内存、时间开销
    • 框架可以在页面之间共享更多的资源,进一步减少运行时内存、时间开销
    • 框架的代码之间无需再通过 JSBridge 进行数据交换,减少了大量通信时间开销

    而与此同时,这个新的架构能很好地保持和原有架构的兼容性,可以很大程度上降低首屏的渲染耗时。


    在实际Skyline适配的过程中,我们对遇到的问题进行了记录:


    1.利用backgroundPosition,backgroundImage和height裁剪背景图片的时候,backgroundPosition不可以使用calc运算符:

    目的:裁剪图片从底部开始,向上,高度为gradientHeight的部分

    原写法:

    style={{
        backgroundPosition: `center calc(100% + ${getPx(gradientHeight)})`
    }} >
    

    适配写法:

    style={{
        backgroundPosition: `center bottom -${gradientHeight}px`
    }} >
    

    2.在需要吸顶展示的场景,position: sticky不适用,需要改写:

    目的:滚动到距顶部statusBarHeight的时候吸顶展示

    原写法:

    style={{
        position: sticky,
        top: statusBarHeight,    
    }} >
    

    适配写法

    <ScrollView type="list">
        <StickySection pushPinnedHeader={false}>
            <StickyHeader offsetTop={statusBarHeight}>
                <View className={styles.view}>
                  ...
                </View>
            </StickyHeader>
        </StickySection>
    </ScrollView>
    

    3.子视图节点有用到position: absolute的场景,根结点需要设置position: relative

    4.在视图设置全圆角的时候,单独设置某一变的颜色,会使圆角失效:

    .loading {
        border-radius: 100%;
        border-top-color: transparent;
    }
    

    现象:


    5.position: fixed属性失效:使用position:

    absolute和position: relative按需代替

    6.z-index只在同层级之间有效,跨层级无效:

    如果实在无法提高层级,可以考虑使用: root-portal组件

    7.所有节点默认是 relative,可能导致absolute不准/margin-top无效:

    按实际情况调整UI。如果遇到节点下的第一个margin-top无效,可以在前面加一个占位的的view

    最终适配完成后的优化效果如下

    冷启动:


    热启动:


    2.资源位延迟加载

    feeds楼层存在着渲染时长偏长的问题,最主要的问题集中在店带品楼层上:

    该楼层带有商品列表,列表中的商品每一个都会渲染一个资源位,数目在15到20个不等,这样的楼层会下发13个左右,且每次都会在接口下发后一次性全部渲染,导致渲染的资源位数目暴增。

    本次优化对商品资源位的加载进行了优化,首屏只最多渲染6个:

    其余商品在滑动触底是懒加载。

    <ScrollView 
     ...
     onScrollToLower={handleScrolltolower}
     ...
    />
    
    
    
    const handleScrolltolower = useCallback(e => {
     if (loadMoreImg.current == false) {
     loadMoreImg.current = true
     //加载剩余图片
     setDatasource)
     }
    }, [loadMoreImg])

    以此方式来减少渲染工作量,提高渲染速度。底部的feeds商品资源位也采用相同的处理方式,首屏最多加载6个:

    3.多团队沟通优化

    除了使用懒加载的方式,我们也积极与产品和UED团队沟通,针对店带品的使用场景沟通解决方案。最终确定可以将首屏下发的楼层数从13个调整为9个,进一步降低渲染压力,提升feeds部分的渲染速度。

    在实际优化实践中,往往与其他团队进行沟通,是最有效的优化方式,大家可以多借鉴一下。

    4.图片资源优化

    图片资源尺寸过大,会导致图片下载缓慢,资源位白屏,用户体验差。以往网管在进行商品图片下发的时候,无论是店带品楼层的商品还是商品详情页展示的商品大图,采用的都是同一套尺寸较大的图片,这就导致在店带品楼层商品列表过多时,图片下载过程等待时间过长。经过与后端团队,产品和UED团队积极沟通,确定了一套3尺寸图片方案:

    产品配置图片的时候,会配置大、中、小三种尺寸的图片,网关在下发时会根据资源位的类型区别下发,针对店带品楼层、feeds商品这种楼层,仅下发小尺寸图片,以减小接口请求数据量以及图片下发时间,极大地提高了图片夹杂速度。

    5.接口请求逻辑改造

    秒送频道页涉及到两个接口请求,分别是主接口和feeds数据接口,之前因为代码结构的原因,两个接口采用了串行请求的方式做请求。这次的优化经过方案评审,将串行改为并行,并将两个接口返回的结果进行隔离,分批渲染,从而降低了整体接口请求的时长。

    优化成果

    经过一系列优化,在接口请求总时长,feeds渲染提升非常明显,首屏加载速度有了很大提升:

    根据掐秒表的结果,也能够最直观的感觉出整体开启速度的提升:

    结语

    Taro小程序开发的性能优化实践,不仅涉及到前端代码优化,还涉及到了多个团队之间的沟通配合,好的代码习惯也不是一朝一夕就能养成的,优化也需要日积月累,不断持续地推进,希望这篇文章可以帮助到大家,助力大促期间的用户体验改进。