AndroidStudio之build.gradle问题集锦

工程根目录的build.gradle

根目录下的gradle文件，这个文件的设置对project下的所有module都是有效的
buildscript {
    
    repositories {  // 这里1
        google()
        jcenter()
    }
    dependencies {
        classpath 'com.android.tools.build:gradle:3.1.4'
        

        // NOTE: Do not place your application dependencies here; they belong
        // in the individual module build.gradle files
    }
}

allprojects {
    repositories {  // 这里2
        google()
        jcenter()
    }
}

task clean(type: Delete) {
    delete rootProject.buildDir
}

为什么repositories要声明两次？

• buildScript块主要是为了Gradle脚本自身的执行，获取脚本依赖插件。如Gradle脚本需要com.jfrog.artifactory插件才能执行成功，而这个插件是从URL为https://plugins.gradle.org/m2/的Maven仓库获得。
• allprojects块的repositories用于多项目构建，为所有项目提供共同所需依赖包。而子项目可以配置自己的repositories以获取自己独需的依赖包。
• 根级别的repositories主要是为了当前项目提供所需依赖包，比如log4j、spring-core等依赖包可从mavenCentral仓库获得。

 

 

 

Module的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目录

 

 

资料源自互联网，经综合整理而成，如有侵权，请联系本人。