as编译源码技巧

首先我们的androidstudio的是根据系统基于 IntelliJ IDEA，就是在IntelliJ IDEA基础上增加ADT，删除其他无关的。自动化构件脚本是gradle。官话一下。

源码的系统签名as签名文件制作：
去我们的源码文件提取platform.pk8 、 platform.x509.pem ，去android studio制作一个jks。这些都是基本的步骤不说了。

。在我们的服务器新建一个文件夹,把上面的文件放在同一个文件夹下。
![image](D:\Users\ktcuser\Desktop

另外需要一个keytool-importkeypair 工具把签名

./keytool-importkeypair -k 838.jks -p mao100121 -pk8 platform.pk8 -cert platform.x509.pem -alias 6586 

把安全哈希算法计算出来的160指纹值写进去，就ok了。在我们工程的根目录新建一个jks的文件夹，把签名后的jks放进去。

在app级的build的android函数中加入添加

android {
    compileSdkVersion 23
    defaultConfig {
        applicationId "com.**.**"
        minSdkVersion 23
        targetSdkVersion 23
        versionCode 3
        versionName "2.19.06.21.1"
        testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner"
    }

    signingConfigs {
        release {
            storeFile file("../jks/358.jks")
            storePassword '100121'
            keyAlias '358'
            keyPassword '100121'
        }

        debug {
            storeFile file("../jks/358.jks")
            storePassword '100121'
            keyAlias '358'
            keyPassword '100121'
        }
    }
}

这样导入了我们的系统签名。为什么要导入系统签名呢，因为一个应用需要安装时，首先package manager会对签名和文件哈希值进行检查。因为我们开始的大多数是系统应用。如果没有系统前面我们直接使用adb安装时安装不上。文件哈希值这是密码学上的知识，高深莫测，会了他，区块链开发轻轻松松能搞定。我们的区块链挖矿，就是挖的这个哈希值，像比特币，以太坊这些矿机的挖矿，就是挖出符合条件的哈希值，像比特币是开头开头8位都是0的哈希值。那很难搞到的，需要大量的电力烧cpu电路计算。挖到一个就会有奖励，奖励就是比特币，所以矿工是这么赚钱的。。。。。。。扯远了。

第二个编译的就是修改build variants

有两个选择，debug和release，这两个通过名称就知道是什么意思了，一个是调试版和发行版，我们从表面上来看release的版本只比debug的版本文件大小小一些，至于少的那一部分是什么呢？他会对我们的代码进行一个优化：
比如

 public List getString() {
        if (mInfo != null) {
            return mInfo;
        } else {
            return null;
        }
    }

在debug的apk中还是这样，但是到了release中

 public List getString() {
       return this.mInfo != null ? this.mInfo : null;
    }

是不是一下子少了四行呢！。从中我们也得到一些启示，能一句话写的代码没必要绕来绕去，人家编译器不喜欢。
还有一个地方就是我们的duild文件

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

要是release 版的才会使用的一些配置，比如代码混淆，是否加密这些，要有会再BuildConfig 里面标记build版本,我们的debug版本as单独为我们加了一下配置方便调试的代码。，这会影响我们应用的运行，虽然效果一样。当然一旦我们修改为了release以后就不能在as运行调试了，就是那个三角形不能用了，当然两个apk运行占用的内存也是不一样的。

public final class BuildConfig {
    public static final String APPLICATION_ID = "com.ktc.mslauncher";
    public static final String BUILD_TYPE = "debug";
    public static final boolean DEBUG = Boolean.parseBoolean("true");
    public static final String FLAVOR = "";
    public static final int VERSION_CODE = 2;
    public static final String VERSION_NAME = "2.19.06.12.1";
}

说到这个我们就不得不提一下static这个关键字了，我们来看一下TextView

基本上都是static ,这是为什么呢，因为在我们虚拟机类加载的时候会为这些静态常量去单独分配内存快，而且只分配一次，就算应用有一万个实例他也只占一次内存请求的空间，，比如我们的int 只请求32位内存空间。所以用好static会为我们的应用系统省下不小的内存，当然也不是什么都用static。就比如一些我们用完不需要的实例会被内存清理清除的就没必要用static和实例特有的属性。

还有这里我们要去看一下编代码的时候

我们是v8 arm 不要选到x86的系统那是人家intel公司的芯片架构复杂，虽然也没什么，照样运行，只是为了更好的给android在安装的时候做区分，x86架构我们android系统是支持的，但是不想ARM芯片那么普遍，需要各种转换，因为他两的执行的二进制代码不相同，也就是采用的汇编语言是不一样的。

还有一个就是配置apk的输出名字。

 android.applicationVariants.all {
        variant ->
            variant.outputs.all {
                //这里修改apk文件名
                outputFileName = "6.0_Banana_Launcher_${variant.versionName}_1000.apk"
            }
    }

这些大家都知道的，，就显示一下不说了。没啥好说的额。

还有一个就是导我们系统的包mstar 啊framework啊，mstar 就懒得打字了大家都会，这个framework就写写把，不然字数太少。

两个地方 项目的build 文件

 gradle.projectsEvaluated {
        tasks.withType(JavaCompile) {
            options.compilerArgs.add('-Xbootclasspath/p:app/libs/framework.jar')
        }
    }

我们一般开发的都是系统的应用，添加framework以后就不用很多都不用通过反射来写代码了，包括以下隐藏的api.放射这种东西啊，运行比较慢，具体慢在哪，就在我们的虚拟机类加载机制那里，没法从已加载的类缓存中获取类。好用但是我们既然拥有系统级权限，为啥写代码还有用普通用户级的权限。

第二步 app 的build。

compileOnly files('libs/framework.jar')

只依赖不打包。为什么不打包呢。什么意思呢，不依赖编译器编不过，相当于我们欺骗一下编译器。不打包因为我们系统本来就有这个，虚拟机进行类加载流程的时候也是先去找的系统的，不会用你这个，没必要增加apk的重量。
mstar 包同上不说了，打字慢。来来回回半天打不对一个字。
用上面这些包方便我们直接在as进行adb安装调试，不用来回U盘安装，

另一个是依赖aar的包

implementation(name: 'name', ext: 'aar')

这些大家也是都知道的。

给我想想还有啥 ？？？？--------------------------------------------------------------真没了

as插件 ： 我基本不用，也不知道。用了一个老龙推荐的Gson自动生成bean对象的插件。
GsonFromat :拷贝服务器返回的json数据他会根据这个json自己生成bean对象，不用我们自己去写。我就用了这个插件，其他的不知道了。
好像我们编译源码上面这些就够了，从服务器拿下来的代码基本上都可以在as调试。其他的大家比我还清楚。

看一下androidstudio的自动化构建脚本gradle。

还有一个就是配置apk的输出名字。

 android.applicationVariants.all {
        variant ->
            variant.outputs.all {
                //这里修改apk文件名
                outputFileName = "6.0_Banana_Launcher_${variant.versionName}_1000.apk"
            }
    }

这些大家都知道的，，就显示一下不说了。没啥好说的额。
另一个是依赖aar的包

implementation(name: 'name', ext: 'aar')

这些大家也是都知道的。

# 另外说一下一个android studio的标签 //TODO 高效开发的关键。

网上解释：项目管理者要求代码编写人员在式样无法确定，或者其他原因不能完成编程的时候，用// TODO进行注释，那么管理者就可以随时的通过任务列表查看工作状况和问题点来进行控制。

 // todo 这里是一个bug
  private boolean 我是bug(){
    return true
  }

普通的注释 慎用！慎用！ 不然在人家大公司被很容易代码洁癖的人打和敌对，会扰乱其他人开发 。。一般是用来表示待完成，或者待解决的部分
，自己来发可以标记为代办事项，完成 TODO 标记的事件后，要按照习惯删除该 TODO 注释，如果是要正式版尽量不要上传代码带有TODO，除非是带着问题发布的apk,或者标记这里可能会带出bug的代码，一定标记上TODO，方便他人分析问题，因为这是合作高效开发的关键。

我们开发的应用很小，会觉得没啥，，但是到了大公司，大应用，设计各种架构的的应用，这个显得非常重要，软件经理也会时常观看，这个标签对提高效率和代码高效开发十分的有效。所以要养成习惯，我们普通的注释尽量不要用，用了及时删除，
我们的as都会有一个todo的tab,便于我们查看有疑问的代码，或者未完成，不完善的代码。如果没有 TODO tab，你可以通过左上角的菜单打开：View -> Tool windows -> TODO。

gradle
gradle 是基于Groovy 语言的。
build script 是由statement 和 script blocks组成的，其中statement可以包括函数调用、属性赋值、以及局部变量的定义等；而script block 是将闭包作为参数的一个函数调用。
向我们常用的buildscript

buildscript {
    repositories {
        google()
        jcenter()
        
    }
    dependencies {
        classpath 'com.android.tools.build:gradle:3.4.1'
        
        // NOTE: Do not place your application dependencies here; they belong
        // in the individual module build.gradle files
    }
}

内容少了点看一下app的build文件的代码吧，分析一下。

apply plugin: 'com.android.application'

android {
    compileSdkVersion 27
    defaultConfig {
        applicationId "com.**.**"
        minSdkVersion 23
        targetSdkVersion 27
        versionCode 1
        versionName "1.0"
        testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner"
    }
    buildTypes {
        release {
            minifyEnabled false
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
        }
    }
}

dependencies {
    implementation fileTree(include: ['*.jar'], dir: 'libs')
    implementation 'com.android.support:appcompat-v7:27.1.1'
    implementation 'com.android.support.constraint:constraint-layout:1.1.3'
}

上面这个build.gradle 是针对android工程的，他使用到了id值为“com.android.application”的插件，并通过apply函数把他引入到Gradle脚本中。这个plugin对应的jar包是我们前面看到的“com.android.tools.build:gradle:3.4.1”。而apply则属于org.gradle.api.Project提供的函数，只有通过调用这个函数线显式声明我们需要用到的插件明名，才能保证插件中提供的各种函数和属性都能在文件中使用。