開源我的基於字節的數據補丁算法庫HDiffPatch

開源我的基於字節的數據補丁算法庫HDiffPatch
作者: [email protected]   2013.05.31

tag: HDiffPatch,diff,patch,補丁


HDiffPatch是一個高效的diff/patch實現,比bsdiff更快(只需1/4時間),佔用的內存更小(2/3內存),更容易使用和集成,得到的diff結果壓縮後也經常比bsdiff更小或相當(一般小10%以上)!    (  google也在使用bsdiff; 網址: http://www.daemonology.net/bsdiff/  ; 我也是在google的開源代碼中的第三方源碼庫中發現bsdiff的 )

HDiffPatch使用很簡單:
  1.create_diff(newData字節數組,oldData字節數組,out diffData);
      生成了oldData到newData的差異信息diffData;
  2. bool patch(out newData,oldData,diffData);
      用oldData和diffData就可以合成newData。
      (如果需要傳輸或網絡下載,建議選擇用LZMA或ZIP等壓縮diffData;  )

HDiffPatch算法特性:
    HDiff算法時間複雜度O(newSize+oldSize),(只能算平均複雜度,妥協是爲了優化內存佔用),內存使用newSize+oldSize*5+O(1)字節;(oldSize>=2G時 newSize+oldSize*9+O(1)字節 )。
    HPatch算法時間複雜度O(newSize+oldSize),內存使用newSize+oldSize+O(1)字節; (特殊情況下可以使用patch_stream把O(n)空間消耗轉嫁給硬盤,而消耗內存O(1))。

    bsdiff選擇了bzip2來生成壓縮的diff數據,而HDiff沒有替用戶選擇,生成的數據還處於未壓縮狀態(新版本提供了一個直接生成壓縮數據的diff函數)。這樣處理很有好處,比如用戶可以選擇更好的壓縮算法; (比如用戶可以對多個oldData版本都相對於當前最新版本生成多個diff數據然後壓縮成一個diff包,這樣的話多版本diff數據就會非常小!)  

  (和bsdiff的詳細對比測試:  http://blog.csdn.net/housisong/article/details/9037743 )


HDiffPatch的授權協議:
    HDiff使用的約束非常小的MIT協議(注意: HDiff庫裏使用的唯一第三方庫"sais.hxx",應該也是該協議);
    HPatch使用的約束更小的協議,基本上只要拷貝或修改的源代碼中不要刪除原作者的版權申明信息就好(見源代碼);

HDiffPatch的由來:
    我們2004年的時候做PC聯網遊戲,支持給大量客戶端自動升級到最新版本; 爲了減小需要下載的數據流量,只要傳遞版本之間的差異就可以了,這就有了做diff和patch算法的需求;  開始的時候時候試用過VPatch,覺得生成補丁速度慢,又接觸過後綴數組的概念,就實現了一個自己的版本,參見2006年的blog<一個高效的二進制數據補丁算法>;  
    HDiffPatch是去年在節假日時間重新按diff\ptach算法用C\C++代碼實現了一個版本(以前的版本用Delphi寫的,2份代碼不是移植關係);   其中HDiff用的C++來實現的,HPatch爲了更好的移植性完全用純C語言實現;   所有代碼在windows\macosx\linux,x86\x64\arm下都編譯運行過;  (當然,環境所限,我沒有在更多的系統和CPU體系下編譯和運行)

HDiffPatch的開源計劃:
    項目網址:  https://github.com/sisong/HDiffPatch 
    項目計劃:  ( 沒有明確的開發計劃,大家用着高興就好,作者很懶,可能是如下 )
      .更多環境和CPU體系的使用測試;
      .和其他更多diff/patch的對比測試;
      .英文版的源代碼註釋; (我的英語能力很差; readme文件都改了好多版! )
      .更大範圍使用後的新需求:比如提供  庫提供選擇使用LZMA或zip等壓縮的diffData? (新版本已經提供)   文件和文件夾級別的 diff/patch ? (新倉庫 ApkDiffPatch 提供了一個Zip(Jar,Apk) 包的diff&patch工具)    

      .針對可執行程序文件的一個特殊優化算法的實現(相信會得到小得多的diff數據;但這樣代碼就和不同平臺的可執行程序文件結構有相關性,比如windows平臺需要處理PE文件結構...  ps:google有一個更激進徹底的算法設計: newExe和oldExe可執行程序分別反編譯爲僞源代碼newCode和oldCode,對僞源代碼做常規diff得到diffCode(可以選擇進一步無損壓縮),patch時oldExe反彙編得到oldCode,和diffCode執行常規patch得到newCode,編譯newCode得到newExe(實現複雜度和細節應該不少). )


(ps: github在源代碼共享和協作開發方面比以前的方式方便和安全了很多,我的一些'有趣'或可能算有點兒用的代碼也會陸續放上去 )


 
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章