【快應用篇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組件實現也不可行。

剩下就須要本身動手打造了。既要實現頁面導航，又要實現頁面緩存的功能。

簡要分析下組件的設計思路。

1. 在單頁內實現不一樣頁面的切換，功能至關於一個Tab。

2. 功能區分爲tab標籤欄和tab內容區。

3. 標籤的項目不能寫死，要能夠自由擴展。

4. 每一個標籤對應的頁面以組件形式引入。

在 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的設計思路，也提到了設計的意義，涉及的主要優化有：

1. 按需加載，首次只加載默認標籤頁。

2. 頁面緩存，避免切換時頁面的重複加載。

3. 返回鍵退出應用，避免路由鏈路過長。

TabBar配置的標籤項，默認只會加載其中一個頁面，這個初始展現的頁面由配置項 currentTabName 決定。點擊其它標籤後，才加載對應的頁面。頁面加載完成後，再次切換標籤，已加載的頁面則是顯示或隱藏，不會從新加載渲染。提升了用戶使用體驗的同時，也節約了不必的網絡請求。

前面也提到直接使用路由跳轉也是能夠實現相似的效果。使用路由來實現，技術複雜度會大大下降，但使用感覺也比較糟糕。除了切換時頁面重複加載渲染以外 ，頁面棧也會隨着不斷切換而加大，這時若是想返回則會走很長的連接。雖然能夠經過設置replace路由替換規避，但頁面重複加載渲染是避免不了的。

快應用與web組件的通訊優化

快應用的訂購環節因爲技術限制，須要引用web組件來加載HTML頁面實現訂購。交易環節事關重大，功能上容不得半點差錯，性能上要保證穩定可靠。技術上涉及到快應用與HTML之間的通訊。而在調試過程當中卻發現了通訊機制的一個Bug。

起始在開發中發現web組件存在通訊不穩定的問題，初步斷定爲可能頁面還未加載完成。爲保證通訊的可靠性，咱們在頁面加載完成的回調事件 onpagefinish 中發起通訊。然而web組件會自動觸發兩次 onpagefinish 回調。緣由暫時不明確，問題也和官方溝經過。總之這會形成HTML中監聽通訊的請求也發送兩次。因而想辦法去阻止web組件二次觸發回調事件。

在 onpagefinish 事件中設置回調狀態，若是判斷狀態爲true 則代表web已經完成加載，就不用再次發起通訊。這樣處理以後，發現不會再二次觸發了，並且在調試和測試過程當中觀察通訊成功率達到100%。

總結

項目技術選型、架構設計及優化工做都是開發過程的重要因素。一個合理的項目架構會讓開發過程變得省力有趣。相反則會低效，既影響開發體驗也對優化及後續維護、優化不利。

若是各位對咱們有什麼意見或建議，歡迎回復咱們哦。

以爲不錯的童鞋們請記得點贊、轉發、關注三連哦！！！

從如今起咱們的公衆號已更名爲「大前端早讀」內容範圍圍繞大前端，也開啓系列篇，更多原創文章請關注咱們，

並點擊內容系列--原創篇，學習更多：