編輯:Android資訊
早期的Android系統幾乎只支持ARMv5的CPU架構,你知道現在它支持多少種嗎?7種!
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。
如果項目中使用到了NDK,它將會生成.so文件,因此顯然你已經在關注它了。如果只是使用Java語言進行編碼,你可能在想不需要關注.so文 件了吧,因為Java是跨平台的。但事實上,即使你在項目中只是使用Java語言,很多情況下,你可能並沒有意識到項目中依賴的函數庫或者引擎庫裡面已經 嵌入了.so文件,並依賴於不同的ABI。
例如,項目中使用RenderScript支持庫,OpenCV,Unity,android-gif-drawable,SQLCipher等,你都已經在生成的APK文件中包含.so文件了,而你需要關注.so文件。
Android應用支持的ABI取決於APK中位於lib/ABI目錄中的.so文件,其中ABI可能是上面說過的七種ABI中的一種。
Native Libs Monitor 這個應用可以幫助我們理解手機上安裝的APK用到了哪些.so文件,以及.so文件來源於哪些函數庫或者框架。
當然,我們也可以自己對app反編譯來獲取這些信息,不過相對麻煩一些。
很多設備都支持多於一種的ABI。例如ARM64和x86設備也可以同時運行armeabi-v7a和armeabi的二進制包。但最好是針對特 定平台提供相應平台的二進制包,這種情況下運行時就少了一個模擬層(例如x86設備上模擬arm的虛擬層),從而得到更好的性能(歸功於最近的架構更新, 例如硬件fpu,更多的寄存器,更好的向量化等)。
我們可以通過Build.SUPPORTED_ABIS得到根據偏好排序的設備支持的ABI列表。但你不應該從你的應用程序中讀取它,因為 Android包管理器安裝APK時,會自動選擇APK包中為對應系統ABI預編譯好的.so文件,如果在對應的lib/ABI目錄中存在.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或者低下的性能:
使用NDK時,你可能會傾向於使用最新的編譯平台,但事實上這是錯誤的,因為NDK平台不是後向兼容的,而是前向兼容的。推薦使用app的minSdkVersion對應的編譯平台。
這也意味著當你引入一個預編譯好的.so文件時,你需要檢查它被編譯所用的平台版本。
.so文件可以依賴於不同的C++運行時,靜態編譯或者動態加載。混合使用不同版本的C++運行時可能導致很多奇怪的crash,是應該避免的。 作為一個經驗法則,當只有一個.so文件時,靜態編譯C++運行時是沒問題的,否則當存在多個.so文件時,應該讓所有的.so文件都動態鏈接相同的 C++運行時。
這意味著當引入一個新的預編譯.so文件,而且項目中還存在其他的.so文件時,我們需要首先確認新引入的.so文件使用的C++運行時是否和已經存在的.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,或者設置
ndk.abiFilters
顯示指定支持的ABIs。
最後一點: 如果你是一個SDK提供者,但提供的函數庫不支持所有的ABIs,那你將會搞砸你的用戶,因為他們能支持的ABIs必將只能少於你提供的。
我們往往很容易對.so文件應該放在或者生成到哪裡感到困惑,下面是一個總結:
所有的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': 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 } } }
本文將介紹在Android中如何使用include標簽來更便捷地重用布局代碼,從而減少冗余的Android代碼。 在一個Android項目中我們可能會需要用到相同
關於Android程序的構架, 當前(2016.10)最流行的模式即為MVP模式, Google官方提供了Sample代碼來展示這種模式的用法. Repo地址:
在日常的開發中,尤其是app開發,因為不像web端那樣 出錯以後可以熱更新,所以app開發 一般對軟件質量有更高的要求(你可以想一下 一個發出去的版本如果有重大缺
GridView按照行列的方式來顯示內容,一般適合顯示圖標、圖片等內容,主要用於設置Adapter 在這裡主要是基礎BaseAdapter類,重寫其中的方法,主要