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

該篇為“快應用”第一篇。歡迎大家閱讀！

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

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

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

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

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

hap init hiquick

項目：

得到一個如下結構的項目目錄：

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

├── src

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

│   ├── Demo //頁面目錄

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

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

│   └── manifest.json //項目配置文件，配置應用圖標、頁面路由等

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

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

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

├── sign 

├── src

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

│   ├── components //公用組件

│   ├── pages                  

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

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

│   │  └── login

│   ├── app.ux

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

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

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

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

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

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

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

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

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

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

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

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

3. 標簽的項目不能寫死，要可以自由擴展。

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

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

│   ├── pages                  

│   │  ├── index //索引導航目錄

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

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

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

│   │  │  │  └── member

│   │  │  │       └── index.ux

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

快應用的訂購環(huán)節(jié)由于技術限制，需要引用web組件來加載HTML頁面實現(xiàn)訂購。交易環(huán)節(jié)事關重大，功能上容不得半點差錯，性能上要保證穩(wěn)定可靠。技術上涉及到快應用與HTML之間的通信。而在調(diào)試過程中卻發(fā)現(xiàn)了通信機制的一個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 事件中設置回調(diào)狀態(tài)，如果判斷狀態(tài)為true 則表明web已經(jīng)完成加載，就不用再次發(fā)起通信。這樣處理之后，發(fā)現(xiàn)不會再二次觸發(fā)了，而且在調(diào)試和測試過程中觀察通信成功率達到100%。

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

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

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

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

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