【快應用篇01】快應用它來了！帶你瞭解什麼是快應用！
分享人：夏燕飛
近期因為需求與bug比較多，因此有些拖更了。非常抱歉，那麼今天的乾貨開始了。。。
該篇為“快應用”第一篇。歡迎大家閱讀！
自快應用問世，到現在也已經有一年多了。快應用和微信小程式類似。都是使用者體驗介於網頁與原生APP之間的新型應用模式。微信小程式我想大家都用過，但是快應用卻不一定。首先微信小程式問世要比快應用早一年，而且靠著微信的使用者社交粘性和閉環，以及小程式支援安卓與ios端。使得小程式到目前為止，依舊發展得比快應用好。但未來不一定。
快應用可以說是9大手機廠商為了不使微信小程式搶佔應用流量而出現的吧。
畢竟微信小程式是以微信為載體，是一種二級應用，開啟小程式前必須要開啟微信的佔用記憶體。而快應用是手機廠商出品的，不需要以某個為載體，直接作業系統開啟，屬於一級應用。可以直接呼叫底層系統功能。其實廠商可根據其優勢，提升手機的原生效能，使得其強於微信小程式的體驗也是可以的，不過這得待後期發展了。
現在我們從技術角度來說說開發快應用吧！
專案結構
按快應用腳手架工具初始化的專案基本能滿足一般的專案開發需求了。比如現在初始化一個
hap init hiquick
專案：
得到一個如下結構的專案目錄：
├── sign //rpk包簽名模組
├── src
│ ├── Common //公用的資源和元件檔案
│ ├── Demo //頁面目錄
│ │ └── index.ux //頁面檔案，可自定義頁面名稱
│ ├── app.ux //APP檔案，可引入公共指令碼，暴露公共資料和方法等
│ └── manifest.json //專案配置檔案，配置應用圖示、頁面路由等
其中 Demo 目錄即是一個頁面目錄，包含一個 ux 字尾的頁面檔案。專案構建執行之後，還會產生 build/、dist/ 兩個目錄。build 是打包構建後生成的 js 檔案、dist 則是 rpk 安裝包。
在我們實際專案中由於業務比較複雜，會建立很多頁面，這樣平鋪在根目錄下，造成資料夾過多不易管理維護。
於是我們新建一個資料夾 pages 專門存放頁面，這樣專案結構就變成了：
├── sign
├── src
│ ├── common //公用資源、全域性配置
│ ├── components //公用元件
│ ├── pages
│ │ ├── index //頁面目錄
│ │ │ └── index.ux //頁面檔案
│ │ └── login
│ ├── app.ux
改造後的目錄結構更直觀、簡潔。不過要記得去修改預設的頁面路由配置：router.pages、display.pages 兩項的頁面鍵值要改和頁面路徑一致。如這裡首頁的配置就是 pages/index。
除了新增 pages 目錄，還新增了 components 資料夾和更改 common 資料夾的用途。
新增的 components 資料夾專門存放公用的元件檔案，而 common 則專門用來存放公共資源、工具方法和全域性配置等檔案。這樣使得目錄的功能區分更明白了，也為後面的程式碼複用作好了基礎準備。
其中全域性配置的配置項皆以模組化輸出，既對變數有一個統一的維護管理，也方便在業務直接引入呼叫，一舉兩得，非常高效。
頁面劃分
上面已經說了我們為所有頁面專門建立了一個 pages 資料夾。從中可以看出應用中的所有頁面是平級劃分的。雖然在業務邏輯上可能存在父子關係，但實際頁面沒必要分出從屬，那樣只會增加頁面關係的複雜度。
但這裡有一個特殊頁面還是設計了父子關係。這麼做也恰恰想表明頁面間從屬關係。這就是 pages/index 頁面，為了避免概念混淆，這裡先稱之為索引頁。因為它正是起著索引導航作用的，並不是常規意義上的首頁。
通常，一個APP的介面是這樣的：
在介面底部會有一個導航選單欄，叫做 TabBar，然而快應用並沒有這種元件。雖然利用頁面路由可以做導航，但效果並不理想，切換過來的頁面都需要重新載入。由於頁面中已經使用了 tabs 元件，使用tabs元件實現也不可行。
剩下就需要自己動手打造了。既要實現頁面導航，又要實現頁面快取的功能。
簡要分析下元件的設計思路。
在單頁內實現不同頁面的切換，功能相當於一個Tab。
功能區分為tab標籤欄和tab內容區。
標籤的專案不能寫死，要可以自由擴充套件。
每個標籤對應的頁面以元件形式引入。
在 index.ux 頁面需要引入 TabBar 頁面元件。作為子元件，為方便管理，我們把這些子頁面元件作為子資料夾放在 index/ 下管理維護，一目瞭然地表明頁面的從屬關係，整體專案的頁面切分工作也完成了。
│ ├── pages
│ │ ├── index //索引導航目錄
│ │ │ ├── subpages //子頁面目錄
│ │ │ │ ├── featured //子頁面
│ │ │ │ │ └── index.ux //子頁面元件檔案
│ │ │ │ └── member
│ │ │ │ └── index.ux
上面 TabBar 的功能設計還忽略一點，就是子頁面元件更新的問題。為此做了監聽標籤切換及頁面 onShow 事件觸發元件更新的處理，這裡不做詳細說明。
公共程式碼
下面著重來說下公共程式碼部分，公共程式碼及元件化向來都是專案中的重點部分，這部分作好了，會使得專案程式碼越寫越少，越寫越高率。相反，如果這部分沒有做好，不僅會讓專案程式碼變得一團糟，不斷地重複工作，還極有可能會埋下一些潛在的危險。
比如專案中公用的一個引數，分別寫在各個地方，等到需要更改時，很可能改了一個地方而忘了另一個地方，等到出錯還不容易排查問題出在哪裡。如果統一在一處配置好，其它所有地方只引入這個配置，則會從根本上規避這個低階錯誤。
當然這只是做好公共管理的優點之一。
公共程式碼和元件化開發應該深入到任何專案的任何角落，應該時刻保持這種意識。
在快應用專案中我們將公共資源、公共程式碼都放在了 common 資料夾下。包含全域性基礎樣式檔案、圖片資源、配置項檔案、和工具方法。
配置項檔案 config.js 集中管理全域性使用的常量和API介面地址，並對依賴不同域名環境下的配置項做自動切換處理。
工具方法 utils.js 將可複用的工具函式方法抽象出來，並以模組化形式匯出，方便其它模組中按需引入，而不需要在不同的地方重複地寫同一個工具方法了。
再來說說元件化，這也是專案開發中的重點。
元件化應該是在專案一開始就需要著手考慮的事情，原則上在互動稿評審階段就需要開始了。分析出哪些部件可以提取抽象出公共元件。這樣多人協作的專案中，共同開發將變得非常有效率。
快應用專案目前拆分出的公共元件有圖文展示元件、TitleBar頁面標題欄元件、錯誤狀態提示元件、章節目錄元件等（排除快應用框架自身的元件）。
TitleBar元件實現自定義的頭部標題樣式，在預設的標題欄不滿足需求時可以使用該元件實現。
錯誤狀態提示也是複用較高的元件，在處理無網路、暫無資料等狀態下都可以直接引用。大大減少程式碼的重複開發工作。
體驗、效能的優化
除了以上的改造優化外，效能的優化也是無法繞開的。開發過程中除了基本該做的優化要做到之外，能發現的效能問題也應該尋找方案解決。當然如果時間不允許或者暫無方案解決則另當別論。
那快應用專案中所做的效能優化工作列舉幾點如下。
TabBar頁面導航優化
前面說了TabBar的設計思路，也提到了設計的意義，涉及的主要優化有：
按需載入，首次只加載預設標籤頁。
頁面快取，避免切換時頁面的重複載入。
返回鍵退出應用，避免路由鏈路過長。
TabBar配置的標籤項，預設只會載入其中一個頁面，這個初始展示的頁面由配置項 currentTabName 決定。點選其它標籤後，才載入對應的頁面。頁面載入完成後，再次切換標籤，已載入的頁面則是顯示或隱藏，不會重新載入渲染。提高了使用者使用體驗的同時，也節約了沒必要的網路請求。
前面也提到直接使用路由跳轉也是可以實現類似的效果。使用路由來實現，技術複雜度會大大降低，但使用感受也比較糟糕。除了切換時頁面重複載入渲染之外 ，頁面棧也會隨著不斷切換而加大，這時如果想返回則會走很長的連結。雖然可以通過設定replace路由替換規避，但頁面重複載入渲染是避免不了的。
快應用與web元件的通訊優化
快應用的訂購環節由於技術限制，需要引用web元件來載入HTML頁面實現訂購。交易環節事關重大，功能上容不得半點差錯，效能上要保證穩定可靠。技術上涉及到快應用與HTML之間的通訊。而在除錯過程中卻發現了通訊機制的一個Bug。
起始在開發中發現web元件存在通訊不穩定的問題，初步判定為可能頁面還未載入完成。為保證通訊的可靠性，我們在頁面載入完成的回撥事件 onpagefinish 中發起通訊。然而web元件會自動觸發兩次 onpagefinish 回撥。原因暫時不明確，問題也和官方溝通過。總之這會造成HTML中監聽通訊的請求也傳送兩次。於是想辦法去阻止web元件二次觸發回撥事件。
在 onpagefinish 事件中設定回撥狀態，如果判斷狀態為true 則表明web已經完成載入，就不用再次發起通訊。這樣處理之後，發現不會再二次觸發了，而且在除錯和測試過程中觀察通訊成功率達到100%。
總結
專案技術選型、架構設計及優化工作都是開發過程的重要因素。一個合理的專案架構會讓開發過程變得省力有趣。相反則會低效，既影響開發體驗也對優化及後續維護、優化不利。
如果各位對我們有什麼意見或建議，歡迎回復我們哦。
覺得不錯的童鞋們請記得點贊、轉發、關注三連哦！！！
從現在起我們的公眾號已改名為“大前端早讀”內容範圍圍繞大前端，也開啟系列篇，更多原創文章請關注我們，
並點選內容系列--原創篇，學習更多：
