ミニプログラム開発の原則は何ですか?

ミニ プログラムは、HTML、CSS、JS を使用した、WEB 仕様に基づいたフレームワークのセットです。WeChat では公式に、WXML、WXSS という非常にクールな名前を付けていますが、本質的には、依然として WEB システム全体の下に構築されています。

WXML、個人的には WeChat の Xml に名前が付けられたのではないかと推測していますが、結局のところ、これは XML のサブセットです。

WXML は、WeChat 自体によって定義された少数のタグ WXSS を使用します。これは誰もが独自に定義した CSS として理解できます。ロジック部分を実装するJSはまだ一般的なES仕様です。また、ランタイムは依然として Webview (IOS WKWEBVIEW、ANDROID X5) です。

小プログラム

小プログラム フォルダー構造

完全な小さなプログラムプログラムは主に次の部分で構成されます。

エントリ ファイル: app.js

グローバル スタイル: app.wxss

グローバル設定: app.json

ページ: ページの下。各ページはフォルダーに分かれています。 1 ページあたり 4 ファイル

ビュー: wxml、wxss

ロジック: js。 json (ページ構成、必須ではありません)

注: ページは、モジュールに基づいてサブフォルダーと孫フォルダーに分割することもできます。 app.json に登録するときにパスを入力するだけです。

ミニプログラムのパッケージ化

開発完了後。ここでボタンを視覚化できます。クリックすると直接パッケージ化され、公開用にアップロードされます。レビューに合格した後、ユーザーは検索できるようになります。

関連する推奨事項: 「WeChat ミニ プログラム 」

それでは、パッケージ化はどのように実装されるのでしょうか?

これには、このエディタの実装原理と実装方法が含まれます。それ自体も WEB テクノロジー システムに基づいて実装されており、nwjs React、nwjs とは: 簡単に言うと、ノード Web キットであり、ノードはローカル API 機能を提供し、Web キットは Web 機能を提供します。 JS HTML を使用してネイティブ アプリケーションを実装します。

nodejsがあるので、上記のパッケージ化オプションの機能を簡単に実現できます。

ES6 ～ ES5: babel-core のノード パッケージの導入

CSS 補完: postcss と autoprefixer のノード パッケージの導入 (postcss と autoprefixer の原理についてはこちらを参照)

コード圧縮: uglifyjs のノード パッケージを導入します。

##注: Android では x5 カーネルが使用されます。 ES6のサポートは良くありません。互換性を保つには、ES5 構文を使用するか、babel-polyfill 互換性ライブラリを導入します。

パッケージ化されたフォルダー構造

ミニ プログラムのパッケージ化された構造は次のとおりです:

すべてのミニ プログラム基本的には、最終的に上記の構造

1. WAService.js フレームワーク JS ライブラリに入力されます。ロジック レイヤー

2 (WAWebview.js フレームワーク JS ライブラリ) に基本的な API 機能を提供し、ビュー レイヤー

3 (WAConsole.js フレームワーク JS ライブラリ) に基本的な API 機能を提供します。コンソール

4、app-config.js アプレットの構成を完了します。 app.json で渡したすべての設定を、デフォルトの設定タイプ

5、app-service.js、および独自の JS コードと組み合わせて、すべてこのファイル

6 ページにパッケージ化します。 - Frame.html はアプレット ビューのテンプレート ファイルであり、すべてのページはこのファイルを使用してロードおよびレンダリングされます。そして、すべての WXML は JS に逆アセンブルされ、ここ

7、ページ すべてのページにパッケージ化されます。これは以前の wxml ファイルではなく、主に WXSS 変換を処理し、js を使用してヘッダー領域に挿入します。

ミニ プログラム アーキテクチャ

WeChat ミニ プログラムのフレームワークには、ビュー レイヤーと App Service ロジック レイヤーの 2 つの部分が含まれています。 View レイヤーはページ構造のレンダリングに使用され、AppService レイヤーは論理処理、データ要求、インターフェイス呼び出しに使用されます。これらは 2 つのプロセス (2 つの Webview) で実行されます。

ビュー レイヤーとロジック レイヤーは、システム レイヤーの JSBridage を介して通信します。ロジック レイヤーは、データ変更をビュー レイヤーに通知し、ビュー レイヤーのページ更新をトリガーします。ビュー レイヤーは、トリガーされたイベントをロジックに通知します。業務処理を行う層です。

ミニ プログラムのアーキテクチャ図:

ミニ プログラムが開始されると、ミニ プログラムの完全なパッケージが CDN からダウンロードされます。通常は、_-2082693788_4.wxapkg

小プログラム テクノロジ実装 のように数値で名前が付けられます。

ミニ プログラムの UI ビューと論理処理は、複数の Web ビューを使用して実装されます。論理処理用の JS コードはすべて、AppService と呼ばれる 1 つの Web ビューにロードされます。ミニ プログラム全体で 1 つだけあります。さらに、ライフサイクル全体がメモリ内に常駐し、すべてのビュー (wxml および wxss) は AppView と呼ばれる別個の Web ビューによってホストされます。したがって、小さなプログラムを開くと、少なくとも 2 つの Webview プロセスが存在します。正式には、各ビューは独立した Webview プロセスであるため、パフォーマンスの消費を考慮して、小さなプログラムでは 5 レベルを超えるページを開くことはできません。 、それは経験のためでもあります。

AppService

AppService は単純なページであることが理解できます。その主な機能は、論理処理部分の実行を担当することです。最下層は、さまざまな API インターフェイスを提供する WAService.js ファイルは主に次の部分で構成されます。

メッセージ通信パッケージは WeixinJSBridge (開発環境は window.postMessage、IOS では window.webkit.messageHandlers.invokeHandler) です。 WKWebview の postMessage。Android では WeixinJSCore.invokeHandler を使用します)

1. ログ コンポーネント Reporter のカプセル化

2. wx オブジェクトの API メソッド

3. グローバル アプリ、ページ、 getApp、getCurrentPages、その他のグローバル メソッド

4. AMD モジュール仕様の実装もあります

次に、ページ全体に、上記のミニ プログラム構成を含む一連の JS ファイルがロードされます。 WAService.js (デバッグ モードの asdebug.js があります)。残りはすべて自分たちで書いた js ファイルで、一度にロードされます。

開発環境の場合

1. ページ テンプレート: app.nw/app/dist/weapp/tpl/appserviceTpl.js

2.構成情報は js 変数に直接書き込まれます。 __wxConfig.

3、その他の構成

オンライン環境

オンラインにすると、アプリケーション部分は次のようにパッケージ化されます。 app-config.json と app-service.js という名前の 2 つのファイルを作成すると、WeChat は Web ビューを開いてロードします。オンライン部分については、WeChat 自体が対応するテンプレート ファイルを提供しているはずですが、圧縮パッケージには見つかりませんでした。

1. WAService.js (基礎となるサポート)

2. app-config.json (アプリケーション構成)

3. app-service.js (アプリケーション ロジック)

次に、JavaScriptCore エンジンで実行します。

AppView

これは h5 ページとして理解できます。 UI レンダリングを提供し、最下層は基盤となる機能を提供する WAWebview.js を提供します。詳細は次のとおりです:

1. メッセージ通信パッケージは WeixinJSBridge (開発環境は window.postMessage で、 IOS は WKWebview の window.webkit. messageHandlers.invokeHandler.postMessage. Android では WeixinJSCore.invokeHandler を使用します)

2. ログ コンポーネント Reporter のカプセル化

3. wx オブジェクトの下の API。ここでの API は WAService の API とは異なり、ほぼ同じ機能を持った API もありますが、ほとんどが UI 表示に関するメソッドです

4. 小さなプログラム部品の実装と登録

5. VirtualDOM、Diff、レンダリング UI の実装

6. ページ イベントのトリガー

これに基づいて、AppView には HTML テンプレート ファイルがあり、これを通じて詳細情報が読み込まれます。このテンプレートには主に $gwx という 1 つのメソッドがあり、主に指定されたページの VirtualDOM を返します。パッケージ化するときに、すべてのページの WXML が事前に VirtualDOM に変換されてテンプレート ファイルに配置されます。WeChat には 2 つのツール wcc ( WXML を VirtualDOM に変換します) および wcsc (WXSS を JS 文字列に変換し、style タグを介してヘッダーに追加します)。

サービスとビューの通信

メッセージ パブリッシュおよびサブスクライブ メカニズムを使用して、2 つの Web ビュー間の通信を実装します。実装方法は、WeixinJSBridge オブジェクトを均一にカプセル化することです。異なる環境では、異なるインターフェイスがカプセル化されます。詳細な実装テクノロジは次のとおりです。

windows 環境

window.postMessage を通じて実装 (Chrome 拡張インターフェイスを使用して contentScript.js を挿入します。postMessage をカプセル化します)メソッド、Web ビュー間の通信を実現します。また、 chrome.runtime.connect メソッドを通じて Chrome ネイティブ メソッドを直接操作するためのインターフェイスも提供します)

Send message: window.postMessage(data, '*'); 。 // データに webviewID を指定します

受信メッセージ: window.addEventListener('message', messageHandler); // メッセージの処理と配布は、nwjs を呼び出すネイティブ機能もサポートします。

contentScript にある文を見ました。 appserviceもwebview経由で実装されていることが確認されており、実装原理はviewと同じですが、処理するビジネスロジックが異なります。

'webframe' === b ? postMessageToWebPage(a) : 'appservice' === b && postMessageToWebPage(a)

IOS

window.webkit via WKWebview 。 messageHandlers.NAME.postMessage は、WeChat ナビイト コードに 2 つのハンドラー メッセージ プロセッサを実装します。

invokeHandler: ネイティブ機能の呼び出し

publishHandler: メッセージ配布

Android

WeixinJSCore.invokeHanlder を通じて達成されます。この WeixinJSCore は、JS 呼び出し用に WeChat によって提供されるインターフェイスです (ネイティブ実装)

invokeHandler: ネイティブを呼び出します機能

publishHandler: メッセージ配信

WeChat コンポーネント

WAWebview.js には exparser というオブジェクトがあります。ミニプログラム内でコンポーネントを完全に実装します 詳細な実装方法を見ると、考え方はw3c Webコンポーネントの仕様に似ていますが、詳細な実装は異なります 使用するコンポーネントはすべて事前に登録され、Webview Replaceに登録されますレンダリング中に組み立てます。

exparser にはコア メソッドがあります:

registerBehavior: コンポーネントが継承するようにコンポーネントのいくつかの基本的な動作を登録します。

registerElement: コンポーネント、つまり対話するためのインターフェイスを登録します。主にプロパティとイベントです

#このコンポーネントは (webviewID を使用して) イベントをトリガーし、WeixinJSBridge インターフェイスを呼び出し、ネイティブに公開します。そして、ネイティブはAppService層の指定されたwebviewIDのページ登録イベント処理メソッドに配布されます。

概要

ミニ プログラムの最下層は依然として Webview に基づいています。新しいテクノロジーやフレームワーク システム全体の発明や創造はありません。比較的明確かつシンプルであり、Web 仕様に基づいて既存のスキルの価値を最大化するため、フレームワークの仕様を理解するだけで、既存の Web テクノロジーを開発に使用できます。理解と開発が簡単です。

MSSM: ロジックと UI は完全に分離されています。これは、現在人気のある React、agular、および Vue とは根本的に異なります。アプレット ロジックと UI は 2 つの独立した Web ビューで完全に実行され、後者はいくつかのフレームワークで実行されます。必要に応じて、引き続き Web ビューで実行します。 DOM オブジェクトを直接操作して UI レンダリングを実行することは引き続き可能です。

コンポーネント メカニズム: コンポーネント化されたメカニズムを導入しますが、完全にコンポーネント開発に基づいているわけではありません。 vue と同様に、ほとんどの UI は依然としてテンプレート レンダリングですが、コンポーネント メカニズムの導入により、開発モデルの標準化が向上し、アップグレードと保守が容易になります。

複数の制限: 同時に開くことができるフォームは 5 つまでです。パッケージ化されたファイルは 1M を超えることはできず、DOM オブジェクトは 16,000 を超えることはできません。これらはすべて、より良いエクスペリエンスを保証するためのものです。

以上がミニプログラム開発の原則は何ですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。