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

我们团队在利用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尺寸图片方案：