內容來源：2017年3月11日，周偉鵬在“H5夢工廠”進行《京東小程式的三生三世》演講分享。IT大咖說（id：itdakashuo）作為獨家視訊合作方，經主辦方和講者審閱授權釋出。

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

摘要

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

“不是每個人都能看透這三生三世的愛恨交織。”

嘉賓演講視訊地址及PPT：http://suo.im/4A4Y3z

前世

之前京東購物入口的首頁還是比較複雜的，現在首頁簡化到只有搜尋和領券的功能。

初見

1、小程式產品定位

用完即走，觸手可及。

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

優秀的操作體驗。

2、小程式組成

作為開發者來說，小程式需要WXML、WXSS和JS三部分。WXML和WXSS組成了view層，負責view層的渲染。JS組成了manager層，JS負責整個小程式的邏輯部分。

3、小程式架構

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

頁面可以通過JSbridge和app service進行互動，也可以呼叫一些native元件。

Manager也是通過JSbridge，額外有一個單獨封裝的API，就可以直接通過API呼叫native元件。

4、小程式native元件

小程式的實現方式是通過小程式JSbridge的API，獲取原來Web元件的資訊，在Webview上蓋了一層native的元件。

小程式裡具有native能力的元件大概有canvas、video、input、textarea、map和picker。這幾個元件在小程式裡是以native的形式展現出來。

5、與Web端的區別

優點：

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

它接近原生應用的使用者體驗。

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

提供大量常用元件，開發成本低。

自帶ES6支援。

限制：

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

無法繫結原生事件。

更新需要發版本，微信稽核。

6、京東購物小程式

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

元件開發團隊：我們的開發團隊前端是四個人，“後臺”開發有六個人。

確定結構及分工：

我們把小程式分為page和models、API兩部分。

前端主要負責page部分，包括頁面重構、資料渲染、使用者互動邏輯等等。

Models和API這層是“後臺”開發負責的，它們主要負責資料的獲取、加工，提供公共的API。

制定開發規範：我們制定了命名規範、介面規範、樣式規範、文件規範、檔案目錄規範和git分支規範。

渡劫

1、手動實現cookie

我們在開發小程式的時候遇到的第一個問題就是執行環境裡沒有cookie，導致後臺介面無法驗證登入態。

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

2、用Nginx進行轉發

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

因為京東業務分散，域名很多，一個頁面需要呼叫大量API介面，這些API都散落在不同的域名下面。

我們配置了一臺nginx，培植了一個新域名專門供小程式進行域名的轉發，把需要用到的域名全都對映到新域名的路徑裡，這樣就可以把大量域名合併到一個或幾個很小的域名裡，成功繞過了限制。

3、使用Websocket

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

傳統方式是通過page直接和Server進行互動。有了小程式限制之後，我們在中間加入了WS Server，就可以把請求包裝到Websocket裡，Websocket再通過轉發到Server，Server返回資料後再通過Websocket的形式回到前面的小程式。

因為微信原生支援Websocket，併發數也比較高，基本滿足了併發的需求。

4、提前梳理好頁面層級關係

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

提前做好頁面層級關係的梳理，保證頁面邏輯在5層之內。

5、元件開發模式

小程式只能通過page物件來進行頁面內容的修改，加大了UI元件的開發難度。

京東的小程式開發是把元件完全獨立出來，每個元件都擁有自己的JS、WXML和WXSS。利用元件自己的JS，setData到WXML，WXML通過事件回撥的方式回撥到自己的JS。

元件開發完之後WXML通過import+template的方式引用到頁面的WXML裡。JS通過require的方式引入頁面。

6、程式碼動態下發？

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

我們當時有想過將JS指令碼內容通過介面請求，然後用eval執行，或是把模版檔案內容通過介面獲取後，動態插入到頁面中。但是微信在這方面有許多限制，eval等能動態執行JS語句的函式被禁用，模版檔案內容無法動態新增。

飛昇

1、關於效能優化

“Getthe hardest part done first.”這裡的the hardest part我們當時首先想到的是圖片。

2、基礎支援

京東有一套比較好的圖片系統，它是基於京東分散式檔案系統JFS和CDN系統的一個包括儲存、圖片的線上處理、快取分發的圖片系統。

3、圖片優化

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

按需載入不同尺寸的圖片；

使用Webp圖片格式；

根據當前網路狀況請求不同壓縮質量的圖片。

4、0ms呈現首屏

小程式本地儲存的檔案是像HTML、CSS、IMG和JS這類靜態資源。

利用小程式的能力，通過上一個頁面直接把首屏需要展現的頁面傳到下一個頁面。在開啟新頁面的時候，靜態資源和介面資料都已經有了，就可以直接展現出來。

5、頁面滑動優化

搜尋列表頁通過回收螢幕外的節點來保持滑動的流暢性。

6、Page間的通訊

我們用事件的方式做了一個page間的通訊，支付成功後會觸發一個事件，通知到前面需要訂閱它的頁面去更新自己的狀態。

7、網路容災

Page是通過Websocket的方式和Server進行互動的，但因為使用者的網路情況是不確定的，導致有時候小程式會連不到Websocket。這時我們會在小程式裡自動切到備份的HTTPS的伺服器，通過HTTPS伺服器和Server正常地進行互動，保證了小程式的穩定性。

8、異常監控

在一些不確定的情況下，小程式有可能出現報錯之類的情況。微信給我們提供了onError的API，通過這個API可以捕獲到小程式的一些錯誤，然後我們就能把這些錯誤資訊提交到monitor上，根據監控平臺反饋的資料對這些錯誤進行不斷優化和迭代。

9、一次開發，多次複用

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

我的分享到此結束，謝謝大家！