ANDROID動態加載使用SO庫時要注意的一些問題

WilliamsCCE 7年前發布 | 6K 次閱讀安卓開發 Android開發移動開發

Android項目里的SO庫

正好動態加載系列文章談到了加載SO庫的地方，我覺得這里可以順便談談使用SO庫時需要注意的一些問題。或許這些問題對于經常和SO庫開發打交道的同學來說已經是老生長談，但是既然要討論一整個動態加載系列，我想還是有必要說說使用SO庫時的一些問題。

在項目里使用SO庫非常簡單，在加載SD卡中的SO庫中也有談到，只需要把需要用到的SO庫拷貝進 jniLibs(或者Eclipse項目里面的libs) 中，然后在JAVA代碼中調用 System.loadLibrary(“xxx”) 加載對應的SO庫，就可以使用JNI語句調用SO庫里面的Native方法了。

但是有同學注意到了，SO庫文件可以隨便改文件名，卻不能任意修改文件夾路徑，而是“armeabi”、“armeabi-v7a”、“x86”等文件夾名有著嚴格的要求，這些文件夾名有什么意義么？

SO庫類型和CPU架構類型

原因很簡單，不同CPU架構的設備需要用不同類型SO庫（從文件名也可以猜出來個大概嘛 ╮(￣▽￣”)╭）。

記得還在學校的時候，提及ARM處理器時，老師說以后移動設備的CPU基本就是ARM類型的了。老師不曾欺我，早期的Android系統幾乎只支持ARM的CPU架構，不過現在至少支持以下七種不同的CPU架構：ARMv5，ARMv7，x86，MIPS，ARMv8，MIPS64和x86_64。每一種CPU類型都對應一種ABI（Application Binary Interface），“armeabi-v7a”文件夾前面的“armeabi”指的就是ARM這種類型的ABI，后面的“v7a”指的是ARMv7。這7種CPU類型對應的SO庫的文件夾名是：armeabi，armeabi-v7a，x86，mips，arm64-v8a，mips64，x86_64。

不同類型的移動設備在運行APP時，需要加載自己支持的類型的SO庫，不然就GG了。通過 Build.SUPPORTED_ABIS 我們可以判斷當前設備支持的ABI，不過一般情況下，不需要開發者自己去判斷ABI，Android系統在安裝APK的時候，不會安裝APK里面全部的SO庫文件，而是會根據當前CPU類型支持的ABI，從APK里面拷貝最合適的SO庫，并保存在APP的內部存儲路徑的 libs 下面。（這里說一般情況，是因為有例外的情況存在，比如我們動態加載外部的SO庫的時候，就需要自己判斷ABI類型了。）

一種CPU架構 = 一種對應的ABI參數 = 一種對應類型的SO庫

到這里，我們發現使用SO庫的邏輯還是比較簡單的，但是Android系統加載SO庫的邏輯還是給我們留下了一些坑。

使用SO庫時要注意的一些問題

1. 別把SO庫放錯地方

SO庫其實都是APP運行時加載的，也就是說APP只有在運行的時候才知道SO庫文件的存在，這就無法通過靜態代碼檢查或者在編譯APP時檢查SO庫文件是否正常。所以，Android開發對SO庫的存放路徑有嚴格的要求。

使用SO庫的時候，除了“armeabi-v7a”等文件夾名需要嚴格按照規定的來自外，SO庫要放在項目的哪個文件夾下也要按照套路來，以下是一些總結：

Android Studio 工程放在 jniLibs/xxxabi 目錄中（當然也可以通過在build.gradle文件中的設置jniLibs.srcDir屬性自己指定）；
Eclipse 工程放在 libs/xxxabi 目錄中（這也是使用ndk-build命令生成SO庫的默認目錄）；
aar 依賴包中位于 jni/ABI 目錄中（SO庫會自動包含到引用AAR壓縮包到APK中）；
最終構建出來的APK文件中，SO庫存在 lib/xxxabi 目錄中（也就是說無論你用什么方式構建，只要保證APK包里SO庫的這個路徑沒錯就沒問題）；
通過 PackageManager 安裝后，在小于 Android 5.0 的系統中，SO庫位于 APP 的 nativeLibraryPath 目錄中；在大于等于 Android 5.0 的系統中，SO庫位于 APP 的 nativeLibraryRootDir/CPU_ARCH 目錄中；

既然扯到了這里，順便說一下，我在使用 Android Studio 1.5 構建APK的時候，發現 Gradle 插件只會默認打包application類型的module的jniLibs下面的SO庫文件，而不會打包aar依賴包的SO庫，所以會導致最終構建出來的APK里的SO庫文件缺失。暫時的解決方案是把所有的SO庫都放在application模塊中（這顯然不是很好的解決方案），不知道這是不是Studio的BUG，同事的解決方案是通過修改Gradle插件來增加對aar依賴包的SO庫的打包支持（GitHub有開源的第三方Gradle插件項目，使用Java和Groovy語言開發）。

2. 盡可能提供CPU支持的最優SO庫

當一個應用安裝在設備上，只有該設備支持的CPU架構對應的SO庫會被安裝。但是，有時候，設備支持的SO庫類型不止一種，比如大多的X86設備除了支持X86類型的SO庫，還兼容ARM類型的SO庫（目前應用市場上大部分的APP只適配了ARM類型的SO庫，X86類型的設備如果不能兼容ARM類型的SO庫的話，大概要嗝屁了吧）。

所以如果你的APK只適配了ARM類型的SO庫的話，還是能以兼容的模式在X86類型的設備上運行（比如華碩的平板），但是這不意味著你就不用適配X86類型的SO庫了，因為X86的CPU使用兼容模式運行ARM類型的SO庫會異常卡頓（試著回想幾年前你開始學習Android開發的時候，在PC上使用AVD模擬器的那種感覺）。

3. 注意SO庫的編譯版本

除了要注意使用了正確CPU類型的SO庫，也要注意SO庫的編譯版本的問題。雖然現在的Android Studio支持在項目中直接編譯SO庫，但是更多的時候我們還是選擇使用事先編譯好的SO庫，這時就要注意了，編譯APK的時候，我們總是希望使用最新版本的build-tools來編譯，因為Android SDK最新版本會幫我們做出最優的向下兼容工作。

但是這對于編譯SO庫來說就不一樣了，因為NDK平臺不是向下兼容的，而是向上兼容的。應該使用app的minSdkVersion對應的版本的NDK標本來編譯SO庫文件，如果使用了太高版本的NDK，可能會導致APP性能低下，或者引發一些SO庫相關的運行時異常，比如“UnsatisfiedLinkError”，“dlopen: failed”以及其他類型的Crash。

一般情況下，我們都是使用編譯好的SO庫文件，所以當你引入一個預編譯好的SO庫時，你需要檢查它被編譯所用的平臺版本。

4. 盡可能為每種CPU類型都提供對應的SO庫

比如有時候，因為業務的需求，我們的APP不需要支持AMR64的設備，但這不意味著我們就不用編譯ARM64對應的SO庫。舉個例子，我們的APP只支持armeabi-v7a和x86架構，然后我們的APP使用了一個第三方的Library，而這個Library提供了AMR64等更多類型CPU架構的支持，構建APK的時候，這些ARM64的SO庫依然會被打包進APK里面，也就是說我們自己的SO庫沒有對應的ARM64的SO庫，而第三方的Library卻有。這時候，某些ARM64的設備安裝該APK的時候，發現我們的APK里帶有ARM64的SO庫，會誤以為我們的APP已經做好了AMR64的適配工作，所以只會選擇安裝APK里面ARM64類型的SO庫，這樣會導致我們自己項目的SO庫沒有被正確安裝（雖然armeabi-v7a和x86類型的SO庫確實存在APK包里面）。

這時正確的做法是，給我們自己的SO庫也提供AMR64支持，或者不打包第三方Library項目的ARM64的SO庫。使用第二種方案時，可以把APK里面不需要支持的ABI文件夾給刪除，然后重新打包，而在Android Studio下，則可以通過以下的構建方式指定需要類型的SO庫。

productFlavors {
    flavor1 {
        ndk {
            abiFilters "armeabi-v7a"
            abiFilters "x86"
            abiFilters "armeabi"
        }
    }
    flavor2 {
        ndk {
            abiFilters "armeabi-v7a"
            abiFilters "x86"
            abiFilters "armeabi"
            abiFilters "arm64-v8a"
            abiFilters "x86_64"
        }
    }
}

需要說明的是，如果我們的項目是SDK項目，我們最好提供全平臺類型的SO庫支持，因為APP能支持的設備CPU類型的數量，就是項目中所有SO庫支持的最少CPU類型的數量（使用我們SDK的APP能支持的CPU類型只能少于等于我們SDK支持的類型）。

5. 不要通過“減少其他CPU類型支持的SO庫”來減少APK的體積

確實，所有的x86/x86_64/armeabi-v7a/arm64-v8a設備都支持armeabi架構的SO庫，因此似乎移除其他ABIs的SO庫是一個減少APK大小的好辦法。但事實上并不是，這不只影響到函數庫的性能和兼容性。

X86設備能夠很好的運行ARM類型函數庫，但并不保證100%不發生crash，特別是對舊設備，兼容只是一種保底方案。64位設備（arm64-v8a, x86_64, mips64）能夠運行32位的函數庫，但是以32位模式運行，在64位平臺上運行32位版本的ART和Android組件，將丟失專為64位優化過的性能（ART，webview，media等等）。

過減少其他CPU類型支持的SO庫來減少APK的體積不是很明智的做法，如果真的需要通過減少SO庫來做APK瘦身，我們也有其他辦法。

減少SO庫體積的正確姿勢

1. 構建特定ABI支持的APK

我們可以構建一個APK，它支持所有的CPU類型。但是反過來，我們可以為每個CPU類型都單獨構建一個APK，然后不同CPU類型的設備安裝對應的APK即可，當然前提是應用市場得提供用戶設備CPU類型設別的支持，就目前來說，至少PLAY市場是支持的。

Gradle可以通過以下配置生成不同ABI支持的APK（引用自別的文章，沒實際使用過）：

android {
    ...
    splits {
        abi {
            enable true
            reset()
            include 'x86', 'x86_64', 'armeabi-v7a', 'arm64-v8a' //select ABIs to build APKs for
            universalApk true //generate an additional APK that contains all the ABIs
        }
    }

// map for the version code
project.ext.versionCodes = ['armeabi': 1, 'armeabi-v7a': 2, 'arm64-v8a': 3, 'mips': 5, 'mips64': 6, 'x86': 8, 'x86_64': 9]

android.applicationVariants.all { variant ->
    // assign different version code for each output
    variant.outputs.each { output ->
        output.versionCodeOverride =
                project.ext.versionCodes.get(output.getFilter(com.android.build.OutputFile.ABI), 0) * 1000000 + android.defaultConfig.versionCode
    }
}

}</code></pre> 
  
2. 從網絡下載當前設備支持的SO庫 
  說到這里，總算回到動態加載的主題了。⊙﹏⊙ 
  使用Android的動態加載技術，可以加載外部的SO庫，所以我們可以從網絡下載SO庫文件并加載了。我們可以下載所有類型的SO庫文件，然后加載對應類型的SO庫，也可以下載對應類型的SO庫然后加載，不過無論哪種方式，我們最好都在加載SO庫前，對SO庫文件的類型做一下判斷。 
  我個人的方案是，存儲在服務器的SO庫依然按照APK包的壓縮方式打包，也就是，SO庫存放在APK包的 libs/xxxabi 路徑下面，下載完帶有SO庫的APK包后，我們可以遍歷libs路徑下的所有SO庫，選擇加載對應類型的SO庫。 
  具體實現代碼看上去像是： 
  /**

將一個SO庫復制到指定路徑，會先檢查改SO庫是否與當前CPU兼容
*
@param sourceDir     SO庫所在目錄
@param so            SO庫名字
@param destDir       目標根目錄
@param nativeLibName 目標SO庫目錄名
@return
*/
public static boolean copySoLib(File sourceDir, String so, String destDir, String nativeLibName) throws IOException {
boolean isSuccess = false;
 try {

 LogUtil.d(TAG, "[copySo] 開始處理so文件");

 if (Build.VERSION.SDK_INT >= 21) {
     String[] abis = Build.SUPPORTED_ABIS;
     if (abis != null) {
         for (String abi : abis) {
             LogUtil.d(TAG, "[copySo] try supported abi:" + abi);
             String name = "lib" + File.separator + abi + File.separator + so;
             File sourceFile = new File(sourceDir, name);
             if (sourceFile.exists()) {
                 LogUtil.i(TAG, "[copySo] copy so: " + sourceFile.getAbsolutePath());
                 isSuccess = FileUtil.copyFile(sourceFile.getAbsolutePath(), destDir + File.separator + nativeLibName + File.separator + so);
                 //api21 64位系統的目錄可能有些不同
                 //copyFile(sourceFile.getAbsolutePath(), destDir + File.separator +  name);
                 break;
             }
         }
     } else {
         LogUtil.e(TAG, "[copySo] get abis == null");
     }
 } else {
     LogUtil.d(TAG, "[copySo] supported api:" + Build.CPU_ABI + " " + Build.CPU_ABI2);

     String name = "lib" + File.separator + Build.CPU_ABI + File.separator + so;
     File sourceFile = new File(sourceDir, name);

     if (!sourceFile.exists() && Build.CPU_ABI2 != null) {
         name = "lib" + File.separator + Build.CPU_ABI2 + File.separator + so;
         sourceFile = new File(sourceDir, name);

         if (!sourceFile.exists()) {
             name = "lib" + File.separator + "armeabi" + File.separator + so;
             sourceFile = new File(sourceDir, name);
         }
     }
     if (sourceFile.exists()) {
         LogUtil.i(TAG, "[copySo] copy so: " + sourceFile.getAbsolutePath());
         isSuccess = FileUtil.copyFile(sourceFile.getAbsolutePath(), destDir + File.separator + nativeLibName + File.separator + so);
     }
 }

 if (!isSuccess) {
     LogUtil.e(TAG, "[copySo] 安裝 " + so + " 失敗 : NO_MATCHING_ABIS");
     throw new IOException("install " + so + " fail : NO_MATCHING_ABIS");
 }


} catch (IOException e) {

 e.printStackTrace();
 throw e;

}
return true;
}</code></pre> 
總結 
 
一種CPU架構 = 一種ABI = 一種對應的SO庫； 
加載SO庫時，需要加載對應類型的SO庫； 
盡量提供全平臺CPU類型的SO庫支持； 

題外話，SO庫的使用本身就是一種最純粹的動態加載技術，SO庫本身不參與APK的編譯過程，使用JNI調用SO庫里的Native方法的方式看上去也像是一種“硬編程”，Native方法看上去與一般的Java靜態方法沒什么區別，但是它的具體實現卻是可以隨時動態更換的（更換SO庫就好），這也可以用來實現熱修復的方案，與Java方法一旦加載進內存就無法再次更換不同，Native方法不需要重啟APP就可以隨意更換。 
出于安全和生態控制的原因，Google Play市場不允許APP有加載外部可執行文件的行為，一旦你的APK里被檢查出有額外的可執行文件時就不好玩了，所以現在許多APP都偷偷把用于動態加載的可執行文件的后綴名換成“.so”，這樣被發現的幾率就降低了，因為加載SO庫看上去就是官方合法版本的動態加載啊（不然SO庫怎么工作），雖然這么做看起來有點掩耳盜鈴。 
  
來自：http://www.androidchina.net/6176.html


                    
                         本文由用戶 WilliamsCCE 自行上傳分享，僅供網友學習交流。所有權歸原作者，若您的權利被侵害，請聯系管理員。
                         轉載本站原創文章，請注明出處，并保留原始鏈接、圖片水印。
                         本站是一個以用戶分享為主的開源技術平臺，歡迎各類分享！
                         本文地址：http://www.baiduhome.net/lib/view/open1482999861820.html
                         安卓開發 Android開發 移動開發

ANDROID動態加載使用SO庫時要注意的一些問題

Android項目里的SO庫

SO庫類型和CPU架構類型

使用SO庫時要注意的一些問題

1. 別把SO庫放錯地方

2. 盡可能提供CPU支持的最優SO庫

3. 注意SO庫的編譯版本

4. 盡可能為每種CPU類型都提供對應的SO庫

5. 不要通過“減少其他CPU類型支持的SO庫”來減少APK的體積

減少SO庫體積的正確姿勢

1. 構建特定ABI支持的APK

2. 從網絡下載當前設備支持的SO庫

總結

相關經驗

相關資訊

相關文檔

目錄

ANDROID動態加載 使用SO庫時要注意的一些問題

Android項目里的SO庫

SO庫類型和CPU架構類型

使用SO庫時要注意的一些問題

1. 別把SO庫放錯地方

2. 盡可能提供CPU支持的最優SO庫

3. 注意SO庫的編譯版本

4. 盡可能為每種CPU類型都提供對應的SO庫

5. 不要通過“減少其他CPU類型支持的SO庫”來減少APK的體積

減少SO庫體積的正確姿勢

1. 構建特定ABI支持的APK

2. 從網絡下載當前設備支持的SO庫

總結

相關經驗

相關資訊

相關文檔

目錄

ANDROID動態加載使用SO庫時要注意的一些問題