配合 APP 調用 JS 的一次嘗試

項目初衷

最初的場景是用戶在對購物車的操做中，因爲用戶對購物車的每次操做（包括選擇，調整數量）都須要計算商品的促銷和分組的狀況，而這段邏輯的計算都須要調用後端的接口，那麼瓶頸來了：

• 請求時間長——一次 HTTPS 的請求對於 web 性能有很大的影響，尤爲是對於移動端來講，用戶所在的網絡情況直接影響請求延時的長短。
• 數據計算量大——少許的計算看起來不會有太多影響，但與之疊加的業務邏輯和大量的數據計算將隱性增長時間的消耗和出錯的概率。
• 交互卡頓——上述兩個時間上的消耗將直接致使用戶操做的障礙，特別是對於購物車中調整數量和選中的操做。
• 多端統一——對購物車的操做是 APP 和 WAP 多端統一的操做，須要收斂管理，若是後端再也不適合處理，那麼發佈統一語言的、多端共同調用的 JS 功能包將是個不錯的選擇。

抹平差別

APP 中調用 JS 的基本思路就是使用內嵌的 JS 引擎，與 Chrome 的 V8 引擎不一樣，iOS 使用的是自帶的 JavaScriptCore；而 Andriod 則引用了 Duktape。這裏還有許多其餘的引擎。

因爲調用平臺不一樣，JS 引擎也不一樣，要想使得 JS 在多端輸入輸出保持一致，須要瞭解：

• 代碼的管理方式
• 對於原生方法的支持

如表格：

	WAP	iOS	Andriod
代碼管理	modules	JSContext	duktape.evaluate
原生支持	caniuse	Safari	duktape

對於代碼的管理，WAP 下支持正常的模塊化寫法和調用；iOS 提供的 JSContext 能找到 JS 中對應的對象和方法；Andriod 下 duktape-android 只提供了 evaluate 解析字符串並在 runtime 模式下調用（因此 Andriod 下執行較慢）。後兩種直接屏蔽了模塊化的寫法，最終方案只能選擇原始的對象管理方法的形式。

對於原生方法的支持，WAP 下因爲跟機型和原生瀏覽器相關，可在 caniuse 上查找；iOS 中的 JavaScriptCore 暫時沒查到具體的支持狀況，因爲 Safari 下使用相同的 JS 引擎，可查詢對應版本的 Safari 的支持狀況；duktape 因爲是開源的，很容易查詢。所以只要注意調用方法的兼容，以及跟 APP 端的調試，便可避免。

Tips：本項目在調試中就發現 JavaScriptCore 缺乏 Array.prototype.find 原生方法的支持，對 Array.prototype.sort 的實現效果與 V8 也不太同樣。

代碼調試

項目開發中最困難的地方在於代碼的調試，經過本地 node.js 測試的代碼不必定能在 APP 的 JS 引擎上跑通（例如對原生方法的支持上）。因爲相似在兩個不一樣的 REPL 中調試，目前沒有什麼太好的版本，只能在調試代碼中儘可能拋出全部可讀異常，而後在 APP 的 JS 引擎中捕捉到的異常信息分析問題。

腳本安全

參考 JSPatch 部署的安全策略，主要分爲傳輸安全和執行安全。

傳輸安全作了兩件事：

• HTTPS 傳輸——將 JS 文件放在支持 HTTPS 的服務器上，保證傳輸中泄露和劫持的安全性。
• RSA 校驗——在服務端對 JS 文件內容作了 MD5 校驗，併發送給 APP。客戶端根據公鑰解密，保證文件沒有被纂改。

執行安全上，因爲不像 JSPatch 須要 JS 調用 APP 的功能，安全性上相對較小，只要 APP 對 JS 文件的執行異常作出處理便可不會形成 APP crash。固然這種重要的邏輯，JS 的單測和較高的測試覆蓋率是必不可少的。同時 APP 也可對 JS 的執行進行監控上報，對支持 JS 的版本實行灰度發佈。

版本控制

這是該項目的紅利所在。因爲是調用 JS 文件，所以 JS 邏輯的更新免去了 APP 發版的苦惱。新版本的 JS 文件由接口經過文件名控制版本並下發到客戶端，客戶端校驗 MD5 經過後便可使用新的 JS 版本。

後續

在 APP 中調用 JS 的方式無疑緩解了請求資源的消耗和版本控制的煩惱，同時也保證了邏輯的統一。但大規模的使用，必將考慮到 JS 的執行效率、平臺的差別以及業務方的需求。實際的效果如何，還需進一步的探討。