移動端高速發展的這些年，伴隨著企業對研發效率、動態能力的訴求不斷增加，跨平臺技術也如雨后春筍層出不窮。那么，在這篇文章中將向大家分享移動端跨平臺技術演進之路。首先我們看為什么需要跨平臺技術？

為什么需要跨平臺技術？

為什么需要跨平臺技術

• 一方面伴隨著移動互聯網的高速發展，公司間競爭越來越激烈，如何將業務快速落地、快速試錯，成為備受關注的問題。
• 另一方面，提升研發效率、縮短研發周期，保障產品快速試錯并能快速迭代新功能，讓新產品新功能以更快的速度同觸達 Android、iOS 等多端用戶是當今企業的一致的訴求。

眾所周知，Android 應用需要采用 Java/Kotlin 來編寫，iOS 應用需要采用 Objective-C/Swift 來編寫，Web 需要端采用 HTML /CSS/JavaScript 來編寫。這就導致當需要開發支持多端的應用，每一端都需要獨立研發、測試，一直到上線，以及后續的維護工作，工作量成倍增漲，勢必延長研發周期，拖慢產品迭代的節奏。

為了解決多端需要獨立開發的問題，跨平臺技術便應運而生，國內外互聯網公司為此都投入大量人力，于是出現了各種跨平臺技術框架。

跨平臺框架發展總覽

移動端跨平臺技術演進之路

石器時期

這個時期還沒有相應的跨平臺開發框架，開發者使用的是最原始的HTML + CSS + JS的方式進行的應用開發。

HTML

時間：1993

HTML是一種用于創建網頁的標準標記語言。HTML + CSS + JS 這樣的組合是歷史上最成功跨平臺開發的例子。

在這個時期存在的最大的問題還是開發體驗問題，你無法想象開發一個功能，代碼要適配N個不同版本的瀏覽器。
這個在iOS上還好，在Android上因為其碎片化的問題，使得開發適配成本很大；有過前端開發經驗的小伙伴會深有感觸。

Hybrid時期

在這個時期開始陸陸續續有一些跨平臺開發框架出來，比較有代表性的有：Cordova、Ionic。

Cordova

時間：2009

Cordova的前身是PhoneGap，通過它可以使用HTML, CSS & JS進行移動App開發。

Ionic

時間：2013

Ionic是基于AngularJS和Cordova構建的一個輕量的手機UI庫，具有速度快，界面現代化、美觀等特點。

雖然在Hybrid時期，開發體驗提升了；但是APP的實際運行性能和流暢度和原生APP還是沒法比。
于是呢，不少公司和開發者開始琢磨如何既能兼顧開發體驗又能提升APP的運行性能。其實，制約Hybrid應用的性能的主要因素是：

• 網絡傳輸速度，造成前端數據呈現延遲（css，js等資源）；
• webview 容器帶來的限制和JavaScript的單線程；

瀏覽器解析渲染 DOM Tree 和 CSS Tree，解析執行 JavaScript，幾乎所有的操作都是在主線程中進行。

當認識到Hybrid應用的性能瓶頸之后，我們不妨有個大膽的想象：

是否可以將業務代碼和UI用JS+CSS來實現，而渲染交給原生來處理，這樣就可以擺脫webview的束縛，做到開發體驗和性能兼得。

來自大洋彼岸的FB的工程師們做到了，他們將這個方案叫做React Native；React指的是React.js一個前端開發框架，通過JS+CSS開發；后面加個Native主要有兩層含義：

• 這些"JS+CSS"最終會被解釋稱原生控件；
• 有著Native的性能體驗；

RN的出現這標志值移動端跨平臺開發進入OEM時期。

從這個案例中告訴我們：作為工程師來說永遠不要限制自己的想象；要能夠大膽的假設，萬一實現了。

OEM時期

在這個時期框架會進行DSL層的封裝，UI最終會被渲染成Android/iOS原生的控件。

React Native

時間：2015

React Native是Facebook開源的一套基于React的跨平臺開發框架。它的出現標志著跨平臺開發框架進入了OEM時代。

• RN的開源掀起了國內的跨平臺開發的熱潮，國內一些互聯網大廠紛紛投入RN的陣營；
• 有實力的大廠也開始對RN做些魔改，使其能夠適應自己公司的業務；比較有代表性的就是阿里的Weex；
• 當然也有些很多大廠基于RN做了一些封裝，但沒有開源，所以大家可能不知道，比如：攜程的CRN，就是攜程內部的RN；

Weex

時間：2016

Weex是阿里開源的一套使用流行的 Web 開發體驗來開發高性能原生應用的框架。

• Weex可是說是國內的RN，它和RN最大的不同是它天生支持bundle拆分，一個頁面一個JS bundle更加適合國內企業的使用場景；
• 另外，Weex支持Vue.js和Rax框架開發，Rax是阿里的一套基于React協議的輕量，高性能，易上手的前端開發框架；

看似OEM時期的方案很完美，但是還是有不少的問題：

• OEM框架本身的維護成本高：
  • 主要是因為這些OEM框架提供的組件依賴于原生的空間，那么這些Android和iOS控件可不是一成不變的，系統廠商會時不時地做一些迭代，那么一旦有了這些迭代
    OEM的組件也不得不做出適配，這個適配成本是很高的；
  • 另外，因為最終呈現給用戶的這些控件是系統廠商提供的，而Android和iOS又有著天然的行為和特性上的一些差異，所以導致OEM框架要想抹平這些系統的差異，不僅成本高而且有些是根本做不到的
    ，比如：RN的一個日期選擇組件，有不止一個小伙伴問過我，為什么RN的日期選擇組件在Android和iOS上運行的效果差別這么大呢。
• 重平臺特性和產品追求一致的體驗的矛盾：
  • OEM框架是比較重平臺特性特性的，其實"重平臺特性特性"這句話是來自RN團隊的，可以看出RN團隊對外宣稱RN的重平臺特性是無奈的；
  • 因為RN框架本身的特性限制了它不得不重平臺特性，這就導致了它和大部分產品所期望的在不同平臺能夠有一致的體驗所矛盾；有很多團隊和公司為了解決這個矛盾，不得不通過自定義組件來解決，自定義組件的成本是很高的，需要有原生開發經驗的Android和iOS同學才能搞得定；

自渲染時期

在這個時期框架不在做OEM時期控件的搬運工，而是另起爐灶，自己不僅負責上層UI的封裝，而且也負責底層界面的渲染。

Flutter

時間：2017

Flutter是一個由谷歌開發的跨平臺開發工具包，用于為Android、iOS、 Windows、Mac、Linux、Google Fuchsia開發應用。

• 我在這里時間標的是17年，17年可不是它真正誕生的時間，17年是它被大眾所熟知的一年；
• 在《移動端架構師成長體系課》中有講到，如果追溯Flutter的起源的話可以到2014年，那時它還叫Sky，Sky是它當時的一個發開代號；在2015年的時候才被改名為Flutter；
• 在2017年Google I/O大會上，Google正式向外界公布了Flutter，這個時候Flutter才正式走進大家的視野；
• Flutter不同于OEM時期的框架是，它采用Dart來實現上層UI，然后底層基于Skia來進行渲染，從而擺脫了Android和iOS 傳統控件的束縛；

參考

• 移動端架構師

以上就是移動端跨平臺技術演進之路的全部內容，喜歡??的小伙伴可以點贊關注一下哦??。