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