點進來的同學應該是對JSPatch有初步的了解了,主要在此介紹一下我的學習總結:
- 首先要了解OC代碼如何轉換為JS代碼,語法層面
- 如何實現動態,即如何通過服務器進行腳本下發
- 與后臺協調如何更好解決多個版本下發的問題
- JSPatch安全問題,如果沒有對JSPatch腳本加密,攻擊者就會通過網絡傳輸的中間人攻擊手段下發惡意腳本到用戶APP.接入JSPatch時請做好加密傳輸,只要做RSA非對稱加密傳輸就不會有問題.
- 充分測試問題,灰度測試
- 防止連續crash
- 實現原理(OC與JS的調用,OC黑科技runtime)
一丶OC轉換為JS代碼
1.1 require
在使用OC類之前需要調用require('className'):
require('UIView')
var view = UIView.alloc().init()
或者在使用時去調用
require('UIView').alloc().init()
1.2 調用OC方法
調用類方法: var redColor = UIColor.redColor
獲取Property就等于調用這個Property的getter方法:view.setBackgroundColor(redColor);
修改這個值就等于調用了setter方法:view.setBackgroundColor(redColor);
方法名轉換,多參數要用_分割:`var indexPath = require('NSIndexPath').indexPathForRow_inSection(0,1);
這里只是簡單介紹一下轉換方法,其它的具體轉換方法,請參考
JSPath作者,bang的文檔
在平常使用過程中,作者提供了一個OC轉JS代碼的工具,點擊這里查看:
JSPatch Conver,可以先寫好要改動的OC代碼,然后用工具進行轉換,然后檢查轉換后的代碼是否有誤,確認無誤之后,進入下一步測試階段.
二丶下發JS腳本
2.1 版本管理
因為不同的版本存在的bug不同,而且新的版本已經把舊版本已知的bug修復,所以在下發版本的時候,一定要做版本的區分.同一版本也可對應多個修復文件,對應同一APP版本的新版本補丁覆蓋舊版本補丁,如下圖:
2.2 下載使用策略
這里本來是計劃把下載和使用都放在didFinishLaunchingWithOptions：這個方法里,這里參考了一位同行的做法,使用js文件的代碼放在didFinishLaunchingWithOptions： 而下載js文件的代碼放在applicationDidBecomeActive: 因為這個方法在程序啟動和后臺回到前臺時都會調用。然后設置一個間隔時間，根據一些?數據和權衡之后我們采用的是間隔時間設為1小時。 也就是說每次來到這個方法時，先要檢測是距離上次發請求的時間間隔是否超過1小時，超過則發請求，否則跳過。如下圖:
2.3 倉庫設置
倉庫設置也要有個規范的流程,不能亂來,要不然后期可維護性比較差.對于一個APP來說,有多個版本即分為多個文件夾,然后在文件夾里放入JS文件,供客戶端下載,同時也可以在JS文件同層放入json文件來自定義這個流程.
三丶安全問題
使用JSPatch主要有兩個安全問題,傳輸安全:JS腳本可以調用任意OC方法,權限非常大,若被中間人攻擊替換代碼,會造成較大的危害;執行安全:下發的JS腳本靈活度大,相當于一次小型更新,若未進行充分測試,可能出現crash等情況.
傳輸安全
我們的目的是防止傳輸過程中數據被篡改,然后做了一些危害程序的操作,而我們還傻乎乎的去執行這個文件- -,所以這里選擇作者傾情推薦的安全性高,部署簡單,門檻低的方案:RSA校驗.這種方式屬于數字簽名,用了跟HTTPS一樣的非對稱加密,把非對稱加密只用于校驗文件,不解決傳輸過程中數據內容泄露的問題.整個校驗過程如下:
- 服務端計算出腳本文件的MD5值,作為這個文字的數字簽名.
- 服務端通過私鑰加密第1步算出的MD5值,得到一個加密后的MD5值.
- 把腳本文件和加密后的MD5值一起下發給客戶端.
- 把客戶端拿到的已經加密過的MD5值,通過保存在客戶端的公鑰解密.
- 客戶端計算腳本文件的MD5值.
- 比對第4步和第5步的兩個MD5值(分別是客戶端和服務端計算出來的MD5值),如果相等則通過校驗.
只要通過校驗,就可以確保腳本在傳輸過程中沒有被篡改,因為第三方若要篡改腳本文件,必須要計算出新的腳本文件MD5并用私鑰加密,客戶端公鑰才能解密出這個MD5值,而在服務器未泄露的情況下第三方是拿不到私鑰的.
執行安全
因為一旦下發JS腳本,就代表客戶端就會根據腳本文件執行方法(如果JS腳本替換類的方法寫錯了,當我沒說...),如果某個地方的代碼寫的不夠嚴謹,就可能導致大量crash,或者是一些奇怪的問題.需要有一些機制來避免這種情況發生.若要做的完整,可以分為:事發前(灰度),事發中(監控),事發后(回退).
灰度
首先需要在事發前把出現問題的影響面降到最低，對于中大型 APP，不能一次把腳本下發給所有用戶，需要有灰度機制，也就是一開始只下發給其中一部分用戶，看看會不會出現異常情況，再逐步覆蓋到所有用戶。有條件的話灰度的用戶最好按機型/系統/地域等屬性隨機分配，盡量讓最少的人覆蓋到大部分情況。
監控
接著是事發了我們需要知道腳本有問題，需要對 APP 有一些監控機制，像 crash 監控，這個一般所有 APP 都有接入，再按需求自行加入其他監控指標。
回退
最后是事發后回退代碼。一般為了避免不可預料的情況出現，JSPatch 腳本建議在啟動時執行，APP 運行過程中不去除，所以這個回退建議的實現方式是后臺下發命令，讓 APP 在下次啟動時不執行 JSPatch 腳本即可。
但這里能回退的前提是 APP 可以接收到后臺下發的回退命令，若因為下發的腳本導致 APP 啟動即時 crash，這個回退命令也會接收不到。所以建議再加一層防啟動 crash 的機制，APP 在連續啟動即 crash 后，下次啟動不再執行腳本文件。
這里需要補充一下,JS腳本引起的crash按崩潰的階段可分為:
- 調用到JS腳本里修改后的方法引起崩潰,這種可以通過下發新的JS腳本來解決.
- APP啟動即崩潰,這種情況已經不能通過下發腳本解決.要有專門的防止連續crash的解決方案.
連續crash解決方案
(.........)等我專門研究清楚了重開一篇~~~
在文末幫偶像bang推薦一下他的JSPatch平臺,大家如果由于某些原因不通過自家服務器下發腳本,可以通過這個平臺來進行腳本的下發:JSPatch平臺.
有問題歡迎聯系我溝通交流,QQ:364385155.順便給俺點個喜歡更好~
