ミニプログラムを最適化する方法を段階的に説明しましょう。（実践まとめ）-ミニプログラム開発-php.cn

小さなプログラムを最適化するにはどうすればよいですか?この記事では、ミニプログラムの最適化の実践をまとめ、ミニプログラムの最適化項目について説明します。

ミニプログラムを最適化する方法を段階的に説明しましょう。（実践まとめ）

ミニプログラムの実行プロセス

まず、ミニプログラムの動作原理を整理しましょう。休むことなく木を切ります。

百聞は一見に如かず:

ミニプログラムを最適化する方法を段階的に説明しましょう。（実践まとめ）

画像の内容を注意深く理解することをお勧めします。小さなプログラムに対する強力な理論的サポートがあります。開発と最適化の方向性。

最適化項目

1. 下請けの適正利用

WeChat miniのポイントプログラム高速起動が特徴ですが、この機能に関して公式はパッケージサイズを2Mまでと制限しています。

下請けはミニプログラムの最適化にとって最優先事項であり、これによりミニプログラムの起動速度とページを開く速度を効果的に向上させることができます。

パッケージは[本体パッケージ][通常下請け][独立下請け]に分かれています。

[メインパッケージ] には、スタートアップページまたは TabBar ページのみを配置する必要があります。

[通常のサブパッケージ] TabBar ページ以外のページを配置するため、ページ数やモジュール数に応じて複数のサブパッケージを分割し、サイズを小さくすることを推奨します。ユーザーが対応するサブパッケージページに入ると、このパッケージは必要な場合にのみダウンロードされるため、パッケージのオンデマンド読み込みも可能になり、リソースの無駄が回避されます。通常のサブパッケージ内のページからミニプログラムを起動する場合、最初にメインパッケージをダウンロードし、次にサブパッケージをダウンロードする必要があります。

[独立サブパッケージ] 独立性の高いページをいくつか配置し、独立サブパッケージ内のページからミニプログラムを起動すると、独立サブパッケージのみがダウンロードされるため、起動が大幅に改善されます。ミニプログラムの速度ユーザーが、対応するパッケージをダウンロードするために戻る前に、TabBar ページまたは他の通常のサブパッケージページに移動するとき。

独立したサブパッケージにはコンポーネントやログインなどのグローバルなものを含めることはできず、他のパッケージからリソースを導入するとエラーが発生します。

著者は、外注する前にページと機能を整理することを推奨しています。外注の制限は、パッケージのサイズが 2M を超えることではなく、ビジネスと機能に応じて柔軟に分割する必要があります。現在の通常のネットワーク状況では、2M サブパッケージと 500KB サブパッケージのダウンロードに特に大きな違いは感じられないかもしれませんが、ネットワークが弱い環境では、この 2 つの違いは大きく異なります。そうしないと、ユーザーが空白の画面を表示する時間に大きなギャップが生じます（個人的な経験です。これは胸が張り裂けるようなものであると言えます）。

たとえば、TabBar ページから直接アクセスでき、頻度が高い二次ページをサブパッケージに配置し、その後にその他のページを配置します。より深いページまたは、それほど重要ではないページをパッケージに分割するか、注文ビジネスモジュール全体のページをパッケージに分割します。

パッケージが分割された以上、当然ながら【サブパッケージの事前ダウンロード】は必須となります。

公式サイトのルールに従って設定することができ、ユーザーが特定のページに入ると、事前にパッケージがダウンロードされます。

2. オンデマンドでの注入

アプレットがパッケージをダウンロードした後、パッケージのすべての

JS## が開きます。 #Merge インジェクション、一部の未訪問のページおよび未使用のカスタムコンポーネントも実行環境にインジェクションされます。注入時間とメモリ使用量に影響します。私たちが望んでいるのは、パッケージのダウンロードが完了したときに、これから開こうとしているページのコードのみが挿入されることです。

これは、ミニプログラムの開始や下請けページへのジャンプがホワイトスクリーンタイムに影響を与えるポイントでもあります。

{
    "lazyCodeLoading" : "requiredComponents"
}
ログイン後にコピー

3. setData# # のいくつかの呼び出し原則を明確にする#ミニプログラムは WeChat クライアント上で実行されます。つまり、wxml

、

wxs、wxss はすべてクライアント上で実行され、オペレーティングシステム環境レンダリングスレッドとロジックスレッドの 2 つのスレッドに分割されます。レンダリング層はレンダリングに WebView を使用し、ロジック層は JSCore を使用して JS コードを実行します。 wxml と wxss はレンダリングスレッドで動作し、wxs は論理スレッドで動作します。 2 つのスレッド間で通信するにはどうすればよいでしょうか?

#転送ステーションとしてクライアントを介して通信

レンダリング層はイベントをトリガーし、クライアントに応答します。ロジック層は setData を渡し、データをクライアントに送信します。両側のデータは文字列に変換されて送信されます。クライアントは個別に応答し、応答はリアルタイムではありません。これは、ロジック層で
setData

モデルは図に示すとおりです。

ネイティブミニプログラムを最適化する方法を段階的に説明しましょう。（実践まとめ）はクライアントです。

回到问题，setData在逻辑层调用，让渲染层快速响应取决于逻辑层到客户端的数据传输效率，而这个传输效率又取决于你传输数据的大小，所以在调用setData的时候应该尽可能减少数据传输大小。

Native会将wxml转换成 js对象，然后和setData传进来的对象做差异化对比，将差异化渲染到视图上。

综上原理，我们调用setData应该遵循几个原则：

尽可能减小需要 setData 数据的大小，JSON.stringify后不超过 256KB。
避免将不需要渲染的数据（不在wxml中绑定的数据）传入setData，减少差异对比耗时。
避免过于频繁调用setData，会导致逻辑层业务繁忙，一直在处理setData的传输队列，而导致抽不开身去处理渲染层的响应，从而导致渲染阻塞，页面出现卡顿，甚至setData无效。如果可以的话，可以采用节流等方式进行优化。
尽可能将多个需要更新的数据合并为一次setData，减少通信过程。
避免后台页面触发setData，也会占用Js线程，有可能会造成阻塞，导致真正需要setData的数据没有响应

减小setData的数据大小通常在列表场景中，通常只更新需要更新的下标：

const needRefresh = `list[${index}]`
// 写法一
setData({
    [needRefresh]: &#39;新值&#39;
})

// 写法二
setData({
    [`list[${index}]`]: &#39;新值&#39;
})

// 写法三
setData({
    &#39;list[0]&#39;: &#39;新值&#39;
})

// 写法四
const needRefresh = `list[${index}].disabled`
setData({
    [needRefresh]: &#39;新值&#39;
})

// 写法5 更新对象
setData({
    &#39;personal.name&#39;:&#39;xxx&#39;
})

ログイン後にコピー

如果有变量，就需要放在[]内。

4. 控制图片大小比例

图片太大会增加下载时间和内存的消耗，并且为了用户体验，应该控制图片的高宽比例，防止图片变形或者被裁切（这个问题可以根据image的mode属性进行调整）。

一个合格的图片应该满足以下两点：

图片宽高乘积 <= 实际显示宽高乘积 * (设备像素比 ^ 2)。
显示的高/宽与原图的高/宽不超过 15%。

由于这些图片都出自 UI，所以在这一条优化上你需要做的是：拿着这两条指标去跟 UI battle。

good lucky ～

以上第一条就是和设备的【dpr】相关，移动端开发一定要理解【dpr】，这里就不多赘述了。

我们应该合理的采用图片资源，例如在【dpr】为 2 的设备上，一个 60x60 的元素区域显示的图片为了兼顾清晰度与资源大小，图片大小不应该超过 120x120，同理，【dpr】为 3 设备，图片应该不超过 180x180。

我们小程序的资源都放在cdn上，可以利用cdn的图片云处理功能对资源请求进行控制，我司用的七牛云和又拍云，如下：

// 七牛云
`${_src}?imageMogr2/thumbnail/!${scaleRatio}p`

// 又拍云
`${_src}!/scale/${scaleRatio}`

ログイン後にコピー

更多云处理功能可以挪步官网：七牛云（https://developer.qiniu.com/dora/8255/the-zoom）和又拍云（https://help.upyun.com/knowledge-base/image/）

我们在小程序内自定义了图片组件 cus-image , 该组件会根据【dpr】对图片进行云处理。并提供了 ratio 属性灵活调整图片大小（因为运营方上传的图片可能在不同尺寸的元素区域内引用，所以需要开发人员灵活控制）。

5. 避免短时间内发起太多请求

小程序中wx.request、wx.uploadFile、wx.downloadFile的发起的网络请求短时间内最大并发限制是 10 个，超过 10 个就会导致请求阻塞。而图片请求的并发最大数量为6。

那短时间怎么去界定呢？

【网络请求】耗时超过 300ms 的请求并发数不超过 10 个（一般不会出现这个问题，如果有这个问题那可能该考虑拆分页面、拆分业务或者合并接口了。）
【图片请求】同域名耗时超过 100ms 的图片请求并发数不超过 6 个

例如：300ms内发送了12个请求，其中10个请求在300ms内就请求完成了，只有2个请求超过300ms，这样是没有问题的。

【解决方案】

在接口请求上我们应该尽可能的减少请求数量。
图片可以设置懒加载lazy-load。
图标可以使用雪碧图。
将图片资源拆分在多个域名下。
自定义一个分片处理函数，将请求拆分成数个阶段发出。

function interelTasks(task,wait){
    this.data.timer = setInterval(()=>{
        task()
    }, wait)
}

async function task(promiseList = []){
    const result = await promise.all(promiseList)
    // do something
}

ログイン後にコピー