蜘蛛池出租

近期因?yàn)樾枨笈cbug比較多，因此有些拖更了。非常抱歉，那么今天的干貨開(kāi)始了。。。

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

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

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

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

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

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

hap init hiquick

項(xiàng)目：

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

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

├── src

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

│   ├── Demo //頁(yè)面目錄

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

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

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

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

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

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

├── sign 

├── src

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

│   ├── components //公用組件

│   ├── pages                  

│   │  ├── index //頁(yè)面目錄

│   │  │  └── index.ux //頁(yè)面文件

│   │  └── login

│   ├── app.ux

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

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

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

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

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

但這里有一個(gè)特殊頁(yè)面還是設(shè)計(jì)了父子關(guān)系。這么做也恰恰想表明頁(yè)面間從屬關(guān)系。這就是 pages/index 頁(yè)面，為了避免概念混淆，這里先稱之為索引頁(yè)。因?yàn)樗瞧鹬饕龑?dǎo)航作用的，并不是常規(guī)意義上的首頁(yè)。

通常，一個(gè)APP的界面是這樣的：

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

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

簡(jiǎn)要分析下組件的設(shè)計(jì)思路。

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

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

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

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

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

│   ├── pages                  

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

│   │  │  ├── subpages //子頁(yè)面目錄

│   │  │  │  ├── featured //子頁(yè)面

│   │  │  │  │  └── index.ux  //子頁(yè)面組件文件

│   │  │  │  └── member

│   │  │  │       └── index.ux

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

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

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

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

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

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

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

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

再來(lái)說(shuō)說(shuō)組件化，這也是項(xiàng)目開(kāi)發(fā)中的重點(diǎn)。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

覺(jué)得不錯(cuò)的童鞋們請(qǐng)記得點(diǎn)贊、轉(zhuǎn)發(fā)、關(guān)注三連哦?。?！

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

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