如何优化Widget中的动画以提高页面性能，对理解Widget的基本运行原理和性能优化有启发。

01

背景

这个项目的诉求是实现地球的3D效果，支持旋转动画效果，但是小程序不支持webGL。我们曾经考虑过使用webview，但是这个产品包含动态共享文案，webview开发的工作量比较大。最终的解决方案是通过在小程序中逐帧播放图像来模拟3D旋转的效果。

经过考虑，最终图片数量为：144png格式图片。每张图像大约被压缩30k，最终结果是每125ms改变一张图像。这里要考虑两个难点：一是144图片的预加载（图片预加载方案），二是这144图片的处理方法（图片显示方案）

02

图片预加载

公式

什么是图像预加载？所谓预加载，就是提前加载图片，将其存储在本地的缓存中，这样当应用程序使用该图片时，可以直接从缓存中检索出来，相应的响应速度也更快，就像我们吃饭的时候一样。自助餐，我们提前把食物送到餐桌上，让我们吃起来更方便。

我们知道，在传统的Web中我们经常可以通过Image对象来预加载图像，但是小程序没有Image对象，所以我们必须解决它。 。虽然小程序不提供 Image 对象，但它确实有一个可以使用的 。当然，换个思路，我们也可以在页面和显示器上隐藏几个 image 组件 image 组件的加载方式用于预加载。以下是这两个解决方案的示例代码：

1。隐藏页面上的图片并监听load事件来缓存图片。示例代码如下：

<image
    hidden
    wx:for="{{preLoadImageList}}"
    wx:key="{{index}}"
    data-id="{{item}}"
    
    bindload="imageOnload"
    binderror="imageError"
/>

2。通过微信提供的API预加载图片进行缓存。

({
  // 仅为示例，并非真实的资源
  url: '', 
  success(res) {
    // 图片临时路径
    console.log()
  }
})

上面列出了这两个问题的解决方案。首先我们看一下图片预加载方案在实际操作中的优缺点：

提案注意事项

预加载图片的两种方案（组件和组件其实没有本质区别）图像），但在某些情况下使用键进行预加载可以更方便地处理我们的业务逻辑。

在实际处理过程中，笔者发现，在iOS系统（普通Android系统）中，通过隐藏image❀来预加载图像的方式效果更好。失控。所谓不受控制是指当我们的image组件的hidden属性设置为true时，部分时间图像会被回收。另外，作者测试发现，当组件display属性设置为none时，也会出现同样的结果。这也进一步说明，使用组件的 hidden 属性处理小程序确实会更改组件的 display 属性，这意味着该元素仍然存在于 DOM 树中。至于图片回收，官网其实也有解释：

iOS程序小页面由多个WKWebView组成。当系统内存紧张时，部分WKWebView会被回收。从之前分析的案例来看，使用大图片和长列表图片会导致WKWebView回收。

（注：WKWebView是iOS系统渲染层的运行环境）

但是按照官网的说法，小程序会回收整个页面，但这并不在现实，所以我猜WKWebView处理这个问题的方法是当图像display属性为image❀none时不缓存这些图像

<image
    catchtouchstart="touchStart"
    catchtouchmove="touchMove"
    catchtouchend="touchEnd"
    
/>

<view
    catchtouchstart="touchStart"
    catchtouchmove="touchMove"
    catchtouchend="touchEnd"
    style="background-image:url({{imageUrl}})"
/>

<view
    catchtouchstart="touchStart"
    catchtouchmove="touchMove"
    catchtouchend="touchEnd"
>
    <image
        wx:for="{{imageList}}"
        wx:for-index="idx"
        wx:key="{{idx}}"
        data-id="{{item}}"
        bindload="imageOnload"
        binderror="imageError"
        
        style="transform: {{idx === index ? 'translate(0, 0)' : 'translate(-100%, 0)'}};"
    />
view>

官网上的解释很长。其实我感觉初学者一定看不懂。这其实要从小程序的运行环境说起。小程序的运行环境分为渲染层和逻辑层。 WXML 模板和 WXSS 样式在渲染层中工作，JS 样式在渲染层中工作。通信

如上，每当我们在逻辑层（JS代码）执行setData时，它首先会从逻辑层传递到原生。渲染层（视图层）Nativen进行处理。好了，既然知道了渲染层和逻辑层是什么，那么跳转到上面的官网解释就很顺利了。

在传统的Web应用中，我们可以直接编辑DOM某个元素，也就是路径结束的时候。这不适用于小程序。没有办法一路走下去。 Native充当转发的“桥梁”。这就是我们觉得Android被卡住的根本原因，因为它走了“弯路”。

所以我们需要提高Android上的页面性能，启用硬件加速就成了一条捷径。我们将上面的代码改成如下方式：

<view
    catchtouchstart="touchStart"
    catchtouchmove="touchMove"
    catchtouchend="touchEnd">
    <image
        wx:for="{{imageList}}"
        wx:for-index="idx"
        wx:key="{{idx}}"
        data-id="{{item}}"
        bindload="imageOnload"
        binderror="imageError"
        
        style="transform: {{idx === index ? 'translate(0, 0)' : 'translate(-100%, 0)'}};"

/>view>

开启硬件加速后，Android不会卡顿，但页面可以正常旋转、左右滑动。但是… Apple iOS又回到了旧的疯狂闪屏…其实代码只是translate3d和

<div style="display:inline-block; ...">
    <div style="display:inline-block;background-image:url({{url}});...">
        ...
    div>
div>

小程序的自定义组件有一个单独的构造函数用于实例化 Component，因此它的 setData 和 坺 位于主页面互不影响。确实非常适合应用到这个业务场景。图像切换和滑动逻辑可以封装为单独的组件，然后呈现在主页上。这样既不会影响主页面的性能，也可以为这部分数据变化提供更快的响应时间。

WXS响应事件

WXS是小程序自带的脚本语言。语法与JS基本相同，可以直接嵌入WXML。我们的界面说JS和WXML通信需要NativeNative这个“桥梁”无法直接完成❙♹。 活动。 WXS可以直接作用于DOM。

事实上，在传统的 Web 开发中，通常从图像创建交互式动画是相对常见的。很多情况下，直接使用DOM。小程序则不同。小部件没有 DOM API 。现在网上很多人都说小部件没有DOM。这其实是不准确的。请记住：小部件具有 DOM ，但 DOM API 和 BOM API 不存在。因此，它不能直接使用jQuery等库。

WXS的应用原理也是基于此。我们不再继续setData，即JS和WXML

，在中WXS

05

结论

综上所述，通过预加载和调整每张图片的可见度我们解决了图片闪烁的问题，通过自定义组件和开启GPU加速我们解决了动画滞后的问题。动画的最终解决方案是使用自定义组件，使用预加载图像，列出所有元素，并控制每个图像的可见性，以达到切换图像的目的。另外，系统会通过评估Android和iOS来决定是否启用GPU加速。

这就是动画最终的技术方案。在这个过程中，我们列出了很多其他的解决方案，也可以作为参考。在某些业务场景下它们可能是更好的解决方案。上述解决方案更多地侧重于依赖小程序的某些功能。除了小程序本身之外，关于图片的东西就没有太多了，比如图片格式（webp、apng形状的图片）、大小（是否还有可折叠的）模式）等