京東小程序的三生三世

內容來源：2017年3月11日，周偉鵬在「H5夢工廠」進行《京東小程序的三生三世》演講分享。IT大咖說做爲獨家視頻合做方，經主辦方和講者審閱受權發佈。

閱讀字數：2211 | 3分鐘閱讀

摘要

做爲中國最大的自營式電商企業，京東小程序的開發也是一波三折。

「不是每一個人都能看透這三生三世的愛恨交織。」

嘉賓演講視頻地址：t.cn/R9Vtevu

前世

以前京東購物入口的首頁仍是比較複雜的，如今首頁簡化到只有搜索和領券的功能。

初見

一、小程序產品定位

用完即走，觸手可及。

輕量、突出重點，快速直達用戶的核心需求。

優秀的操做體驗。

二、小程序組成

做爲開發者來講，小程序須要WXML、WXSS和JS三部分。WXML和WXSS組成了view層，負責view層的渲染。JS組成了manager層，JS負責整個小程序的邏輯部分。

三、小程序架構

WXML和WXSS負責配置部分，小程序的view層其實仍是Web view的形式。Manger是在app service的部分。

頁面能夠經過JSbridge和app service進行交互，也能夠調用一些native組件。

Manager也是經過JSbridge，額外有一個單獨封裝的API，就能夠直接經過API調用native組件。

四、小程序native組件

小程序的實現方式是經過小程序JSbridge的API，獲取原來Web組件的信息，在Webview上蓋了一層native的組件。

小程序裏具備native能力的組件大概有canvas、video、input、textarea、map和picker。這幾個組件在小程序裏是以native的形式展示出來。

五、與Web端的區別

優勢：

小程序具備native的能力，有掃碼、離線、地圖之類的功能。

它接近原生應用的用戶體驗。

它是相似Web的開發語言，入門門檻低。

提供大量經常使用組件，開發成本低。

自帶ES6支持。

限制：

沒法訪問到真實的DOM節點。

沒法綁定原生事件。

更新須要發版本，微信審覈。

六、京東購物小程序

技術預研：前期咱們作了大量的技術預研。閱讀一些官方文檔、事例代碼，動手編寫demo，也讓一些同事組織了內部技術分享。

組件開發團隊：咱們的開發團隊前端是四我的，「後臺」開發有六我的。

肯定結構及分工：

咱們把小程序分爲page和models、API兩部分。

前端主要負責page部分，包括頁面重構、數據渲染、用戶交互邏輯等等。

Models和API這層是「後臺」開發負責的，它們主要負責數據的獲取、加工，提供公共的API。

制定開發規範：咱們制定了命名規範、接口規範、樣式規範、文檔規範、文件目錄規範和git分支規範。

渡劫

一、手動實現cookie

咱們在開發小程序的時候遇到的第一個問題就是運行環境裏沒有cookie，致使後臺接口沒法驗證登陸態。

利用本地存儲的能力，在得到網絡請求的時候拿到cookie，存到local storage裏。下次髮網絡請求的時候，再從storage裏拿出cookie，手動添加到header裏，實現了手動cookie的過程。

二、用Nginx進行轉發

第二個問題是wx.request的合法域名最多爲10個，致使其餘域名下的業務請求失敗。

由於京東業務分散，域名不少，一個頁面須要調用大量API接口，這些API都散落在不一樣的域名下面。

咱們配置了一臺nginx，培植了一個新域名專門供小程序進行域名的轉發，把須要用到的域名全都映射到新域名的路徑裏，這樣就能夠把大量域名合併到一個或幾個很小的域名裏，成功繞過了限制。

三、使用Websocket

wx.request的併發數不能超過5個，致使併發能力受限，超出限制時請求失敗。

傳統方式是經過page直接和Server進行交互。有了小程序限制以後，咱們在中間加入了WS Server，就能夠把請求包裝到Websocket裏，Websocket再經過轉發到Server，Server返回數據後再經過Websocket的形式回到前面的小程序。

由於微信原生支持Websocket，併發數也比較高，基本知足了併發的需求。

四、提早梳理好頁面層級關係

微信小程序頁面層級最多爲5個，這就會致使像京東購物這樣比較複雜的頁面層級達到上限時頁面跳轉無響應。

提早作好頁面層級關係的梳理，保證頁面邏輯在5層以內。

五、組件開發模式

小程序只能經過page對象來進行頁面內容的修改，加大了UI組件的開發難度。

京東的小程序開發是把組件徹底獨立出來，每一個組件都擁有本身的JS、WXML和WXSS。利用組件本身的JS，setData到WXML，WXML經過事件回調的方式回調到本身的JS。

組件開發完以後WXML經過import+template的方式引用到頁面的WXML裏。JS經過require的方式引入頁面。

六、代碼動態下發？

小程序的程序包大小不能超過1MB，使不少功能受限。對於電商應用，1MB確實不太夠。

咱們當時有想過將JS腳本內容經過接口請求，而後用eval執行，或是把模版文件內容經過接口獲取後，動態插入到頁面中。可是微信在這方面有許多限制，eval等能動態執行JS語句的函數被禁用，模版文件內容沒法動態添加。

飛昇

一、關於性能優化

「Getthe hardest part done first.」這裏的the hardest part咱們當時首先想到的是圖片。

二、基礎支持

京東有一套比較好的圖片系統，它是基於京東分佈式文件系統JFS和CDN系統的一個包括存儲、圖片的在線處理、緩存分發的圖片系統。

三、圖片優化

利用CDN域名來分散請求，從而擴大並行下載數；

按需加載不一樣尺寸的圖片；

使用Webp圖片格式；

根據當前網絡情況請求不一樣壓縮質量的圖片。

四、0ms呈現首屏

小程序本地存儲的文件是像HTML、CSS、IMG和JS這類靜態資源。

利用小程序的能力，經過上一個頁面直接把首屏須要展示的頁面傳到下一個頁面。在打開新頁面的時候，靜態資源和接口數據都已經有了，就能夠直接展示出來。

五、頁面滑動優化

搜索列表頁經過回收屏幕外的節點來保持滑動的流暢性。

六、Page間的通訊

咱們用事件的方式作了一個page間的通訊，支付成功後會觸發一個事件，通知到前面須要訂閱它的頁面去更新本身的狀態。

七、網絡容災

Page是經過Websocket的方式和Server進行交互的，但由於用戶的網絡狀況是不肯定的，致使有時候小程序會連不到Websocket。這時咱們會在小程序裏自動切到備份的HTTPS的服務器，經過HTTPS服務器和Server正常地進行交互，保證了小程序的穩定性。

八、異常監控

在一些不肯定的狀況下，小程序有可能出現報錯之類的狀況。微信給咱們提供了onError的API，經過這個API能夠捕獲到小程序的一些錯誤，而後咱們就能把這些錯誤信息提交到monitor上，根據監控平臺反饋的數據對這些錯誤進行不斷優化和迭代。

九、一次開發，屢次複用

把基礎類服務打包，給其它小程序作引用。

個人分享到此結束，謝謝你們！

相關推薦

• 移動端SDK優化的特色與經驗分享
  

• Shall we begin？