小さなフレームワークは、小さなクロスプラットフォームの開発を支援するプログラムをリリース2.0 MPX、マイクロチャネルは、直接既存の小さなプログラムを変換することができるドロップ...

著者：ドンHongping（hiyuki）

MPXは、経験と効率アプレット強化フレームワークの開発を向上させることに努め小さなプログラムで、同社は旅行アプレットを含むビットのサポートによって内部ビット、現在では、アプレットは、旅行広場、緑、オレンジ、自転車、オートバイダークホースをドロップ小さなオレンジ、小さなエコを含む小さなオレンジ色の給油手順を、車を維持し、最後の11月以来のオープン、MPXはまた、オープンMPXの開発に基づいて、参加するために良い無料の通り、花や他の小さなメモリプログラムを多くの外部の開発者を行く吸収しました。

長い間、MPX優れた開発経験やMPXと一致している開発者の全会一致の認識と賞賛の強力な内部および外部の安定性が設計されています。しかし、大手メーカーは、独自の小さなプログラムのプラットフォームを発表しており、様々な技術基準は、単に要求小さな開発者の大部分を満たすことができない一つのプラットフォームの開発経験を上げ、今日統一されていない、一套代码在多小程序平台运行それが現実のものとなっていますちょうど上にあります。この小さなプログラム開発の痛みのポイントを解決するために、MPXは、すべてのアプレットのプラットフォームに合わせて、バージョン2.0をリリースした業界は、（マイクロチャネル、アリペイ、Baiduは、ヘッドライン、QQ）リリース、およびマイクロ手紙アプレットを既存の直接コンパイルを提供されていています他のプラットフォームに出力する機能が実行されています。

メインMpx2.0の主な特徴の新バージョンは、次のとおりです。

• すべてのアプレットのプラットフォームをフルサポート（マイクロ手紙、アリペイ、Baiduは、QQ、見出し）業界の出版;
• MPX小さなクロスプラットフォームのプログラム開発、サポートはすでにサポートされている他のプロジェクトに既存のMPXマイクロチャネルの出力をコンパイルしますプラットフォーム実行中のアプレット、詳細情報を参照してくださいするにはここをクリック。
• 既存のマイクロチャネルネイティブコンパイラコンポーネントは、アプレットを実行するためにサポートされている他のプラットフォームに輸出されているサポートアプレットのネイティブコンポーネントクロスプラットフォームコンパイラ。
• ディープサブ最適化、正確決意サブコンパイルプロセスのためのリソース、すべてのサブだけのリソース（構成要素、JS、外部スタイル、外部テンプレート、WXS、画像媒体、等）の正確なサブディレクトリに出力されます。
• 、機能モジュールWXSフルサポートをレンダリング詳細は、機能をクリックしてレンダリングについて。
• それは、テンプレート、インラインWXS、カスタムタブバー、独立した下請け業者、労働者、クラウド開発し、さらにネイティブの互換性を向上させるために他のネイティブ機能の導入をサポートしています。

エンドフレーム全体で業界の主流アプレットと比較すると、MPXは、それ自体がより小さなプログラムの開発に注力アプレット開発では、次のような利点があります。

• アプレットベースの技術基準は、自分を高めるために、DSLの再変換されていない、開発中に遭遇ピットが少なくなります。
• オリジナルの技術仕様アプレット、0コストの移行ネイティブアプレットプロジェクトと完全互換。
• クロスプラットフォーム開発目標のための小さなクロスプラットフォームのプログラムと、コンパイル時に変動スムーズな作業の多く、大いにパッケージの量を増加させるためのランタイム・アダプテーション層を減らします。
• 業界アプレットサポートマイクロチャネルコンポーネントライブラリ（例えばvant、このiViewなど）他のインターネットアプレット実行中に直接変換。
• 我々は、深さのsetDataとパッケージサイズの最適化を提供し、小さなプログラムのパフォーマンスを重視します。

より詳細な説明についてはMPXは閲覧でき公文書をして、この記事の。

Githubの：github.com/didi/mpx

クロスプラットフォーム開発

バージョン2.0のコア機能として、MPXクロスプラットフォーム開発機能は、既存の小さなプログラムをコンパイルするために、直接出力にユーザーを可能にするアプレットを実行している他のプラットフォームへのプロジェクトを支援してきました。小型マイクロチャネルプログラム小さなプログラムの概念の提唱者として、生態系の最も広範なカバレッジを持って、我々は他のプラットフォームアプレット用にコンパイルされた小型のマイクロチャネル・プログラムの機能をサポートするために優先させて頂きます。この能力に基づいて、ユーザーだけでなく、クロスプラットフォームコンパイラマイクロ手紙MPXプロジェクト、でもマイクロチャネルネイティブカスタムコンポーネントは、他の小さなプログラムのプラットフォームへのコンパイラは、私たちのクロスプラットフォームのプロジェクトはいくつかのコミュニティ内に存在するから直接使用することができることを意味し、実行することができます大幅クロスプラットフォーム開発の範囲を向上させるUIコンポーネントライブラリの生態（等vant、iViewの、など）。

デザイン

MPXコアの設計思想は、フレームワークを強化し、拡大し、開発経験やアプレットの効率を改善するためのネイティブ既存のアプレット上の容量、アプレットの開発力に基づいて追加を行うための手段を強化することです。コンセプトは、より確実性と予測可能性をもたらすためにMPXの開発を行うために設計された低学習が始めるために、コストを試運転します。この考えに基づき、さまざまな違いの強化適応でアプレットプラットフォーム、および各プラットフォームの参照テンプレートコマンドスタイルでMPXは、各プラットフォームアプレットにユーザーをできるように、異なるテンプレートに強化された命令セットを提供していますが強化することができます独自のプラットフォームのネイティブ機能を最大限に活用するための方法。

私たちは、クロスプラットフォーム機能のサポートを提供する場合もMPX強化コアの設計思想に従ってください。簡単に言えば後は、MPXクロスプラットフォームの機能は、マルチプラットフォームの機能に基づいており、それはコンパイル時にレイヤ変換層を追加し、既存のターゲットプラットフォームに基づいて、その後、ターゲットプラットフォームのためのプラットフォームのコードのソースコードを変換するには、時間を実行します強化処理ロジックは、我々はまた、条件付きコンパイルメカニズムの包括的なセットを提供し、ユーザーが自分の数を変換することはできませんフレームワークの一部を達成することができます。

MPXの概略クロスプラットフォーム開発プロセス

業界ではMPXのクロスプラットフォーム機能は、他の小さなプログラム、クロスプラットフォームのフレームワークの設計思想とは大きく異なっていた、主な違いは、次のとおりです。

• ウェブを使用せずに参照フレームとしてDSL MPXアプレット自体にDSLの（ヴュを反応させます）。
• 主に処理プラットフォームの違いをコンパイルする方法による変換および実行時のMPX、余分ななめらかな層（基本的なコンポーネントライブラリなど）には差。

この設計は、次のような理由に基づいている理由：

• MPXは、主に、各プラットフォームの現在の技術仕様の目的のために小さなクロスプラットフォームのプログラムにプログラムのサイズはいくつかの類似点があり、滑らかな層との間に差を解消さらに低減することができる一方で、プラットフォームのほとんどの違いは、コンパイラとランタイムツールによって平滑化することができますボリュームFrameworkランタイム。
• 基準としてDSLアプレット自体を使用して、ユーザが直接に基板を横切って既存のプロジェクトを使用することができ、ネイティブ小さなアイテムまたはコンポーネントのプログラムはまた、クロスプラットフォームの機能の出力のために使用することができます。
• 条件付きコンパイルのサポートの完璧な組み合わせは、プログラムはまだユーザーが各アプレットプラットフォームの利用を最大化する能力、MPXは、コアの設計思想を強化し、完全に継続することを可能にしながら、プラットフォーム間でのユーザーのニーズを満たすことができます。

使用

使用MPXクロスプラットフォームの開発は非常に簡単で、ユーザーは単にモードとsrcModeパラメータを渡すときMpxWebpackPluginの作成ソースとターゲットのプラットフォームを指定して、ときに矛盾srcModeモード、フレームは、コンパイルするプロジェクトの対応する設定を読み込み、実行しますとき変換。

// 微信转支付宝
new MpxWebpackPlugin({
  // mode指定目标平台，可选值有(wx|ali|swan|qq|tt)
  mode: 'ali',
  // srcMode指定源码平台，默认值同目标平台一致 
  srcMode: 'wx' 
})
复制代码

違いを滑らかに

現時点では小さなプログラム仕様書の主要メーカーは、一貫性のあるマクロレベルのままになりますが、おおよそ次のセクションに分かれ技術の詳細には多くの違いが、あります。

• テンプレートの構文/ベースコンポーネントの違い
• JSON構成の違い
• 構文の違いWXS
• ページ/コンポーネントオブジェクト差
• APIは、違いを呼び出します
• WebViewのブリッジの違い

その中でも、テンプレート構文/基本コンポーネント、JSON構成と静的差をコンパイル時に指摘文句を言うでしょう変換できない相違点のいくつかのこの部分のために、手段をコンパイルすることにより、当社の主要な変換プロセスでWXS、およびページ/コンポーネントオブジェクトについて、 WebViewの違いとJSランタイムAPI呼び出しを埋める、私たちは主に、ランタイムによって処理、対応するセクションが誤って変換されることはありませんが、実行時に指摘しました。

ターゲットプラットフォームの一部のための能力が存在していない、我々はまた、コンパイルによって可能な限りシミュレーションを提供し、実行時に、我々は転換だけでなく技術基準変換マッピングのクロスプラットフォームの変換で働くか、ということは注目に値しますそして追加のワークロードとクロスプラットフォーム開発を最小限にするためにサポートが支払う必要があります。最大の違いだけでなく、マイクロチャネル転送アリペイの最も現実的な場面では、例えば、MPXシミュレーションは、マイクロ文字をサポートするための機能を多数提供していますが、宝の支払いをサポートしていませんでした。

• コンポーネントのカスタムイベント
• コンポーネント間の関係
• サブコンポーネントのインスタンスを取得します
• オブザーバー/プロパティオブザーバー
• インラインWXS
• 外部スタイルクラス

変換からのネイティブクロスプラットフォームのカスタムコンポーネントのために、我々は簡単な注射で実行されます、MPXフレームワークは変換機能を提供し実行するために使用することができます。

条件付きコンパイル

違いを消去することはできませんフレームの部分は、この部分のために、コンパイルと実行時エラーにエラーを指摘されるために、我々は、ユーザーがターゲットプラットフォームを修復するために、独自のパッチを作成することができます包括的な条件付きコンパイルのメカニズムを提供し、この能力は、達成するために使用することができますこれは、ビジネス・ロジックの違いプラットフォームを持っています。

そしてどのようにプロジェクトの変換、モードとsrcModeは、ユーザーと、着信モードsrcModeを読み取ることによって、全体のプロジェクトをビルドするターゲットプラットフォームとソース・プラットフォームを表しているかどうかを判断するためにMPX上述したように、条件付きコンパイルは、ユーザーがプロジェクトに文を作成することができますプラットフォーム自体は（localSrcMode）ファイルとコードブロックを属性。プロジェクトの建設では、フレームワークは、ターゲットプラットフォームのロードlocalSrcModeマッチ（localSrcMode ===モード）でのプロジェクトを優先させて頂きますファイルとコードブロックのlocalSrcMode文を使用して、ドキュメントやコードブロックのこの部分は述べた彼らの標準プラットフォームに合わせて完全に書き込む必要があること、 MPXは、任意のクロスプラットフォームコンパイラなると実行時の変換をしません。

MPXは、ファイルの大きさ、寸法と、コードブロック寸法は、ユーザーが柔軟にインターネットカバレッジの違いを使用するように選択することができ、3次元の条件付きコンパイルを提供します。

パフォーマンスの最適化

小さなプログラムの開発に焦点を当てMPXフレームワーク、パフォーマンスの最適化は、我々は二つの側面に焦点を当て、試みと努力の多くを行っています。

• setDataメソッド最適化されたランタイム
• 場合は、パッケージのボリュームの最適化コンパイラの建設

setDataメソッドの最適化

データ応答は、手動でsetDataメソッドを呼び出す必要がなく、ユーザーが見ることができますMPXランタイムコア機能を強化し、Vueの小さなプログラム開発中と同じ特性を使用して計算し、データ駆動型のビューは、オペレーションの直接割り当てで更新されます換言すれば、フレームワークは、setDataメソッド呼び出しアプレットを引き継ぎました。

ご使用のプラットフォームのサイズが推奨する最適化性能と設計原則はsetDataメソッドは、アプレットのパフォーマンスのために非常に重要であり、学習することができ、setDataメソッドは二つの方向を最適化していること：

• 呼び出しの頻度を最小限に抑えるにsetData
• データの伝送単一のsetDataを最小化

最適にsetDataを達成するために、我々は、各コンポーネントテンプレートのテンプレートをコンパイルするプロセスであるが、アクセス時間は、各実行データをレンダリングするために必要なレンダリング機能（機能をレンダリング）、機能の論理シミュレーションテンプレートをレンダリングし、生成しますそしてアクセスされたデータ値は、リターンパスを記録し、時間の関数として返します。

実行時には、フレームワークは、各コンポーネントがレンダリングウォッチャー、そのウォッチャートレースレンダリング機能、非同期実行のレンダリング関数を作成するときに作成されますが、機能はこれらに基づいて依存データをレンダリングすると、変更された場合におけるウォッチャーコールバックをレンダリングレンダリングされたデータ・パスを、取得に戻ります。キャッシュされたデータの差分を比較するためのパス、フィルタリングされたデータを取得するために最低限必要なデータが変更され、最終的に必要な最低限の層をレンダリングするアプレットの更新プログラムの実際のビューにデータを送信するためにsetDataを呼び出していません。

データが変更され、この機構に基づいて、データのその部分は、非同期に発生するデータの変化だけ現在のレンダリングに依存する部分が実行ウォッチャレンダリングトリガ、各実行は唯一の真の変化が発生した後にsetDataレンダリングに送信されます層。だから、ユーザーは、ユーザーエクスペリエンスを向上させながらのsetData最適化フレームワークを呼び出すことに注意を払うことなく、自動的に呼び出すにsetData最適可能となり、ビジネスニーズに応じて自由にデータを操作することができるだけでなく、プログラムのパフォーマンスの開発を強化します。

バージョン1.1では、レンダリング・ロジック機能はWXSを含むアセンブリは総量モード設定データに追いやられるため、WXS内で実行することができない、バージョン2.0は、我々は、射出JS後翻訳処理モジュールの実行可能コードをWXS JS関数をレンダリング含むWXSにバンドルが正常にアクセスし、論理WXS実行することができます。

setDataメソッド最適化の概略図

最適化のパッケージ巻

買収を実行するのに似にsetDataについて、MPXは、コンパイル時にプロジェクトリソースの管理を引き継ぎました。おかげで、強力なプラグイン機構をWebPACKの、MPXは、プログラムを完了小型パッケージのWebPACKを構築する作業に基づいて、カスタマイズWebPACKのプラグインの深さを開発しました。使用中のユーザーは、最新のWeb開発機能は、依存性をNPMのアプレット無制限に使用を開発MPX、その上の最新の機能とCSSプリプロセッサをESと。同時に、パッケージサイズの最適化にMPXは、パケットのボリューム管理のためにあまりにも多くのエネルギーを費やすことなく、ユーザーがビジネスの発展に集中することができ、多くの作業を行うことができ、次のように、私たちは仕事を最適化します：

• 完全に依存関係の分析に基づいて、パッケージの建築工事は、参照されるすべてのリソースは、distの彼らには表示されませんありません。
• 完全に全体のディレクトリminiprogram_distをコピーしません、詰めオンデマンドのページや依存解析を構築するためのNPMアセンブリは、小型のマイクロチャネルプログラム自体NPM支援プログラムよりも優れているNPM、経験とパッケージ・サイズを構築するために行う必要はありません。
• 抽出及び圧縮コードの最適化のためのWebPACKの共通モジュールを提供する能力に基づきます。
• パーフェクト下請けのサポートは、すべてのリソースの依存解析、すべての下請け業者のサブディレクトリのみのリソースにすべて出力すること。

（オンデマンド非同期ロードと同様）コア手段のサブ最適化されたマイクロ文字アプレットパッケージボリュームとして、それが完全サポートすることMPX。オーダーのみのサブリソースを正確にマークするには、我々は、メインとサブパケットを構築するメインパッケージ、サブ再処理に処理、分割オープンコレクタシリアル処理ステップを依存しています。メインパケットの処理において、メインパケットすべての非参照ページのJSリソース（コンポーネント、外部スタイル、外部テンプレート、WXS、画像メディア、など）、サブ処理に記録され、外注への参照メインパッケージは、メインパッケージへの出力を引用した場合に非jsのリソースは、下請業者のみ次のサブディレクトリに出力をリソースとしてそれ以外の場合はマークされ、確認してください。

JSモジュールのリソースのために、我々は、足場装置はユーザ設定サブバンドルを容易にするためのヘルパー機能を提供し、構成した後、共通モジュールにのみサブサブサブバンドルに出力される構築物を生成しディレクトリ、通常のメインバンドルへのパブリックモジュールの残りの部分。

クロスプラットフォーム開発では、我々はあなたがMPXを使用することをお勧めして提供するパッケージを下請けに変換する際に、アプレットのプラットフォームが自動的に同期パッケージを処理するためにダウングレードされますサポートしていないように、下請け業者を定義します。

建設下請け業者のためのスキーム

プログレッシブ移行

MPXは、ネイティブまたは他の小さな手続きのフレームワークを使用する開発者のための良いプログレッシブ移行サポートを提供し、段階的な導入MPXの開発コストを介して段階的な移行は重要ではありません。

バージョン2.0では、私たちは、このような同時フィルのカスタムタブバー、独立した下請け、サブプリロード、労働者の能力、クラウド開発、などのフォローアップサポート様々なアプレット最新の技術プラットフォーム機能は、ネイティブの互換性MPXをさらに向上していますチーは、いくつかのバージョン1.xのサポートが不足しています。これのおかげで、小さな開発するネイティブアプリケーション開発者を使用して、マイグレーションMPXのコストはほぼゼロ、コンストラクタページ部品交換のcreatePage / createCompnent MPXを提供するために、単にユーザに対応し、提供MPXを使用することができます様々なエンパワーメント。

他のフレームワークを使用する開発者のために、MPXはまた、特定のページやコンポーネントネイティブコンポーネントにのみビルド出力にユーザーをできるように、地元の建設のためのメカニズムを提供し、ユーザーは手動でのみに必要とするか、またはネイティブコンポーネント記述されたスクリプトの出力は、元のプロジェクトに統合しますことができます。

今後の計画

小さな会社のインフラ、内部手続きや生態系の作品として、我々は長期的な保守更新のためのMPXフレームワーク、最新の技術が最初に時間を特長としています、各プラットフォームのアプレットをサポートすることを確認します。同時に、我々はさらに、基本的な能力の枠組みを改善し、ラフトがサポートされるようにスケジュールされた機能は以下のとおりです。

• I18N
• TSのサポート
• ユニットテストのサポート

クロスプラットフォーム機能の面では、我々は、コミュニティからのフィードバックや提案だけでなく、標準化プロセスアプレット、その継続的な改善と更新に基づいて行われます。

あなたは小さなプログラムの開発に注力している場合最後に、MPXは、あなたの最良の選択となりますことを、開発経験と製品の性能に焦点を当てます。