 |
VOOZH | about |
|
VOOZH | about |
安卓壓縮工具集說明文檔
一、 工具集介紹 （項目地址： ）
安卓壓縮工具集提供了一個極為簡潔的方法，能夠比安卓原有的Zip提供更高壓縮比的存儲應用內的so文件 （後期版本還可以支持壓縮動態加載的jar包，以及遊戲資源文件），同時提供了應用內網絡更新下載壓縮文件的方法，使得應用可以將部分so存儲到雲端，減小應用的尺寸。
|
最高節省50%空間！ |
在雲測平台上測試了158款終端，涵蓋2.3到4.4多個系統版本，100%通過
|
100%通過測試！ |
|
8M文件1s內解壓 |
壓縮原理： 壓縮工具會把所有的so使用LZMA算法壓縮到assert目錄，應用在第一次啟動的時候，會解壓到應用的私有目錄下
二、 工具集組成
工具集為一個安裝程序，建議安裝在默認路徑下，安裝在program files下在win7可能有讀寫權限的問題導致一些異常
安裝後，你可以看見4個目錄，此目錄內都含有源碼。
安裝後的四個目錄如下
其中 ApkLibComrepss 為java命令行程序的源碼，在此目錄的bin子目錄中，你可以找到ApkCompress.jar，使用這個文件可以把一個普通的apk文件轉換為壓縮的apk文件
CompressDemo為一個樣例代碼，你可以參考這個代碼知道如何整合壓縮的SDK。
DecRawso是壓縮的SDK，你的開發工程需要引用這個SDK，並進行一些源碼上的修改，才能整合壓縮的功能
RawsoCreator為windows下的轉換工具， 這個工具一般無需使用， 僅僅在調試和二次開發壓縮SDK的時候使用。
三、 如何整合壓縮SDK
打開CompressDemo，我們以這個工程為例子講解如何整合壓縮SDK
1. 首先需要引入DecRawso工程
2. 然後需要在你的工程內最初始的地方調用DecRawso.NewInstance。在此demo工程內，是在MainActivity.java的OnCreate內調用了此方法， 此方法是創建了一個解壓的唯一實例。注意：此方法是異步的，所以你可以傳入一個handler接受異步解碼完成的消息，如果同時傳入參數showProgress=true，SDK內會產生一個進度對話框以阻塞主進程。不推薦使用DecRawso.NewInstance(mContext,null,false);的方式，此方式不接受任何消息，且無進度對話框，解壓會在後台自動完成，並且在應用第一次load so的時候阻塞直到後台解壓完成。所以如果阻塞時間過長，可能會導致應用無響應。
3. 修改load so文件的方法：所有的System.loadlibrary(***)改為 System.load(DecRawso.GetInstance.GetPath(「***"));
新版本， 這步可以省略了，sdk會修改system的libaray加載路徑，一般情況下，系統升級不會出問題 （非正規代碼，小概率會隨android升級修改新的代碼），如果方便的話，還是採用System.load(DecRawso.GetInstance.GetPath(「***"))
經過這幾個簡單的步驟，壓縮的SDK已經整合到工程內了。
四、 如何壓縮發布APK
使用ApkCompress.jar壓縮發布APK。 此工具為命令行工具。一般的此命令使用方式為：在命令行運行ComPressApk.jar-a C:/my/test.apk -k c:/key *** ### alias -x86 （也可以運行 java –jarComPressApk.jar ）
-a 後面跟apk路徑名， 可以不是全路徑
-k 後面是簽名文件[key storepasskeypass alias name] ，key可以不是全路徑名 (name 如果不寫， 默認就是CERT)
-x86 表示需要存儲x86庫文件在雲端， 後面跟以http://開頭的連結，最後實際的存儲位置應該為
命令執行完以後， 會生成test_CompressAlign.apk. 這個apk就是壓縮後的apk
五、 開發模式和壓縮模式
為了方便開發，在實現開發的過程中（修改了源碼支持壓縮後），也可以不壓縮so，apk也可以正常運行，壓縮的SDK內部會自動判斷是否有壓縮包， 如果沒有壓縮包，則加載的路徑恢復成android默認的路徑。所以最方便的開發是，先整合代碼，在開發過程中和原來一樣開發（不壓縮），在發布的時候才壓縮apk
六、 X86和ARM庫混合調用
在實現開發過程中，可能會有某些第三方庫確實沒有x86版本，通常情況下ISV並不在x86目錄下放置arm的第三方庫，那麼在實際運行過程中會導致缺庫現象的發生。在缺庫的情況下，壓縮的SDK會在x86設備上自動解壓arm的壓縮包，避免缺庫現象的發生。（只有真正加載了缺失的庫才是缺庫，庫文件不一致並不一定就是缺庫）
但是顯然這樣會導致運行的低效率，如果在第三方so和x86的庫完全沒有相互引用的情況下（也就是說這些庫都是java層使用JNI調用的，在native層沒有相互調用），可以拷貝arm的第三方庫到x86目錄下，這樣就不會出現缺庫的情況。當然這種情況會導致arm庫多餘的拷貝，在以前的zip壓縮情況下，會使得壓縮包變大，但是在新的LZMA壓縮情況下，庫大小完全不會增大，因為LZMA壓縮由於字典比較大，能夠儘可能的壓縮關聯的幾個文件，如果文件完全相同，LZMA的壓縮會和單個文件基本一致。如下圖