為什麼使用so

• so機制讓開發者最大化利用已有的C和C++程式碼，達到重用的效果，利用軟體世界積累了幾十年的優秀程式碼；
• so是二進位制，沒有解釋編譯的開消，用so實現的功能比純java實現的功能要快；
• so記憶體分配不受Dalivik/ART的單個應用限制，減少OOM；
• 相對於java程式碼，二進位制程式碼的反編譯難度更大，一些核心程式碼可以考慮放在so中。

說起.so檔案就必須提一下arm64、armeabi、armeabi-v7a、x86、x86_64等檔案夾了，這些資料夾分別代表不同的CPU架構。他們存在的意義就是來做不同CPU架構手機的相容的。

資料夾下，.so檔案存在用來做各種手機CPU架構不同的相容的。而apicloud 模組開發的雲平臺的雲編譯，只會保留armeabi這個.所以就有用到了abiFilters來指定NDK需要相容的架構。

例：

ndk {
    abiFilters "armeabi"  // 指定要ndk需要相容的架構(這樣其他依賴包裡mips,x86,armeabi-v7a,arm-v8之類的so會被過濾掉)
}

apk安裝過程中對so的選擇

在Android上安裝應用程式時，Package Manager會掃描整個apk檔案，尋找符合下面檔案路徑格式的動態連線庫：

在這裡，primary-abi是上面表中的abi的值，name對應的是我們在Android.mk中定義的LOCAL_MODULE

如果在apk內並沒有找到適合當前機器primary-abi的so，Package Manager會嘗試尋找適合secondary-abi的so檔案：

即安裝應用時，系統會根據當前CPU架構選擇最優ABI適配，如果找到了合適的so檔案，包管理器會將該ABI資料夾下所有so庫全部拷貝至應用的data目錄下：data/data/<package_name>/lib/

注意：apk安裝過程對so選擇是基於整個ABI資料夾的，而非以單個so檔案為粒度，也就是說把lib/armeabi 、lib/armeabi-v7a、lib/x86等等資料夾的其中一個資料夾內所有.so複製到應用的data目錄下。

如果我們在程式碼中呼叫了某個so的功能，而最終拷貝的ABI資料夾下並沒有提供這個檔案，apk的安裝過程中並不會報錯，但是執行時會遇到java.lang.UnsatisfiedLinkError。

so的載入

對於so的載入，Android在System類中提供了兩種方法：

System.loadLibrary

這是我們最常用的一個方法，System.loadLibrary只需要傳入so在Android.mk中定義的LOCAL_MODULE的值即可，
系統會呼叫System.mapLibraryName把這個libName轉化成對應平臺的so的全稱並去嘗試尋找這個so載入。
比如我們的so檔案全名為libmath.so，載入該動態庫只需要傳入math即可：

System.load

對於System.load方法，官方是這樣介紹的：

Loads a code file with the specified filename from the local file system as a dynamic library.
The filename argument must be a complete path name.

所以它為動態載入非apk打包期間內建的so檔案提供了可能，也就是說可以使用這個方法來指定我們要載入的so檔案的路徑來動態的載入so檔案。
比如我們在打包期間並不打包so檔案，而是在應用執行時將當前裝置適用的so檔案從伺服器上下載下來，放在/data/data/<package-name>/mydir下，然後在使用so時呼叫：

即可成功載入這個so，開始呼叫本地方法了。

其實loadLibrary和load最終都會呼叫nativeLoad(name, loader, ldLibraryPath)方法，只是因為loadLibrary的引數傳入的僅僅是so的檔名，所以，loadLibrary需要首先找到這個檔案的路徑，然後載入這個so檔案。
而load傳入的引數是一個檔案路徑，所以它不需要去尋找這個檔案路徑，而是直接通過這個路徑來載入so檔案。

但是當我們把需要載入的so檔案放在SdCard中，會發生什麼呢？把上面so的路徑改成/mnt/sdcard/libmath.so，再嘗試載入時，會得到如下錯誤：

這是因為SD卡等外部儲存路徑是一種可拆卸的（mounted）不可執行（noexec）的儲存媒介，不能直接用來作為可執行檔案的執行目錄，使用前應該把可執行檔案複製到APP內部儲存下再執行。所以使用System.load載入so時要注意把so拷貝至/data/data/<package-name>/下。

通過精簡so來減小包大小

現在的apk動輒幾十M或者更大，apk包大小的精簡成為了開發過程中的重要一環。通過上面的介紹，我們知道x86、x86_64、armeabi-v7a、arm64-v8a裝置都支援armeabi架構的so，因此，通過移除不必要的so來減小包大小是一個不錯的選擇。

按照ABI分別單獨打包APK

我們可以選擇在Google Play上傳指定ABI版本的APK，生成不同ABI版本的APK可以在build.gradle中進行如下配置：

只提供armabi的so

上面的方法需要應用市場提供使用者裝置CPU型別更識別的支援，在國內並不是一個十分適用的方案。常用的處理方式是利用gradle中的abiFilters配置。
首先配置修改主工程build.gradle下的abiFilters：

abiFilters後面的ABI型別即為要打包進apk的ABI型別，除此以外都不打包進apk裡。
然後在專案的根目錄下的gradle.properties（沒有的話新建一個）中加入下面這行：

通過上面方法減少的apk體積是十分可觀的，也是目前比較主流的處理方案。

進階版方案

如果進一步，會發現上面的方案並不完美。首先是效能問題：使用相容模式去執行arm架構的so，會丟失專門為當前ABI優化過的效能；其次還有相容性問題，雖然x86裝置能相容arm型別的函式庫，但是並不意味著100%的相容，某些情況下還是會發生crash，所以x86的arm相容只是一個折中方案，為了最好的利用x86自身的效能和避免相容性問題，我們最好的做法仍是專為x86提供對應的so。
針對這些問題，我們可以採用一個相對更好的方案：讓所有so都來自於網路，應用下載伺服器上的so庫後，利用System.load方法動態載入當前裝置對應的so.

需要注意的問題

不要把so放錯地方

首先要注意的是不要把另一個ABI下的so檔案放在另一個ABI資料夾下（每個ABI資料夾下的so檔名是相同的，有可能會搞錯）。

儘可能為所有ABI提供so

理想狀況下，應該儘可能為所有ABI都提供對應的so，這一點的好處我們已經在上面討論過了：在可以發揮更好效能的同時，還能減少由於相容帶來的某些crash問題。當然，這一點要結合實際情況（如SDK提供的so不全、晶片市場佔有率、apk包大小等）去考量，如果使用的so本身就很小，我們大可為儘可能多的ABI都提供so。
若是侷限於包大小等因素，可以結合通過精簡so來減小包大小一節中提供的第三個方案來調整so的使用策略。

所有ABI資料夾提供的so要保持一致

這是一個十分容易出現的錯誤。
如果我們的應用選擇了支援多個ABI，要十分注意：對於每個ABI下的so，但要麼全部支援，要麼都不支援。不應該混合著使用，而應該為每個ABI目錄提供對應的.so檔案。

先舉個例子，Bugtags的so支援所有的ABI：

但不是所有開發者提供的so都支援所有ABI：

如果不做任何設定，最終打出來的apk的lib目錄會是這樣的：

參考上面apk安裝過程中對so的選擇一節，假設當前裝置是x86機器，包管理器會先去lib/x86下尋找，發現該資料夾是存在的，所以最終只有lib/x86下的so–即只有libBugtags.so會被安裝。當嘗試在執行期間載入libImages.so時，就會遇上下面常見的UnsatisfiedLinkError錯誤：

所以，我們需要遵循這樣的準則：

• 對於so開發者：支援所有的平臺，否則將會搞砸你的使用者。
• 對於so使用者：要麼支援所有平臺，要麼都不支援。

然而，因為種種原因（遺留so、晶片市場佔有率、apk包大小等），並不是所有人都遵循這樣的原則。

一種可行的處理方案是：取你所有的so庫所支援的ABI的交集，移除其他（可以通過上面介紹的abiFilters來實現）。
如上面的例子，最終生成的apk可以是: