java8语言拥护的应对利用方法（AS3.1）-BBMarkets资讯网

.dex资料更小并且拥有更好的运行时性能

涵盖java 8语言拥护的应对

java8语言拥护的应对利用方法（AS3.1）

利用方法(AS3.1默认)

gradle.properties  android.enableD8=true

和混淆类似，利用随机无意义的名称

内联，避免对象分配

在删除未利用的类、字段、防范上更好

与相比，R8能使apk减小约10%，bbm蓝莓外汇平台怎么样体积更小

利用方法

android.enableR8=trueandroid.enableR8.libraries=true

d、移除无用代码

随着业务提升，许多之前利用的类可能并没有用到，然后又想着以后万一又能用到呢？反正就一个资料，删不删除无所谓，占内存又不大，长此以往，apk就越来越大了。

我平时都用自带的 Lint 检查软件无效代码

慕课网的性能优化影片里讲到过一种计划，通过（简单入门）对某个包下的类就行构造函数切面

@After("execution(org.jay.launchstarter.Task.new(..)")public void newObject(JoinPoint point) {    LogHelper.i(" new "+ point.getTarget().getClass().getSimpleName());}

感觉这个确实能打印出来利用的类，可以搜集起来，那还得写一个脚本找出没利用得类，删除，bbm蓝莓交易平台有点风险。

我觉得还是倡导的计划简单有效，通过插件基于线上读者上报无用代码解读

2、资源瘦身

首先我们了解一下APK解压后，资源有关的目录

a、资源混淆

混淆优点

采用计划微信的

b 、无用资源删除

android{    ....    buildTypes{        release{            shrinkResources trueminifyEnable true}    }}

一般我们都会在build.里面配置上述代码，并通过自带的Lint检查软件进行删除无用资源，这里注意，笔者流程流程中，发现用Lint检查出来的无用资源，很多其实都引用了的。

注意，这里配置 true 是真的TMGM外汇代理将无用资源去除了吗？答案：不是的

理由有两点

综上，所以说平台目前的这种做法并没有真正下降资料数目，.arsc、签名数据、以及ZIP资料数据依然没有改良。

为什么平台不做删除呢？因为.arsc和R资料的资源ID默认是连续的，删除无用资源资料，资源ID会变更，这个时候代码中已经替换过的ID就会出现资源找不到的现状，所以只是替换成了空资料。

思路计划：删除资料，并且keep住R资料和.arsc中的ID

还有一种，利用 - 解读，具体可以查看

c、图像压缩

这个对比好实现，笔者将项目中大于10k的图像都压缩了一下，体积减小了3%，笔记利用了cwebp 软件，转换成webp

# coding=utf-8import osfrom pathlib import Path'''file_directory : 目录modules : 变长参数 指定模块才解析'''def findAndConvert(file_directory, *modules):    iflen(modules) == 0:        print("modules must Designated")        returniffile_directory.is_file():        print("this is a file , need a directory")        returnifos.path.exists(file_directory):        print("has this directory")        forhomes, dirs, files inos.walk(file_directory):            # print(homes)# print(dirs)# print(files)formodule inlist(modules):                check_path = os.path.join(file_directory.absolute(), module)                ifcheck_path inhomes:                    # print("============== convert  this path " + check_path + " ================== ")# 寻找 src/main/res/darwable开头的资料# 或者直接找png jpg图像if"src\\main\\res"inhomes and "drawable"inhomes:                        # print(homes)forfile infiles:                            iffile.endswith(".png") or file.endswith(".jpg"):                                file_path = Path(os.path.join(homes, file))                                iffile_path.is_file() and os.path.getsize(file_path.absolute()) >10 * 1024:                                    # print(file)# print(file[:-4])current_file = os.path.join(homes, file)                                    target_file = os.path.join(homes, file[:-4] + ".webp")                                    cmd = "cwebp "+ current_file + " -o "+ target_file                                    result = os.system(cmd)                                    ifresult == 0:                                        # os.remove(file_path.absolute())os.system("svn add "+ target_file)                                        os.system("svn del "+ current_file)                # else:# print("please check this path " + check_path)    else:        print("this directory has not exists")if__name__ == '__main__':    path = Path("D:/WorkSVN/项目Prject/")    # 指定包名 变长参数必填findAndConvert(path, "模块名","模块名2")

d 、资源资料规范化

3 、SO瘦身

这个不多说了，直接上代码

defaultConfig {    ndk {        abiFilters "armeabi"}}

现在市面上大多都是EX外汇平台架构，例如，微信APK解读一下，也能发现只有，虽然微信对启动做了CPU 架构的适配，什么时候启动的哪个so资料，都有适配。

具体可以了解为何大厂APP如微信、支付宝、淘宝、手Q等只适配了-v7a/ ？

这里给出一个abi工作规则图

从图中可以得出另一个规则

三、进阶瘦身计划1、代码瘦身

a、三方库应对

其实这个都不能算做进阶瘦身计划，但在实际流程中，我确实没有想到对三方库进行应对，引发没必要的依赖启动进来的，毕竟将所有模块代码看一遍，很多模块不是自己写的，优化起来丢三落四的，所以放到进阶计划里了。

在选择第三方库时，需要评审一下，以性能为第一指标，包体积为第二指标，尽量选择性能好，体积小的第三方SDK，并且在利用到第三方SDK某个作用时，尽量继承某个作用依赖，而不是全部，例如只需要的某个webp作用，那就只集成webp依赖就好了。

我按照计划，将项目里所有依赖都过了一遍，发现图像有关Glide和都利用了，GG，并不能选择一个用，改动太大，涉及测试也很多，只能将这种计划在组内会议规范一下。（PS：启动长图会呈现空白的）

b、去除debug数据与行号数据

dex资料架构图(摘自极客时间开发高手课包体积优化)

一般，我们都会在混淆配置中以下面的方法保留行号数据

-keepattributes SourceFile, LineNumberTable

如果不保留行号数据，dex大约可以下降5%的体积，但是Crash上报后，会拿不到行号怎么办？难题该怎么识别？同学，莫慌，支付宝包大小极致压缩计划帮你处理。

当然，支付宝这个计划是参考的的 ReDex ，这个只拥护linux、和mac 。因为我之前了解过ReDex，所以在接到压缩体积包时，也调研过，可是编译阶段硬是没有编译过去，后面试了两次，还是有点难题，就没有利用该计划。

ReDex 有六个优点

c、Dex分包优化

上面讲到了ReDex的一个优点，基于反馈的Class字节码布局，这是啥意思呢？

类字节码在单个 Dex 中的布局是根据编译顺序而不是运行时行为决定，即便会将 App 定义的组件以及部分开展需要的类放在 Main Dex 中，但依然不是根据运行时顺序布局，这会引发程序开展时需要查找随机分布在 Dex 中的类。

ReDex 会将 APK 在 Lab 中试运行，并跟踪开展时哪些类需要启动，然后将这些类字节码放到 Dex 前部，下降开展时从闪存中寻找类的时间，从而提高 App 开展速度。

好的，大致了解了，那你可能会问，这个跟Dex分包优化有半毛钱关系？

在我们利用分包后，此时的每一个Dex可能会调用到其它的Dex中的方法，这种跨Dex调用的方法会造成许多冗余数据，具体有两点

为了保证Dex有效率在80%以上，通过以下公式来衡量优化效果

Dex 数据有效率 = define methods数目 / reference methods 数目

为了实现上述所说的数据冗余去除，ReDex配置一下就可以

{    "redex": {        "passes": [            "InterDexPass",            "RegAllocPass"]    },    "InterDexPass": {        "minimize_cross_dex_refs": true,        "minimize_cross_dex_refs_method_ref_weight": 100,        "minimize_cross_dex_refs_field_ref_weight": 90,        "minimize_cross_dex_refs_type_ref_weight": 100,        "minimize_cross_dex_refs_string_ref_weight": 90    },    "RegAllocPass": {        "live_range_splitting": false},    "string_sort_mode": "class_order",    "bytecode_sort_mode": "class_order"}