ミニプログラムでのデュアルスレッドモデルの詳細な分析-ミニプログラム開発-php.cn

この記事は、WeChat ミニプログラムのデュアルスレッドモデルを理解するのに役立ちます。ミニプログラムのデュアルスレッドモデルとは何ですか?アプレットがブラウザのスレッドモデルを使用せず、デュアルスレッドモデルを使用するのはなぜですか? 皆さんのお役に立てれば幸いです。

ミニプログラムでのデュアルスレッドモデルの詳細な分析

WeChat アプレット開発の経験がある友人なら、「デュアルスレッドモデル」の概念を知っているはずです。この記事では、デュアルスレッドモデルに関する一般的な科学知識を簡単にまとめます。 . 知識が浅いので、間違いがあればご指摘ください。

私は以前「ミニプログラム·クラウド開発」チームで働いていましたが、外部の研修や技術共有の場でよく次のような質問を受けました。「WeChat ミニプログラムと Web サイトの主な技術的な違いは何ですか?」プログラミング言語とパラダイムの観点から見ると、小規模なプログラム開発は Web フロントエンド開発と非常によく似ています (たとえば、どちらも JavaScript 言語、HTML/CSS によく似た WXML/WXSS などを使用します)。ネイティブフロントエンドテクノロジを直接使用しません。 [関連する学習の推奨事項: 小さなプログラム開発チュートリアル ]

Web Web サイトと比較して、WeChat でホストされる小規模なプログラムは、セキュリティ、パフォーマンス、その他の要素を考慮する必要があります。ミニプログラムは、WeChat アプリ自体にセキュリティリスクをもたらすことはなく、同時に、ネイティブアプリケーションにできるだけ近いパフォーマンスとユーザーエクスペリエンスを実現しようとします。これらは、小さなプログラムがブラウザのスレッドモデルを直接使用せず、独自にデュアルスレッドモデルを構築する必要がある主な 2 つの理由です。

それでは、小規模プログラムのデュアルスレッドモデルとは何でしょうか?

新しい概念やテクノロジを理解するための最良の方法は、リファレンスを提供することです。したがって、小さなプログラムのスレッドモデルを理解するには、まずブラウザのスレッドモデルをある程度理解する必要があります。。

ブラウザはマルチプロセスです

おそらく、すべてのフロントエンドエンジニアは、最初に業界に入ったときに面接官から「フロントエンドの単一スレッドをどのように理解していますか?」と何度か尋ねられたことがあります。スキルの一つであるJavaScript言語はシングルスレッドです。JSシングルスレッドの動作を完全に理解し、使いこなすことは、フロントエンドエンジニアにとって最も基本的な要件です。しかし、多くの初心者が陥りやすい誤解があります。それは、「JavaScript シングルスレッド」を「ブラウザシングルスレッド」と誤って理解することです。

実際、ブラウザの内部アーキテクチャは非常に複雑ですが、相互排他的でブロッキングな管理モデルを使用して、GUI レンダリングスレッドと JavaScript ロジックスクリプトスレッドを処理します。開発者は混乱し、誤解されています。

Chrome ブラウザを例に挙げると、右上隅にある設定ボタンをクリックし、「その他のツール」→「タスクマネージャー」と入力すると、次のようなポップアップウィンドウが表示されます。

Chrome がブラウザプロセス、ネットワークプロセス、GPU プロセスなどを含む複数のプロセスを開いていることがわかります。これらはすべて一般的なプロセスです。 注意してください, 上の図には 2 つのタブプロセスがあります。Chrome はタブページごとに独立したレンダリングプロセス (レンダラープロセス) を開き、各プロセス間のリソース (CPU、メモリなど) と動作を開きます。 (UI、ロジックなど) は相互に共有されないため、1 つのタブがクラッシュしても、他のタブには影響しません。

各タブプロセスでは、ブラウザはさまざまなタスクを対応するスレッドに渡します。たとえば、GUI レンダリングスレッドは HTML をビジュアル UI にレンダリングする役割を果たし、JavaScript エンジンスレッドは解析と実行を担当します。 JavaScript コード。ロジック。タイミングトリガースレッドは、setTimeout/setInterval タイマーなどの処理を担当します。

もう 1 つ、混乱しやすい場所があります。実際、setTimeout/setInterval は JavaScript 言語の一部ではなく、ランタイム (元々はブラウザー、後にノード) です。 .js もサポートしています) の機能を提供します。

GUI レンダリングスレッドと JavaScript エンジンスレッドは相互に排他的です。JavaScript は実行中に UI のレンダリングをブロックします。スクリプトの実行時間が長すぎる場合でも、ページはしばらく応答しなくなります。 GUI レンダリングスレッドと JavaScript エンジンスレッド間のこの相互排他的でブロック的なスレッド管理方法により、フロントエンド開発者の中にはブラウザがシングルスレッドであると考える人もいます。

では、なぜ JavaScript はシングルスレッドになるように設計されているのでしょうか?

JavaScript の創始者は、この言語を作成するのに 10 日しかかかりませんでした。彼の当初のアイデアは、ユーザーインタラクションや DOM 操作などを処理するために、ブラウザーにいくつかの単純なスクリプトロジックを提供することでした。

構文は単純です;
操作メカニズムは単純です。

構文の点では、JavaScript は Java から借用していますが、型宣言やモジュールシステム (後で追加) などの多くの複雑な設定が削除されています。

実行メカニズムに関して、JavaScript は Java のようなマルチスレッド機能を提供しません。主な理由は、マルチスレッドの DOM 操作によって引き起こされる UI の競合を回避するためです。たとえば、複数のスレッドが同じ DOM を同時に操作する場合、ブラウザは最終的な UI 効果を生成するためにどのスレッドが使用されるかをどのように決定すればよいでしょうか?これは古典的なスレッドセーフティ (スレッド同期とも呼ばれます) の問題です。マルチスレッドプログラミングの分野には、ロックメカニズムの追加など、多くの解決策がありますが、これはシンプルで使いやすい設計とは異なり、より複雑になります。 JavaScript の本来の意図に反します。

これは、GUI レンダリングスレッドと JavaScript エンジンスレッドが相互に排他的である理由も説明しています。JavaScript コードには、DOM を変更する権限があります。

JavaScript コードが実行されると、GUI レンダリングスレッドは一時停止され、JavaScript エンジンスレッドがアイドル状態になるまで待機してから実行されます。これにより、レンダリング中に JavaScript による DOM の繰り返し変更によって引き起こされる不要なレンダリングのプレッシャーが回避されます。相互排他モードを使用して JavaScript コードの実行が完了するのを待機すると、レンダリングが最終的な実行結果になるようにできます。したがって、ブラウザのアイドル時間も、Web サイトのパフォーマンスを測定するための重要な指標の 1 つになっています。アイドル時間は主に、JavaScript ロジックが集中的ではなく、DOM 変更の頻度が低いことを示します。この場合、ブラウザはユーザーインタラクションに応答できます。

#React Fiber はアイドル時間を使用してシャーディングタスクを処理します。

その後、HTML5 では、複数のスレッドで JavaScript コードを実行できる機能を提供する Web ワーカーが導入されました。ただし、他のプログラミング言語とは異なり、ワーカースレッドはメインスレッドと並列ではなく、メインスレッドです。 . スレーブ (マスター/スレーブ) マルチスレッドモデル。

ワーカー内の JavaScript コードは DOM を操作できないため、スレッドセーフとして理解できます。 これは、後で説明する小規模プログラムのデュアルスレッドモデルの重要な基礎であることを覚えておいてください。

では、なぜ WeChat アプレットはブラウザのスレッドモデルを直接使用しないのでしょうか?そのためには、ミニプログラムと Web サイトの違いを製品と技術の両方の観点から比較する必要があります。

なぜミニプログラムはブラウザのスレッドモデルを使用しないのですか?

私が初めてミニプログラム開発に触れたとき、Web と比較して機能が弱いことがよく「嫌い」でした。単純にVueと比較したり、過剰な文法など。当時、私はミニプログラムが WeChat の膨大なユーザー数に依存した技術独占であると感じていました。

しかし、技術や製品を深く理解し続けるにつれて、ミニプログラムに対する私の態度も「嫌い」から「賞賛」に変わりました。なぜなら、ミニプログラムの製品ポジショニングを十分に理解した後、 デュアルスレッドモデルは、小規模プログラムなどの製品シナリオにおける最適なソリューション です。では、ミニプログラムとはどのような製品なのでしょうか？

ミニプログラムのホストは WeChat ですが、ミニプログラムのバージョンの反復は独立しており、アップグレードや更新はホストに依存せず、これは Web ウェブサイトと同じです。言い換えれば、ミニプログラムは Web の利点の一部を継承していますが、Web ではありません。現在、Web 関連テクノロジは非常に包括的であり、3D マップ、ゲームなどの非常に大規模なアプリケーションをホストできます。

ミニプログラムは、小さく、美しく、使い終わったら消えるという位置づけであり、WeChat の Web 機能をすべて追求しているわけではないため、Web に比べて性能的には明らかに劣ります。同時に、WeChat によって提供されるネイティブ機能の一部 (ネイティブコンポーネント、システムレベル、WeChat エコシステム API など) も備えています。

また、「ミニプログラム-WeChat」の関係は「ウェブサイト-ブラウザ」の関係とは異なり、前者のほうがCodePenやJSFiddlerなどのオンラインプログラミングプラットフォームにおける各プログラムのケースに近いです(参考) as platform in class) (ケースと呼びます) とプラットフォームの関係。

技術的な観点から見ると、プラットフォームの中心的な考慮事項の 1 つは、ケースに十分な機能を提供することです。 ケースのロジックがプラットフォームのセキュリティを危険にさらさないようにするためです。 。 CodePen 上で CodePen の個人情報を取得するプログラムを作成できたら、おそらく次の日 CodePen がクラッシュして従業員全員が解雇されることを想像してください。

このようなプロダクトトーンの下でテクノロジーの選択が行われると、次のステップはアーキテクトとプログラマーの作業になります。

CodePen を例に挙げますが、そのようなプログラミングプラットフォームの設計を依頼された場合、どのようなテクノロジを使用しますか? iframe 内ですべての Web 機能を使用できるため、最初に iframe を使用することを考えるかもしれません。実際、CodePen はプログラム効果を表現するために iframe を使用しますが、入力された JavaScript コードを実行のために iframe に完全にコピーするわけではなく、コードは iframe に挿入される前にコンパイルプロセスを経ます。この開始点は主にセキュリティ上の考慮事項に基づいており、コンパイルプロセス中にいくつかの危険なコードを削除します。次に、これにより、プラットフォームで typescript などのより多くの言語をサポートすることもできます。もちろんパフォーマンスの問題もありますが、パフォーマンスの問題は iframe に関する一般的な問題なので、詳細については説明しません。

したがって、iframe を使用する必要があるだけでなく、追加の JavaScript コンパイラーを導入する必要もあります。 CodePen は、それぞれのケースで JavaScript コードがスレッドセーフであることを確認する必要があります。最も基本的なことは、プログラムが CodePen Web サイトの DOM を操作することを禁止することです。これを実現するには 2 つの方法があります:

1 つは Web Worker;
もう 1 つは Shadow DOM を使用することです。

Web Worker はスレッドセーフです。Worker 内の JavaScript コードは Window オブジェクトと Document オブジェクトを取得できないため、DOM を操作できません。さらに、ワーカーのスレッドセーフ機能により、ワーカー内のコードは実行中に外部の GUI レンダリングスレッドをブロックせず、これら 2 つは並行して実行できます。

Shadow DOM は Web コンポーネント仕様の一部です。ShadowRoot のモードを closed に設定すると、ShadowRoot ノードが取得できなくなり、内部 DOM を操作できなくなります。

この 2 つと比較すると、Shadow DOM の互換性は Web Worker よりも悪く、大規模な利用の時期にはまだ遠いため、Web Worker ソリューションの方が現実的です。

これは単純な 2 スレッドモデルを形成します。ワーカースレッドは計算を担当し、結果を postMessage を通じてメインスレッドに渡し、メインスレッドはレンダリングを担当します。

ただし、このモデルには深刻なパフォーマンスの問題があります。Web ワーカーは非常にリソースを消費します。コンピューティングの消費に加えて、メインスレッドとの通信プロセスにも非常に深刻な問題があります。パフォーマンスへの影響。

では、パフォーマンスを考慮し、優れたユーザーエクスペリエンスを確保しながら、Web Worker と同じスレッドセーフを実現する方法はあるのでしょうか?これが、WeChat アプレットにデュアルスレッドモデルを使用する主な目的です。

安全で効率的なデュアルスレッドモデル

先ほど CodePen などのプログラミングプラットフォームを例えとして使用しましたが、小規模プログラムと CodePen の技術要件はまったく同じではありません。主な違いは次のとおりです。すべての HTML タグをサポートし、限られた数の UI コンポーネントのみを提供する必要があるミニプログラムの製品位置付けに従って、ミニプログラムの主な技術要件を次のように要約できます。 (新しいテクノロジやアーキテクチャは、特定の問題を解決するように設計されているため、アプレットの主な技術要件を理解する必要があります。)

UI コンポーネントタイプを制限して、許可するもののみを指定します。指定する宣言

アプレットは、コンポーネントの宣言時にネイティブ HTML タグを使用しませんが、WeChat が提供するいくつかの組み込みの基本コンポーネントのみを使用できます。もちろん、コンポーネントをカスタマイズすることもできます, しかし、それは、組み込みの基本コンポーネントの組み合わせによっても実現されます。
論理スレッドの安全性を確保し、UI コンポーネントの直接操作を許可しない

ミニプログラムが UI を更新する方法は、 Vue/React などの MVVM フレームワークでは、JavaScript コードで DOM を直接操作することはできませんが (ちなみに、実際にはアプレットに DOM の概念はありません)、状態を更新する (setState) ことで UI を非同期に更新します。 VDOM と効率的な diff アルゴリズムが使用されます (この 2 つの点は私たちが議論したいことではありません。関連する情報は授業後に検索できます)。
WeChat に依存せずにオンラインで更新可能

ミニプログラムのホストは WeChat であり、純粋なネイティブを使用して実装されている場合は、ミニプログラムのバージョンが更新されます。WeChat に依存して、WeChat コードとともにバージョンをリリースする必要がありますが、これは絶対に不可能です。純粋な Web 実装の場合、セキュリティとパフォーマンスを保証するのは困難です。

ミニプログラムは、Web などのクラウドでリソースをホストし、独立して更新できる必要があると同時に、十分なセキュリティとパフォーマンスを確保できる必要があります。したがって、最終的に、アプレットは混合アーキテクチャモデルを採用しました: Webview を使用して UI をレンダリングし、Web ワーカーと同様の独立したスレッドを使用してロジックを実行します。これはデュアルスレッドモデルです。
ユーザーエクスペリエンスを確保するには、パフォーマンスを可能な限り改善する必要があります。
シンプルなデュアルスレッドモデルベースのパフォーマンス大きな問題は、ミニプログラムのデュアルスレッドモデルが Web Worker のサブスレッドではなく、独立した「メインスレッド」を使用するため、比較的良好なパフォーマンスが保証されることです。

レンダリングスレッドとロジックスレッド

アプレットのデュアルスレッドは、レンダリングスレッドとロジックスレッドを指します。これら 2 つのスレッドは、UI のレンダリングと実行を担当します。 JavaScript コードがそれぞれ動作します。次の図に示すように:

#レンダリングスレッドは Webview を使用して UI をレンダリングします。 Webview は、JavaScript を実行する機能を備えた完全なブラウザに似たオペレーティング環境です。ただし、アプレットはロジックスクリプトを Webview に入れて実行するのではなく、クライアントを使用して JavaScript を提供するためにロジック層を Webview と並行したスレッドに分離します。エンジンはコード、iOS の JavaScriptCore、Android の JsCore 環境、および Tencent の X5 カーネルによって提供される nwjs IDE ツールを実行します。

論理スレッドは JavaScript のみを実行できるサンドボックス環境です。DOM 操作に関する API は提供されていないため、UI を直接操作することはできません。setData を介してデータを更新することによって UI を非同期的に更新することしかできません。

イベントドリブンの通信方式

上図のレンダリングスレッドとロジックスレッド間の通信方式に注目してください。、アプレットレンダリング層とロジック層の間の通信は、両者の間でデータやイベントを直接転送しませんが、は仲介者としてネイティブによって転送されます。

プロセス全体は典型的なイベント駆動型モデルです:

レンダリング層 (ビュー層とも呼ばれます) は、インタラクションを通じて特定のイベントをトリガーします。イベント;
イベントはロジック層に渡されます;
ロジック層は一連のロジック処理を渡します、データリクエスト、インターフェイスの呼び出しやその他のアクションにより、処理されたデータがレンダリングレイヤに渡されます。
#最終レンダリングレイヤは、データをビジュアル UI にレンダリングします。

このデータ駆動型 UI モデルは、現在、フロントエンドプログラミングの分野でより尊敬されているプログラミングパラダイムです。5 年以上の開発経験を持つフロントエンド開発者であれば、 , それから、このモデルに触れるとき、最初は多少の違和感があるはずだと思います。なぜなら、これ以前は、DOM の JavaScript 操作はほぼ「業界のルール」だったからです。入門用の本、ブログ、教科書もたくさんあります。 DOM 操作から始まるフロントエンドですが、今では確かに少し時代遅れになっているようです。

ロジックとレンダリングを分離するこのスレッド分割モードにより、論理スレッドサンドボックスで実行される JavaScript コードがスレッドセーフであることが保証される一方で、レンダリングスレッドの計算量が増加するため、が非常に小さいため、ユーザーインタラクション動作に対する迅速な応答によりユーザーエクスペリエンスが向上します。

一般に、ブラウザのスレッドモデルと比較して、ミニプログラムのデュアルスレッドモデルは、Web ワーカーと同じスレッドセーフを実現しながら、Web ワーカーの懸念されるパフォーマンスを解決または回避します。パフォーマンスとセキュリティの両方の観点から。 デュアルスレッドモードは、ブラウザの既存のプロセスとスレッド管理モデルによって制限される小規模プログラムの特定のシナリオ内で改善されたアーキテクチャソリューションであると要約できます。

要約

私の意見では、プログラマーの中核的な能力と競争力は、特定の言語やフレームワークの API を完全に理解することではなく、これらの言語の基礎となる原則を知ることであり、フレームワーク。小規模なプログラム開発者にとって、仕事で技術的な問題が発生したときの解決策は、多くの場合、基礎となる原則に基づいています (さらに単純に言えば、就職面接を探しているときに、小規模なプログラムの構文について質問する人は誰もいません)。

ミニプログラムのデュアルスレッドモデルの背景、設計、通信を理解することで、皆さんがミニプログラムの基礎となるアーキテクチャをより深く理解できることを願っています。後続の作業で同様のシナリオが必要な場合。もちろん、小規模プログラムのデュアルスレッドモデルを理解することが唯一の目標ではありません。この知識は、主にパフォーマンスの観点から、ある程度、日常の開発作業にインスピレーションを与えることができます。 ##機能性確保を前提にシンプルな構造のUIを使用することを心がける;