包体积优化---这图片怎么这么大
之前有一个版本，产品要求增加视频动态，无意间听到商务问加完之后包多大，会后和商务沟通了一下，发现投放推广的成本跟包体大小密切相关，我觉得这个事情有趣且有意义，后面就去研究了一下，最终找到方法，写了一个脚本，2分钟把包体缩小了30%，按商务的估算，单个用户的成本降低0.5-1块钱
既然要做包体积优化了，那么首先第一步肯定是google一下，看看有没有成熟方案，刚好有不少现成的方案可选，所以直接跟着前人的经验做就好了。
这里我们假设google完，没有找到合适的方案，那么我们该如何完成一项未知的工作呢？也就是解决问题的通用套路了。
分治思想
既然包体积优化这个大任务让我们无从下手，那么尝试看看怎么切割成小任务，那么首先想到的就是看看一个apk由哪些东西组成，把一个apk拖到AS中，可以看到主要的大部头内容有以下几种
- lib 下面存放对应指令集对应的so库
- res 下面存放图片资源、布局资源、字符串资源
- assets 下面存放工程目录assets中的资源，比如svga、lottie动画
- 多个dex 这里就是我们项目的字节码了
这里我们就挑res这个柿子来讲，按照体积从大到小排列，我们可以看到最大的那个目录是xxhdpi，里面存放的全都是我们项目的图片。好了，那么这个子任务就很明确了，那就是对图片大小进行优化。
跟包体积优化一样，我们看一下什么是图片，其大小怎么计算的，图片格式我们常见的有png、jpeg，大小都是这么计算的：宽 * 高 * 每个像素所占的大小。所以有两种方案
- 从宽高入手，对图片尺寸做处理，只导入需要的尺寸
- 对单位像素大小操作，降低每个像素的大小，重复上面的操作，对像素大小进行拆分，看看一个"点"是有哪些东西(ARGB、RGB)，然后继续继续看看ARGB、RGB是怎么表示的，最后最后就到了bit了，如果不需要透明度，那么把A去掉，缩减1/4的大小，对像素要求不高的小icon，我们可以用8bit来表示一个R、G、B，如果是纯黑白的，那么1bit足够表示。
通过观察，我们可以发现一个点与周围的点大概率是一样的内容，一张图片的视觉效果往往也具有明显的块状，比如对蓝天白云拍照，那么图片这些点上有大部分是白色和蓝色，如果我们对图片质量要求不高，那么相同颜色代码的点就越多了，那么其实我们可以考虑对24bit的点(RGB 3 * 8)继续做优化，既然有几大块区域颜色代码是一样的，那么我们直觉告诉我们，我们可以用哈夫曼编码来进行压缩。
解决子问题
好了，通过上面的过程，现在我们知道具体怎么对图片大小做优化了，首先当然是挑一个耗时最少、效果最高的来动手，那么就是图片单位像素压缩了，我们在上面找图片格式的时候，找到了png和jpeg，两者我们最熟悉的区别应该是前者有透明度，后者没有透明度，除此之外还有一个重要的区别就是前者是无损压缩，后者是有损压缩。
那么我们就有了以下几个关键点：
- 图片格式
- 图片压缩
- 哈夫曼编码
- Android
有了上面的关键点，我们就可以继续google寻找解决方案了，最终我们会找到一种解决方案，那就是使用webp压缩格式的图片
- 首先我们看webp是什么
- 其次看我们支持的所有设备是否支持webp
- 选几张代表性的图片，转一转，做前后大小对比，看看是否稳定、压缩效果如何，图片质量如何
- 找专业的人员(UI)来看效果
如果上面一系列操作都没有问题，那么我们本次挑选的方案就是可行，可以落地了。
结尾
最后我们通过google提供的图片转换工具，将图片转成webp，采用默认75%的压缩，将图片资源的大小缩小87%，让包体积整体缩小30%。
google的转换工具一次只能转一张图片，所以我写了一个脚本，批量执行。其次，.9.png图片不能转成webp，这里做转换的时候记得pass掉。
我一贯的想法是既然我们不是搞基础研究的，那么所学的东西一定要落地，才具备其商业价值，所以我觉得上面步骤中，第一步动机最难，只要迈出这一步，那么就会有第二、第三步，最终持之以恒，超越同行者。
很多我能想到的方案，在我之前已经被不少人想到并且成熟落地，所以即使把一个方案架构、细节研究透，我还是不想自己重新造轮子，没这个必要，分解问题，只是为了更好更快地找到成熟的解决方案，能直接用的就直接用，不行那么就拼拼凑凑合并一下，如果实在没有成熟方案，那么再考虑自造轮子也不迟。
最后思考一下，根据图片资源优化的套路，后面我们如何对lib、assets、dex做优化？
