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

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

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 開発。

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

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: &#39;更新提示&#39;,
    content: &#39;新版本已经准备好，是否重启应用？&#39;,
    success(res) {
      if (res.confirm) {
        // 新的版本已经下载好，调用 applyUpdate 应用新版本并重启
        updateManager.applyUpdate()
      }
    }
  })
})
updateManager.onUpdateFailed(function () {
  // 新版本下载失败
})

ログイン後にコピー

データ通信メカニズム

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

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

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

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

evaluateJavascript について:

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

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

ログインメカニズム

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

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

図の主なプロセスは次のとおりです。目的は、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の状況について言及しているだけなので直接否定したわけではありません。

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