android aar 超过2g apk大于2g

减小apk的大小，不仅对自己是经验的积累，对公司的用户来说，在下载体验上，小的包下载时间很短，不用等太久，而且省流量，所以减小包是很不错的；

一、分析APK：

使用Android Studio 2.2 新功能直接能分析APK的大小，双击打开就能看到那些占用APK比例大，方法数等。

使用方法：Build -> Analyz APK

通过以上任一工具分析我们知道我们项目中主要是以下文件占用APK大小：

• classes.dex
  classes.dex是java源码编译后生成的java字节码文件，
• resources.arsc
  编译后的二进制资源文件，非常多无效资源文件(语言)
• res
  主要是存放我们的图片资源
• assets
  主要存放了我们的缓存数据文件，已做最优化压缩，我们考虑能否云端存放。
• lib
  主要是存放我们的so库，目前我们已经优化了
  既然知道了那些数据导致我们APK体积大，那么我们就着手瘦身了。

二、资源处理

1.极限压缩：

• assets资源压缩，使用7zip或者lzma压缩方式最高
• res 图片资源的压缩，使用tinypng优化Android的资源图片，通常我们可以在保证图片不失真的情况下，多压缩几次。目前tinypng已经支持png和jpg图片、.9图的压缩
• 将非alpha的图转换成jpg形式
  tinypng的链接地址

2.使用WEBP：

WebP是谷歌研发出来的一种图片数据格式，它是一种支持有损压缩和无损压缩的图片文件格式，如果应用支持到Android 4.0+（是指没有alpha，如果有alpha的话，必须支出4.2+），那么我们可以使用WebP格式代替PNG，我们的资源大小能降低50%多。或者有些资源可以使用SVG图片资源更小。

这里提供方便转换的WEBP资源的工具：

• https://isparta.github.io/
• https://imageoptim.com/mac

3.利用AndResGuard资源压缩打包工具：

微信中的资源混淆工具主要为了混淆资源ID长度(例如将res/drawable/icon.png,png变成混淆为r/s/a.png)，同时利用7z深度压缩、对png的存储方式做了改变占用内存更小，大大减少了安装包体积

具体源码与使用方法详细在github中：

https://github.com/shwenzhang/AndResGuard

4.清除你的无用的代码以及资源：

(1)使用命令清除僵尸代码：
Analyze –>Run Inspection by name –> unused resources

分析的得到没有用资源的结果：

Analyze –>Run Inspection by name –> unused declaration

分析得到没有用的方法以及类：

上面删除之前最好用Alt+F7再确认一下，是否被引用；

其中getDefaultProguardFile(‘proguard-android.txt’)默认ProGuard设置来自于Android SDK tools/proguard/中的文件夹；

更多的代码减少可以尝试使用相同位置的proguard-android-optimize.txt文件（这里我们又减少了0.5M）proguard-rules.pro是你自定义的proguard规则。

resource shrinker 目前还不支持移除定义在values/目录下的资源文件(strings,dimensions,styles,colors),

可以指定特定的语言：

android {
    defaultConfig {
        ...
        resConfigs "zh-rCn", "zh-rHK","zh-rTW"
    }
}

五、使用APK Splits构建APK：

虽然我们上面很好的使用了resource shrinker可以回收一些未使用的资源(v7、v4、google Service 等Libarry资源)，但有些资源仍然未被清除。

例如：那些未使用的多套替代资源，或者是library内部隐患着引用着的资源而我们却没有使用到。或者是我们要根据用户的手机去提供不同版本的APK，如分辨率(xxhdpi,mhdpi等)，so库等。那么我们可以使用APK Splits大大的减少一些无用的资源，这里我们主要参考了http://tools.android.com/tech-docs/new-build-system/user-guide/apk-splits 文档。

多 apk 只支持以下类型：

屏幕密度
ABI

使用新的APK Splits，构建同一个应用程序的hdpi版本和mdpi版本，能够共享很多的任务 （如 javac，dx，proguard）。此外，它会被认为是一个单一的variant，并且同一个测试程序将会被用来测试每个多APK。

按屏幕密度拆分

android {
  ...
  splits {
    density {
      enable true
      exclude "ldpi", "tvdpi", "xxxhdpi"
      compatibleScreens 'small', 'normal', 'large', 'xlarge'
    }
  }

• enable： 启用屏幕密度拆分机制
• exclude： 默认情况下所有屏幕密度都包括在内，你可以移除一些密度。
• include： 表示要包括哪些屏幕密度
• reset()： 重置屏幕密度列表为只包含一个空字符串 （这能够实现，在与include一起使用时可以表示使用哪一个屏幕密度，而不是要忽略哪一些屏幕密度）
• compatibleScreens：表示兼容屏幕的列表。这将会注入到manifest中匹配的 节点。这个设置是可选的。

构建完成后可以在out/apk/目录下看到多个版本的APK

按 ABI 拆分

android {
  ...
  splits {
    abi {
      enable true
      reset()
      include 'x86', 'armeabi-v7a', 'mips'
      universalApk true
    }
  }
}

• enable： 启用ABI拆分机制
• exclude： 默认情况下所有ABI都包括在内，你可以移除一些ABI。
• include：指明要包含哪些ABI
• reset()：重置ABI列表为只包含一个空字符串（这可以实现，在与include一起使用来可以表示要使用哪一个ABI，而不是要忽略哪一些ABI）
• universalApk：指示是否打包一个通用版本（包含所有的ABI）。默认值为 false。
  例如：我们项目主要提供xxhdpi的图片资源，而项目中引用到了很多第三方库(v7、v4、google Service 等Libarry资源)我们无法使用到，那么我们可以通过这种方法来去除那些资源。这样我们的APK又减小了非常多

六、资源动态加载：

我们可以在项目中使用资源动态加载形式，例如：表情，语言，离线库等资源动态加载，减小APK的大小

七、依赖库优化：

1. 使用更轻量级的库代替，或者优化library的大小，不然自己写更好；
2. 删除没有应用的库；

八、支持插件化：

未来对于一些独立业务模块，可以做成插件化动态加载，用户需要使用时，只需下载少部分插件。

1. shrinkResources true 6.52 – 6.47
2. Refactor – Remove Unused Resources 6.47 – 6.16
3. resConfigs “zh-rCn”,”zh-rHK”,”zh-rTW” 6.47 – 6.02 ()