AndroidStudio之app/build.gradle問題集錦

快速入門gradle方法：開啟build.gradle檔案，執行下面操作，



對比著生成的gradle檔案來學習


 

1、自定義輸出包名報錯：Cannot set the value of read-only property 'outputFile' for

 

2、jni開發之so靜態庫相關：

externalNativeBuild {
            cmake {
                cppFlags "-std=c++11 -frtti -fexceptions -fPIC  -lz"
                abiFilters "armeabi"
                abiFilters "armeabi-v7a"
                abiFilters "x86"
                abiFilters "mips"
            }
}

 1）什麼是ABI？Application Binary Interface(應用程式二進位制介面)
定義了二進位制檔案（尤其是.so檔案）如何執行在相應的系統平臺上，從使用的指令集，記憶體對齊到可用的系統函式庫。在Android系統上，每一個CPU架構對應一個ABI：armeabi，armeabi-v7a，x86，mips，arm64-v8a，mips64，x86_64。
    2) 不同abi有什麼區別？
        armeabiv-v7a: 第7代及以上的 ARM 處理器。2011年15月以後的生產的大部分Android裝置都使用它.
        arm64-v8a: 第8代、64位ARM處理器。
        armeabi: 第5代、第6代的ARM處理器，早期的手機用的比較多。
        x86: 平板、模擬器用得比較多。
        x86_64: 64位的平板。
        mips: 閘道器、機頂盒、路由

一、架構
1.Arm架構：是一個32位精簡指令集（RISC）處理器架構，其廣泛地使用在許多嵌入式系統設計。
2.X86架構；是一個intel通用計算機系列的標準編號縮寫,也標識一套通用的計算機指令集合。
3.Mips架構：是一種採取精簡指令集（RISC）的處理器架構。

二、三者區別
　　X86架構是X86指令集，它屬於CISC指令集。ARM架構是ARM指令集，屬於RISC指令集。
　　X86是馮若依曼結構，ARM是哈弗結構，這個不一定，比如ARM7TDMI用的就是馮若依曼結構。
　　其實都是差不多，X86指令多，應用範圍廣，但效率就顯得低一點，ARM指令少，應用範圍小，效率顯得高。

　　MIPS架構的處理器多用在閘道器、貓、機頂盒什麼的。ARM處理器用在便攜裝置，智慧手機。

　　X86，依靠強有力的工廠，前後端聯合調優，用tick-tock的穩定，強悍路標，強勢控制產業鏈，獲取價值鏈上最豐厚的那部分利潤。
　　ARM， 靠IP授權的商業模式，且技術上走與Intel差異化路線，加上一些些運氣（踏對了手機這條路，謝謝TI-Nokia，Apple，Samsung for big.Little）走小而美的路線，但是憑藉已經形成巨大的生態系統，佔據優勢。
　　MIPS，本有機會很帥，但是對指令集控制鬆散，導致生態系統分裂，沒有形成合力，最終被市場拋棄。　
　　Power，沒有形成規模效益，也沒有進入良性迴圈週期，預測是Power8會是最後一顆晶片，就這樣結束。

so庫資料夾的相容性：
arm64-v8a是可以向下相容的，如果你有兩個資料夾armeabi和arm64-v8a
armeabi有：a.so 和 b.so,
arm64-v8a只有a.so，
若app安裝在arm64-v8a架構的手機，且app有arm64-v8a的資料夾，在用到b.so的時候就會在這個資料夾查詢b.so，但由於沒有b.so所以會報錯。
解決方法是：刪掉arm64-v8a資料夾，這時手機會直接去找armeabi的so庫載入b.so

更多請參考：這裡

 

3、dependecies中api與implementation的區別
       a）compile 等同於 api
       b）implementation可以讓module在編譯時隱藏自己使用的依賴，但是在執行時這個依賴對所有模組是可見的。而api與compile一樣，無法隱藏自己使用的依賴。
假設：app module依賴了core module，而core module 又implementation了glide庫，
那麼：glide庫只對core module起作用，app module不能直接呼叫glide庫。
 

4、打包混淆相關：

buildTypes {
    release {
        // 使用混淆：true，混淆規則與下方的proguardFiles相關
        minifyEnabled false
        // Zipalign優化
        zipAlignEnabled true
        // 移除無用的resource檔案
        shrinkResources true
        // 獲取混淆配置，前一部分代表系統預設的混淆檔案，已包含基本的混淆宣告，後一個檔案是自己的定義混淆檔案
        proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'

    }
}

a）zipalign是什麼？能為我們帶來什麼？
一臉懵逼的標準回答：幫助作業系統更高效率的根據請求索引資源，將resource-handling code統一將Data structure alignment（資料結構對齊標準：DSA）限定為4-byte boundaries。 如果不採取對齊的標準，處理器無法準確和快速的在記憶體地址中定位相關資源。 
目前的系統中使用fallbackmechanism機制處理那些沒有應用DSA標準的應用程式，這的確大大的方便了普通開發者無需關注繁瑣的記憶體操作問題。但是相反，對於這樣的應用程式將給普通使用者帶來一定的麻煩，不但影響程式的執行的效率，而且使系統的整體執行效率下降和佔用大量不必要的記憶體資源，甚至消耗一定的電池資源(battery life)。 
總而言之：Android系統快速響應app程式、提高執行速度的一種技術。

b）使用混淆的注意問題：

• Java的反射不能混淆：因為程式碼混淆，類名、方法名、屬性名都改變了，而反射它還是按照原來的名字去反射，結果程式崩潰。
• 註解不能混淆：因為用了反射，不混淆任何包含native方法的類的類名以及native方法名，否則找不到本地方法。
• Activity不能混淆：因為AndroidManifest.xml檔案中是完整的名字，混淆後找不到。
• 自定義view不能混淆：因為帶了包名寫在xml佈局中，要是換成a，怎麼破？R檔案混淆了，id沒了，介面自然崩潰咯
• 第三方開源庫如新浪微博、騰訊、微信等jar包不混淆。設定方法：-keep class com.packagename.widget.**{*;}

c）移除無用resource檔案：AS 3.0.1後，如果使用shrinkResources來移除未引用資源，必須要先開啟混淆minifyEnabled，才能通過資源壓縮器將它們移除，否則編譯會報錯：Error: Removing unused resources requires unused code shrinking to be turned on.

 

5、打包的兩種方式：

    方式1）利用Android Studio生成：build--->Generate Signed APK...---> 選擇keystore檔案---> 生成
    方式2）利用Gradle生成：
 

方式二：使用Gradle 生成

1.編輯 根目錄檔案 gradle.properties 新增如下內容:
 

KEY_PATH=D:/Android/test1.jks
KEY_PASS=12345678
ALIAS_NAME=test
ALIAS_PASS=12345678

2.編輯 app/build.gradle 讀取指定的路徑密碼：在android 閉包中新增signingConfigs閉包：

android {
    compileSdkVersion 25
    buildToolsVersion "25.0.3"
    defaultConfig {
        applicationId "com.example.test"
        minSdkVersion 16
        targetSdkVersion 25
        versionCode 1
        versionName "1.0"
        testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner"
    }
signingConfigs {
    config {
        storeFile file(KEY_PATH)
        storePassword KEY_PASS
        keyAlias ALIAS_NAME
        keyPassword ALIAS_PASS
    }
}

在buildTypes release 閉包中新增 signingConfig signingConfigs.config 應用前面的簽名配置(ps:signingConfigs閉包必須在buildTypes閉包前)

buildTypes {
        release {
            minifyEnabled false
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
            signingConfig signingConfigs.config
        }
    }

3.點選右側工具欄的Gradle->專案名->:app->Tasks->build

assemble 用於生成測試版和正式版的apk
assembleDebug 用於生成測試版apk
assembleRelease 用於生成正式版apk

點選assembleRelease ，這裡提示BUILD SUCCESSFUL,說明生成成功 

apk自動生成在app/build/outputs/apk目錄

 

 

資料源自網際網路，經綜合整理而成，如有侵權，請聯絡本人。