ミニプログラムの動作メカニズムの簡単な分析

執筆の背景

私はしばらく小さなプログラムに触れてきました。一般に、小さなプログラムを開発する敷居は比較的低いですが、それでも基本的な操作を理解する必要があります。仕組みと原理。 「たとえば、面接中にミニ プログラムについて質問されました。ミニ プログラムにはウィンドウ オブジェクトがありますか? 彼はそうですと答えました。」しかし、実際にはありません。ミニプログラムの根本的な部分が理解できていない感じで、最終的にはこのツールしか使えないのですが、その理由が分かりません。

ミニ プログラムは、技術アーキテクチャの根本から分析する必要がある通常の Web 開発とは大きく異なります。たとえば、Vue や React の開発に慣れている開発者は、ミニ プログラム用に新しいページを作成するのが面倒で、ページは複数のファイルで構成する必要があり、コンポーネントのサポートが不完全で、データ内のデータが毎回更新されるなどの煩わしさに不満を抱くでしょう。変更された場合、setData を設定する必要があります Vue ほど便利ではありません 監視があり、Dom を操作できないため、複雑なシナリオには適していません 以前は npm、sass、およびプリコンパイルの少ない処理言語をサポートしていませんでした

「ミニプログラムは去勢された Vue のようなものだと言う人もいます（笑）。もちろん、設計の出発点は異なります。また、ミニプログラムの設計の本来の意図を理解する必要があります。その使用シナリオを通じて、なぜこの技術アーキテクチャが採用されているのか、この技術アーキテクチャの利点は何なのか、これを理解すると理解できると思います。以下では、ミニプログラムの動作メカニズムとその全体的な技術アーキテクチャを次の観点から分析します。

ミニ プログラムの起源を理解する

ミニ プログラムが登場する前に、WeChat WebView は徐々にモバイル Web への重要な入り口になってきました。WeChat は Web 開発の完全なセットをリリースしました。 JS-SDK と呼ばれるこのツールは、すべての Web 開発者に新しいウィンドウを開き、すべての開発者が WeChat のネイティブ機能を使用して、以前は不可能または困難であったことを実現できるようにします。

ただし、JS-SDK モデルでは、デバイスのパフォーマンスやネットワーク速度の制限により白い画面が表示される可能性など、モバイル Web ページを使用する際のエクスペリエンスが低下する問題は解決されません。そこで、JS-SDKの強化版である「WeChat Web Resource Offline Storage」が設計されましたが、複雑なページではページ切り替えの硬さとクリックの遅れにより、依然として白い画面が表示される問題が発生します。このとき、ユーザーエクスペリエンスを向上させるためにはJS-SDKでは扱えない仕組みが必要となり、小さなプログラムが登場しました。

高速読み込み

より強力な機能

ネイティブ エクスペリエンス

使いやすく安全な WeChat データのオープン

効率的かつシンプル開発

小さなプログラムと通常の Web ページ開発の違い

小さなプログラムの開発は、通常の Web ページの開発と非常によく似ています。主な開発言語は次のとおりです。 JavaScript とも互換性がありますが、この 2 つの間にはまだいくつかの違いがあります。

通常の Web 開発では、さまざまなブラウザーが提供する DOM API を使用して DOM 操作を実行できます。アプレットのロジック層とレンダリング層は分離されています。ロジック層は JSCore で実行され、完全なブラウザー オブジェクトを持ちません。したがって、関連する DOM API と BOM API が不足しています。

通常の Web 開発のレンダリング スレッドとスクリプト スレッドは相互に排他的であるため、スクリプトを長期間実行するとページの応答が失われる可能性があります。小規模なプログラムでは、この 2 つは分離され、スレッド内で別のスレッドで実行されます。

Web 開発者が Web ページを開発するときは、ブラウザーといくつかの補助ツールまたはエディターを使用するだけで済みます。ミニ プログラムの開発は異なり、ミニ プログラム アカウントの申請、ミニ プログラム開発者ツールのインストール、プロジェクトの構成などのプロセスを経る必要があります。

ミニプログラムの実行環境

ミニプログラムの構造

1. テクノロジーの選択

概要一般に、インターフェイスのレンダリングには次の 3 つのテクノロジがあります。

純粋なクライアント側のネイティブ テクノロジを使用したレンダリング

純粋な Web テクノロジを使用したレンダリング

クライアント側のネイティブ テクノロジと Web の使用技術 レンダリングするための複合ハイブリッド技術 (略してハイブリッド技術)

#次の側面分析を通じて、ミニ プログラムにどの技術ソリューションが使用されるかを決定します

開発の敷居: Web の敷居は低く、ネイティブもこのような RN はフレームワークでサポートされます

エクスペリエンス: ネイティブ エクスペリエンスは Web よりもはるかに優れており、ハイブリッドはある程度 Web よりもネイティブ エクスペリエンスに近いです

バージョン更新: Web はオンライン更新をサポートし、ネイティブは次のことを行う必要がありますレビューのために WeChat にパッケージ化する リリース

制御とセキュリティ: Web はページのコンテンツにジャンプしたり変更したりすることができますが、いくつかの制御できない要素とセキュリティ リスクがあります

ミニ プログラムのホスト環境は次のとおりです。 WeChat 純粋なクライアント ネイティブを使用する場合 ミニ プログラムを作成するテクノロジーを使用する場合、毎回ミニ プログラム コードを WeChat コードと一緒にリリースする必要があり、この方法は絶対に実現できません。

そのため、Web テクノロジーのように、クラウド上でいつでも更新できるリソース パッケージが必要となり、ローカルにダウンロードし、動的実行後にインターフェイスをレンダリングすることができます。純粋な Web テクノロジを使用して小さなプログラムをレンダリングする場合、一部の複雑な対話でパフォーマンスの問題に直面する可能性があります。これは、Web テクノロジでは、UI レンダリングと JavaScript スクリプトの実行が単一のスレッドで実行され、一部の論理タスクが簡単に発生する可能性があるためです。 UI レンダリング リソースを占有します。

そこで私たちは最終的に、この 2 つを組み合わせて小さなプログラムをレンダリングするハイブリッド技術を採用しました。Web に似た方法で開発でき、コードはオンラインで更新できます。同時にコンポーネントの導入も可能です。次のような利点もあります:

Web の機能を拡張します。たとえば、入力ボックス コンポーネント (入力、テキストエリア) には、キーボードをより適切に制御する機能があります。

エクスペリエンスが向上し、WebView のレンダリング作業も軽減されます。

setData のバイパス、データ通信レンダリング パフォーマンスを向上させるための再レンダリング プロセス

クライアント側のネイティブ レンダリングを使用していくつかの複雑なコンポーネントを組み込むと、パフォーマンスが向上します

2. デュアル スレッド モデル

アプレットのレンダリング層とロジック層はそれぞれ 2 つのスレッドによって管理されます。ビュー層インターフェイスはレンダリングに WebView を使用し、ロジック層は JsCore スレッドを使用して JS スクリプトを実行します。

では、なぜこのように設計されているのでしょうか? 制御とセキュリティについても前述しましたが、これらの問題を解決するには、開発者がブラウザのウィンドウ オブジェクト、ページのジャンプ、DOM の操作などを使用できないようにする必要があります。 、動的実行、スクリプト作成用のオープン インターフェイス。

クライアント システムの JavaScript エンジン、iOS では JavaScriptCore フレームワーク、Android では Tencent x5 カーネルによって提供される JsCore 環境を使用できます。

このサンドボックス環境は、ブラウザ関連のインターフェイスを持たない、純粋な JavaScript の解釈および実行環境のみを提供します。

これは、ミニ プログラムのデュアル スレッド モデルの起源です:

ロジック層: JavaScript を実行するための別のスレッドを作成します。ここには、ミニ プログラムのビジネス ロジックに関連するすべてのコードが含まれます。実行され、ロジックの処理、データ要求、インターフェイス呼び出しなどを担当します。

View レイヤー: インターフェイスのレンダリングに関連するすべてのタスクは WebView スレッドで実行され、どのインターフェイスがレンダリングされるかはロジック レイヤーを通じて制御されます。コード。小さなプログラムには複数のインターフェイスがあるため、ビュー層に複数の WebView スレッドが存在します。

JSBridge は上位レベルの開発とネイティブ (システム層) の間のブリッジとして機能し、小さなプログラムがネイティブ機能を使用できるようにします。一部のコンポーネントはネイティブ コンポーネントとして実装されているため、優れたエクスペリエンスが得られます

3. デュアル スレッド通信

開発者の JS ロジック コードを別のスレッドを実行しますが、Webview スレッドでは、開発者は DOM を直接操作できません。

インターフェイスを動的に変更するにはどうすればよいですか?

上図に示すように、論理層とビュー層の間の通信はネイティブ (WeChat クライアント) によって中継され、論理層から送信されたネットワーク リクエストもネイティブによって転送されます。

これは、単純なデータ通信を通じて DOM を更新できることを意味します。

仮想 DOM 皆さんはすでに理解していると思いますが、大まかなプロセスは次のとおりです: JS オブジェクトを使用して DOM ツリーをシミュレートする -> 2 つの仮想 DOM ツリーの違いを比較する -> 違いを実際の DOM ツリーに適用するDOM ツリー。

図に示すように:

WXML をレンダリング層の対応する JS オブジェクトに変換します。

データ変更が論理層で発生すると、データはホスト環境によって提供される setData メソッドを通じて論理層からネイティブに渡され、その後レンダリング層に転送されます。

前後の差分を比較した後、その差分を元の DOM ツリーに適用し、インターフェースを更新します。

WXML をデータに変換し、Native 経由で転送することで、ロジック層とレンダリング層の間の対話と通信を実現します。

このような完全なフレームワークをミニ プログラムの基本ライブラリから分離することはできません。

4. ミニ プログラムの基本ライブラリ

ミニ プログラムの基本ライブラリはビュー層とロジック層に注入して実行でき、主に次の側面に使用されます。

ビュー層では、インターフェイス要素を構築するためにさまざまなコンポーネントが提供されます

ロジック層では、さまざまなロジックを処理するためにさまざまな API が提供されます

データバインディングとコンポーネントシステム、イベントシステム、通信システム、および一連のフレームワークロジックの処理

アプレットのレンダリング層とロジック層は2つのスレッドで管理されるため、2つのスレッドにそれぞれ基本ライブラリが注入されます。

ミニ プログラムの基本ライブラリは、特定のミニ プログラムのコード パッケージにパッケージ化されるのではなく、事前に WeChat クライアントに組み込まれます。

これにより、次のことが可能になります。

ビジネス アプレットのコード パッケージ サイズを削減します。

ビジネス アプレットのコード パッケージを変更せずに、基本ライブラリのバグを個別に修正できます

5. Exparser フレームワーク

Exparser は、WeChat アプレットのコンポーネント構成フレームワークであり、アプレットの基本ライブラリに組み込まれており、WeChat アプレットのさまざまなコンポーネントの基本サポートを提供します。アプレット。組み込みコンポーネントやカスタム コンポーネントを含む、ミニ プログラム内のすべてのコンポーネントは、Exparser によって編成および管理されます。

Exparser の主な機能は次のとおりです:

Shadow DOM モデルに基づいています: このモデルは WebComponents の ShadowDOM によく似ていますが、依存しません。ブラウザのネイティブ サポート。他に依存するライブラリはありません。実装中に、小さなプログラム コンポーネントのプログラミングをサポートするために他の API が特別に追加されました。

純粋な JS 環境で実行可能: これは、ロジック層にも特定のコンポーネント ツリー構成機能があることを意味します。

効率的かつ軽量: 特に多数のコンポーネント インスタンスがある環境で優れたパフォーマンスを発揮し、コード サイズも小さくなります。

ミニ プログラムでは、WXML からページへの最終ノード ツリーの構築、createSelectorQuery の呼び出し、カスタム コンポーネントの特性など、ノード ツリー関連のすべての操作が Exparser に依存します。

組み込みコンポーネント

Exparser フレームワークに基づいたミニ プログラムには、ビュー コンテナ クラス、フォーム クラス、ナビゲーション クラスを提供する一連の組み込みコンポーネントがあります。 、メディアクラス、オープンクラスなど数十のコンポーネント。このような豊富なコンポーネントのセットと WXSS を組み合わせることで、あらゆる効果を備えたインターフェイスを構築できます。機能レベルでも、ほとんどのニーズを満たします。

6. 動作メカニズム

アプレットの起動には「コールドスタート」と「ホットスタート」の 2 つの状況があります。ユーザーが小さなプログラムを既に開いていて、一定期間内に再度開いた場合は、この時点で再起動する必要はありません。バックグラウンドにある小さなプログラムをフォアグラウンドに切り替えるだけです。このプロセスはホット スタートです。コールド スタートとは、ユーザーのミニ プログラムを初めて開くとき、または WeChat によってアクティブに破棄された後に再度開くとき、ミニ プログラムをリロードして開始する必要があることを指します。

ミニ プログラムを再起動するという概念はありません

ミニ プログラムがバックグラウンドに入ると、クライアントは一定期間実行状態を維持します。一定時間 (現在は 5 分) WeChat によって積極的に破棄されます

短期間 (5 秒) に 3 つ以上のシステム メモリ アラームを受信すると、ミニ プログラムは破棄されます

7. 更新メカニズム

コールド スタート中にミニ プログラムの新しいバージョンが見つかった場合、コード パッケージの新しいバージョンが非同期でダウンロードされ、クライアントのローカル パッケージで開始されます。つまり、新しいバージョンのミニ プログラムは次回まで待つ必要があり、コールド スタート後にのみ適用されます。最新バージョンをすぐに適用する必要がある場合は、wx.getUpdateManager API を使用して処理できます。

8. パフォーマンスの最適化

主な最適化戦略は 3 つのポイントに要約できます:

コードを合理化し、WXML 構造の複雑さを軽減します。および JS コード ;

setData 呼び出しを合理的に使用して、setData の数とデータ量を削減します;

必要に応じて、下請け最適化を使用します。

1. setData の仕組み

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

evaluateJavaScript の実行は多くの側面の影響を受けるため、ビュー層に到着するデータはリアルタイムではありません。

2. 一般的な setData 操作エラー

頻繁に setData 私たちが分析したいくつかのケースでは、いくつかの小さなプログラムが setData を非常に頻繁 (ミリ秒) に setData し、これにより 2 つの結果が生じます。 : Android 環境のユーザーはスライド時に引っかかりを感じ、操作のフィードバックが大幅に遅れます。JS スレッドがコンパイルとレンダリングを行っているため、ユーザーの操作イベントが時間内にロジック層に渡されず、ロジック層も操作処理の結果を返しません。ビュー層への配信が間に合わず、レンダリングに遅延が発生する WebView の JS スレッドが常にビジー状態であるため、ロジック層からページ層への通信時間が増加し、ビュー層が受信するデータメッセージが遅延する送信時から遅延します。数百ミリ秒が経過しており、レンダリング結果はリアルタイムではありません;

setData が大量の新しいデータを転送するたびに、基になる実装から確認できます。データ送信は実際にはevaluateJavascript

scriptプロセスであるsetData。データ量が多すぎると、スクリプトのコンパイルと実行時間が増加し、WebView JSスレッドを占有して、上でsetDataを実行します。バックグラウンド状態ページ。ページがバックグラウンド状態 (ユーザーには表示されない) になったとき、setData はバックグラウンド状態ページをユーザーにレンダリングし続けるべきではありません。それは理解できません。さらに、バックグラウンド ページの setData は、バックグラウンド状態ページの実行もプリエンプトします。前景ページ。

概要

この記事では、ミニ プログラムの起源から創発、設計、コミュニケーション、ライブラリ、Exparser フレームワーク、実行メカニズム、パフォーマンスの最適化などはすべて関連しており、相互に影響を与える選択です。小さなプログラムの基礎となるフレームワークの設計については、もっと多くのことが必要です。それぞれのフレームワークの誕生には、それぞれ独自の意味があります。開発者として私たちにできることは、このツールを使用するだけでなく、その設計パターンを理解することです。そうすることでのみ、ツールに影響されずにさらに前進することができます。

以上がミニプログラムの動作メカニズムの簡単な分析の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。