快應用開發優化技巧
2018年3月，華為、小米、OPPO等九大手機廠商共同發布了快應用?？鞈脴藴视芍髁魇謾C廠商組成的快應用聯盟共同制定，其擁有傳統app的應用體驗，同時又具備無需安裝、即點即用的特點。其實，早在2013年，百度曾推出了輕應用，2017年，騰訊又推出了小程序，之后，阿里也推出了支付寶的小程序。業務細節上，它們各有不同，但大體上定位是類似的，如同當年CS架構轉向BS架構一樣，這種無需安裝、即點即用的應用形式，正在成為app市場新的趨勢。
閑言少敘,書歸正傳。本文的目的，是為了讓大家了解到快應用開發常用的優化手段，提升對應用代碼整理的組織能力，合理拆分功能模塊，從而使項目更易維護，提高工作效率。至于如何搭建開發環境，開發流程以及系統api的描述，大家均可在快應用的官方文檔中找到。本文將介紹快應用開發的優化技巧。
快應用開發采用前端技術棧，其優化方式主要可從以下四方面進行：
- 數據共享
- 性能優化
- 錯誤處理
- 結構優化
數據共享
在快應用開發中，開發者需要了解頁面與APP之間，頁面與頁面之間的數據共享方式。其實不止快應用，任何前端工程都需要考慮這個問題，如react開發中，引入redux可方便統一管理數據源，在快應用開發中，可以通過使用框架API或使用全局變量global兩種方式實現數據共享。
1. 框架API
開發者可以在頁面ViewModel中，通過this.$app.$def獲取APP上定義的數據及方法。
但這種方式的缺點在于需要依賴ViewModel實例，然而，很多全局方法與生命周期無關。全局變量global作為獨立于應用生命周期的引用，理應成為開發者的***。
2. 全局變量global
在app.ux、${anyPage}.ux中，開發者都可以使用變量global。然而，頁面與APP之間，頁面與頁面之間的變量global并不相同，引用的值指向不同的對象；雖然不相同，但它們的原型都指向同一個全局的對象。因此，開發者可以在這個全局對象上定義變量，這樣在任何JS中均可訪問。同樣，這種方式也存在缺點，比如存在污染全局環境，在復雜場景下容易引發難以復現的BUG等問題。
性能優化
1. 更合理的Dom結構
Dom節點是構成頁面最基本的元素，盡量使用符合語義的標簽，同時減少Dom層級結構會對頁面的可讀性及性能都會有明顯提升。
2. 更有效的選擇器
快應用的開發框架支持后代選擇器，這對開發者提供了很大的便利，但與此同時，后代選擇器的性能損耗是相對較大的，如使用不得當，會對頁面性能造成較多損耗。
我們首先要知道，CSS選擇器是由右向左解釋的。看以下選擇器
#container > a {font-weight:blod;}
對于很多剛開始了解css的朋友來說，通常會認為，該選擇器先找到id為container的元素，然后將字體加粗效果應用到直系子元素中的 a 元素上，應該是個高效的選擇器。然而事實并非如此，瀏覽器首先會便利頁面中所有的a元素，然后篩選出父元素id為container的節點。所以這個看似高效的選擇器，其實也是花費了不少的開銷。
了解到這個規則后，對于后代選擇器的使用，我們建議做到以下幾點優化。
- 避免使用組件名稱作為后代選擇的***一項匹配規則，越是基礎的組件，復用度就越多，越是要避免。如： .container #doc text { ... }；否則每個text組件渲染時都會遍歷匹配一次
- 減少后代選擇的層級數量，層級越深，單次匹配耗時則成指數式增長。
- 后代選擇中***一條匹配規則的定義名稱盡量唯一，如：.container #doc .doc-item .doc-name-zh{ ... }
3. 圖片優化
在前端開發中，圖片通常占據了較大的空間。較多的圖片資源也意味著較多的http請求，在相同帶寬條件下，下載一個200k的圖片，一定比下載兩次100k的圖片速度更快。建議可以做幾下幾點優化。
- 使用CSS Sprites，其實就是把網頁中一些背景圖片整合到一張圖片文件中，再利用CSS的“background-image”，“background-repeat”，“background-position”的組合進行背景定位，這種方式***的優點就是減少了http請求，大大提高了網頁性能。話說回來，這種方式也有缺點，比如開發起來會相對麻煩。
- 對于頁面上簡單的圖標文件，可盡量使用css3實現，或矢量圖代替，這樣也能明顯減少圖片占用的空間，提高性能。
- 避免圖片壓縮，如果頁面中用不到較大的圖片，就完全沒必要通過css去壓縮圖片以適應需求。直接使用小圖或其他可替代方式更加明智。
4. 簡化ViewModel的data屬性
數據驅動是當下流行的前端開發形式，在快應用中也是如此。在ViewModel的定義中，data屬性主要承擔數據驅動的數據定義，會對賦值的data中每個屬性進行遞歸式的定義。因此，屬性定義語義結構越清晰且數量越少，則質量越高。
例如，當我們發出fetch請求，返回結果中包含了很多數據，而前端需要顯示的數據只是其中很少一部分，則在該頁面的data中，就只需要定義前端需要顯示的數據即可，如下面的示例代碼片段。
// fetch請求返回的數據，數據量大，而data中只需要其中部分數據
const tradeInfoList = [
{
"_id" : "5c31aa2a565e9938214da13b",
"currentPrice" : 1,
"tradePrice" : 1,
"userId" : "admin",
"tradeAmount" : 600,
"stockInfo" : {
"code" : "000008",
"name" : "股票8",
"price" : 1,
"des" : "描述8"
}
},
{
// ...
}
]
export default {
data () {
return {
list: []
}
},
onInit () {
// 返回頁面中需要的對象屬性，過濾其他屬性
this.list = tradeInfoList.map(item => {
userId: item.userId,
tradePrice: item.tradePrice
})
}
}
5. 懶加載
懶加載是一種通用的優化手段，傳統H5頁面中的懶加載，指的是頁面即將進入屏幕可視區域時，才加載資源，渲染頁面。這樣，給用戶直觀的感受就是，頁面加載速度變快了。在快應用開發中，可使用指令或事件觸發來實現懶加載。
比如很常見的場景，一個包含list組件的頁面，我們開始只渲染前十條數據，當頁面下滑至某位置時，觸發加載更多來完成渲染。
錯誤處理
前端開發中，一旦程序執行出錯，就會報出JS異常彈框。
1. 訪問null或undefined的屬性
以上的這種錯誤可能是最常見的一種了，在稍微復雜的業務邏輯代碼中，多加判空條件，是避免這種錯誤的最簡易方式。即便某些數據在定義時是必須存在的，但我們無法完全保證，存在各種原因導致這些數據為空或undefined。保證代碼的嚴謹性，是應對不確定性異常的根本方式。當然有些稍微復雜的情況下，需要特殊處理，如后兩種場景。
2. JSON.parse解析出錯
這種錯誤也十分常見。當我們轉換一個JSON字符串時，如果這個字符串的格式并不是一個標準的JSON格式，那轉換肯定失敗?？梢栽贘SON.parse()時，使用try-catch進行包裹，以便對錯誤信息進行分析，如
當然，在每處JSON.parse()的地方都執行try-catch會有些麻煩，更推薦的方式是，在app.ux中提前代理JSON.parse()，使用try-catch包圍，如
export function parseProxy() {
const rawParse = JSON.parse JSON.parse = function (str, defaults) {
try {
return rawParse(str)
} catch (err) {
console.error( ` JSON解析失?。? {str}, $ {err.stack}` )return defaults
}
}
}
3、ViewModel回調函數異常場景
用戶打開PageA，然后在該頁面中執行接口方法（如fetch請求），然后立即跳轉到PageB；此時接口的回調函數返回，但PageA已經出棧銷毀，此時，執行開發者傳遞的回調函數報錯。
這是由于，回調函數中訪問了一些data數據等，而這些ViewModel的數據屬性已經伴隨著頁面銷毀而刪除了，所以引起報錯。對于這種異常，通?？刹捎靡韵路绞浇鉀Q。
A. 在回調函數執行之前，通過ViewModel對象的$valid、$visible判斷頁面狀態
B. 在Function.prototype上定義方法，關聯到每個回調函數綁定ViewModel實例。
/**
* 在Function原型上定義bindPage方法：將回調函數綁定到頁面對象，頁面不可見或者銷毀時，不執行回調函數
*/
export function bindPageLC () {
Function.prototype.bindPage = function (vmInst) {
const fn = this
return function () {
if (!vmInst) {
throw new Error(`使用錯誤：請傳遞VM對象`)
}
if (vmInst.$valid && vmInst.$visible) {
return fn(...arguments)
}
else {
console.info(`頁面不可見或者銷毀時，不執行回調函數`)
}
}
}
}
在${anyPage}.ux中，通過fn.bindPage(this)，在回調函數上綁定ViewModel實例
export default {
data () {
return {}
},
request () {
// 調用bindPage(this)返回：綁定了頁面對象的回調函數，當頁面不可見或者銷毀時，不執行回調函數
fetch.fetch({
success: function(ret) {
// 數據操作等
}.bindPage(this)
})
}
}
C. 通常在頁面發送請求時，頁面需要添加loading處理，以防止用戶在此時進行其他操作，當然這種方式是從業務角度規避了這個異常。不過確是一種很常用的方式?？山Y合方式B以保證代碼嚴謹性。
結構優化
結構優化的目的是減小頁面以及整體rpk包的體積，減少冗余代碼
常用的手段有以下幾項：
A. 在app.ux中引入常用的JS庫，并暴露給每個頁面使用；可以避免每個頁面在打包時對JS的重復定義
B. 項目內部的代碼抽象封裝，如封裝常用的工具類函數，封裝統一的Fetch請求方法，這些封裝可作為公共方法提供給各個頁面，便于維護的同時，也有效降低了代碼量。
結尾
優化的目的是為了提高代碼的可維護性以及應用性能，可以說，正是多種多樣的優化手段，讓邏輯性極強的代碼變的充滿藝術性。為了越發優雅地完成編碼，我相信這個話題會一直探討下去。
