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

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

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

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

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

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

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

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

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

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

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

各タブ プロセスでは、ブラウザはさまざまなタスクを?qū)潖辘工毳攻欹氓嗓硕嗓筏蓼埂￥郡趣à?、GUI レンダリング スレッドは HTML をビジュアル UI にレンダリングする役割を果たし、JavaScript エンジン スレッドは解析と実行を擔(dān)當(dāng)します。 JavaScript コード。ロジック。タイミング トリガー スレッドは、setTimeout/setInterval タイマーなどの処理を擔(dān)當(dāng)します。

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

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

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

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

• 構(gòu)文は単純です;

• 操作メカニズムは単純です。

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

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

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

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

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

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

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

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

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

私が初めてミニ プログラム開発に觸れたとき、Web と比較して機(jī)能が弱いことがよく「嫌い」でした。単純にVueと比較したり、過剰な文法など。當(dāng)時、私はミニ プログラムが WeChat の膨大なユーザー數(shù)に依存した技術(shù)獨(dú)占であると感じていました。

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

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

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

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

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

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

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

したがって、iframe を使用する必要があるだけでなく、追加の JavaScript コンパイラーを?qū)毪工氡匾猡ⅳ辘蓼埂?/strong> CodePen は、それぞれのケースで JavaScript コードがスレッドセーフであることを確認(rèn)する必要があります。最も基本的なことは、プログラムが CodePen Web サイトの DOM を操作することを禁止することです。これを?qū)g現(xiàn)するには 2 つの方法があります: