背景
在开发的过程中，发现应用程序apk大小越来越大，相对于它能提供的
功能而言，它是在不应该拥有那么大的体积，没干多少 活，饭倒是没少吃，所以决定对它做精简，提高它的质量。
决定一个人会不会下载这款软件大概有那么几个方面（个人认知，轻喷）
实用性：我需要用它来解决某些问题，我不一定喜欢它，但是它能够解决我的问题。
吸引力：它提起了我的兴趣，里面有我想要欣赏或者去尝试的内容。
客观条件：应用程序大小（毕竟用户还是很珍惜流量，假如没有wifi，还有就是手机的内存）。
像前两点都是靠主观能动性去解决的，它并没有一个固定的标准，退一步说，就算是做到了极致，也还是有人会不喜欢（就是那么任性，你能有什么办法）。但是第三点，是可以通过客观存在的知识去解决的（你可以尽情去发挥，不用在意别人的脸色），而且可以在较短时间内快速解决。
正常情况下，我们所编写的代码并不会占用太大的内存（即使你跟我一样菜，冗余代码一大堆），占用apk尺寸的一般有so文件，本地的资源文件，远程服务器集成的三方工具（这个不太好弄，人家都是本着你爱用不用的态度，就看你如何根据你的应用程序去选择最优的方案了），我主要跟大家聊聊so文件与本地资源文件的精简。
so库精简
android跟ios不一样，android的cpu架构比较丰富多彩，就目前为止大概有这7中cpu架构ARMv5、ARMv7、ARMv8、x86、x86_64、MIPS和MIPS64。这7中cpu架构呢又都有各自支持的ABI（应用程序二进制接口 描述了应用程序和操作系统之间，一个应用和它的库之间，或者应用的组成部分之间的低接口。我也是百度过来的，如果有深刻理解ABI的朋友，还请您传道受业解惑）
| CPU架构 | 首选so文件类型 | 次选so文件类型 | 更次so文件类型 | 无奈so文件类型 |
|---|---|---|---|---|
| ARMv5 | armeabi | |||
| ARMv7 | armeabi-v7a | armeabi | ||
| ARMv8 | arm64-v8a | armeabi-v7a | armeabi | |
| x86 | x86 | armeabi-v7a | armeabi | |
| x86_64 | x86_64 | x86 | armeabi-v7a | armeabi |
| MIPS | mips | |||
| MIPS64 | mips64 | mips |
以上是cpu对ABI的支持情况，但是对他们的支持并不是同等级别的（就像你喜欢的女孩，总有最喜欢的和挺喜欢的），ARMv5只支持armeabi,所以他没得选择，ARMv7会首先选择armeabi-v7a,得不到的话，就会退而求其次选择armeabi（毕竟日子还是要过的），ARMv8支持的ABI顺序依次是arm64-v8a,armeabi-v7a,armeabi,x86支持的ABI顺序依次是x86,armeabi-v7a,armeabi,x86_64支持的ABI顺序依次是x86_64,x86,armeabi-v7a,armeabi,MIPS只支持mips，MIPS64支持的ABI顺序依次是mips64,mips。手机系统会根据这个顺序去选择最适合自己的so文件，直到别无选择，放弃此应用程序。
如果我们将所有类型的so库都安装的话，必然会导致apk的体积增大，所以我们就要选择最优的方案来避免这种问题，首先可以排除mips和mips64，手机厂商不会选择MIPS与MIPS64架构作为自己的手机架构，ARMv8可用32位模式运行armeabi-v7a和armeabi。x86与x86_64，一般inter的处理器会用到，目前的手机市场的占有率极低，我在网上找到了这几款摩托罗拉MT788、XT890(RAZR i) 联想K800、K900、P90 华硕ZenFone 2/2E/4/5/6、Zoom、PadFone Mini 中兴Geek、中兴Grand X in 诺基亚Lumia 1000 Intel x86 LG GW990 Lava XOLO X900（印度） Orange San Diego（英国） Megafon Mint（俄罗斯），而且他们都包含ARM模拟层，可以兼容ARM类型的ABI，剩下的ARMv5，比较古老的cpu架构，你要是很谨慎的话，应用程序的覆盖范围比较宽泛，跨度比较大的话，考虑适配，ARMv7最主流的cpu架构，覆盖范围99%，追求应用程序性能的话，可以抛弃其他所有，只适配他（毕竟最爱的人嘛）。
图片资源压缩
大家可以去pngquant — lossy PNG compressor官网下载相应的操作系统版本
解压后进入文件夹，将你要压缩的文件夹复制到此处，在pngquant下运行 .\pngquant256--force --ext .png .\文件夹名称*.png