アブストラクト＃Huawei社のクラウド。＃プログラマーが暗い馬を探して
最も早いのPhoneGap、またはかどうかアンドロイド、IOSを解決しても、H5、コードの再利用のアプレットマルチ問題するように、ネイティブ、Weex、フラッターを反応させるのか、各企業独自の開発言語は、常に統一言語を開発しようとしていますさ開発効率を向上させるために、保守費用とスタッフの学習を減らします。
WebViewのベースのフレームワークの利点は明白である、彼らはほぼ完全に近代的なWeb開発のすべての成果を継承します（などダイナミックのフルページフレームの多様なニーズを満たすために、より豊かなコントロールライブラリ、自動テストツール、）と、もちろんされていますWeb開発者は多くの学習を必要とせず、移行コストは、Appを開発することができます。一方、WebViewのフレームワークは、効率のWebViewレンダリングやJavaScriptの実行パフォーマンスが悪い、である（高い需要状況の経験＆パフォーマンスで）致命的な欠陥を持っています。様々な機器メーカーとAndroidのカスタムシステムのバージョンと相まって、すべてのデバイスで一貫した体験を提供できる場所を確保することは困難です。
ネイティブもHTML + JSにUI構築ロジックをクラスを使用しながら、最終的には、システムに返さ作業をレンダリングしますが、最終的に対応するカスタムネイティブコントロールを生成しますフレームのクラスによって表さ反応するように、差分のWebViewのパフォーマンス問題を解決するために、 WebViewの高いレンダリング効率に対するネイティブコントロールをフルに活用します。同時にこの戦略は、フレームワーク自体、システム上のコントロールのシステムに縛らアプリ開発者になるだけでなく、フレームワーク自体は、プラットフォーム固有のロジックを大量に処理する必要がある、とAPIのシステムバージョンの変更に変化するとき、開発者は、対処する必要があるかもしれません違い異なるプラットフォーム、さらにいくつかの特性が唯一のプラットフォームの一部に達成することができ、クロスプラットフォームは、このようなフレームワークが大幅に低減されています。
フラッターは、それも論理的な開発言語をレンダリング、UIコントロールを含むクロスプラットフォームのUIフレームワークのセットを、書き換え最初から最後まで、思考の全く新しい道を開きます。Skiaレンダリングエンジンは、クロスプラットフォームのグラフィックスライブラリに依存して実装されているシステムにのみインターフェースをレンダリンググラフィックスに関連する依存している、あなたは異なるプラットフォームの経験の一貫性、最大限に異なるデバイスを確保することができ、ロジックは、AOTのダーツ言語、実行効率をサポートしていますJavaScriptはそれよりもはるかに高いです。
太郎、MPVUE米国Jingdongはこれらのグループは、再びAPPおよびH5、アプレットとの間の接合部を見て、または言語変換ツールによって、順番にコードを達成するために満たすすべてのモバイル体験の入口端部。
いくつかのアイデア：
1.androidとiOSのネイティブ開発言語（アンドロイドJAVAとにObjC）フロントエンドのビジネス・ロジック層にはヘビー級は存在しませんので、徐々に、バックシート、あるいは失業を取る必要があり、それのようなMVVM + JS言語のルックスのためのフロントエンドフレームワークもし、密接に基礎となる、インターフェースに接続されたJNIの開口部を経由してC言語のより良い性能を達成するためにバインド（カメラ、ビデオコーデック）ライブラリーの機能の性能要件に関連して結合して、十分にしていますクライアントは、（あなたがフラッタフレームワークの使用上の多端子統一様式の効果を作成し、この命題のネイティブ効果のシステムをフォローしたい場合は、それがますます弱体化になるだろう、同様の枠組みのRNを使用し、同様の効果およびネイティブインターフェイスを作りたいです私は同じで、それが優れている私自身の性格、私自身のマルチポートを見て欲しい）、JAVAとにObjCはもっと恥ずかしいだろう?;
2.マイクロ先端が現実になることがあり、各モジュールは別々の容器で実行されている異なる言語で実装、フラッタを実行する1つのアプリでは、容器のWebViewの種々の形態を実行して、プライマリモジュールDavikVM上で実行されている、DartVMサービスモジュール上に実装しましたH5ページには、システムレベルのルーターページは、均一なジャンプスケジューリングに責任があります。
数年前に3モジュラーネイティブ開発言語より人気のホットフィックス、に基づいて、フォローアップが徐々に標準になるだろうが、ホット・フィックス、各フレーム（動的更新モジュール）の態様によれば、我々は確かにAppleのいわゆるポリシー制御を破る方法を見つけるだろう、両方のAPPは、あなたも自分の給料の入り口を開発するために上記の行の後にAPP違反（、またはオンライン更新部ができ、十分な柔軟性を維持するために、動的更新を許可するように、Appleは、その後の道の事前審査からの移行方法に責任の罰を考慮することができますモジュールの後に責任の罰は従事***、暴力、***）。