一、本文需要解决的问题
线上发现一个 OOM,是读取相册图片之后，通过 base64返回给 h5，因为目前带项目事情比较多，交给组内一个大龄同事处理。 过了半天左右，看到他提交的代码，里面写的是如果图片像素是屏幕16倍，则缩放因子是4，如果是9倍则缩放因子是3，，2,,1。看到这一坨代码，我着实害怕，虽然他说这是以前的项目就是这么干的。
作为一个多年工作的程序员，能不写死就不写死，防御性编程。上面这种做法完全就是 it works，但是 no why。而且他说虽然谷歌官网上说 inSampleSize 写的是2的 k 次方，实际上传几倍就是几分之一，然后说还用 demo 验证了下。
于是我就看了他写的 demo，debug 验证他说的 inSampleSize,貌似3，图片长宽真的缩放到1/3。看起来 work 了，但是并不能说服我。
- glide 等官方库都有做图片压缩，防止 OOM，都是以2的 k 次方为目标
- google 官网文档也有 example，也是2的 k 次方
- 我们用了很久的自研网络图片库也是2的 k 次方
所以，趁着下班时间，我写了同样的 demo，发现
- 4.4 缩放到2的 k 次方
- 5.0 缩放到2的 k 次方
- 6.0 无手机测试
- 7.0 给多少倍，是多少倍
所以证明这只是 google 在7.0新系统上 api 有所差异，不能以偏概全。
虽然直接用缩放比例，在7.0以后的系统上的确效果更好，但是还是要注意兼容以前的系统。 不能写死16，9倍之类的东西，永远记住：看起来不可能发生的事情，早晚要发生。
结论
用官方 example 来做缩放
总结
虽然我到目前只有三年的工作经验，但是我觉得一个事情，要搞清楚来龙去脉，不能写个 demo，就说是这样，而且连 google 官方文档、著名开源库，业界统一规范也不相信。
本文只是记录一下，趁着自己还有时间深入捣鼓，多写写，也算是经验分享吧。
