2019/08/01 Google 即將有大動作
要求 APP 全面支援 64 位元
所以只要不符條件的一律無法上架至 Google Play
因此公司也開始了 APP 的改革之路
由於公司有用到 Unity 與其它的第三方合作套件
因此先由這裡開始做起
我們把他們提供的 so 檔放到下列的路徑
ProjectName ▸ app ▸ src ▸ main ▸ jniLibs
小提示一: lib vs libs 有什麼不同呢? 前者只是引用,後者會將檔案包進 apk 增加 apk size
到了 jniLibs 看到了琳瑯滿目的各式資料夾,如下圖
那我們到底要放在哪一個下面呢?
接下來我就來說說各分類的差異吧
arm64-v8a、armeabi-v7a、armeabi、x86、x86_64、mips、mips64
這些代表了不同的 cup 型別
Android裝置的CPU型別,又常通稱為 ABIs
為大家整理了下表
mips / mips64 => 極少數,幾乎可忽略
x86 / x86_64 => 大多氣平板 / 模擬器,Intel 提供 Houdini 指令集動態轉碼工具,可兼容 arm.so,市佔大約 1%
armeabi-v7a => 目前主流,2011年之後的手機都用 arm7
arm64-v8a => support 64 位元
這樣大家懂了嗎
為了支援這些 cup 我們就需要包相對應的 so 檔進 apk 裡
直到目前為止,Android 共有 7種 不同的 cpu
分別為
ARMv5,ARMv7(從2010年起)
x86(從2011年起)
MIPS(從2012年起)
ARMv8,MIPS64和x86_64(從2014年起)
小提示二:
如果真的很需要減少 apk size 的話
可以只保留 armeabi 和 armeabi-v7a 兩個資料夾
並保證這兩個資料夾中.so數量一致
然後複製一份 armeabi 版本的第三方 .so 到armeabi-v7a資料夾
但這麼做會犧牲某些 cpu 的效率
小提示三:
arm64-v8a 是可以向下相容的
但有一點要注意
如果你有 armeabi 和 arm64-v8a 兩個資料夾
armeabi 裡面有 a.so 和 b.so,arm64-v8a 裡面只有 a.so
那麼 arm64-v8a 的手機在用到 b.so 的時候
發現 arm64-v8a 資料夾裡面沒有b.so 就會 crash
若沒有 arm64-v8a 資料夾,手機就會直接去 armeabi 找
所以我們有兩個做法
一個是不要有 arm64-v8a
一個是用到的 so 檔兩個資料夾都要有
小提示四:
若真的需要支援到多 cpu 且在意效能
其實可以在 build.gradle 設定
讓每一個 ABIs 都 build 出相應的 apk
來避免 apk 過大的問題喔
最後,回正題
放好之後,到 build.gradle 設定要 build 支援的 cpu 即可,如下
defaultConfig { 。。。 ndk { // abiFilters "armeabi-v7a", "x86" abiFilters "arm64-v8a", "x86_64" }
資料來源:
https://blog.csdn.net/u012400885/article/details/52923765
https://www.itread01.com/content/1548366498.html
留言列表