ミニプログラムの最適化の提案

現在、ミニプログラム最適化提案では、2 つのパフォーマンス分析ツール、エクスペリエンス評価プラグイン、およびいくつかのパフォーマンス最適化提案が提供されており、杭州ミニプログラム開発者はこれらを参考にして使用することができます。

データの設定

setData はミニプログラム開発で最も頻繁に使用されるインターフェースであり、パフォーマンスの問題を引き起こす可能性が最も高いインターフェースでもあります。よくある誤った使用法を紹介する前に、setData の動作原理を簡単に紹介しましょう。

仕組み

ミニプログラムのビュー レイヤーは現在、レンダリング キャリアとして WebView を使用していますが、ロジック レイヤーは実行環境として独立した JavascriptCore を使用しています。アーキテクチャ的には、WebView と JavascriptCore は独立したモジュールであり、直接データを共有するためのチャネルはありません。現在、ビュー層とロジック層間のデータ転送は、実際には両側から提供されるevaluateJavascriptを通じて実装されています。つまり、ユーザーが送信したデータを文字列に変換して送信する必要があり、同時に、変換されたデータ内容をJSスクリプトにつなぎ合わせて、JSスクリプトを実行することで2つの独立した環境に送信します。

評価Javascript の実行は多くの要因の影響を受け、データはリアルタイムでビュー層に到達しません。

一般的なsetData操作エラー

1. 頻繁に設定されるデータ

私たちが分析したいくつかのケースでは、一部のミニプログラムが非常に頻繁に（ミリ秒単位で）setData を実行し、次の 2 つの結果が生じました。

Android では、JS スレッドが常にコンパイルとレンダリングを行っているため、ユーザー操作イベントをロジック レイヤーに時間どおりに渡すことができず、ロジック レイヤーも操作処理結果をビュー レイヤーに時間どおりに渡すことができないため、スライド時にユーザーが遅延を感じ、操作フィードバックが大幅に遅れます。
レンダリングに遅延が発生します。WebView の JS スレッドは常にビジー状態であるため、ロジック層からページ層への通信時間が増加します。ビュー層がデータ メッセージを受信すると、送信されてから数百ミリ秒が経過しており、レンダリング結果はリアルタイムではありません。

2. 各setDataは大量の新しいデータを渡す

setData の基礎となる実装から、データ転送は実際にはevaluateJavascript スクリプト プロセスであることがわかります。データの量が多すぎると、スクリプトのコンパイルと実行時間が長くなり、WebView JS スレッドが占有されます。

3. バックグラウンドページでのSetData

ページがバックグラウンド状態（ユーザーには見えない状態）に入ると、setData を継続しないでください。ユーザーはバックグラウンド状態のページのレンダリングを感じることができません。また、バックグラウンド状態のページでの settingData は、フォアグラウンド ページの実行を先取りすることになります。

画像リソース

現在、画像リソースの主なパフォーマンスの問題は、大きな画像と長いリスト画像です。これらの両方の状況により、iOS クライアントのメモリ使用量が増加し、システムがミニプログラム ページをリサイクルする原因となる可能性があります。

イメージが記憶に与える影響

iOS では、ミニプログラムのページは複数の WKWebView で構成されます。システムメモリが不足している場合は、一部の WKWebView がリサイクルされます。過去に分析した事例から、大きな画像や長いリスト画像を使用すると、WKWebView がリサイクルされることがわかります。

ページ切り替えにおける画像の影響

メモリの問題に加えて、大きな画像によってページ切り替えの遅延が発生することもあります。私たちが分析したケースでは、一部のミニプログラムはページ内の大きな画像を参照しており、ページを切り替えるときにフレーム ドロップやフリーズが発生します。

現在、開発者は大きな画像リソースの使用を最小限に抑えることをお勧めします。

コードパッケージサイズの最適化

当初、ミニプログラムのコードパッケージは 1MB に制限されていましたが、コードパッケージのサイズが足りないというフィードバックを多数いただきました。評価の結果、この制限を緩和し、2MB に増やしました。コード パッケージの制限を増やすと、開発者はより豊富な機能を実現できるようになりますが、ユーザーにとってはダウンロード トラフィックとローカル スペースの使用量も増加します。

ビジネス ロジックを実装する場合、開発者はコード パッケージのサイズも最小限に抑える必要があります。コード パッケージのサイズはダウンロード速度に直接影響し、ユーザーの最初の起動エクスペリエンスに影響するからです。コード自体のリファクタリング最適化に加えて、次の 2 つの側面からコード サイズを最適化することもできます。

コードパッケージ内の画像リソースの制御

ミニプログラムのコード パッケージがコンパイルされると、WeChat の CDN に配置され、ユーザーがダウンロードできるようになります。CDN では GZIP 圧縮が有効になっているため、ユーザーは圧縮された GZIP パッケージをダウンロードします。このパッケージは、コード パッケージの元のサイズよりも小さくなります。 しかし、データを分析したところ、ミニプログラム間でコード パッケージの圧縮率が大きく異なり、30% に達するものもあれば、80% にしか満たないものもあります。この違いの理由の 1 つは、画像リソースの使用です。 GZIP はテキストベースのリソースに最適に機能し、大きなファイルでは 70% ～ 80% の圧縮率を達成することがよくありますが、既に圧縮されているリソース (ほとんどの画像形式など) にはほとんど効果がありません。

未使用のコードとリソースを適時にクリーンアップする

日常的な開発中に、いくつかの新しいライブラリ ファイルを導入することがありますが、しばらくすると、さまざまな理由からこのライブラリは使用されなくなります。コード内の参照を削除しただけで、そのようなライブラリ ファイルを削除することを忘れてしまうことがよくあります。現在、ミニプログラムをパッケージ化すると、プロジェクト内のすべてのファイルがコード パッケージに含まれます。つまり、実際には使用されていないライブラリ ファイルやリソースもコード パッケージに含まれるため、コード パッケージ全体のサイズに影響します。