# 移動開發技術簡介 ## 原生開發與跨平臺技術 ### 原生開發 原生應用程序是指某一個移動平臺（比如iOS或安卓）所特有的應用，使用相應平臺支持的開發工具和語言，并直接調用系統提供的SDK API。比如Android原生應用就是指使用Java或Kotlin語言直接調用Android SDK開發的應用程序；而iOS原生應用就是指通過Objective-C或Swift語言直接調用iOS SDK開發的應用程序。原生開發有以下主要優勢： - 可訪問平臺全部功能（GPS、攝像頭）； - 速度快、性能高、可以實現復雜動畫及繪制，整體用戶體驗好； 主要缺點： - 平臺特定，開發成本高；不同平臺必須維護不同代碼，人力成本隨之變大； - 內容固定，動態化弱，大多數情況下，有新功能更新時只能發版； 在移動互聯網發展初期，業務場景并不復雜，原生開發還可以應對產品需求迭代。 但近幾年，隨著物聯網時代到來、移動互聯網高歌猛進，日新月異，在很多業務場景中，傳統的純原生開發已經不能滿足日益增長的業務需求。主要表現在： - 動態化內容需求增大；當需求發生變化時，純原生應用需要通過版本升級來更新內容，但應用上架、審核是需要周期的，這對高速變化的互聯網時代來說是很難接受的，所以，對應用動態化(不發版也可以更新應用內容)的需求就變的迫在眉睫。 - 業務需求變化快，開發成本變大；由于原生開發一般都要維護Android、iOS兩個開發團隊，版本迭代時，無論人力成本，還是測試成本都會變大。 總結一下，純原生開發主要面臨動態化和開發成本兩個問題，而針對這兩個問題，誕生了一些跨平臺的動態化框架。 ### 跨平臺技術簡介 針對原生開發面臨問題，人們一直都在努力尋找好的解決方案，而時至今日，已經有很多跨平臺框架(注意，本書中所指的“跨平臺”若無特殊說明，即特指Android和iOS兩個平臺)，根據其原理，主要分為三類： - H5+原生（Cordova、Ionic、微信小程序） - JavaScript開發+原生渲染 （React Native、Weex、快應用） - 自繪UI+原生(QT for mobile、Flutter) 在接下來的章節中我們逐個來看看這三類框架的原理及優缺點。 ## Hybrid技術簡介 ### H5+原生混合開發 這類框架主要原理就是將APP的一部分需要動態變動的內容通過H5來實現，通過原生的網頁加載控件WebView (Android)或WKWebView（ios）來加載（以后若無特殊說明，我們用WebView來統一指代android和ios中的網頁加載控件）。這樣一來，H5部分是可以隨時改變而不用發版，動態化需求能滿足；同時，由于h5代碼只需要一次開發，就能同時在Android和iOS兩個平臺運行，這也可以減小開發成本，也就是說，h5部分功能越多，開發成本就越小。我們稱這種h5+原生的開發模式為**混合開發** ，采用混合模式開發的APP我們稱之為**混合應用**或**Hybrid APP** ，如果一個應用的大多數功能都是H5實現的話，我們稱其為**Web APP** 。 目前混合開發框架的典型代表有：Cordova、Ionic 和微信小程序，值得一提的是微信小程序目前是在webview中渲染的，并非原生渲染，但將來有可能會采用原生渲染。 ### 混合開發技術點 如之前所述，原生開發可以訪問平臺所有功能，而混合開發中，h5代碼是運行在WebView中，而WebView實質上就是一個瀏覽器內核，其JavaScript依然運行在一個權限受限的沙箱中，所以對于大多數系統能力都沒有訪問權限，如無法訪問文件系統、不能使用藍牙等。所以，對于H5不能實現的功能，都需要原生去做。而混合框架一般都會在原生代碼中預先實現一些訪問系統能力的API， 然后暴露給WebView以供JavaScript調用，這樣一來，WebView就成為了JavaScript與原生API之間通信的橋梁，主要負責JavaScript與原生之間傳遞調用消息，而消息的傳遞必須遵守一個標準的協議，它規定了消息的格式與含義，我們把依賴于WebView的用于在JavaScript與原生之間通信并實現了某種消息傳輸協議的工具稱之為**WebView JavaScript Bridge**, 簡稱 **JsBridge**，它也是混合開發框架的核心。 #### 示例：JavaScript調用原生API獲取手機型號 下面我們以Android為例，實現一個獲取手機型號的原生API供JavaScript調用。在這個示例中將展示JavaScript調用原生API的流程，讀者可以直觀的感受一下調用流程。我們選用筆者在Github上開源的dsBridge作為JsBridge來進行通信。dsBridge是一個支持同步調用的跨平臺的JsBridge，此示例中只使用其同步調用功能。 1. 首先在原生中實現獲取手機型號的API `getPhoneModel` ``` class JSAPI{ @JavascriptInterface public Object getPhoneModel(Object msg){ return Build.MODEL; } } ``` 2. 將原生API通過WebView注冊到JsBridge中 ``` import wendu.dsbridge.DWebView ... //DWebView繼承自WebView，由dsBridge提供 DWebView dwebView= (DWebView) findViewById(R.id.dwebview); //注冊原生API到JsBridge dwebView.addJavascriptObject(new JsAPI(), null); ``` 3. 在JavaScript中調用原生API ``` var dsBridge=require("dsbridge") //直接調用原生API `getPhoneModel` var model=dsBridge.call("getPhoneModel"); //打印機型 console.log(model); ``` 上面示例演示了JavaScript調用原生API的過程，同樣的，一般來說優秀的JsBridge也支持原生調用JavaScript，dsBridge也是支持的，如果您感興趣，可以去github dsBridge項目主頁查看。 現在，我們回頭來看一下，混合應用無非就是在第一步中預先實現一系列API供JavaScript調用，讓JavaScript有訪問系統的能力，看到這里，我相信你也可以自己實現一個混合開發框架了。 ### 總結 混合應用的優點是動態內容是H5，web技術棧，社區及資源豐富，缺點是性能不好，對于復雜用戶界面或動畫，webview不堪重任。 ## React Native和Weex 本篇主要介紹一下 **JavaScript開發+原生渲染**的跨平臺框架原理。 React Native (簡稱RN)是Facebook于2015年4月開源的跨平臺移動應用開發框架，是Facebook早先開源的JS框架 React 在原生移動應用平臺的衍生產物，目前支持iOS和Android兩個平臺。RN使用Javascript語言，類似于HTML的JSX，以及CSS來開發移動應用，因此熟悉Web前端開發的技術人員只需很少的學習就可以進入移動應用開發領域。 由于RN和React原理相通，并且Flutter也是受React啟發，很多思想也都是相通的，萬丈高樓平地起，我們有必要深入了解一下React原理。React是一個響應式的Web框架，我們先了解一下兩個重要的概念：Dom樹與響應式編程。 ### DOM樹與控件樹 文檔對象模型（Document Object Model，簡稱DOM），是W3C組織推薦的處理可擴展標志語言的標準編程接口，一種獨立于平臺和語言的方式訪問和修改一個文檔的內容和結構。換句話說，這是表示和處理一個HTML或XML文檔的標準接口。簡單來說，DOM就是文檔樹，與用戶界面控件樹對應，在前端開發中通常指HTML對應的渲染樹，但廣義的DOM也可以指Android中的XML布局文件對應的控件樹，而術語**DOM操作**就是指直接來操作渲染樹（或控件樹）， 因此，可以看到其實DOM樹和控件樹是等價的概念，只不過前者常用語Web開發中，而后者常用于原生開發中。 ### 響應式編程 React中提出一個重要思想：狀態改變則UI隨之自動改變，而React框架本身就是響應用戶狀態改變的事件而執行重新構建用戶界面的工作，這就是典型的**響應式**編程范式，下面我們總結一下React中響應式原理： - 開發者只需關注狀態轉移（數據），當狀態發生變化，React框架會自動根據新的狀態重新構建UI。 - React框架在接收到用戶狀態改變通知后，會根據當前渲染樹，結合最新的狀態改變，通過Diff算法，計算出樹中變化的部分，然后只更新變化的部分（DOM操作），從而避免整棵樹重構，提高性能。 值得注意的是，在第二步中，狀態變化后React框架并不會立即去計算并渲染DOM樹的變化部分，相反，React會在DOM的基礎上建立一個抽象層，即**虛擬DOM**樹，對數據和狀態所做的任何改動，都會被自動且高效的同步到虛擬DOM，最后再批量同步到真實DOM中，而不是每次改變都去操作一下DOM。為什么不能每次改變都直接去操作DOM樹？這是因為在瀏覽器中每一次DOM操作都有可能引起瀏覽器的重繪或回流： 1. 如果DOM只是外觀風格發生變化，如顏色變化，會導致瀏覽器重繪界面。 2. 如果DOM樹的結構發生變化，如尺寸、布局、節點隱藏等導致，瀏覽器就需要回流（及重新排版布局）。 而瀏覽器的重繪和回流都是比較昂貴的操作，如果每一次改變都直接對DOM進行操作，這會帶來性能問題，而批量操作只會觸發一次DOM更新。 > 思考題：Diff操作和DOM批量更新難道不應該是瀏覽器的職責嗎？第三方框架中去做合不合適？ > > 此處需要有一張插圖 ### React Native 上文已經提到React Native 是React 在原生移動應用平臺的衍生產物，那兩者主要的區別是什么呢？其實，主要的區別在于虛擬DOM映射的對象是什么？React中虛擬DOM最終會映射為瀏覽器DOM樹，而RN中虛擬DOM會通過 JavaScriptCore 映射為原生控件樹。 JavaScriptCore 是一個JavaScript解釋器，它在React Native中主要有兩個作用： 1. 為JavaScript提供運行環境。 2. 是JavaScript與原生應用之間通信的橋梁，作用和JsBridge一樣，事實上，在iOS中，很多JsBridge的實現都是基于 JavaScriptCore 。 而RN中將虛擬DOM映射為原生控件的過程中分兩步： 1. 布局消息傳遞； 將虛擬DOM布局信息傳遞給原生； 2. 原生根據布局信息通過對應的原生控件渲染控件樹； 至此，React Native 便實現了跨平臺。 相對于混合應用，由于React Native是原生控件渲染，所以性能會比混合應用中H5好很多，同時React Native是Web開發技術棧，也只需維護一份代碼，同樣是跨平臺框架。 ### Weex Weex是阿里巴巴于2016年發布的跨平臺移動端開發框架，思想及原理和React Native類似，最大的不同是語法層面，Weex支持Vue語法和Rax語法，Rax 的 DSL 語法是基于 React JSX 語法而創造。與 React 不同，在 Rax 中 JSX 是必選的，它不支持通過其它方式創建組件，所以學習 JSX 是使用 Rax 的必要基礎。而React Native只支持JSX語法。 ### 快應用 快應用是華為、小米、OPPO、魅族等國內9大主流手機廠商共同制定的輕量級應用標準，目標直指微信小程序。它也是采用JavaScript語言開發，原生控件渲染，與React Native和Weex相比主要有兩點不同： 1. 快應用自身不支持Vue或React語法，其采用原生JavaScript開發，其開發框架和微信小程序很像，值得一提的是小程序目前已經可以使用Vue語法開發（mpvue），從原理上來講，Vue的語法也可以移植到快應用上。 2. React Native和Weex的渲染/排版引擎是集成到框架中的，每一個APP都需要打包一份，安裝包體積較大；而快應用渲染/排版引擎是集成到ROM中的，應用中無需打包，安裝包體積小，正因如此，快應用才能在保證性能的同時做到快速分發。 ### 總結 JavaScript開發+原生渲染的方式主要優點如下： 1. 采用Web開發技術棧，社區龐大、上手快、開發成本相對較低。 2. 原生渲染，性能相比H5提高很多。 3. 動態化較好，支持熱更新。 不足： 1. 渲染時需要JavaScript和原生之間通信，在有些場景如拖動可能會因為通信頻繁導致卡頓。 2. JavaScript為腳本語言，執行時需要JIT，執行效率和AOT代碼仍有差距。 3. 由于渲染依賴原生控件，不同平臺的控件需要單獨維護，并且當系統更新時，社區控件可能會滯后；除此之外，其控件系統也會受到原生UI系統限制，例如，在Android中，手勢沖突消歧規則是固定的，這在使用不同人寫的控件嵌套時，手勢沖突問題將會變得非常棘手。 ## QT Moblie與Flutter 在本篇中，我們看看最后一種跨平臺技術：自繪UI+原生。這種技術的思路是，通過在不同平臺實現一個統一接口的渲染引擎來繪制UI，而不依賴系統原生控件，所以可以做到不同平臺UI的一致性。注意，自繪引擎解決的是UI的跨平臺問題，如果涉及其它系統能力調用，依然要涉及原生開發。這種平臺技術的優點如下： 1. 性能高；由于自繪引擎是直接調用系統API來繪制UI，所以性能和原生控件接近。 2. 靈活、組件庫易維護、UI外觀保真度和一致性高；由于UI渲染不依賴原生控件，也就不需要根據不同平臺的控件單獨維護一套組件庫，所以代碼容易維護。由于組件庫是同一套代碼、同一個渲染引擎，所以在不同平臺，組件顯示外觀可以做到高保真和高一致性；另外，由于不依賴原生控件，也就不會受原生布局系統的限制，這樣布局系統會非常靈活。 不足： 1. 動態性不足；為了保證UI繪制性能，自繪UI系統一般都會采用AOT模式編譯其發布包，所以應用發布后，不能像Hybrid和RN那些使用JavaScript（JIT）作為開發語言的框架那樣動態下發代碼。 也許你已經猜到Flutter就屬于這一類跨平臺技術，沒錯，Flutter正是實現一套自繪引擎，并擁有一套自己的UI布局系統。不過，自繪制引擎的思路并不是什么新概念，Flutter并不是第一個嘗試這么做的，在它之前有一個典型的代表，即大名鼎鼎的QT。 ### QT簡介 Qt是一個1991年由Qt Company開發的跨平臺C++圖形用戶界面應用程序開發框架。2008年，Qt Company科技被諾基亞公司收購，Qt也因此成為諾基亞旗下的編程語言工具。2012年，Qt被Digia收購。2014年4月，跨平臺集成開發環境Qt Creator 3.1.0正式發布，實現了對于iOS的完全支持，新增WinRT、Beautifier等插件，廢棄了無Python接口的GDB調試支持，集成了基于Clang的C/C++代碼模塊，并對Android支持做出了調整，至此實現了全面支持iOS、Android、WP，它提供給應用程序開發者構建圖形用戶界面所需的所有功能。但是，QT雖然在PC端獲得了巨大成功，備受社區追捧，然而其在移動端卻表現不佳，在近幾年，雖然偶爾能聽到QT的聲音，但一直很弱，無論QT本身技術如何、設計思想如何，但事實上終究是敗了，究其原因，筆者認為主要有四： 第一：QT移動開發社區太小，學習資料不足，生態不好。 第二：官方推廣不利，支持不夠。 第三：移動端發力較晚，市場已被其它動態化框架占領（Hybrid和RN)。 第四：在移動開發中，C++開發和Web開發棧相比有著先天的劣勢，直接結果就是QT開發效率太低。 基于此四點，盡管QT是移動端開發跨平臺自繪引擎的先驅，但卻成為了烈士。 ### Flutter簡介 “千呼萬喚始出來”，鋪墊這么久，現在終于等到本書的主角出場了！ Flutter是Google發布的一個用于創建跨平臺、高性能移動應用的框架。Flutter和QT mobile一樣，都沒有使用原生控件，相反都實現了一個自繪引擎，使用自身的布局、繪制系統。那么，我們會擔心，QT mobile面對的問題Flutter是否也一樣，Flutter會不會步入QT mobile后塵，成為另一個烈士？要回到這個問題，我們先來看看Flutter誕生過程： - 2017 年 Google I/O 大會上，Google 首次推出了一款新的用于創建跨平臺、高性能的移動應用框架——Flutter。 - 2018年2月，Flutter發布了第一個Beta版本，同年五月， 在2018年Google I/O 大會上，Flutter 更新到了 beta 3 版本。 - 2018年6月，Flutter發布了首個預覽版本，這意味著 Flutter 進入了正式版（1.0）發布前的最后階段。 觀其發展，在2018年5月份，Flutter 進入了 GitHub stars 排行榜前 100 名，已有 27k star。而今天(2018年8月16日)，已經有35K的Star。經歷了短短一年多的時間，Flutter 生態系統得以快速增長，由此可見，Flutter在開發者中受到了熱烈的歡迎，其未來發展值得期待！ 現在，我們來和QT mobile做一個對比： 1. 生態；從Github上來看，目前Flutter活躍用戶正在高速增長。從Stackoverflow上提問來看，Flutter社區現在已經很龐大。Flutter的文檔、資源也越來越豐富，開發過程中遇到的很多問題都可以在Stackoverflow或其github issue中找到答案。 2. 技術支持；現在Google正在大力推廣Flutter，Flutter的作者中很多人都是來自Chromium團隊，并且github上活躍度很高。另一個角度，從今年上半年Flutter頻繁的版本發布也可以看出Google對Flutter的投入的資源不小，所以在官方技術支持這方面，大可不必擔心。 3. 開發效率；Flutter的熱重載可幫助開發者快速地進行測試、構建UI、添加功能并更快地修復錯誤。在iOS和Android模擬器或真機上可以實現毫秒級熱重載，并且不會丟失狀態。這真的很棒，相信我，如果你是一名原生開發者，體驗了Flutter開發流后，很可能就不想重新回去做原生了，畢竟很少有人不吐槽原生開發的編譯速度。 基于以上三點，相信讀者和筆者一樣，flutter未來如何，心中自有定論。到現在為止，我們已經對移動端開發技術有了一個全面的了解，接下來我們便要進入本書的主題，你準備好了嗎！ ## 本章總結 本章主要介紹了目前移動開發中三種跨平臺技術，現在我們從框架角度對比一下： 技術類型UI渲染方式性能開發效率動態化框架代表H5+原生WebView渲染一般高??Cordova、IonicJavaScript+原生渲染原生控件渲染好高??RN、Weex自繪UI+原生調用系統API渲染好Flutter高, QT低默認不支持QT、Flutter上表中**開發語言**主要指UI的開發語言，**動態化**主要指是否支持動態下發代碼和是否支持熱更新。值得注意的是Flutter的Release包默認是使用Dart AOT模式編譯的，所以不支持動態化，但Dart還有JIT或snapshot運行方式，這些模式都是支持動態化的，后續會介紹。