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

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

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

開発の起源

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

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

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

WebView は、モバイル端末 (攜帯電話、IPad) が提供する JavaScript を?qū)g行するための環(huán)境です。システムが Web ページをレンダリングするためのコントロールです。ページ上の JavaScript と対話して、混合を?qū)g現(xiàn)できます。 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 データのオープン性。

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

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

ホスト環(huán)境

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

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

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

実行環(huán)境

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

操作メカニズム

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

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

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

注:

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

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

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

更新メカニズム

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

const updateManager = wx.getUpdateManager()
updateManager.onCheckForUpdate(function (res) {
  // 請求完新版本信息的回調(diào)
  console.log(res.hasUpdate)
})
updateManager.onUpdateReady(function () {
  wx.showModal({
    title: '更新提示',
    content: '新版本已經(jīng)準備好，是否重啟應用？',
    success(res) {
      if (res.confirm) {
        // 新的版本已經(jīng)下載好，調(diào)用 applyUpdate 應用新版本并重啟
        updateManager.applyUpdate()
      }
    }
  })
})
updateManager.onUpdateFailed(function () {
  // 新版本下載失敗
})

データ通信メカニズム

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

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

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

evaluateJavascript について:

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

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

ログイン メカニズム

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

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

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

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

UnionIDの仕組み説明

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

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

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

パフォーマンスの問題

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

setData() を頻繁に呼び出す

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

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

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

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

ページの複雑で多數(shù)の DOM 構造

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

JSCore

上で「ロジック層は JSCore で実行される」という文に疑問があると述べましたが、それは、ロジック層が実行される環(huán)境が表にリストされている必要があると見たからです。 . システム環(huán)境に応じて區(qū)別されますが、この文は一般的すぎますか？それともこの文章は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 で、內(nèi)部エンジンは JSCore です。

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

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

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

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

]

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