高工做CPU架構(gòu)適配的心得體會
作者丨手藝人來源丨IT爛筆頭
有 哪 些 CPU 架 構(gòu)
我們在日常開發(fā)中接觸比較多的就兩類：X86、arm
如上圖所示，armabi的庫可以運(yùn)行在x86、x86-64以及armabi-v7a和armabi-v8a的CPU架構(gòu)上，從下往上的方向上，下方架構(gòu)的so庫可以兼容的運(yùn)行在更上方的CPU架構(gòu)中，只是可能會出現(xiàn)性能問題。比如PC端跑模擬器的時候，就比較卡頓。
當(dāng)我們在我們項(xiàng)目中的libs中新建不同的CPU架構(gòu)的目錄文件時一定要注意一點(diǎn)就是在同一架構(gòu)目錄中一定要提供全部的so庫。這是因?yàn)榧虞dso的策略所決定的，假設(shè)你當(dāng)前在arm64-v8a的機(jī)器上，然后你需要加載兩個so庫：liba.so、libb.so。
那么顯然會優(yōu)先去尋找與其CPU架構(gòu)匹配的目錄下尋找so包，如圖：
那如果我們將該arm64-v8a下面的libb.so刪除掉會怎么樣呢？
其實(shí)這時候會出問題的，因?yàn)橹皇莿h除了一個文件，而arm64i-v8a的文件目錄還存在，當(dāng)需要加載libb.so時，還是會去arm64-v8a目錄下去尋找，顯然是找不到的。但如果我們將整個目錄刪除了，反而能正常：
沒錯，只有在arm64-v8a目錄不存在的時候才會去兼容包里加載。到這里作為初級工程師一般都會了解。
2
SO?混 用
一般情況下，我們不太可能完完全全提供所有CPU架構(gòu)的so庫的，那樣會讓你的APK大小變的很恐怖。所以，我們一般會提供一套兼容的比如只使用armabi（兼容性最好）的so。但是如果都是只使用armabi的必然會引起許多的性能問題，針對這一點(diǎn)呢，有人就采用混用的方式（包括微信），如下圖所示：
例如你使用v7a架構(gòu)的手機(jī)，對一些性能要求比較高的so，可以將其對應(yīng)的v7a的so包放到armabi目錄中，在代碼中根據(jù)判斷當(dāng)前手機(jī)的cpu架構(gòu)來選擇加載更適合的so庫，但是前提是cpu位數(shù)要相同，你不能將arm64-v8a（64位）的so放到armabi（32位）中。為什么？因?yàn)槿绻覀兊臋C(jī)器是64位的，我們將64位的so混在armabi（32位）中，當(dāng)機(jī)器檢測到只有armabi的目錄，會以32位的模式去加載so。
到這里作為一名中級工程師是都需要了解的。
3
優(yōu) 化
因?yàn)樘砑觭o庫，必然會造成apk包體的增大，所以在一些非啟動就必須加載的so庫，完全可以去動態(tài)加載，在使用的時候再去加載它。
對于必須要加載的我們可以考慮如何去減小so的體積，當(dāng)然我們可以從下面幾個方面去優(yōu)化它：
1、隱藏所有的符號，只公開必要的：-fvisibility=hidden
2、禁用 C++ Exception 和 RTTI： -fno-exception -fno-rtti
3、不使用iostream，使用Android Log
4、使用 gc-sections去除無用代碼
除了上面所講的，還可以從另外的手段去做優(yōu)化，比如構(gòu)建時分包，根據(jù)CPU的架構(gòu)打不同的包，目前很多商店是支持按CPU架構(gòu)分發(fā)安裝包的。
另外，如果你是一名SDK開發(fā)者，這里有幾點(diǎn)注意值得你關(guān)注一下：
1、盡量不在Native層開發(fā)，降低SDK的維護(hù)成本
2、盡量優(yōu)化Native庫的體積，降低接入開發(fā)者的使用成本
3、必須提供完整的CPU架構(gòu)依賴庫供開發(fā)者使用
到這里為止呢，基本具有高工的潛質(zhì)了。
近期精彩內(nèi)容推薦：??
?在 IntelliJ IDEA 中使用 Git，太方便了！
在看點(diǎn)這里
好文分享給更多人↓↓
評論
圖片
表情