WeChat ミニプログラムアーキテクチャの基本原理の詳細な説明

この記事では、WeChat ミニ プログラム に関する関連事項を紹介します。主に、ホスト環境、実行環境、ミニ プログラムの全体構造、動作など、基本的なアーキテクチャ原則に関する関連コンテンツを紹介します。仕組み、アップデートの仕組み、データ通信の仕組みなどを一緒に見ていきましょう。

[関連する学習の推奨事項: ミニ プログラム学習チュートリアル ]

次の図は、WeChat ミニ プログラムの全体的なアーキテクチャを示しています。

開発の起源

まず、WeChat ミニ プログラムの開発の歴史について簡単に説明しますが、自分と敵を知ることによってのみ、すべての戦いに勝つことができます。 WeChat ミニ プログラムはミニ プログラムと呼ばれます。 Zhang Xiaolong 氏は、2017 年 1 月 9 日に WeChat オープンクラスで正式な立ち上げを発表しました。ミニプログラムの英語名は Mini Program で、スキャンや検索でアプリケーションを開くことができ、「すぐにアプリケーションが使える」という夢を実現する、ダウンロードやインストールが不要なアプリケーションです。

ミニ プログラムの開始以来、このアプリはポータブル版 APP と呼ばれています。この 2 つの違いは、ミニ プログラムは比較的軽量で、開発コストが低く、開発サイクルが短く、結果が早いことです。 。

ミニ プログラムは何もないところから生まれた概念ではなく、WeChat の WebView が徐々にモバイル Web への重要な入り口になったとき、WeChat には関連する JS API がありました。

WebView は、モバイル端末 (携帯電話、IPad) が提供する JavaScript を実行するための環境です。システムが Web ページをレンダリングするためのコントロールです。ページ上の JavaScript と対話して、混合を実現できます。 APP と Web の開発 WebView の Web ページのレンダリングには、強力なレンダリング カーネルのサポートが必要ですが、Android と IOS システムのカーネルは異なります。

私の理解によれば、ミニ プログラム誕生の主な原動力は、WeChat でのコミュニケーション エクスペリエンスの貧弱さとモバイル Web ページの機能の弱さです。ネイティブAPPの欠点、それぞれのデメリットなど 毎回App Storeや他のアプリケーションマーケットからダウンロードする必要がある ダウンロードしてもシステム上の容量を多く消費する多くの場合、ユーザーによって削除される可能性が非常に高くなります。

ネイティブ APP の問題は脇に置き、WeChat での通信体験の貧弱さとモバイル Web ページの能力の低さの問題については、後に WeChat チームがモバイル Web ページの不十分な問題を解決するために JS-SDK を立ち上げましたが、しかし、JS-SDK モデルでは、モバイル Web ページを使用する際のエクスペリエンス低下の問題は解決できません。その理由は、白い画面の問題、ページ切り替えの固さ、クリックの遅延の 3 つの点に要約できます。

これらの問題を解決するために、WeChat チームが直面している問題は、すべての開発者が WeChat でより良いエクスペリエンスを得ることができるように、より良いシステムを設計する方法です。この問題は以前の JS-SDK では処理できず、これを完了するには新しいシステムが必要であり、すべての開発者が次のことを達成できるようにする必要があります:

• 高速読み込み。

• #さらに強力な能力。

• ネイティブの経験。

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

• 効率的でシンプルな開発。

これがミニプログラムの起源です。ドキュメント

ホスト環境

WeChat アプレットのホスティング環境は WeChat クライアントです。これは WeChat クライアントでの実行に依存し、アプレットの基本ライブラリのバージョンと重要な関係があります。 。

WeChat クライアントとミニ プログラム基本ライブラリを WeChat ミニ プログラムのホスティング環境として参照できます。

WeChat ミニ プログラムは、ホスト環境によって提供される WeChat クライアントの機能を呼び出すことができ、通常の Web ページでは実行できない多くの機能を実行できるため、ミニ プログラムは通常の Web ページよりも多くの機能を備えています。ミニ プログラムは異なるバージョンのホスト環境 (異なる WeChat クライアントと異なる基本ライブラリ) で実行されるため、プログラムをホスト環境の各バージョンと互換性を持たせることが避けられません。

実行環境

小規模プログラムの主な開発言語は Javascript です。これは従来の Web 開発に似ていますが、いくつかの違いがあります。

• Web ページの開発、レンダリング スレッド、およびスクリプトは相互に排他的であるため、長時間スクリプトを実行するとページの応答が失われる可能性があります。本質的には、JS はシングルスレッドであるとよく言われることです。

• ミニプログラムではビュー層とロジック層を分けて2つのスレッドを同時に実行しており、ビュー層のインターフェースはWebViewで描画し、ロジック層はレイヤーは JSCore で実行されます。

• Web 開発では主にさまざまなメーカーのブラウザを扱いますが、モバイル側では、Safari、Chrome、iOS、Android システムのさまざまな WebView も扱う必要があります。

• ミニ プログラムは、主に 2 つの主要なオペレーティング システム IOS と Android の WeChat クライアント、開発ツール、PC (ウィンドウ)、Mac で使用されます。開発時には、WeChat クライアントのバージョン番号と、ミニ プログラム API がサポートする基本ライブラリのバージョン番号に注意する必要があります。

WeChat アプレットは複数のプラットフォームで実行されます: iOS (iPhone/iPad) WeChat クライアント、Android WeChat クライアント、PC WeChat クライアント、Mac WeChat クライアント、およびデバッグ ツール用 WeChat 開発。

各プラットフォームのスクリプト実行環境と非ネイティブコンポーネントのレンダリングに使用される環境は異なります。具体的な違いは次のとおりです:

全体構造ミニプログラムの概要

上記の内容を通じて、ミニプログラムの誕生と環境についておおよそ理解していただけたかと思いますが、ここからはミニプログラムの全体的な設計構造について説明していきます。

ミニ プログラム システム アーキテクチャ全体は、ビュー層 (WebView) とロジック層 (App Service) の 2 つの部分に分かれており、これら 2 つの部分は 2 つの独立したスレッドによって管理されます。

• ビュー レイヤー: レンダリング レイヤーとも呼ばれ、レンダリング レイヤーはページ構造をレンダリングするために使用され、主に WebView によってレンダリングされます。小さなプログラムには複数のインターフェイスを持つことができるため、複数のインターフェイスが存在する場合があります。レンダリングレイヤー WebView スレッド。

• 論理層: 論理層は JSCore スレッドを使用して JS スクリプトを実行します。ロジック層は主にロジック処理、データリクエスト、インターフェース呼び出しなどに使用されます。

ビュー レイヤーとロジック レイヤー間の通信には、システム レイヤー (WeixinJsBridage) を使用する必要があります。ロジック レイヤーは、データの変更をビュー レイヤーに通知し、ビュー レイヤーのページ更新をトリガーします。ビュー層 ビジネスロジック処理のために、トリガーされたイベントをロジック層に通知します。

ページ レンダリングの一般的なプロセスは次のとおりです: プロジェクトをコンパイルするとき、WXML を対応する JS オブジェクト (仮想 DOM) に変換します。論理レイヤーでデータが変更されるときは、 setData() メソッド データをロジック層からビュー層に渡します。データを受信した後、ビュー層は内部で差異を比較し、その差異を元の Dom ツリーに適用してから、UI インターフェイスを正しくレンダリングしてページを完成させます。レンダリングプロセス。

上記の分析を通じて、最初に配置されたアーキテクチャ図を理解できましたか?

上記の分析では、一般に JSBridge と呼ばれるシステム層 (WeixinJsBridage) についても言及しています。中間の橋の役割を果たしており、非常に重要です。これにより、ビュー層とロジック層の 2 つの別個のスレッドが通信できるようになるだけでなく、上位レベルの開発と基盤となるシステム関数 (ネイティブ) の間にブリッジが構築され、小規模なプログラムが API を呼び出してネイティブ関数を使用できるようになります。コンポーネントはネイティブ コンポーネントを使用して実装されるため、優れたエクスペリエンスが得られます。

論理層には、ネットワーク リクエストを送信するという重要な操作もあります。ネットワーク リクエストはシステム層を通じて転送されます。

ここまでで、ミニ プログラムの全体的な構造についてはある程度理解していただけたと思いますが、まず、ミニ プログラムの内部メカニズムのいくつかについて話しましょう。

操作メカニズム

ミニ プログラムの開始と実行には 2 つの状況があります:

• コールド スタート (再起動): ユーザーがミニ プログラムを開きます。初めての場合、またはミニ プログラムが WeChat によってアクティブにアクティブ化された場合、破壊された後に再度開くと、アプレットをリロードして起動する必要があります。これはコールド スタートです。

• ホット スタート: ユーザーが既にアプレットを開いているため、一定時間内に再度アプレットを開きます。この時点では再起動する必要はなく、切り替えるだけで済みます。バックグラウンドのアプレットをフォアグラウンドに移動する、このプロセスはホット スタートです。

注:

1. ミニ プログラムには再起動の概念がありません。

2. ミニ プログラムがバックグラウンドに入ると、クライアントは一定期間実行状態を維持し、一定時間が経過すると WeChat によってアクティブに破棄されます。

3. システムが短期間に 3 つ以上のメモリ警告を受信した場合、アプレットは破棄されます。これが、ページ メモリがオーバーフローするとページがクラッシュする根本的な理由です。

更新メカニズム

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

const updateManager = wx.getUpdateManager()
updateManager.onCheckForUpdate(function (res) {
  // 请求完新版本信息的回调
  console.log(res.hasUpdate)
})
updateManager.onUpdateReady(function () {
  wx.showModal({
    title: '更新提示',
    content: '新版本已经准备好，是否重启应用？',
    success(res) {
      if (res.confirm) {
        // 新的版本已经下载好，调用 applyUpdate 应用新版本并重启
        updateManager.applyUpdate()
      }
    }
  })
})
updateManager.onUpdateFailed(function () {
  // 新版本下载失败
})

データ通信メカニズム

アプレットはデュアル スレッドに基づいていると前述しました。これは、ビュー層とロジック層の間のあらゆるデータ転送を意味します。これはすべて通信です。これは、一定の遅延が発生することを意味します。これは、ページを更新する必要があるときに、関連する API を呼び出して同期的にレンダリングできる従来の Web とは異なりますが、ミニ プログラム アーキテクチャでは、これはすべて非同期操作です。

非同期では、各部分の実行タイミングがより複雑になります。例えば、最初の画面を描画する際、ロジック層とレンダリング層は同時に初期化作業を開始しますが、レンダリング層はインターフェースを描画するためにロジック層からのデータを必要とするため、レンダリング層の初期化作業が早く完了すると、ロジック層からの指示を待つ必要があり、それができて初めて次のステップに進むことができます。したがって、ロジック層とレンダリング層には正しいタイミングを確保するための特定のメカニズムが必要であり、各ミニプログラム ページのライフ サイクル中に複数のページ データ通信が行われます。

ビュー層とロジック層の間の具体的な通信プロセスを理解した後、ビュー層とロジック層の間のデータ送信についても少し理解しました。この 2 つの間の通信は、次の関数に依存していることがわかります。システム層ですが、実際には、両側から提供されるevaluateJavascriptを通じて実装されます。つまり、ユーザーが送信したデータを文字列に変換して渡す必要があるのと同時に、変換されたデータ内容をJSスクリプトにつなぎ合わせて、実行することで両側の独立した環境に渡します。 JSスクリプト。

evaluateJavascript について:

ネイティブは JS を呼び出します。通常は直接 JS コード文字列を呼び出します。これは、JS で eval を呼び出してコード文字列を実行する方法と似ています。通常、loadUrl や EvaluateJavascript などのいくつかのメソッドがあります。

ここではあまり詳しく説明しませんが、JS 文字列の呼び出しと実行に使用され、ネイティブが JS コードを識別する方法であることを覚えておいてください。

ログイン メカニズム

小さなプログラムを作成したことのある人は、この図に精通しているはずです。

図の主なプロセスは次のとおりです。目的は、WeChat ユーザーの一意の openid と session_key を取得することです。その後、開発者サーバーは、ユーザー ID に基づいてカスタム ログイン状態を生成し、後続のフロントエンドおよびバックエンドの対話中にユーザーの ID を識別するために使用できます。ビジネスの論理。

• wx.login() を呼び出して一時的なログイン資格情報コードを取得し、開発者サーバーに送り返します。

• ユーザーの一意の識別子 openid と引き換えに、auth.code2Session インターフェイスを呼び出します。WeChat オープン プラットフォーム アカウントにあるユーザーの一意の識別子 UnionID (現在のミニ プログラムが WeChat にバインドされている場合)オープンプラットフォームアカウント）とセッションキー session_key。

UnionIDの仕組み説明

UnionIDはWeChatが少し前に新しく追加したプロパティで、取得方法もopenidと同様で、機能も同様です。ユーザーの一意の識別に限定されますが、それはもう少し広いものです。

公式説明: 開発者が複数のモバイル アプリケーション、Web サイト アプリケーション、およびパブリック アカウント (ミニ プログラムを含む) を持っている場合、同じ WeChat である限り、UnionID を使用してユーザーの一意性を区別できます。モバイル アプリケーション、Web サイト アプリケーション、およびプラットフォーム アカウントに基づくパブリック アカウント (ミニ プログラムを含む) の場合、ユーザーの UnionID は一意です。つまり、同じユーザーの場合、同じ WeChat オープン プラットフォーム上の異なるアプリケーションでも UnionID は同じになります。

知らないですか?率直に言うと、ミニ プログラムを WeChat オープン プラットフォーム アカウントにバインドした後、そのアカウントにバインドされている他のモバイル アプリケーション、Web サイト アプリケーション、パブリック アカウントに接続できます。例：同一ユーザーがPC上でスキャンしてログインし、WeChat公式アカウントで開発したページを認証し、WeChatアプレットを認証する場合、同一ユーザーであることが識別でき、取得したUnionIDは同じ。ポータル

パフォーマンスの問題

ミニ プログラムのアーキテクチャ原則を学習した後、基礎となるアーキテクチャの観点から、一般的なミニ プログラムのパフォーマンスの問題がどのように発生するかを簡単に分析してみましょう。

setData() を頻繁に呼び出す

setData() を頻繁に呼び出すことは、タイマーでの呼び出しなど、非常に一般的な問題であると考えられます。 、ページのスクロールを監視するフックで呼び出されます。これらのシナリオでは、ページのフリーズやタイミングの悪いページ データの更新など、ミニ プログラムのパフォーマンスの問題が簡単に発生する可能性があります。

データ通信メカニズムのところで、ミニ プログラムがデュアル スレッドに基づいていると述べました。これは、ビュー層とロジック層の間のデータ転送はすべてスレッド間の通信であり、setData( ) はスレッドをビジー状態に保ち、ロジック層がビュー層に通知するのに時間がかかります。ビュー層がメッセージを受信すると、メッセージが送信されてから一定の時間が経過している可能性があり、ページのレンダリングが行われます。間に合わないです。

膨大な量のデータは setData() を呼び出します

以前のデータ通信メカニズムでも、送信されるデータは次のようにする必要があると述べました。文字列に変換された形で渡され、JSスクリプトの形で実行されますが、データ量が多いとスクリプトを実行する際のコンパイル時間や実行時間も長くなり、スレッドを占有します。

ページの複雑で多数の DOM 構造

ページに複雑で非常に大規模な DOM 構造がある場合、必然的に遅延が発生します。ページの表示が滞り、ページがクラッシュする可能性もあります。その理由は想像できます。DOM の描画と計算に時間がかかり、スレッド遷移が機能し、クライアントのメモリ使用量が増加します。が上昇し、システムがミニ プログラム ページをリサイクルするようにトリガーされます。

JSCore

上で「ロジック層は JSCore で実行される」という文に疑問があると述べましたが、それは、ロジック層が実行される環境が表にリストされている必要があると見たからです。 . システム環境に応じて区別されますが、この文は一般的すぎますか？それともこの文章はiOSの状況を指しているのでしょうか？公式ドキュメントに書いてあることなので、間違って書かれている、あるいはIOSの状況について言及しているだけなので直接否定したわけではありません。

検証の結果、この文には問題がないことが確認されましたが、その結果の過程を追跡するには、ブラウザの一般的な状況について記述する必要があります:

ブラウザの中核となる部分はブラウザ カーネルであり、各ブラウザには独自のカーネルがありますが、モバイル分野に最も大きな影響を与えるのは WebKit です。

WebKit はページレンダリングおよびロジック処理エンジンであり、HTML/CSS/JavaScript が処理され、表示および操作可能な Web ページになります。

WebKit はいくつかの重要なモジュールで構成されており、全体的な構造は次のとおりです:

WebKit は 4 つの部分で構成されています。

#WebKit Embedding API: ブラウザ UI と WebKit の間の対話を担当します。
プラットフォーム API (WebKit ポート): WebKit をさまざまなオペレーティング システムやプラットフォームに移植しやすくし、ネイティブ ライブラリを呼び出すためのいくつかのインターフェイスを提供します。
WebCore: WebKit 全体のコア レンダリング エンジン。
JavascriptCore: JSCore は WebKit のデフォルトの組み込み JS エンジンであり、C を使用して Apple によって開発されました。
JSCore 部分に注目しましょう。JSCore は、WebKit のデフォルトの組み込み JS エンジンです。WebKit ブランチに基づいて開発された多くのブラウザ エンジンが、WebKit ブランチに基づいて開発されているため、デフォルトで組み込まれていると言われています。独自の JS エンジン。最も有名なのは Chrome の V8 エンジンです。

V8 エンジンは、フロントエンドの友人にはよく知られていると思いますが、WebKit ベースなので、最下層にもデフォルトで JSCore が埋め込まれており、Android のロジック層は V8 上で動作します。

IOS のブラウザ エンジンは WebKit で、内部エンジンは JSCore です。

最後に、開発ツールのロジック層は NW.js 上で実行されます。公式 Web サイトにアクセスして次の段落を参照してください:

私はそうすべきだと信じていますWebKitとも関係があります。

[関連する学習の推奨事項:

小プログラム学習チュートリアル

]

以上がWeChat ミニプログラムアーキテクチャの基本原理の詳細な説明の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。