何謂「快應用」呢？它是基於手機硬件平臺的新型應用形態，標準是由主流手機廠商組成的快應用聯盟聯合制定。其標準的誕生將在研發接口、能力接入、開發者服務等層面建設標準平臺，以平臺化的生態模式對個人開發者和企業開發者全品類開放。快應用具備傳統 APP 完整的應用體驗，無需安裝、即點即用； 覆蓋 10 億設備，與操作系統深度集成，探索新型應用場景。快應用 ──複雜生活的簡單答案，讓生活更順暢 ── 來自 快應用官方網站 | 傾城之鏈。
本文首發於個人新博客：靜晴軒別苑 | 快應用之開發體驗紀要。
快應用特點
下面列出些關於「快應用」特點，這將有助於對它有更深刻的理解；
- 基於手機硬件平臺，標準由主流手機廠商組成的快應用聯盟制定;
- 無需安裝、即點即用，且具備傳統 APP 完整的應用體驗;
- 與操作系統深度集成，一鍵直達;
- 更新直接推送，新版本直接更新到後臺，用戶無感知快應用的技術實現;
- 基於前端技術棧開發、可快速迭代;
- 通過全新的引擎，將系統原生的渲染機制和接口能力提供給上層應用;
- 運行在框架應用進程中，對每個快應用會開一個
Launcher進程快應用的開發、發佈和使用流程; - 開發者需要在快應用官網註冊，上傳至快應用官網，測試並通過審覈後即可進行分發;
- 使用前端技術棧進行開發，經過編譯、簽名後最終產出
rpk文件; - 開發者需登錄快應用官網進行上傳和發佈，發佈前會經過審覈快應用與小程序的對比;
- 快應用使用
native渲染，性能體驗會比較好，而小程序是使用webview渲染 ; - 快應用的系統級能力更強，能調用更多系統級 API;
與小程序對比
── | 開發技術 | 渲染方式 | 硬件資源扶持 | 系統級能力 | 桌面留存 |
|---|---|---|---|---|---|
小程序 | 前端技術棧 | webview 渲染 | 有 | 強 | 有 |
快應用 | 前端技術棧 | native 渲染 | 無 | 弱 | 有 |
以上這些比對，皆是從兩者的出生角度而言；可以肯定的是，「快應用」得益於其與生俱來的優勢，將在更多應用場景發揮作用，它的崛起，將會給 Android 用戶帶來更多的便捷。同時作爲後起之秀，其開發體驗上，是明顯優於小程序的；但目前的小程序，已經有長足的發展，而「快應用」才處於剛起步階段，在經驗累積、應用數量、分發傳播、社區建設等方面，兩者之間還存在些差距；後續故事將會如何，讓我們將拭目以待。
開發 & 調試
環境搭建
- 鑑於
「快應用」基於前端技術棧來開發，因此需要安裝 Node.js (>= 6.0)；yarn （推薦使用）。 - 安裝 hap-toolkit ；它是針對
「快應用」衍生出的開發者工具；
yarn global add hap-toolkit // 檢測是否成功安裝 hap-toolkit hap -V
- 手機安裝「快應用」調試器 ── 一個
Android應用程序，它可以連接到手機系統內的快應用執行環境，包含掃碼安裝、本地安裝、在線更新、開始調試、等功能；
掃碼安裝：配置 HTTP 服務器地址，下載 rpk 包，並喚起平臺運行 rpk 包； 本地安裝：選擇手機文件系統中的 rpk 包，並喚起平臺運行 rpk 包； 在線更新：重新發送 HTTP 請求，更新 rpk 包，並喚起平臺運行 rpk 包； 開始調試：喚起平臺運行 rpk 包，並啓動遠程調試工具； 備註：當您的手機系統尚未內置快應用運行平臺，或您想在開發過程中體驗快應用尚未正式發佈的新功能、新特性，您可以安裝 快應用預覽版,這是一個包含了快應用基礎功能的 Android 應用程序。下載安裝成功後，通過快應用調試器可以選擇在快應用預覽版運行
rpk包，開發測試對應平臺的 api 和功能。更詳細的敘述，請參見快應用開發文檔 | 環境搭建 。
開發環境
在「快應用」中，對代碼編輯配置做了說明；你可以使用 VsCode、Sublime Text、WebStorm 等工具來開發。鑑於官方針對 VsCode 推出了 Hap Extension 擴展，這裏推薦使用 VsCode 來編寫快應用代碼（據悉，專門用於開發「快應用」的編輯器，尚在開發中 18-08-15）。
開發調試
在開發文檔調試工具一節，對此有詳細說明；從一般性開發角度總結而言，只需運行以下兩個命令: npm run server 和 npm run watch；前者會在終端會輸出一個二維碼，用手機上啓動快應用調試器，點擊掃碼安裝掃描，即可下載安裝 apk 包，並運行之；而後者將會啓動文件監視器，每次修改工程文件時，會自動編譯並在手機端刷新，速度蠻快；至於日誌查看，可利用 devtools 調試界面 console 輸出，也可利用 adb 工具，在終端進行查看：
adb logcat -s JsConsole
快應用示例
在安裝 Toolkit 工具後，可通過全局 hap 命令創建一個項目模板，如下所示：
hap init <YourProjectName>
鑑於其內置的 Demo 項目示例，尚處於入門級項目設定(@18-08)，不便於用戶着手開發，且不利於高效編寫、維護；因此，有將編寫的快應用 nicelinks-quick-app 開源，藉此以探索新型應用設計；此外，也是在探索如何構建優質快應用，希望可以在此事兒上提供些參考。其代碼組織結構如下：
├── sign # 存儲 rpk 包簽名模塊; │ ├── debug # 調試環境證書/私鑰文件 │ └── release # 正式環境證書/私鑰文件 └── src │ ├── assets # 公用的資源(Images/Styles/字體...) │ │ ├──images # 存儲 png/jpg/svg 等公共圖片資源 │ │ └──styles # 存放 less/css/sass 等公共樣式資源 │ ├── helper # 項目自定義輔助各類工具 │ │ ├──apis # 存儲與後臺請求接口相關(已封裝好) │ │ ├──ajax.js # 對系統提供的 fetch api 進行鏈式封裝 │ │ └──util.js # 存放項目所需公共工具類方法 │ ├── pages # 統一存放項目頁面級代碼 │ ├── app.ux # 應用程序代碼的人口文件 │ └── manifest.json # 配置應用基本信息 └── package.json # 定義項目需要的各種模塊及配置信息
有必要談及的是，此項目秉承在高效開發 Web 單頁應用解決方案中所傳遞的理念：爲高效開發而設計；相比於內置 Demo，她具有以下諸多優點：
- 對項目結構進行優化；如上組織結構所示，將各資源模塊，更專業的分門別類，使之可以便捷的去編寫、維護、查找，同時也是基於前端開發既定共識去設計，更容易爲初接觸者所理解 & 上手；
- 更優雅的處理數據請求；採用
Promise對系統內置請求@system.fetch進行封裝，並拋出至全局，使得可以極簡的進行鏈式調用，同時便捷地處理返回數據； - 內置了樣式處理方案；「快應用」支持 less, sass 的預編譯；這裏採取
less方案，並內置了部分變量，以及常用混合方法，使得可以輕鬆開啓樣式編寫、複用、修改等； - 優化本地開發端口設定；「快應用」默認端口爲
12306，雖說可自定義端口，但使用體驗卻不夠友好；此處參考creat-react-app設定，對本地開發地址端口使用進行優化：如果?️定端口(默認:8080)被佔用，則向上遞增尋找新的可用端口(如：8081 / 8082 / … )； - 瀏覽器打開調試主頁二維碼；運行
npm run server，會啓動 HTTP 調試服務器，並將該地址在命令行終端顯示，手機端用快應用調試器掃碼，即可下載並運行 rpk 包；當終端積累的信息流多了，就造成掃碼不便；故增設在瀏覽器打開調試主頁二維碼；如想不使用此功能，在 command/server.js 文件中，將 autoOpenBrowser 設置爲false即可； - 會持續探究，逐步將更多好用姿勢集成 ……
快應用存在的缺陷
從上面快應用特點，應該對其優點有所感受；接下來不妨‘揣測’下它或將是缺陷的存在（當然，在年與時馳間，隨着版本的不斷迭代升級，某些現在看來是缺陷，日後興許就蕩然無存，也說不定）。
- 若要運行「快應用」，須要手機出廠時在底層支持；否則就須要先安裝
平臺預覽版; - 使用前端技術棧開發，
native渲染，標籤、樣式、功能等都需要一一映射處理，目前來看支持不夠完善；長期迭代情況將會好轉； - 暫不支持使用主流前端框架（Eg:
vue、react）進行開發，且很多功能需要填補；長期迭代情況將會好轉； - 相比於其他‘競品’而言，文檔、周圍生態系統、等都需要亟待完善；長期迭代情況將會好轉；
- 由國內
Android手機廠商聯合推出的，不支持IOS操作系統，目測以後也無法給予支持； - 社交：「快應用」缺乏微信的社交場景能力和傳播手段，推廣拉新，成本不低；再有上一條先天不足，現在來看，不容樂觀。
- ……
如何看待「快應用」?
就目前來看，在移動設備市場，充盈各種類型的應用，大有“諸子百家爭鳴”之基礎；以技術棧來分，有原生型、混合型、Web 型、小程序、「快應用」…… 百花齊放；從類別上看，有支付寶這般豐富的超級 App，亦有許多精品級小衆應用；就用戶而言，不僅能享受其便捷性，同時也能體驗市場的多元化；而各種不同類型應用間良性競爭，對更一步改善用戶體驗也是大有裨益。如此，看來「快應用」的誕生，從外部環境來看，有其成長的土壤；而具有體量的公司都參與的事情（如閃充、全面屏），便是不錯的趨勢，至少不會輸，受影響的是舊的模式 ── 原生應用。
談及「快應用」，微信小程序是無法繞過的點；兩者肯定存在競爭關係，同時也可算是夥伴：如同兩部同時上映的電影，雖有競爭，也會是彼此之助力，共同把盤子做大，吸引更多的用戶傾斜，從而變更未來的應用格局。再有，都是基於前端技術棧，如能有互轉工具給予鋪成，對於開發者而言，即可實現一次編寫，多平臺運行；將會爲這種模式提升更多競爭力。
上面已經從出生層面，對「快應用」和小程序做了對比；「快應用」使用 native 渲染，而非小程序基於 webview 渲染，再加上硬件資源扶持，體驗上則能更上一層樓。況且，對於已經司空見慣的事物，新鮮感在如今看來，也極具誘惑，如子彈短信的出現；就小程序而言目前火熱程度，已有百萬應用，漸成壟斷之勢，從過往歷史來看，這對於用戶來講，絕不都是好事；現在來看「快應用」，機遇與挑戰並存，未來它將如何，朋友你怎麼看？
@2018-08-06 於深圳.福田 Last Modify：2018-09-02