android7.0之前，Bitmap.compress不支持哈夫曼压缩算法，压缩效率不高，因此引入libTurboJpeg库来改善压缩效率。
安卓底层使用Skia作为它的图片处理引擎，通过对libjpeg进行封装，来进行压缩图片。然而在libjpeg进行压缩图片时，有一个参数，叫optimize_coding，默认为FALSE。关于这个参数，官方的解释是，如果设置为TRUE，在压缩过程中，会计算哈夫曼表，这会显著消耗空间和时间。
然而这是对于十几年前的设备而言的，现在的设备来做这个计算完全没有压力。因此，只有在安卓7.0之后，才支持了哈夫曼算法。
开发时，把Java层的Bitmap传递到native层，然后使用AndroidBitmapAPI 取出图像所有的argb数据，接着可以舍弃a通道信息，只保留rgb信息到一个新的uint_8数组中，将这个数组作为参数传入jpeg-turbo库中，开启哈夫曼编码，就可以保存到一个新的路径中。
参考链接：//www.greatytc.com/p/32ff62bc33d5?from=timeline
1 哈夫曼树
- 先统计各个元素（像素点颜色）出现的次数，按照递增排序，得到一个数组，
- 取最小的两个，按照左小右大的原则，作为两个叶子结点，
- 计算两个叶子结点的数值之和，放入数组中，同时删除之前的两个元素，再重新排序，
- 重复步骤2,3
- 数组为空时，哈夫曼树构造完毕
- 从根节点开始，在路径上左边0右边1的规则，得到所有元素节点的哈夫曼编码
- 保存哈夫曼编码的映射表，用元素的哈夫曼编码替换元素，就可以实现数据长度的压缩。
- 解压缩时，根据哈夫曼编码表逆推出原始数据。
我们来看看2，6，8，9，3权值节点构成哈夫曼树的过程。
初始时候各个节点独立，先将其排序(这里使用优先队列)，然后选两个最小节点(抛出)生成一个新的节点，再将其加入优先队列中，此次操作完成后优先队列中有5，6，8，9节点
重复上面操作，这次结束 队列中有11，8，9节点(排序后8，9，11)
如果队列为空，那么返回节点，并且这个节点为整个哈夫曼树根节点root。
否则继续加入队列进行排序。重复上述操作，直到队列为空。
哈夫曼编码
先统计字符出现的次数，然后将这个次数当成权值按照上面介绍的方法构造一棵哈夫曼树，然后树的根不存，往左为0往右为1每个叶子节点得到的二进制数字就是它的编码，这样频率高的字符在上面更短在整个二进制存储中也更节省空间。
