近期因為需求與bug比較多，因此有些拖更了。非常抱歉，那么今天的干貨開始了。。。

該篇為“快應(yīng)用”第一篇。歡迎大家閱讀！

自快應(yīng)用問世，到現(xiàn)在也已經(jīng)有一年多了?？鞈?yīng)用和微信小程序類似。都是用戶體驗介于網(wǎng)頁與原生APP之間的新型應(yīng)用模式。微信小程序我想大家都用過，但是快應(yīng)用卻不一定。首先微信小程序問世要比快應(yīng)用早一年，而且靠著微信的用戶社交粘性和閉環(huán)，以及小程序支持安卓與ios端。使得小程序到目前為止，依舊發(fā)展得比快應(yīng)用好。但未來不一定。

快應(yīng)用可以說是9大手機(jī)廠商為了不使微信小程序搶占應(yīng)用流量而出現(xiàn)的吧。

畢竟微信小程序是以微信為載體，是一種二級應(yīng)用，打開小程序前必須要打開微信的占用內(nèi)存。而快應(yīng)用是手機(jī)廠商出品的，不需要以某個為載體，直接操作系統(tǒng)打開，屬于一級應(yīng)用?？梢灾苯诱{(diào)用底層系統(tǒng)功能。其實廠商可根據(jù)其優(yōu)勢，提升手機(jī)的原生性能，使得其強(qiáng)于微信小程序的體驗也是可以的，不過這得待后期發(fā)展了。

現(xiàn)在我們從技術(shù)角度來說說開發(fā)快應(yīng)用吧！

按快應(yīng)用腳手架工具初始化的項目基本能滿足一般的項目開發(fā)需求了。比如現(xiàn)在初始化一個

hap init hiquick

項目：

得到一個如下結(jié)構(gòu)的項目目錄：

├── sign //rpk包簽名模塊

├── src

│   ├── Common //公用的資源和組件文件

│   ├── Demo //頁面目錄

│   │  └── index.ux //頁面文件，可自定義頁面名稱

│   ├── app.ux //APP文件，可引入公共腳本，暴露公共數(shù)據(jù)和方法等

│   └── manifest.json //項目配置文件，配置應(yīng)用圖標(biāo)、頁面路由等

其中 Demo 目錄即是一個頁面目錄，包含一個 ux 后綴的頁面文件。項目構(gòu)建運(yùn)行之后，還會產(chǎn)生 build/、dist/ 兩個目錄。build 是打包構(gòu)建后生成的 js 文件、dist 則是 rpk 安裝包。

在我們實際項目中由于業(yè)務(wù)比較復(fù)雜，會創(chuàng)建很多頁面，這樣平鋪在根目錄下，造成文件夾過多不易管理維護(hù)。

于是我們新建一個文件夾 pages 專門存放頁面，這樣項目結(jié)構(gòu)就變成了：

├── sign 

├── src

│   ├── common //公用資源、全局配置

│   ├── components //公用組件

│   ├── pages                  

│   │  ├── index //頁面目錄

│   │  │  └── index.ux //頁面文件

│   │  └── login

│   ├── app.ux

改造后的目錄結(jié)構(gòu)更直觀、簡潔。不過要記得去修改默認(rèn)的頁面路由配置：router.pages、display.pages 兩項的頁面鍵值要改和頁面路徑一致。如這里首頁的配置就是 pages/index。

除了新增 pages 目錄，還新增了 components 文件夾和更改 common 文件夾的用途。

新增的 components 文件夾專門存放公用的組件文件，而 common 則專門用來存放公共資源、工具方法和全局配置等文件。這樣使得目錄的功能區(qū)分更明白了，也為后面的代碼復(fù)用作好了基礎(chǔ)準(zhǔn)備。

其中全局配置的配置項皆以模塊化輸出，既對變量有一個統(tǒng)一的維護(hù)管理，也方便在業(yè)務(wù)直接引入調(diào)用，一舉兩得，非常高效。

上面已經(jīng)說了我們?yōu)樗许撁鎸ｉT建立了一個 pages 文件夾。從中可以看出應(yīng)用中的所有頁面是平級劃分的。雖然在業(yè)務(wù)邏輯上可能存在父子關(guān)系，但實際頁面沒必要分出從屬，那樣只會增加頁面關(guān)系的復(fù)雜度。

但這里有一個特殊頁面還是設(shè)計了父子關(guān)系。這么做也恰恰想表明頁面間從屬關(guān)系。這就是 pages/index 頁面，為了避免概念混淆，這里先稱之為索引頁。因為它正是起著索引導(dǎo)航作用的，并不是常規(guī)意義上的首頁。

通常，一個APP的界面是這樣的：

在界面底部會有一個導(dǎo)航菜單欄，叫做 TabBar，然而快應(yīng)用并沒有這種組件。雖然利用頁面路由可以做導(dǎo)航，但效果并不理想，切換過來的頁面都需要重新加載。由于頁面中已經(jīng)使用了 tabs 組件，使用tabs組件實現(xiàn)也不可行。

剩下就需要自己動手打造了。既要實現(xiàn)頁面導(dǎo)航，又要實現(xiàn)頁面緩存的功能。

簡要分析下組件的設(shè)計思路。

1. 在單頁內(nèi)實現(xiàn)不同頁面的切換，功能相當(dāng)于一個Tab。

2. 功能區(qū)分為tab標(biāo)簽欄和tab內(nèi)容區(qū)。

3. 標(biāo)簽的項目不能寫死，要可以自由擴(kuò)展。

4. 每個標(biāo)簽對應(yīng)的頁面以組件形式引入。

在 index.ux 頁面需要引入 TabBar 頁面組件。作為子組件，為方便管理，我們把這些子頁面組件作為子文件夾放在 index/ 下管理維護(hù)，一目了然地表明頁面的從屬關(guān)系，整體項目的頁面切分工作也完成了。

│   ├── pages                  

│   │  ├── index //索引導(dǎo)航目錄

│   │  │  ├── subpages //子頁面目錄

│   │  │  │  ├── featured //子頁面

│   │  │  │  │  └── index.ux  //子頁面組件文件

│   │  │  │  └── member

│   │  │  │       └── index.ux

上面 TabBar 的功能設(shè)計還忽略一點，就是子頁面組件更新的問題。為此做了監(jiān)聽標(biāo)簽切換及頁面 onShow 事件觸發(fā)組件更新的處理，這里不做詳細(xì)說明。

下面著重來說下公共代碼部分，公共代碼及組件化向來都是項目中的重點部分，這部分作好了，會使得項目代碼越寫越少，越寫越高率。相反，如果這部分沒有做好，不僅會讓項目代碼變得一團(tuán)糟，不斷地重復(fù)工作，還極有可能會埋下一些潛在的危險。

比如項目中公用的一個參數(shù)，分別寫在各個地方，等到需要更改時，很可能改了一個地方而忘了另一個地方，等到出錯還不容易排查問題出在哪里。如果統(tǒng)一在一處配置好，其它所有地方只引入這個配置，則會從根本上規(guī)避這個低級錯誤。

當(dāng)然這只是做好公共管理的優(yōu)點之一。

公共代碼和組件化開發(fā)應(yīng)該深入到任何項目的任何角落，應(yīng)該時刻保持這種意識。

在快應(yīng)用項目中我們將公共資源、公共代碼都放在了 common 文件夾下。包含全局基礎(chǔ)樣式文件、圖片資源、配置項文件、和工具方法。

配置項文件 config.js 集中管理全局使用的常量和API接口地址，并對依賴不同域名環(huán)境下的配置項做自動切換處理。

工具方法 utils.js 將可復(fù)用的工具函數(shù)方法抽象出來，并以模塊化形式導(dǎo)出，方便其它模塊中按需引入，而不需要在不同的地方重復(fù)地寫同一個工具方法了。

再來說說組件化，這也是項目開發(fā)中的重點。

組件化應(yīng)該是在項目一開始就需要著手考慮的事情，原則上在交互稿評審階段就需要開始了。分析出哪些部件可以提取抽象出公共組件。這樣多人協(xié)作的項目中，共同開發(fā)將變得非常有效率。

快應(yīng)用項目目前拆分出的公共組件有圖文展示組件、TitleBar頁面標(biāo)題欄組件、錯誤狀態(tài)提示組件、章節(jié)目錄組件等（排除快應(yīng)用框架自身的組件）。

TitleBar組件實現(xiàn)自定義的頭部標(biāo)題樣式，在默認(rèn)的標(biāo)題欄不滿足需求時可以使用該組件實現(xiàn)。

錯誤狀態(tài)提示也是復(fù)用較高的組件，在處理無網(wǎng)絡(luò)、暫無數(shù)據(jù)等狀態(tài)下都可以直接引用。大大減少代碼的重復(fù)開發(fā)工作。

除了以上的改造優(yōu)化外，性能的優(yōu)化也是無法繞開的。開發(fā)過程中除了基本該做的優(yōu)化要做到之外，能發(fā)現(xiàn)的性能問題也應(yīng)該尋找方案解決。當(dāng)然如果時間不允許或者暫無方案解決則另當(dāng)別論。

那快應(yīng)用項目中所做的性能優(yōu)化工作列舉幾點如下。

TabBar頁面導(dǎo)航優(yōu)化

前面說了TabBar的設(shè)計思路，也提到了設(shè)計的意義，涉及的主要優(yōu)化有：

1. 按需加載，首次只加載默認(rèn)標(biāo)簽頁。

2. 頁面緩存，避免切換時頁面的重復(fù)加載。

3. 返回鍵退出應(yīng)用，避免路由鏈路過長。

TabBar配置的標(biāo)簽項，默認(rèn)只會加載其中一個頁面，這個初始展示的頁面由配置項 currentTabName 決定。點擊其它標(biāo)簽后，才加載對應(yīng)的頁面。頁面加載完成后，再次切換標(biāo)簽，已加載的頁面則是顯示或隱藏，不會重新加載渲染。提高了用戶使用體驗的同時，也節(jié)約了沒必要的網(wǎng)絡(luò)請求。

前面也提到直接使用路由跳轉(zhuǎn)也是可以實現(xiàn)類似的效果。使用路由來實現(xiàn)，技術(shù)復(fù)雜度會大大降低，但使用感受也比較糟糕。除了切換時頁面重復(fù)加載渲染之外 ，頁面棧也會隨著不斷切換而加大，這時如果想返回則會走很長的鏈接。雖然可以通過設(shè)置replace路由替換規(guī)避，但頁面重復(fù)加載渲染是避免不了的。

快應(yīng)用與web組件的通信優(yōu)化

快應(yīng)用的訂購環(huán)節(jié)由于技術(shù)限制，需要引用web組件來加載HTML頁面實現(xiàn)訂購。交易環(huán)節(jié)事關(guān)重大，功能上容不得半點差錯，性能上要保證穩(wěn)定可靠。技術(shù)上涉及到快應(yīng)用與HTML之間的通信。而在調(diào)試過程中卻發(fā)現(xiàn)了通信機(jī)制的一個Bug。

起始在開發(fā)中發(fā)現(xiàn)web組件存在通信不穩(wěn)定的問題，初步判定為可能頁面還未加載完成。為保證通信的可靠性，我們在頁面加載完成的回調(diào)事件 onpagefinish 中發(fā)起通信。然而web組件會自動觸發(fā)兩次 onpagefinish 回調(diào)。原因暫時不明確，問題也和官方溝通過?？傊@會造成HTML中監(jiān)聽通信的請求也發(fā)送兩次。于是想辦法去阻止web組件二次觸發(fā)回調(diào)事件。

在 onpagefinish 事件中設(shè)置回調(diào)狀態(tài)，如果判斷狀態(tài)為true 則表明web已經(jīng)完成加載，就不用再次發(fā)起通信。這樣處理之后，發(fā)現(xiàn)不會再二次觸發(fā)了，而且在調(diào)試和測試過程中觀察通信成功率達(dá)到100%。

項目技術(shù)選型、架構(gòu)設(shè)計及優(yōu)化工作都是開發(fā)過程的重要因素。一個合理的項目架構(gòu)會讓開發(fā)過程變得省力有趣。相反則會低效，既影響開發(fā)體驗也對優(yōu)化及后續(xù)維護(hù)、優(yōu)化不利。

如果各位對我們有什么意見或建議，歡迎回復(fù)我們哦。

覺得不錯的童鞋們請記得點贊、轉(zhuǎn)發(fā)、關(guān)注三連哦?。?！

從現(xiàn)在起我們的公眾號已改名為“大前端早讀”內(nèi)容范圍圍繞大前端，也開啟系列篇，更多原創(chuàng)文章請關(guān)注我們，

并點擊內(nèi)容系列--原創(chuàng)篇，學(xué)習(xí)更多：