android開發——.so檔案相關知識點

一、為什麼你需要重點關注.so檔案

  什麼是so檔案

  so是shared object的縮寫，見名思義就是共享的對象，機器可以直接運作的二進制代碼。大到作業系統，小到一個專用軟體，都離不開so。參見https://en.wikipedia.org/wiki/Library_(computing)

so主要存在于Unix和Linux系統中。

  如果項目中使用到了NDK，它将會生成.so檔案，是以顯然你已經在關注它了。如果隻是使用Java語言進行編碼，你可能在想不需要關注.so檔案了吧，因為Java是跨平台的。但事實上，即使你在項目中隻是使用Java語言，項目中依賴的函數庫或者引擎庫裡面已經嵌入了.so檔案（比如百度地圖sdk就提供了各種.so檔案）

  so是與平台相關的二進制機器碼，Android應用支援的cpu架構取決于APK中位于lib或jniLib目錄中的.so檔案。（Native Libs Monitor這個應用可以幫助我們了解手機上安裝的APK用到了哪些.so檔案，以及.so檔案來源于哪些函數庫或者架構。當然，我們也可以自己對app反編譯來擷取這些資訊，不過相對麻煩一些。）

  很多裝置都支援多于一種的ABI（此概念将在下文中講解）。例如ARM64和x86裝置也可以同時運作armeabi-v7a和armeabi的二進制包。但最好是針對特定平台提供相應平台的二進制包，這種情況下運作時就少了一個模拟層（例如x86裝置上模拟arm的虛拟層），進而得到更好的性能（歸功于最近的架構更新，例如硬體fpu，更多的寄存器，更好的向量化等）。

  那麼，Android 為什麼要使用.so檔案呢？

  由于Android基于Linux Kernl的，也繼承了Linux中所有so相關的設計。除了系統方面的原因，Android開發者還要知道以下幾點：

so機制讓開發者最大化利用已有的C和C++代碼，達到重用的效果，利用軟體世界積累了幾十年的優秀代碼
so是二進制，沒有解釋編譯的開消，用so實作的功能比純java實作的功能要快
so記憶體配置設定不受Dalivik/ART的單個應用限制，減少OOM
           

二、擷取android手機的cpu架構

（此部分轉載自：擷取Android手機CPU類型 ARM、ARMV7、NEON）

手機連接配接電腦（確定驅動已經正确安裝）後，通過cmd打開終端，并以此輸入下列指令（僅針對windows系統）：

  adb shell ——> cd /proc ——> cat cpuinfo

  結果如下圖：

  上面中注明的轉載文章處有 擷取cpu的是arm指令集，armv7指令集、還是neon指令集的代碼 及 調用的該函數的示例方法。

三、關于cpu架構簡析：

1、預備知識

四大cpu體系結構：ARM、X86/Atom、MIPS、PowerPC

其中ARM/MIPS/PowerPC均是基于精簡指令集機器處理器的架構；

X86則是基于複雜指令集的架構，Atom是x86或者是x86指令集的精簡版。

根據各種新聞，Android在支援各種處理器的現狀：

ARM+Android 最早發展、完善的支援，主要在手機市場、上網本、智能等市場；

X86+Android 有比較完善的發展。有atom+Android的上網本，且支援Atom+Android 和 Atom+Window7雙系統；

MIPS+Android 目前在移植、完善過程中；

Powpc+Android 目前在移植、完善過程中。

各架構的詳情可參看 此文

2、android的cpu架構

Android系統目前支援以下七種不同的CPU架構：ARMv5，ARMv7 (從2010年起)，x86 (從2011年起)，MIPS (從2012年起)，ARMv8，MIPS64和x86_64 (從2014年起)，每一種都關聯着一個相應的ABI（應用二進制接口）。

應用程式二進制接口（Application Binary Interface）定義了二進制檔案（尤其是.so檔案）如何運作在相應的系統平台上，從使用的指令集，記憶體對齊到可用的系統函數庫。在Android系統上，每一個CPU架構對應一個ABI：armeabi，armeabi-v7a，x86，mips，arm64-v8a，mips64，x86_64。

關于ABI：（英語：application binary interface，縮寫為 ABI）描述了應用程式（或者其他類型）和作業系統之間或其他應用程式的低級接口。
ABI涵蓋了各種細節，如：
1、資料類型的大小、布局和對齊;
2、調用約定（控制着函數的參數如何傳送以及如何接受傳回值），例如，是所有的參數都通過棧傳遞，還是部分參數通過寄存器傳遞；
哪個寄存器用于哪個函數參數；通過棧傳遞的第一個函數參數是最先push到棧上還是最後；
3、系統調用的編碼和一個應用如何向作業系統進行系統調用；
4、以及在一個完整的作業系統ABI中，目标檔案的二進制格式、程式庫等等。
一個完整的ABI，像Intel二進制相容标準（iBCS）[1]，允許支援它的作業系統上的程式不經修改在其他支援此ABI的作業系統上運作。
ABI不同于應用程式接口（API），API定義了源代碼和庫之間的接口，是以同樣的代碼可以在支援這個API的任何系統中編譯， 
 然而ABI允許編譯好的目标代碼在使用相容ABI的系統中無需改動就能運作。 
           

擴充：EABI

  嵌入式應用二進制接口指定了檔案格式、資料類型、寄存器使用、堆積組織優化和在一個嵌入式軟體中的參數的标準約定。開發者使用自己的彙編語言也可以使用EABI作為與相容的編譯器生成的彙編語言的接口。 支援EABI的編譯器建立的目标檔案可以和使用類似編譯器産生的代碼相容，這樣允許開發者連結一個由不同編譯器産生的庫。EABI與關于通用計算機的ABI的主要差別是應用程式代碼中允許使用特權指令，不需要動态連結（有時是禁止的），和更緊湊的堆棧幀組織用來節省記憶體。廣泛使用EABI的有Power PC和ARM.

四、開發中對.so檔案的處理（主要内容轉載自簡書的文章）

處理.so檔案時有一條簡單卻并不知名的重要法則：
你應該盡可能的提供專為每個ABI優化過的.so檔案，但要麼全部支援，要麼都不支援：你不應該混合着使用。你應該為每個ABI目錄提供對應的.so檔案。
           

  當一個應用安裝在裝置上，隻有該裝置支援的CPU架構對應的.so檔案會被安裝。在x86裝置上，libs/x86目錄中如果存在.so檔案的話，會被安裝，如果不存在，則會選擇armeabi-v7a中的.so檔案，如果也不存在，則選擇armeabi目錄中的.so檔案（因為x86裝置也支援armeabi-v7a和armeabi）。

  當你引入一個.so檔案時，不止影響到CPU架構。我從其他開發者那裡可以看到一系列常見的錯誤，其中最多的是“UnsatisfiedLinkError”，”dlopen: failed”以及其他類型的crash或者低下的性能。

主要針對so檔案的提供者：1、注意編譯平台

  使用NDK時，你可能會傾向于使用最新的編譯平台，但事實上這是錯誤的，因為NDK平台不是向後相容的，而是向前相容的，可以适當忽略“compile against the latest platform”這類優化提示。簡單說，利用NDK針對android-17生成的so檔案可以在android-22上運作，反之卻不行。這點與Android SDK的相容性不一樣，在SDK14上編譯的應用，在API23上也是可以運作的；在SDk23上的編譯的應用，隻要minSdkVersion小于14，同樣在API14上可以運作。是以，推薦使用app的minSdkVersion對應的編譯平台。

  這也意味着當你引入一個預編譯好的.so檔案時，你需要檢查它被編譯所用的平台版本。

  2、混合使用不同C++運作時編譯的.so檔案

  .so檔案可以依賴于不同的C++運作時，靜态編譯或者動态加載。混合使用不同版本的C++運作時可能導緻很多奇怪的crash，是應該避免的。作為一個經驗法則，當隻有一個.so檔案時，靜态編譯C++運作時是沒問題的，否則當存在多個.so檔案時，應該讓所有的.so檔案都動态連結相同的C++運作時。

這意味着當引入一個新的預編譯.so檔案，而且項目中還存在其他的.so檔案時，我們需要首先确認新引入的.so檔案使用的C++運作時是否和已經存在的.so檔案一緻。

  3、沒有為每個支援的CPU架構提供對應的.so檔案

  這一點在前文已經說到了，但你應該真的特别注意它，因為它可能發生在根本沒有意識到的情況下。

  例如：你的app支援armeabi-v7a和x86架構，然後使用Android Studio新增了一個函數庫依賴，這個函數庫包含.so檔案并支援更多的CPU架構，例如新增android-gif-drawable函數庫：

compile ‘pl.droidsonroids.gif:android-gif-drawable:1.1.+’
           

釋出我們的app後，會發現它在某些裝置上會發生Crash，例如Galaxy S6，最終可以發現隻有64位目錄下的.so檔案被安裝進手機。

解決方案：重新編譯我們的.so檔案使其支援缺失的ABIs，或者設定

顯示指定支援的ABIs。

最後一點：如果你是一個SDK提供者，但提供的函數庫不支援所有的ABIs，那你将會搞砸你的使用者，因為他們能支援的ABIs必将隻能少于你提供的。

對于采用so的應用開發者：1、将.so檔案放在錯誤的地方

我們往往很容易對.so檔案應該放在或者生成到哪裡感到困惑，下面是一個總結：

  Android Studio工程放在jniLibs/ABI目錄中（當然也可以通過在build.gradle檔案中的設定jniLibs.srcDir屬性自己指定）

  Eclipse工程放在libs/ABI目錄中（這也是ndk-build指令預設生成.so檔案的目錄）

  AAR壓縮包中位于jni/ABI目錄中（.so檔案會自動包含到引用AAR壓縮包的APK中）

  最終APK檔案中的lib/ABI目錄中

  通過PackageManager安裝後，在小于Android5.0的系統中，.so檔案位于app的nativeLibraryPath目錄中；在大于等于Android 5.0的系統中，.so檔案位于app的nativeLibraryRootDir/CPU_ARCH目錄中。

  2隻提供armeabi架構的.so檔案而忽略其他ABIs的

  所有的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等等）。

  以減少APK包大小為由是一個錯誤的借口，因為你也可以選擇在應用市場上傳指定ABI版本的APK，生成不同ABI版本的APK可以在build.gradle中如下配置：

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': , 'armeabi-v7a': , 'arm64-v8a': , 'mips': , 'mips64': , 'x86': , 'x86_64': ]

    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), ) *  + android.defaultConfig.versionCode
        }
    }
 }