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

作者：京东零售 姜海

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

优化前性能表现

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

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

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

冷启动（初次加载小程序包）

热启动（已安装小程序包，退出微信后重新进入）

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