一、開發框架選型
1、混合應用開發框架橫向對比
目前可供選擇的混合應用開發框架大致可以分爲五類：基礎框架、腳手架、原生編譯框架、開發平臺、自研框架。
基礎框架
基礎框架是指以 WebView 與原生 API 交互爲核心的經典混合應用開發框架，典型代表是 Cordova、Phonegap，早期還有 Interl XDK，不過已經停止維護。
Cordova 提供了跨平臺的交互機制、插件機制，理論上可以在框架基礎上實現任意混合開發需求。但它也存在我們在第01課中提到的兩大問題，第一：前端只能做成 SPA；第二：插件生態相對不夠豐富。帶來的結果就是前端交互體驗受限，另外部分個性化需求可能需要自己開發原生插件，需要額外的原生力量投入。開發成本視需求而定，性能體驗比較差，基本上無法用於商業產品，僅適合簡單的信息展示類或者工具類 App 項目。
腳手架
腳手架是指在基礎框架的基礎上做 UI 層封裝，典型代表是 Ionic，其底層仍然是 Cordova，使用 Angular 封裝了整套樣式、插件，只對開發者暴露 Angular 層面的語法。相對基礎框架來說，腳手架提供了整套 UI 組件和交互插件，使開發者可以擺脫界面開發，專注於業務邏輯，能有效提高 App 開發速度。
腳手架並沒有解決基礎框架 Cordova 存在的兩個核心問題，Ionic 也是採用 HTML5 動畫轉場，在低端機上普遍表現不佳；插件生態也需要依賴 Cordova 插件庫。此外，還爲開發者增加了 UI 層框架的學習成本。如果不介意基礎框架的缺點，同時能接受框架自帶 UI 風格，或者 UI 開發能力偏弱，那麼選擇腳手架可以更快速地開發出 UI 精緻的混合應用。
原生編譯框架
所謂原生編譯框架，是指使用特定語法開發，經過編譯產出跨平臺原生 App 的開發框架。目前比較流行的有 ReactNative、Weex、NativeScript，它們都使用 JavaScript 作爲開發語言。UI 層語法（框架）稍有區別，分別是 React、Vue、XML，但它們的共同點是，UI 層都提供了一套標籤體系，這是最終能將 App 原生化的前提。編譯引擎在處理代碼時會將標籤轉換成對應的原生組件，這一點其實也跟微信小程序非常類似。
這種理念相比經典混合方案更爲先進，一步到位地解決了開發效率和應用性能問題，開發效率雖不及經典模式，但比原生開發還是要快上不少。但並不能說這是完美的解決方案，因爲這種方案的本質是一場用自有標籤操控原生組件的“木偶戲”，標籤體系的豐富度和可定製性將直接制約開發需求能否順利實現。當某種需求無法用標籤實現時，就需要以各種形式引入原生能力，一方面這會降低開發效率，另外這對不具備原生開發能力的開發者來說，則是一個無法逾越的致命障礙。
雖然這類框架都支持插件機制，但 ReactNative 和 Weex 都沒有官方維護的原生插件生態，這使開發者查找和鑑別插件非常不便，而且就開發者的反饋來看，其框架自身以及插件都有不少坑，不懂原生開發很難玩轉得轉。
針對這一問題，NativeScript 建立維護了一個相當完善的官方插件生態，開發者可以很方便的在這裏查找模塊，對不具備原生開發能力的開發者來說，某個需求能不能實現，查一下就知道。但是這個框架在國內不算流行，入坑可能有一定風險，不建議新手淌坑。
總結一下，原生編譯框架的開發效率介於原生開發和混合開發之間，App 性能也介於原生開發和混合開發之間，需要同時具備前端開發能力和原生開發能力，適合技術儲備足夠、產品開發節奏相對較快的團隊。
開發平臺
開發平臺是指將 App 開發的整個生命週期都放在雲端的一種開發方式，開發者需要做的僅僅是寫代碼、上傳代碼、下載安裝包，其他配置都可以在平臺上操作，AppCan、DCloud、APICloud 都屬於這一類。
這種模式是在 Cordova 流行之後，國內廠商針對其缺陷改進而來的，使用多頁+原生轉場替換前端動畫，提供官方維護的插件庫，可視化管理幾乎所有的開發配置，儘可能降低開發門檻。
它們的優點非常明顯，極大幅度的降低了 App 開發成本，甚至開發 iOS 應用都不需要 Mac 電腦，得益於開發者都集中在國內，插件的豐富程度和社區的本土化也都做的不錯，可以說這完全是爲前端開發者量身打造的混合應用開發方案。
其底層仍然是經典混合開發模式，開發語言就是前端語言，開發效率可以得到保證，但缺點也主要集中在前端語言的體驗瓶頸上，另外多頁面加載雖然解決了動畫流暢性問題，但卻帶來了每次載入新頁面的加載延遲，這些都需要在開發中着重優化。另外代碼放在雲端理論上存在不可控因素（DCloud 支持本地打包），對這一點比較敏感的項目可能不適合選擇平臺模式。
自研框架
自研框架是指結合 App 項目需求，由原生團隊自主研發混合應用框架，以滿足最符合項目預期的開發效率和靈活性。比如可以將部分模塊嵌入 WebView 由前端實現以縮短開發週期，或者直接載入 URL 滿足靈活的內容更新需求。
這種方式的優點在於可以任意調整混合比例，實現成本和效率的平衡。雖然也算一種混合開發方式，但團隊建制上依然是傳統的原生+Web，比較適合原生開發能力充裕的團隊。
橫向對比
從一個前端開發者的角度看，以上框架的對比結果是這樣的：
開發快不快、上手難不難、效果好不好，是做技術選型最優先考慮的三個要素。其中開發效率和性能體驗屬於框架的客觀屬性，這兩方面的表現通常不會因爲開發者的原因而發生太大改變，上圖中這兩列的分值越高，說明效率越高、性能越好；上手難度則有一定主觀性，不同開發者由於能力或習慣不同，可能會產生完全不同的主觀印象，以上打分僅供純前端開發者參考，分值越高，說明上手難度越低。
從開發效率上來看，由高到低依次是“開發平臺 > 腳手架 > 基礎框架 > 編輯框架”。對比的基本邏輯是這樣的，前三位都是用傳統前端語言開發，默認開發效率高於非前端語言。其中腳手架由於提供了 UI 層封裝，所以效率高於基礎框架；開發平臺在基本組件封裝的基礎上，還提供了一站式的開發體驗，效率又高於腳手架。根據自己的實際情況也可能有不同的結論，如果你使用 React Native 超溜的話，開發效率也許不比其他方式低。
上手難度的對比結果顯示，“編譯框架 > 腳手架 > 基礎框架 > 開發平臺”，上手難度依次降低。這個結果完全出自前端視角，基本邏輯是非純前端開發的編譯框架難度最高，腳手架因爲增加了 UI 層框架的學習成本，所以理論上難度高於基礎框架，基礎框架因爲強制要求 SPA，所以理論上難度高於多頁面模式的開發平臺。這方面本來就是“會者不難，難者不會”，所以沒有太多好說的。
性能體驗方面，由高到低的排名依次是“編輯框架 > 開發平臺 > 腳手架 > 基礎框架”，遵循的排名邏輯是原生編譯的性能要高於前端渲染。後三位中，開發平臺由於引入原生轉場動畫，所以理論上體驗優於另外兩種；腳手架和基礎框架在體驗上其實沒有可以拿出來做比較的點，都是純前端呈現界面，原生交互的實現也一樣，它倆的排名沒有價值，可以忽略。
注：自研框架靈活性較強，無法直接與其他框架對比。
爲什麼選擇 APICloud
瞭解了各種框架的大致特點後，作爲前端開發者肯定更傾向於無需依賴原生技術棧的雲平臺模式，目前國內已知的平臺有 AppCan、APICloud、DCloud，它們的功能大同小異，表面上看幾乎只有 API 命名的區別，從這個角度講選哪家都是可以的。
相比之下 APICloud 的開發完成度更高，引擎 Bug 更是很少。與 DCloud 相比，APICloud 平臺的周邊功能更爲完善，這應該是目前上手難度較低的混合應用開發框架，後面的實戰課程都將基於 APICloud 平臺展開。
初識 APICloud
HelloWorld
如果你是第一次打開 APICloud 官方文檔，會發現滿屏幕的概念、名詞，不知該從哪兒看起，這是正常的，官方文檔確實有這個效果，我們先不管那麼多，先來做一個 HelloWorld 項目上手體驗一下。
進入平臺，首先我們在平臺上建立一個項目，進入項目頁面後，可以看到左側導航“端開發”部分，這裏包含了我們開發中會用到的所有功能，它們分別是 App 的常規設置、證書設置、代碼管理、模塊管理和最後的編譯打包功能，走完這套流程，我們應該可以在“雲編譯”這一步裏得到一個打包好的 App，掃碼下載安裝到手機上。
1. 用什麼開發工具？
官方開發工具是 APICloud Studio 2，各項功能十分齊全。但作爲編輯器，它實在不太好用，建議使用自己順手的編輯器開發，僅把 APICloud Studio 用作同步工具。或者你也可以給自己的編輯器加上插件實現同步功能，目前 Sublime、Atom、Eclipse、WebStorm 都有相應的插件。
2. 怎麼檢出代碼？
APICloud 平臺默認會爲每個項目分配一個 SVN 地址，SVN 用戶名就是你的 APICloud 平臺賬號郵箱，密碼可以從控制檯的“端開發-代碼”頁面獲取到。
3. 目錄結構有限制嗎？
沒有，只要根目錄下存在 config.xml 文件，就是一個合法的 APICloud 項目，唯一可能的限制是當你要使用加密數據功能時，必須將加密文件 key.xml 存放在根目錄 /res 文件夾下，這個約束是平臺開發者偷懶造成的結果，但無論如何這個路徑暫時是固定的。
4. 怎麼調試？
調試方式首推 WiFi 同步+真機預覽，可以既兼顧效率又保證預覽結果準確性，整套流程是這樣的：
APICloud平臺新建項目
|
配置項目所需模塊
|
編譯自定義 loader 並安裝
|
本地檢出代碼
|
IDE 開啓 WiFi 同步
|
開始開發
|
開發中 WiFi 增量同步實時預覽結果
真機預覽需要在手機上安裝一個 loader，用來跟 PC 端的 IDE 建立連接同步代碼，並在手機上運行代碼，模擬真實打包效果。
loader 分爲官方 loader 和自定義 loader，它們的區別在於，官方 loader 只集成所有官方模塊，不包括第三方模塊，自定義 loader 則會集成我們項目中真實添加的模塊，只有 loader 中集成的模塊預覽時才能生效，顯然自定義 loader 是開發調試更好的選擇。
開發過程中想要預覽效果，可以在 Studio 界面通過快捷鍵 Ctrl+I，將代碼增量同步到手機，這將是我們今後開發中最常用的一個快捷鍵。另外，開發期間建議手機連上充電器，避免手機自動鎖屏，鎖屏狀態或者 loader 應用不在前臺，都無法同步代碼。還有一點需要注意，實現 WiFi 同步的前提是你的手機和 PC 要在同一個局域網內。
還有一些其他調試方法，可以自己酌情使用：
-
文件實時預覽。在 IDE 左側文件列表中選中一個 HTML 文件右鍵單擊，彈出菜單中有一個“實時預覽”，點擊會以瀏覽器窗口的形式打開當前 HTML 文件。這個功能跟拖動 HTML 文件在瀏覽器中打開效果一樣，只能預覽 Web 自身功能，原生模塊無法預覽。這個 IDE 的彈出窗口還有個特點，它會一直保持在桌面最上層，如果你的顯示屏夠大還好，否則就會始終擋住一塊編輯器區域，所以我覺得這個功能不是很好用，只適合偶爾看一下佈局。
-
USB 同步。只適用於安卓機，需要 PC 已經裝好手機驅動，且手機要開啓開發者模式，允許 USB 調試。同步過程就是通過 USB 線纜給手機發送一個安裝包並自動安裝，最終效果跟 WiFi 同步是一樣的，但除了可以不依賴 WiFi 以外，沒有任何優勢，不建議使用。
-
模擬器預覽。算是 USB 同步的改進版，把 USB 連接的真機換成了當前 PC 開啓的安卓模擬器，理論上比 USB 同步方便了很多，但實際上安卓模擬器比較喫性能，普通 PC 跑模擬器通常都不太流暢，而且模擬器環境跟真機環境往往有差異，不能保障預覽結果的準確性，除非你找不到一個用來測試的安卓手機，否則也不建議使用。
進階問題
能不能用 Vue 開發？
多頁面開發模式利用原生動畫解決了 App 轉場流暢性問題，但也讓開發體驗變得零碎而雜亂，那混合應用能不能跟現代前端框架結合呢？以 Vue 爲例，我認爲有兩種可能的結合方式。
-
保持多頁面的開發方式，Vue 只負責頁面渲染，充當響應式模板引擎。這種做法的優點是可以保留原生轉場動畫，缺點是每個頁面都要加載 Vue。而多頁面混合應用的性能瓶頸之一就是頁面文件的加載，每個頁面都加載 Vue，對於 Vue 框架功能利用率不高的頁面，就不符合性能優化原則了。所以建議僅當遇到個別複雜頁面時，單獨引入 Vue 以提升開發效率，普通展示類頁面可以使用更精簡的前端模板引擎渲染。
-
放棄多頁面模式，整體做成單頁面應用。優點是可以最大化發揮 Vue 的開發優勢，而且可以配合 Webpack 之類的自動化開發工具，缺點是無法使用原生轉場，這一點是致命的，因爲 HTML 5 轉場動畫目前仍然無法達到商用標準。如果無視這個問題，倒是可以這麼做。
JS 插件和原生組件怎麼選擇？
通常來說，原生組件總是要比 JS 插件運行更流暢。而且某些特殊功能只能用原生組件實現，比如某些頁面需要一打開立即使輸入框獲得焦點並彈出軟鍵盤，這個需求純前端實現會有嚴重的兼容問題，但如果用 UIInput 原生組件實現就很容易；
原生組件還有一個優勢，即通常不會被其他原生元素遮擋，這個問題經常出現在有 Frame 窗口的頁面中，Frame 本身就是一個覆蓋在頁面上的原生組件，層級高於前端內容，此時我們想在頁面上顯示一個彈窗，用 JS 生成一個彈窗肯定會被遮擋，只能用原生組件來實現。
但原生組件在使用時往往不如 JS 插件方便。原生組件的樣式只能通過組件提供的配置來修改，如果組件提供的配置不夠，那就意味着無法修改到滿意的樣子。
APICloud 模塊庫裏的 UI 組件默認樣式沒有能用的，大部分必備模塊也只能通過配置做到勉強能接受的程度，比如 dialogBox ，通常我寧願用系統默認彈窗也不會用它，而這可能是目前模塊庫中唯一的彈窗組件。另外某些原生組件不會隨 Window 關閉而關閉，比如百度地圖，關閉頁面時需要手動調用地圖關閉方法，否則百度地圖會一直出現在屏幕上。