天天看點

JSPatch – 動态更新iOS APP

JSPatch是最近業餘做的小項目,隻需在項目中引入極小的引擎,就可以使用JavaScript調用任何Objective-C的原生接口,獲得腳本語言的能力:動态更新APP,替換項目原生代碼修複bug。 

用途 

是否有過這樣的經曆:新版本上線後發現有個嚴重的bug,可能會導緻crash率激增,可能會使網絡請求無法發出,這時能做的隻是趕緊修複bug然後送出等待漫長的AppStore稽核,再盼望使用者快點更新,付出巨大的人力和時間成本,才能完成此次bug的修複。 

使用JSPatch可以解決這樣的問題,隻需在項目中引入JSPatch,就可以在發現bug時下發JS腳本更新檔,替換原生方法,無需更新APP即時修複bug。 

例子 

@implementation JPTableViewController
...
- (void)tableView:(UITableView *)tableView didSelectRowAtIndexPath:(NSIndexPath *)indexPath
{
  NSString *content = self.dataSource[[indexPath row]];  //可能會超出數組範圍導緻crash
  JPViewController *ctrl = [[JPViewController alloc] initWithContent:content];
  [self.navigationController pushViewController:ctrl];
}
...
@end
           

上述代碼中取數組元素處可能會超出數組範圍導緻crash。如果在項目裡引用了JSPatch,就可以下發JS腳本修複這個bug: 

#import “JPEngine.m"
@implementation AppDelegate
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
{
    [JPEngine startEngine];
    [NSURLConnection sendAsynchronousRequest:[NSURLRequest requestWithURL:[NSURL URLWithString:@"http://cnbang.net/bugfix.JS"]] queue:[NSOperationQueue mainQueue] completionHandler:^(NSURLResponse *response, NSData *data, NSError *connectionError) {
    NSString *script = [[NSString alloc] initWithData:data encoding:NSUTF8StringEncoding];
    if (script) {
      [JPEngine evaluateScript:script];
    }
}];
   ….
    return YES;
}
@end
           
//JS
defineClass("JPTableViewController", {
  //instance method definitions
  tableView_didSelectRowAtIndexPath: function(tableView, indexPath) {
    var row = indexPath.row()
    if (self.dataSource().length > row) {  //加上判斷越界的邏輯
      var content = self.dataArr()[row];
      var ctrl = JPViewController.alloc().initWithContent(content);
      self.navigationController().pushViewController(ctrl);
    }
  }
}, {})      

這樣 JPTableViewController 裡的 -tableView:didSelectRowAtIndexPath: 就替換成了這個JS腳本裡的實作,在使用者無感覺的情況下修複了這個bug。 

更多的使用文檔和demo請參考github項目首頁。 

原理 

JSPatch用iOS内置的JavaScriptCore.framework作為JS引擎,但沒有用它JSExport的特性進行JS-OC函數互調,而是通過Objective-C Runtime,從JS傳遞要調用的類名函數名到Objective-C,再使用NSInvocation動态調用對應的OC方法。詳細的實作原理以及實作過程中遇到的各種坑和hack方法會另有文章介紹。 

方案對比 

目前已經有一些方案可以實作動态打更新檔,例如WaxPatch,可以用Lua調用OC方法,相對于WaxPatch,JSPatch的優勢是: 

1.JS語言

JS比Lua在應用開發領域有更廣泛的應用,目前前端開發和終端開發有融合的趨勢,作為擴充的腳本語言,JS是不二之選。 

2.符合Apple規則

JSPatch更符合Apple的規則。iOS Developer Program License Agreement裡3.3.2提到不可動态下發可執行代碼,但通過蘋果JavaScriptCore.framework或WebKit執行的代碼除外,JS正是通過JavaScriptCore.framework執行的。 

3.小巧

使用系統内置的JavaScriptCore.framework,無需内嵌腳本引擎,體積小巧。 

4.支援block

wax在幾年前就停止了開發和維護,不支援Objective-C裡block跟Lua程式的互傳,雖然一些第三方已經實作block,但使用時參數上也有比較多的限制。 

相對于WaxPatch,JSPatch劣勢在于不支援iOS6,因為需要引入JavaScriptCore.framework。另外目前記憶體的使用上會高于wax,持續改進中。 

風險 

JSPatch讓腳本語言獲得調用所有原生OC方法的能力,不像web前端把能力局限在浏覽器,使用上會有一些安全風險: 

1.若在網絡傳輸過程中下發明文JS,可能會被中間人篡改JS腳本,執行任意方法,盜取APP裡的相關資訊。可以對傳輸過程進行加密,或用直接使用https解決。 

2.若下載下傳完後的JS儲存在本地沒有加密,在未越獄的機器上使用者也可以手動替換或篡改腳本。這點危害沒有第一點大,因為操作者是手機擁有者,不存在APP内相關資訊被盜用的風險。若要避免使用者修改代碼影響APP運作,可以選擇簡單的加密存儲。 

其他用途 

JSPatch可以動态打更新檔,自由修改APP裡的代碼,理論上還可以完全用JSPatch實作一個業務子產品,甚至整個APP,跟wax一樣,但不推薦這麼做,因為: 

  1. JSPatch和wax一樣都是通過Objective-C Runtime的接口通過字元串反射找到對應的類和方法進行調用,這中間的字元串處理會損耗一定的性能,另外兩種語言間的類型轉換也有性能損耗,若用來做一個完整的業務子產品,大量的頻繁來回互調,可能有性能問題。 
  2. 開發過程中需要用OC的思維寫JS/Lua,喪失了腳本語言自己的特性。 
  3. JSPatch和wax都沒有IDE支援,開發效率低。 

若想動态為APP添加子產品,目前React Native給出了很好的方案,解決了上述三個問題: 

  1. JS/OC不會頻繁通信,會在事件觸發時批量傳遞,提高效率。(詳見React Native通信機制詳解) 
  2. 開發過程無需考慮OC的感受,遵從React架構的思想進行純JS開發就行,剩下的事情React Native幫你處理好了。 
  3. React Native連IDE都準備好了。 

是以動态添加業務子產品目前還是推薦嘗試React Native,但React Native并不會提供原生OC接口的反射調用和方法替換,無法做到修改原生代碼,JSPatch以小巧的引擎補足這個缺口,配合React Native用統一的JS語言讓一個原生APP時刻處于可擴充可修改的狀态。 

— 

目前JSPatch處于開發階段,穩定性和功能還存在一些問題,歡迎大家提建議/bug/PR,一起來做這個項目。

github位址: https://github.com/LazyDuan/JSPatch

來自:http://blog.cnbang.net/works/2767

轉載于:https://www.cnblogs.com/LazyDuan/p/4968887.html