當前位置:成語大全網 - 新華字典 - 如何動態加載android的so文件,如何壓縮apk尺寸

如何動態加載android的so文件,如何壓縮apk尺寸

您好,很高興為您解答。

壹、 工具集介紹 (項目地址: /liyuming1978/NativeLibCompression)

安卓壓縮工具集提供了壹個極為簡潔的方法,能夠比安卓原有的Zip提供更高壓縮比的存儲應用內的so文件 (後期版本還可以支持壓縮動態加載的jar包,以及遊戲資源文件),同時提供了應用內網絡更新下載壓縮文件的方法,使得應用可以將部分so存儲到雲端,減小應用的尺寸。

壓縮原理: 壓縮工具會把所有的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庫文件在雲端, 後面跟以/cloudrawso_x86

命令執行完以後, 會生成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的壓縮會和單個文件基本壹致。

如若滿意,請點擊右側采納答案,如若還有問題,請點擊追問

希望我的回答對您有所幫助,望采納!

~ O(∩_∩)O~