U盤加密狗複製軟件

京喜小程序自去年雙十一上線微信購物一級入口後，時刻迎接着億級用戶量的挑戰，細微的體驗細節都有可能被無限放大，爲此，「極致的頁面性能」、「友好的產品體驗」 和 「穩定的系統服務」 成爲了咱們開發團隊的最基本執行原則。

首頁做爲小程序的門戶，其性能表現和用戶留存率息息相關。所以，咱們對京喜首頁進行了一次全方位的升級改造，從加載、渲染和感知體驗幾大維度深挖小程序的性能可塑性。

除此以外，京喜首頁在微信小程序、H五、APP 三端都有落地場景，爲了提升研發效率，咱們使用了 Taro 框架實現多端統一，所以下文中有部份內容是和 Taro 框架息息相關的。

怎麼定義高性能？

提起互聯網應用性能這個詞，不少人在腦海中的詞法解析就是，「是否足夠快？」，彷佛加載速度成爲衡量系統性能的惟一指標。但這實際上是不夠準確的，試想一下，若是一個小程序加載速度很是快，用戶花費很短期就能看到頁面的主體內容，但此時搜索框卻沒法輸入內容，功能沒法被流暢使用，用戶可能就不會關心頁面渲染有多快了。因此，咱們不該該單純考慮速度指標而忽略用戶的感知體驗，而應該全方位衡量用戶在使用過程當中能感知到的與應用加載相關的每一個節點。

谷歌爲 Web 應用定義了以用戶爲中心的性能指標體系，每一個指標都與用戶體驗節點息息相關：

體驗

指標

頁面可否正常訪問？

首次內容繪製 (First Contentful Paint, FCP)

頁面內容是否有用？

首次有效繪製 (First Meaningful Paint, FMP)

頁面功能是否可用？

可交互時間 (Time to Interactive, TTI)

其中，「是否有用？」 這個問題是很是主觀的，對於不一樣場景的系統可能會有徹底不同的回答，因此 FMP 是一個比較模糊的概念指標，不存在規範化的數值衡量。

小程序做爲一個新的內容載體，衡量指標跟 Web 應用是很是相似的。對於大多數小程序而言，上述指標對應的含義爲：

• FCP：白屏加載結束；
• FMP：首屏渲染完成；
• TTI：全部內容加載完成；

綜上，咱們已基本肯定了高性能的概念指標，接下來就是如何利用數值指標來描繪性能表現。

小程序官方性能指標

小程序官方針對小程序性能表現制訂了權威的數值指標，主要圍繞 渲染表現、setData 數據量、元素節點數 和 網絡請求延時 這幾個維度來給予定義（下面只列出部分關鍵指標）：

• 首屏時間不超過 5 秒；
• 渲染時間不超過 500ms；
• 每秒調用 setData 的次數不超過 20 次；
• setData 的數據在 JSON.stringify 後不超過 256kb；
• 頁面 WXML 節點少於 1000 個，節點樹深度少於 30 層，子節點數不大於 60 個；
• 全部網絡請求都在 1 秒內返回結果；

詳見 小程序性能評分規則

咱們應該把這一系列的官方指標做爲小程序的性能及格線，不斷地打磨和提高小程序的總體體驗，下降用戶流失率。另外，這些指標會直接做爲小程序體驗評分工具的性能評分規則（體驗評分工具會根據這些規則的權重和求和公式計算出體驗得分）。

咱們團隊內部在官方性能指標的基礎上，進一步濃縮優化指標係數，旨在對產品體驗更高要求：

• 首屏時間不超過 2.5 秒；
• setData 的數據量不超過 100kb；
• 全部網絡請求都在 1 秒內返回結果；
• 組件滑動、長列表滾動無卡頓感；

體驗評分工具

小程序提供了 體驗評分工具（Audits 面板） 來測量上述的指標數據，其集成在開發者工具中，在小程序運行時實時檢查相關問題點，併爲開發者給出優化建議。

以上截圖均來自小程序官方文檔

體驗評分工具是目前檢測小程序性能問題最直接有效的途徑，咱們團隊已經把體驗評分做爲頁面/組件是否能達到精品門檻的重要考量手段之一。

小程序後臺性能分析

咱們知道，體驗評分工具是在本地運行小程序代碼時進行分析，但性能數據每每須要在真實環境和大數據量下才更有說服力。恰巧，小程序管理平臺 和 小程序助手 爲開發者提供了大量的真實數據統計。其中，性能分析面板從 啓動性能、運行性能 和 網絡性能 這三個維度分析數據，開發者能夠根據客戶端系統、機型、網絡環境和訪問來源等條件作精細化分析，很是具備考量價值。

其中，啓動總耗時 = 小程序環境初始化 + 代碼包加載 + 代碼執行 + 渲染耗時

第三方測速系統

不少時候，宏觀的耗時統計對於性能瓶頸點分析每每是杯水車薪，做用甚少，咱們須要更細緻地針對某個頁面某些關鍵節點做測速統計，排查出暴露性能問題的代碼區塊，才能更有效地針對性優化。京喜小程序使用的是內部自研的測速系統，支持對地區、運營商、網絡、客戶端系統等多條件篩選，同時也支持數據可視化、同比分析數據等能力。京喜首頁主要圍繞 頁面 onLoad、onReady、數據加載完成、首屏渲染完成、各業務組件首次渲染完成 等幾個關鍵節點統計測速上報，旨在全鏈路監控性能表現。

另外，微信爲開發者提供了 測速系統，也支持針對客戶端系統、網絡類型、用戶地區等維度統計數據，有興趣的能夠嘗試。

瞭解小程序底層架構

爲了更好地爲小程序制訂性能優化措施，咱們有必要先了解小程序的底層架構，以及與 web 瀏覽器的差別性。

微信小程序是大前端跨平臺技術的其中一種產物，與當下其餘熱門的技術 React Native、Weex、Flutter 等不一樣，小程序的最終渲染載體依然是瀏覽器內核，而不是原生客戶端。

而對於傳統的網頁來講，UI 渲染和 JS 腳本是在同一個線程中執行，因此常常會出現 「阻塞」 行爲。微信小程序基於性能的考慮，啓用了雙線程模型：

• 視圖層：也就是 webview 線程，負責啓用不一樣的 webview 來渲染不一樣的小程序頁面；
• 邏輯層：一個單獨的線程執行 JS 代碼，能夠控制視圖層的邏輯；

上圖來自小程序官方開發指南

然而，任何線程間的數據傳輸都是有延時的，這意味着邏輯層和視圖層間通訊是異步行爲。除此以外，微信爲小程序提供了不少客戶端原生能力，在調用客戶端原生能力的過程當中，微信主線程和小程序雙線程之間也會發生通訊，這也是一種異步行爲。這種異步延時的特性會使運行環境複雜化，稍不注意，就會產出效率低下的編碼。

做爲小程序開發者，咱們經常會被下面幾個問題所困擾：

• 小程序啓動慢；
• 白屏時間長；
• 頁面渲染慢；
• 運行內存不足；

接下來，咱們會結合小程序的底層架構分析出這些問題的根本緣由，並針對性地給出解決方案。

小程序啓動太慢？

小程序啓動階段，也就是以下圖所示的展現加載界面的階段。

在這個階段中（包括啓動先後的時機），微信會默默完成下面幾項工做：

1. 準備運行環境：

在小程序啓動前，微信會先啓動雙線程環境，並在線程中完成小程序基礎庫的初始化和預執行。

小程序基礎庫包括 WebView 基礎庫和 AppService 基礎庫，前者注入到視圖層中，後者注入到邏輯層中，分別爲所在層級提供其運行所需的基礎框架能力。

2. 下載小程序代碼包：

在小程序初次啓動時，須要下載編譯後的代碼包到本地。若是啓動了小程序分包，則只有主包的內容會被下載。另外，代碼包會保留在緩存中，後續啓動會優先讀取緩存。

3. 加載小程序代碼包：

小程序代碼包下載好以後，會被加載到適當的線程中執行，基礎庫會完成全部頁面的註冊。

在此階段，主包內的全部頁面 JS 文件及其依賴文件都會被自動執行。

在頁面註冊過程當中，基礎庫會調用頁面 JS 文件的 Page 構造器方法，來記錄頁面的基礎信息（包括初始數據、方法等）。

4. 初始化小程序首頁：

在小程序代碼包加載完以後，基礎庫會根據啓動路徑找到首頁，根據首頁的基礎信息初始化一個頁面實例，並把信息傳遞給視圖層，視圖層會結合 WXML 結構、WXSS 樣式和初始數據來渲染界面。

綜合考慮，爲了節省小程序的「點點點」時間（小程序的啓動動畫是三個圓點循環跑馬燈），除了給每位用戶發一臺高配 5G 手機並順帶提供千兆寬帶網絡以外，還能夠儘可能 控制代碼包大小，縮小代碼包的下載時間。

無用文件、函數、樣式剔除

通過屢次業務迭代，無可避免的會存在一些棄用的組件/頁面，以及不被調用的函數、樣式規則，這些冗餘代碼會白白佔據寶貴的代碼包空間。並且，目前小程序的打包會將工程下全部文件都打入代碼包內，並無作依賴分析。

所以，咱們須要及時地剔除再也不使用的模塊，以保證代碼包空間利用率保持在較高水平。經過一些工具化手段能夠有效地輔助完成這一工做。

• 文件依賴分析

在小程序中，全部頁面的路徑都須要在小程序代碼根目錄 app.json 中被聲明，相似地，自定義組件也須要在頁面配置文件 page.json 中被聲明。另外，WXML、WXSS 和 JS 的模塊化都須要特定的關鍵字來聲明依賴引用關係。

WXML 中的 import 和 include：

<!-- A.wxml -->
<template name='A'>
  <text>{{text}}</text>
</template>

<!-- B.wxml -->
<import src="A.wxml"/>
<template is="A" data="{{text: 'B'}}"/>
複製代碼

<!-- A.wxml -->
<text> A </text>

<!-- B.wxml -->
<include src="A.wxml"/>
<text> B </text>
複製代碼

WXSS 中的 @import：

@import './A.wxss'
複製代碼

JS 中的 require/import：

const A = require('./A')
複製代碼

因此，能夠說小程序裏的全部依賴模塊都是有跡可循的，咱們只須要利用這些關鍵字信息遞歸查找，遍歷出文件依賴樹，而後把沒用的模塊剔除掉。

• JS、CSS Tree-Shaking

JS Tree-Shaking 的原理就是藉助 Babel 把代碼編譯成抽象語法樹（AST），經過 AST 獲取到函數的調用關係，從而把未被調用的函數方法剔除掉。不過這須要依賴 ES module，而小程序最開始是遵循 CommonJS 規範的，這意味着是時候來一波「痛並快樂着」的改造了。

而 CSS 的 Tree-Shaking 能夠利用 PurifyCSS 插件來完成。關於這兩項技術，有興趣的能夠「谷歌一下」，這裏就不鋪開細講了。

題外，京東的小程序團隊已經把這一系列工程化能力集成在一套 CLI 工具中，有興趣的能夠看看這篇分享：小程序工程化探索。

減小代碼包中的靜態資源文件

小程序代碼包最終會通過 GZIP 壓縮放在 CDN 上，但 GZIP 壓縮對於圖片資源來講效果很是低。如 JPG、PNG 等格式文件，自己已經被壓縮過了，再使用 GZIP 壓縮有可能體積更大，得不償失。因此，除了部分用於容錯的圖片必須放在代碼包（譬如網絡異常提示）以外，建議開發者把圖片、視頻等靜態資源都放在 CDN 上。

須要注意， Base64 格式本質上是長字符串，和 CDN 地址比起來也會更佔空間。

邏輯後移，精簡業務邏輯

這是一個 「痛並快樂着」 的優化措施。「痛」 是由於須要給後臺同窗提改造需求，分分鐘被打；「快樂」 則是由於享受刪代碼的過程，並且萬一出 Bug 也不用背鍋了...（開個玩笑）

經過讓後臺承擔更多的業務邏輯，能夠節省小程序前端代碼量，同時線上問題還支持緊急修復，不須要經歷小程序的提審、發佈上線等繁瑣過程。

總結得出，通常不涉及前端計算的展現類邏輯，均可以適當作後移。譬如京喜首頁中的幕簾彈窗（以下圖）邏輯，這裏共有 10+ 種彈窗類型，之前的作法是前端從接口拉取 10+ 個不一樣字段，根據優先級和 「是否已展現」（該狀態存儲在本地緩存） 來決定展現哪種，最後代碼大概是這樣的：

// 檢查每種彈窗類型是否已展現
Promise.all([
  check(popup_1),
  check(popup_2),
  // ...
  check(popup_n)
]).then(result => {
  // 優先級排序
  const queue = [{
    show: result.popup_1
    data: data.popup_1
  }, {
    show: result.popup_2
    data: data.popup_2
  }, 
  // ...
  {
    show: result.popup_n
    data: data.popup_n
  }]
})
複製代碼

邏輯後移以後，前端只需負責拿幕簾字段作展現就能夠了，代碼變成這樣：

this.setData({
  popup: data.popup
})
複製代碼

複用模板插件

京喜首頁做爲電商系統的門戶，須要應對各種頻繁的營銷活動、升級改版等，同時也要知足不一樣用戶屬性的界面個性化需求（俗稱 「千人千面」）。如何既能減小爲應對多樣化場景而產生的代碼量，又能夠提高研發效率，成爲燃眉之急。

相似於組件複用的理念，咱們須要提供更豐富的可配置能力，實現更高的代碼複用度。參考小時候很喜歡玩的 「樂高」 積木玩具，咱們把首頁模塊的模板元素做顆粒度更細的劃分，根據樣式和功能抽象出一塊塊「積木」原料（稱爲插件元素）。當首頁模塊在處理接口數據時，會啓動插件引擎逐個裝載插件，最終輸出個性化的模板樣式，整個流程就比如堆積木。當後續產品/運營須要新增模板時，只要在插件庫中挑選插件排列組合便可，不須要額外新增/修改組件內容，也更不會產生難以維護的 if / else 邏輯，so easy～

固然，要完成這樣的插件化改造免不了幾個先決條件：

• 用戶體驗設計的統一。若是設計風格老是天差地別的，強行插件化只會成爲累贅。
• 服務端接口的統一。同上，若是得浪費大量的精力來兼容不一樣模塊間的接口字段差別，將會很是蛋疼。

下面爲你們提供部分例程來輔助理解。其中，use 方法會接受各種處理鉤子最終拼接出一個 Function，在對應模塊處理數據時會被調用。

// bi.helper.js

/**
 * 插件引擎
 * @param {function} options.formatName 標題處理鉤子
 * @param {function} options.validList 數據校驗器鉤子
 */ 
const use = options => data => format(data)

/**
 * 預置插件庫
 */ 
nameHelpers = {
  text: data => data.text,
  icon: data => data.icon
}
listHelpers = {
  single: list => list.slice(0, 1),
  double: list => list.slice(0, 2)
}

/**
 * 「堆積木」
 */
export default {
  1000: use({
    formatName: nameHelpers.text,
    validList: listHelpers.single
  }),

  1001: use({
    formatName: nameHelpers.icon,
    validList: listHelpers.double
  })
}
複製代碼

<!-- bi.wxml -->
<!-- 各模板節點實現 -->
<template name="renderName">
  <view wx:if="{{type === 'text'}}"> text </view>
  <view wx:elif="{{type === 'icon'}}"> icon </view>
</template>

<view class="bi__name">
  <template is="renderName" data="{{...data.name}"/>
</view>
複製代碼

// bi.js
Component({
  ready() {
    // 根據 tpl 值選擇解析函數
    const formatData = helper[data.tpl]
    this.setData({
      data: formatData(data)
    })
  }
})
複製代碼

分包加載

小程序啓動時只會下載主包/獨立分包，啓用分包能夠有效減小下載時間。（獨立）分包須要遵循一些原則，詳細的能夠看官方文檔：

• 使用分包
• 獨立分包

部分頁面 h5 化

小程序提供了 web-view 組件，支持在小程序環境內訪問網頁。當實在沒法在小程序代碼包中騰出多餘空間時，能夠考慮降級方案 —— 把部分頁面 h5 化。

小程序和 h5 的通訊能夠經過 JSSDK 或 postMessage 通道來實現，詳見 小程序開發文檔。

白屏時間過長？

白屏階段，是指小程序代碼包下載完（也就是啓動界面結束）以後，頁面完成首屏渲染的這一階段，也就是 FMP (首次有效繪製)。

FMP 無法用標準化的指標定義，但對於大部分小程序來講，頁面首屏展現的內容都須要依賴服務端的接口數據，那麼影響白屏加載時間的主要由這兩個元素構成：

• 網絡資源加載時間；
• 渲染時間；

啓用本地緩存

小程序提供了讀寫本地緩存的接口，數據存儲在設備硬盤上。因爲本地 I/O 讀寫（毫秒級）會比網絡請求（秒級）要快不少，因此在用戶訪問頁面時，能夠優先從緩存中取上一次接口調用成功的數據來渲染視圖，待網絡請求成功後再覆蓋最新數據從新渲染。除此以外，緩存數據還能夠做爲兜底數據，避免出現接口請求失敗時頁面空窗，一石二鳥。

但並不是全部場景都適合緩存策略，譬如對數據即時性要求很是高的場景（如搶購入口）來講，展現老數據可能會引起一些問題。

小程序默認會按照 不一樣小程序、不一樣微信用戶 這兩個維度對緩存空間進行隔離。諸如京喜小程序首頁也採用了緩存策略，會進一步按照 數據版本號、用戶屬性 來對緩存進行再隔離，避免信息誤展現。