何謂「快應用」呢？它是基於手機硬體平臺的新型應用形態，標準是由主流手機廠商組成的快應用聯盟聯合制定。其標準的誕生將在研發介面、能力接入、開發者服務等層面建設標準平臺，以平臺化的生態模式對個人開發者和企業開發者全品類開放。快應用具備傳統 APP 完整的應用體驗，無需安裝、即點即用； 覆蓋 10 億裝置，與作業系統深度整合，探索新型應用場景。快應用 ──複雜生活的簡單答案，讓生活更順暢 ── 來自 快應用官方網站 | 傾城之鏈。

快應用特點

下面列出些關於「快應用」特點，這將有助於對它有更深刻的理解；

• 基於手機硬體平臺，標準由主流手機廠商組成的快應用聯盟制定;
• 無需安裝、即點即用，且具備傳統 APP 完整的應用體驗;
• 與作業系統深度整合，一鍵直達;
• 更新直接推送，新版本直接更新到後臺，使用者無感知快應用的技術實現;
• 基於前端技術棧開發、可快速迭代;
• 通過全新的引擎，將系統原生的渲染機制和介面能力提供給上層應用;
• 執行在框架應用程序中，對每個快應用會開一個 Launcher 程序快應用的開發、釋出和使用流程;
• 開發者需要在快應用官網註冊，上傳至快應用官網，測試並通過稽核後即可進行分發;
• 使用前端技術棧進行開發，經過編譯、簽名後最終產出 rpk 檔案;
• 開發者需登入快應用官網進行上傳和釋出，釋出前會經過稽核快應用與小程式的對比;
• 快應用使用 native 渲染，效能體驗會比較好，而小程式是使用 webview
  渲染 ;
• 快應用的系統級能力更強，能呼叫更多系統級 API;

與小程式對比

以上這些比對，皆是從兩者的出生角度而言；可以肯定的是，「快應用」得益於其與生俱來的優勢，將在更多應用場景發揮作用，它的崛起，將會給 Android 使用者帶來更多的便捷。同時作為後起之秀，其開發體驗上，是明顯優於小程式的；但目前的小程式，已經有長足的發展，而「快應用」才處於剛起步階段，在經驗累積、應用數量、分發傳播、社群建設等方面，兩者之間還存在些差距；後續故事將會如何，讓我們將拭目以待。

開發 & 除錯

環境搭建

• 鑑於「快應用」基於前端技術棧來開發，因此需要安裝 Node.js (>= 6.0)；yarn （推薦使用）。
• 安裝 hap-toolkit ；它是針對「快應用」衍生出的開發者工具； JavaScript yarn global add hap-toolkit // 檢測是否成功安裝 hap-toolkit hap -V

  123	yarn globaladd hap-toolkit// 檢測是否成功安裝 hap-toolkithap-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 工具，在終端進行檢視：

快應用示例

在安裝 Toolkit 工具後，可通過全域性 hap 命令建立一個專案模板，如下所示：

鑑於其內建的 Demo 專案示例，尚處於入門級專案設定(@18-08)，不便於使用者著手開發，且不利於高效編寫、維護；因此，有將編寫的快應用 nicelinks-quick-app 開源，藉此以探索新型應用設計；此外，也是在探索如何構建優質快應用，希望可以在此事兒上提供些參考。其程式碼組織結構如下：

有必要談及的是，此專案秉承在高效開發 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 即可；
• 會持續探究，逐步將更多好用姿勢整合 ……

關於快應用の釋出

關於快應用釋出，有必要談下的理由是，其釋出流程說簡單卻也複雜，說快也慢；這是因為涉及多家廠商，且有著不同規則，導致變數橫生；倘若經歷過之後，這個流程就可以描述為：說複雜也簡單，說慢也快；就以個人開發者來聊下相關經驗：

• 首先需要開發一款快應用；務必確認好 minPlatformVersion 版本，應用命名稱也該有所考究，最好都是中文(利推廣)；
• 快應用官網註冊，完善相關資料之後(須手持身份證反面照片，需清晰)，即可建立 & 提交你的快應用（有些資料要填寫）；
• 廠商稽核；對於華為、OPPO、小米等廠商，必須先繫結其開放者賬號才可以（Vivo 無需），所以得先到廠商註冊，並繫結賬號；
• 繫結賬號，應用提交之後，接下來就是坐等；不同平臺稽核結果許有不同：如華為還需上傳免責函簽名至版權處等等；
• 修正稽核提到的問題，如指出應用提交分類錯誤(HuaWei)、應用介面單一、功能過於簡單(OPPO)等，繼續提交，坐等即可(速度還行)；

個人開發的傾城之鏈-快應用版已於 09-05 日，釋出上架；目前在 Vivo 廠商已稽核通過，可在支援快應用手機的負一屏、瀏覽器等搜尋傾城之鏈即可率先體驗，之後將持續迭代升級，敬請期待。

快應用存在的缺陷

從上面快應用特點，應該對其優點有所感受；接下來不妨‘揣測’下它或將是缺陷的存在（當然，在年與時馳間，隨著版本的不斷迭代升級，某些現在看來是缺陷，日後興許就蕩然無存，也說不定）。

• 若要執行「快應用」，須要手機出廠時在底層支援；否則就須要先安裝平臺預覽版;
• 使用前端技術棧開發，native 渲染，標籤、樣式、功能等都需要一一對映處理，目前來看支援不夠完善；長期迭代情況將會好轉；
• 暫不支援使用主流前端框架（Eg: vue、react）進行開發，且很多功能需要填補；長期迭代情況將會好轉；
• 相比於其他‘競品’而言，文件、周圍生態系統、等都需要亟待完善；長期迭代情況將會好轉；
• 由國內 Android 手機廠商聯合推出的，不支援 IOS 作業系統，目測以後也無法給予支援；
• 社交：「快應用」缺乏微信的社交場景能力和傳播手段，推廣拉新，成本不低；再有上一條先天不足，現在來看，不容樂觀。
• ……

如何看待「快應用」?

就目前來看，在移動裝置市場，充盈各種型別的應用，大有“諸子百家爭鳴”之基礎；以技術棧來分，有原生型、混合型、Web 型、小程式、「快應用」…… 百花齊放；從類別上看，有支付寶這般豐富的超級 App，亦有許多精品級小眾應用；就使用者而言，不僅能享受其便捷性，同時也能體驗市場的多元化；而各種不同型別應用間良性競爭，對更一步改善使用者體驗也是大有裨益。如此，看來「快應用」的誕生，從外部環境來看，有其成長的土壤；而具有體量的公司都參與的事情（如閃充、全面屏），便是不錯的趨勢，至少不會輸，受影響的是舊的模式 ── 原生應用。

出於業務需求以及使用者拉新等方面訴求，Native VS Web 這個由來已久之爭，如今愈發向前端技術棧傾斜，且已佔上風；雖然說，技術的發展，同時有給 Native 和 Web 兩種模式，都提供了利好（對 Web，硬體提升使得體驗越來越好；於 Native，越來越大的儲存空間使得使用者裝 APP 成本下降），但“即點即用”這種快捷模式的橫空出世，附帶以前端技術棧開發的低成本，將打破固有局面，修改使用者原有習慣，從而漸變整個格局。

談及「快應用」，微信小程式是無法繞過的點；兩者肯定存在競爭關係，同時也可算是夥伴：如同兩部同時上映的電影，雖有競爭，也會是彼此之助力，共同把盤子做大，吸引更多的使用者傾斜，從而變更未來的應用格局。再有，都是基於前端技術棧，如能有互轉工具給予鋪成，對於開發者而言，即可實現一次編寫，多平臺執行；將會為這種模式提升更多競爭力。

上面已經從出生層面，對「快應用」和小程式做了對比；「快應用」使用 Native 渲染，而非小程式基於 Webview 渲染，再加上硬體資源扶持，體驗上則能更上一層樓。況且，對於已經司空見慣的事物，新鮮感在如今看來，也極具誘惑，如子彈簡訊的出現；就小程式而言目前火熱程度，已有百萬應用，漸成壟斷之勢，從過往歷史來看，這對於使用者來講，絕不都是好事；而對於開發商來說，也盡是受制於人(騰訊有絕對控制權)，無法主導自己命運，多個渠道，則多份活路；況且，兵無常勢，水無常形，在大時代的拉鋸之下，微信又豈會是永恆的王者？獨立的才是自己的，而小程式並不提供這方面紅利；對於個人開發者來講，加入「快應用」陣營，藉助廠商流量扶持，為自己獨立平臺倒量，不失為更明智的抉擇；現在來看「快應用」，機遇與挑戰並存，未來它將如何，朋友你怎麼看？

@2018-08-06 於深圳.福田 Last Modify：2018-09-02

@2018-08-06 於深圳.福田 Last Modify：2018-09-02