この記事の出所：mPaaS
モバイルインターネット2018業界分析報告書の開示によれば、現在の毎月のアクティブユーザーアリペイは、第二位のAppになるために、QQ以上のものを持っています。
アリペイは、楽器のAppの単一のアプリケーションのほんの始まりに、ユーザーが携帯電話でアリペイ関連事業クエリおよび操作を実現することができます。2013年以降、アプリプラットフォームタイプ、サービス、モジュール、コンポーネントベースのツールの機能を備えたプラットフォームタイプアプリにおさめる徐々に移行。アリペイ決済事業だけで、あなたはまた、宝のバランスなど生活関連サービス、たくさんのを顧客に提供する必要はない。この時間は、電気代を支払います。2015アリペイは、電源アプリケーションに上昇し、アリペイ内部のこの時間は、複雑なビジネスの数が多い、と自分自身のフローブースターパートナーと自分のビジネスを開く機能をサポートする必要があるので、全体のAppは、顔に、オープンダイナミックかつ挑戦的な高可用性に直面して我々は次の3点に要約し、これらの課題：
- 複雑なビジネス・コラボレーションをどのように扱いますか？
- 急速な反復のビジネスニーズを満たすためにどのように？
- 未来志向のオープンなエコシステムを構築するには？
ハイブリッドアプリの複雑なビジネス・コラボレーションに対処するためのアーキテクチャを使用して
アプリケーション事業は、より複雑なだけでなく、社内のビジネスは、また、外部パートナーが多数含まれています。伝統的な方法は、ますます複雑なビジネス・シナリオに対応することは困難である場合はアプリの開発。
技術的なソリューションの選択1.1ハイブリッド
ハイブリッド選択の技術的な解決策の観点から、我々は「採用し、開発コスト、ユーザーエクスペリエンス、ダイナミックな、複雑なビジネス・サポート機能、R＆D難易度 5」総合的に勘案し。私たちは、ネイティブとベースラインの比較が完了するよう開発され、代わりにHTML5、ReactNative / Weex、フラッターをスクリーニングしました。（考慮して、最近のフラッター熱が上昇し続け、私たちはフラッターが一緒に解析することが含まれています。）
ビジネスから我々が持っているすべての最初の開発コストの視点：
- 最も基本的な開発モデルのネイティブとして、開発することが、間違いなくダブルエンドされている必要があり、コストが最も高いです。
- ReactNative / Weexに続く、ダブルエンドで実行している間、一度も、開発されたが、それはJSネイティブコンポーネントのレンダリングに変換されるため、実走行はまだ少し差が存在する、主要な開発者は、ビジネス・インターフェース、ネイティブ年末までに必要な違いの一部を書きます解決するには、カスタム開発。全体的に、ReactNative / Weexビジネス側は、開発コストを削減大幅に役立っています。
- 次フラッターは、事業開発の観点から言えば、ダブルエンドの位置合わせのためのフラッターは本当に大きな努力です。ほとんどのシナリオでは、開発完了後のAndroidの終わりはもちろん、iOSのエンドでシームレスに実行することができ、そしてその自己開発したエンジンは、関連します。開発者のために、古いビジネスの移植作業負荷の一部が考慮されるようにして、唯一の必要に基づくダートの言語の開発を舞います。
- 最後に、成熟した言語と成熟した開発モデルとHTML5、ダブルエンド、ほぼ同じ性能およびその他の特性は、HTML5はまだ我々は開発コストを上陸させたプログラムの最低であることを示しています。
次に我々は議論するユーザーエクスペリエンスを：
- まず、ネイティブの経験は間違いなく最高です。
- 独自のレンダリングエンジンフラッター、両方の性能を踏襲し、コントロールのフォームを表示、本来の経験に劣ると言うことができます。
- 次Natvieコスト制御へのフロントエンドのコードをレンダリングすることによって、ReactNative / Weexの実施形態です。以前のバージョンでは、いくつかのコントロールは、最適化のAppカトンにつながる場所ではないため、そのユーザーエクスペリエンスのパフォーマンスの欠如。
- 最後に、HTML5は、完全にプリセットリソース、コア最適化技術と、ブラウザカーネルによってレンダリングされた、HTML5は、元の経験に近い行うことができますが、全体的なパフォーマンスの違いが残っています。
続いダイナミックサポート：
この論文「オフラインパッケージ+メカニズムのパブリッシングプラットフォーム、」急速な反復の観点から、ダイナミックなビジネスシナリオをサポート高同時深さ分析では、我々はよ重要性の2番目のセクションで。
まず、最適なプログラムのダイナミクスがHTML5です：あなたは、オンラインページ、即時効果を持つサーバにアクセスすることができ、また、動的に道の下でリソースを送信することにより、更新を行うことができます。
ReactNative / Weexプログラムを踏襲し、熱パックのフロントエンドは、特定のカスタム、開発者、ホットアップデートによって展開することができます。しかし、「オフラインオンライン+」に比べてダイナミックHTML5はまだ、いくつかのギャップをプログラムを持っています。
次のネイティブで、アンドロイド/ iOSのは、ダブルエンド、いくつかの黒の技術的手段によって行うことができ、動的に更新さが、ポリシーがiOSのを禁止し、その原因にダイナミック、元のプログラムは一時的に推奨されていません。
最後に、フラッター、非常に強力な熱のオーバーロードがありますが、しかし、Googleの制限ので、熱は、iOSのアップデートのオンライン版を行って、その最後のダイナミックな評価フラッターですることはできません。
最後に、我々は、下の様々なプログラムを実装するためにおしゃべり難易度のR＆D：
- ここでは、最初の場所で一時的にHTML5、HTML5ハイブリッドプログラムをやっているので、カーネルの最適化と不可分である、コアの最適化はあなたには、いくつかのコアの研究開発能力を持っている必要があり、そしてHTML5開発者視点の開発の難しさのため、最高度。単純なHTML5コンテナた場合、それは大いに発展の困難さを軽減します。
- 続いフラッターは、現在、実用的なビジネスアプリケーションの場合には、魚のAppの国内の大規模な体重は一時的に唯一のチームがフラッターを引用したアイドル、まだGitHubのフラッターの中で解決すべき未解決の問題が多数存在している間。適用、フラッターのライフサイクル管理の実際の開発プロセスでは、ビューの管理スタック、ネイティブのページ切り替えやその他の問題は、事前選択プロセスに注意を払うように、開発者が必要になります。
- 次ReactNative / Weexは、これら二つのプログラムためのオープンソースであり、オープンソースコードの変更、便利で使いやすくしながら、難易度のコミュニティサポート成熟した技術、研究開発プログラムの多くは、開発者にとって高い存在ではありません。
- 私たちは、ホットフィックスは、そう考えていない場合は最後に、ネイティブプログラムは、ネイティブプログラムは、あなたが直接使用することができ、変更する必要はありません;熱リハビリテーションプログラムを考慮し、現在の市場いくつかの成熟したオープンソースのホットフィックスがありますが直接使用することができます。
要約した後、我々は当事者のメリットを考慮し、複雑なビジネス問題の進展に対処するため、「HTML5 +コアコンテナの最適化」のアプローチを採用することを決めました。その後、我々は、コンテナの下にアーキテクチャを紹介します。
1.2コンテナのアーキテクチャ
最上层是原生的 HTML5 代码，这块就是大家常见的 Web 开发环境，包括 HTML、CSS、JavaScript等。
下面一层即离线包管理，这个我们在第二章节内进行详细介绍。
再往下是 HTML5 容器层，HTML5 容器作为中间层，将浏览器和支付宝底层框架有机结合起来，同时还提供各种生命周期机制、事件机制、扩展插件等内容。
在 HTML5 容器里面有个非常重要的概念： JSBridge。通过 JSBridge，HTML5 容器将支付宝框架底层以及中间件层提供的各种能力和 HTML5 前端代码进行联通，其中包括 RPC（远程过程调用，用来实现 App 和服务器通信）、支付、扫一扫等。
最下面是支付宝底层框架，提供微应用，微服务等概念。一个 HTML5 应用，也会被框架模拟成一个微应用，通过应用 ID 进行解耦。
1.2.1 JSBridge 介绍
JSBridge 是 HTML5 容器的基石，桥接了 JS 环境与 Native，实现了 Native 代码和浏览器环境的双向通信，Native 代码可以通过调用浏览器提供的接口运行JS，从而实现调用 JS 函数、传递参数到 JS 环境等；而浏览器到JS环境的通信是通过 Native 拦截浏览器的请求来实现，请求可以是网络请求或者是一些内部函数的调用。
1.2.2 H5 容器定制化扩展
HTML5 容器提供了 2 种扩展方式：
- JSAPI
JSAPI 方式给 HTML5 页面增加了 Native 功能调用接口，通过实现自定义 JSAPI 类中的 Handler 方式，可以以 Native 的形式实现特定功能，例如调用 Native 加密函数。
- 事件
HTML5 容器在状态变化时会发送事件，通过监听 HTML5 容器特定事件，可以实现对 HTML5 容器生命周期的处理，比如修改加载进度条颜色、修改页面导航栏等。事件提供了更强的定制性，完全可以满足对 HTML5 容器的各种自定义需求
1.3 容器稳定性
上面在研发难度中，我们提及到了，HTML5 方式的研发难度是最高的，因为需要定制化内核进行性能及稳定性优化。目前支付宝采用的是阿里集团的 UC 自研内核，并针对支付宝的 HTML5 容器进行了深度优化和定制。如图所示，UC 内核和系统内核的卡顿卡死率的数据对比效果非常显著，我们可以直观地看到 Webview 稳定性的提升。
离线包机制+发布平台，满足业务即时更新
目前支付宝业务的另外一个特点就是需要快速迭代，变化的政策、突发事件都需要我们可以快速把新的业务需求触达给用户。但是对于 App 开发者有一个不容忽视的问题，就是应用商店审核。由于审核的存在，App 上开发的业务会有一个统一排期，比如说月底会有新版本，那么所有的业务进度都得考虑 App 的排期计划。
2.1 离线包机制
为了做到良好的用户体验，我们在容器中引入了离线包机制。通过离线包机制，我们将原有从线上加载的 HTML5 应用，提前下发到本地，通过读取 IO，或者是内存，进行页面的渲染，达到接近原生的用户体验。
通过发布平台，我们可以将不同的 HTML5 离线包，以单独应用的形式，进行不同维度的下发，使原来 all in 的 Native 发布模式，改为各业务线自行定制发布计划，自行制定发布标准，自行发布的并行发布形式，来满足业务的快速迭代。
2.1.1 加载机制
通过内存提前加载，定时更新，启动预加载内存等手段，我们将一个业务包需要用到的资源加载到内存，从而使启动过程尽量无感知，页面秒开无白屏。同时，我们还有 Fallback 手段，保证在包损坏或者是未下载完成时，可以通过在线页面的形式，保证业务的 100% 可用性。
2.1.2 公共资源包机制
所谓公共资源包，即所有 HTML5 离线包都可能会用到的公共资源的集合。公共资源包解决多个 HTML5 应用使用同一资源产生的冗余问题。如 React 应用使用 ReactJS 框架代码。您可以将公共资源放入全局资源包，以降低 HTML5 应用体积。
通过公共资源包机制，可有效降低各 HTML5 应用的包体积，从而使更新率提高，页面开启速度加快。
2.2 发布平台
为了满足快速迭代的需求，一个强大的发布平台也是必不可少的。发布平台的核心指标，就是将发布内容高效、精准的投放到指定的设备上，为了实现这个目标，我们做了如下的努力。
2.2.1 离线包大小管控及差量包机制
HTML5 容器离线包提供了更新机制，以单个离线包作为更新维度。因为单个离线包业务很简单，所以离线包的大小是可控的，通常小于 500KB。我们通过大量的实践，总结出来“500KB”这个值，既可以满足单个业务的内容，也可以更高效地发布到设备上。500KB，在 4G 的时代，几乎可以做到用户无感知更新，即便是 2G/3G 也可以保证一个高的到达率。
上面说的是一个 HTML5 应用的大小。实际上，我们更新的包会更小，发布平台会通过 diff 算法，计算出相同 HTML5 应用两个不同的版本的差量包，差量包通常也就在几 KB 至几十 KB 不等，可以做到更高的下载成功率，下载成功率一定程度就意味着实际到达率。
2.2.2 Fallback 机制
在一些极端网络场景下，新的业务资源包更新失败，而我们又期望用户使用的是最新的业务，这个时候 Fallback 访问机制就会发挥作用。每个离线包资源都会在发布服平台上存放一份，在刚刚说到的极端场景下，用户会访问服务器的 Fallback 地址获取资源，从而保障页面可用。
2.2.3 多维发布
另外，针对刚开发好的应用，我们可以通过发布平台的灰度发布进行发放，通过外部灰度的形式，对业务指标进行验证，达到标准后，方可正式发布，做到可灰度，可回滚。
更优越的 Hybrid 方案：小程序差异化解析
作为超级 App，一个最主要的特征就是开放。开放就是共享 App 的流量，让外部伙伴的业务可以通过支付宝触达用户，这就面临一个质量管控的问题。支付宝需要保证这些业务是合法合规的，保障用户的财产安全。
3.1 离线包 VS 小程序
如果开发一方业务，离线包肯定是非常好的选择。不过，要是开放给第三方合作伙伴构建生态的话，纯 HTML5 页面就有一些劣势。
上图是 HTML5 离线包和小程序的细节对比。总结来说，对于开放给第三方的生态，从应用体验来讲，小程序更加统一，质量有保障；从应用安全角度来讲，小程序是访问我方发布服务器，不会直接访问第三方链接，安全可控；从研发门槛上来说，小程序是更简单的前端开发方式，同时也提供了非常丰富的组件。
3.2 小程序解析
小程序其实和离线包本质是类似的，都是一种 Hybrid 应用，但小程序是基于一个定制的 DSL 语言，不是前端的标准，但是类似。在 DSL 规则下业务进行小程序的开发，不支持直接操作 DOM，这种 DSL 规则下的自由可以有效的进行质量管控。
小程序作为一个应用，他拥有完整的生命周期。从开发到关闭，开发者都可以感受到，这点也是 HTML5 所不具备的。另外，每个小程序之间从运行时和持久化上，都是完全隔离的，而且小程序运行在特定进程中，所以和支付宝也是隔离开的。
在渲染性能上，小程序采用双线程模式将页面渲染和业务逻辑分别放在两个单独的线程中，renderer 运行在 WebView 中，负责渲染界面；小程序业务逻辑运行在单独的 worker 线程，负责事件处理、API 调用和生命周期管理。两个线程之间通过 postMessage 以及 onMessage 进行数据交换，数据可以从 worker 线程传递到 render 重新渲染界面，同时 renderer 也可以将事件传递给对应的 worker 处理。一个 worker 可以对应多个 renderer，方便页面间数据共享和交互。
在资源加载方面，小程序采用离线化方式加载，也就是说当打开小程序时，小程序离线包必须下载到本地，由于每个版本只下载一次，一方面节省了每次请求的资源开销，另一方面启动速度大大提升了。当有新的版本时，发布平台自动比对本地安装的版本和最新版本产生并下发差量包，客户端不需要下载整个包即可更新小程序至最新版。
3.3 构建生态
通过引入相同的小程序架构，使得小程序，可以作为生态进行多端互投。在支付宝中投放的小程序，可以只经过一些开放接口的适配，即可跑在基于相同小程序架构的 App 中。未来，开发者或第三方服务更多是面向小程序来开发，而 App 则是提供一个统一的架构，真正做到开放生态，用完即走的理念。
关于支付宝自研 HTML5 容器方案
mPaaS 离线包源自于支付宝原生方案，经历了严苛的业务考验，让你直接和支付宝使用同一套框架层代码，拥有统一容器及内核，相对系统内核获取更低 Crash 率和 ANR 率，适配性强，并具备良好的、弹性的扩展能力，结合具体业务需求定制 JSAPI。
它可以帮助减少 App 白屏、解决 Hybrid App 跨平台兼容与适配，提升 App 性能并大幅优化原生开发下的包大小。
目前 mPaaS 离线包 Demo 源码已更新在 GitHub 上，欢迎 Star：
https://github.com/alipay/mpaas-demo
欢迎申请试用，提更多的优化建议和使用反馈：
http://mpaas2019.mikecrm.com/otOU1k1
最后
感谢大家能耐着性子，看完我啰哩啰嗦的文章。
ここで私はまた、仕上げのあなたのコレクションのコピーを共有アーキテクチャPDF +動画+インタビュー+ドキュメント・ソース・ノート勉強アンドロイドを、だけでなく、高度な技術アーキテクチャ高度な脳マッピング、テーマの開発とAndroidのインタビューを、高度な材料は、建築を進めてあなたが高度な学習を強化します、だけでなく、学ぶために、情報の検索にオンラインみんなの時間を節約し、あなたはまた、親しい友人が一緒に勉強して共有することができます
あなたが必要としている場合は、できるように指して、私は従って、その後、参加Androidの開発者交換基の無料受信する（820 198 451）