作者：请叫我大苏
链接：
https://www.jianshu.com/p/6064a14d86a3
本文由作者授权发布。
最近基于 Android StackBlur 开源库，根据自己碰到的需求场景，封装了个高斯模糊组件，顺便记录一下。
https://github.com/kikoso/android-stackblur
为什么要自己重复造轮子？
其实也谈不上重头自己造轮子，毕竟是基于大神的开源库，做了二次封装。封装的目的在于，方便外部使用。毕竟有着自己的编程习惯，大神的开源库也只是提供了基础的功能，现实编程中，产品的需求是各种各样的。
导致每次使用时，都蛮麻烦的，需要额外自己处理蛮多东西。而一旦新的项目又需要接入高斯模糊了，又得重新写一些代码，复制粘贴也麻烦，经常由于各种业务耦合报错。
既然如此，干脆花时间抽个基础、公用的高斯模糊组件，需要时直接依赖即可。
高斯模糊
高斯模糊的原理和算法就不介绍了，我也不懂，没深入，这里就大概讲讲我的粗坯理解：
我们知道，一张图片，本质上其实是一个个像素点构成的，虽然经过计算机处理后，呈现在我们眼前的是具体的图像。但在计算机中，其实就是一堆数组数据。
数组中每个单位就是一个个像素点，那么每个像素点是存储什么内容呢，其实也就是 RGB 或者 ARGB 之类格式的数据。
高斯模糊，大体上就是对这张图片中的每个像素点都重新进行计算，每个像素点的新值等于以它为中心，半径为 r 的周围区域内所有像素点各自按照不同权重相加之和的平均值。
可以粗坯的理解为，本来这个像素点是要呈现它自己本身的内容，但经过高斯模糊计算后，掺杂进它周围区域像素点的内容了。就像加水稀释类似的道理，既然都掺杂进周围的内容了，那么它呈现的内容相比最初，肯定就不那么清晰了。
而如果掺杂的半径越大，混合进的内容也就越多，那么它本身的内容就越淡了，是不是这个理。所以，这就是为什么每个开源的高斯模糊组件库，使用时基本都需要我们传入一个 radius 半径的参数。
而且，半径越大，越模糊。
这么一粗坯的解释，就理解多了，是吧。
为什么需要大概掌握这个理论基础呢？
想想，高斯模糊是遍历所有像素点，对每个像素点都重新计算。那么，这自然是一个耗时的工作，掌握了理论基础，我们要优化时也才有方向去优化。
性能对比
大神的开源库中提供了三种高斯模糊方式，而我在 Blankj 的 AndroidUtilCode https://github.com/Blankj/AndroidUtilCode 开源库中发现了另外一种，所以我将他们都整合起来，一共有四种：
Google 官方提供的 RenderScript 方式 （RSBlur）
C 编写的高斯算法 blur.c 方式 （NativeBlur）
Java 编写的高斯算法方式1（JavaBlur）
Java 编写的高斯算法方式2（StackBlur）
其实，大体上就三种：Google 官方提供的，大神用 C 写的高斯模糊算法，大神用 Java 写的高斯模糊算法。至于后面两种，看了下，算法的代码不一样，我就把它们当做是两种不同的算法实现了。也许是一样，但我没深入去看，反正代码不一样，我就这么认为了。
下面我们来做个实验，在如下相同条件下，不同高斯模糊方案的耗时比较：
radius=10, scale=1, bitmap=200*200(11.69KB)
ps: radius 表示高斯算法计算过程中的半径取值，scale=1表示对 bitmap 原图进行高斯模糊。这些前提条件需要了解一下，不然你在看网上其他类似性能比对的文章时，发现它们动不动就优化到几 ms 级别的，然而你自己尝试却始终达不到。
这是因为也许所使用的这些前提都不一致，不一致的前提下，耗时根本无从比较。
private void testBlur() {
int sum = 0;
for (int i = 0; i < 100; i++) {
long time = SystemClock.uptimeMillis();
DBlur.source(this, R.drawable.image).modeRs().radius(10).sampling(1).build().doBlurSync();
long end = SystemClock.uptimeMillis();
sum += (end - time);
}
Log.e("DBlur", "RSBlur cast " + (sum/100) + "ms");
}
代码模板如上，分别运行 100 次后取平均值，四种不同方式的耗时如下表：
| 前提条件 | RSBlur | NativeBlur | JavaBlur | StackBlur |
|---|---|---|---|---|
| radius=10, scale=1, bitmap=200*200 | 51ms | 13ms | 162ms | 384ms |
| radius=20, scale=1, bitmap=200*200 | 56ms | 12ms | 164ms | 435ms |
| radius=10, scale=2, bitmap=200*200 | 48ms | 11ms | 75ms | 110ms |
| radius=10, scale=8, bitmap=200*200 | 45ms | 7ms | 14ms | 19ms |
| radius=10, scale=8, bitmap=1920*1180 | 183ms | 143ms | 346ms | 460ms |
| radius=20, scale=8, bitmap=1920*1180 | 204ms | 145ms | 353ms | 510ms |
| radius=20, scale=1, bitmap=1920*1180 | 474ms | 444ms | 8663ms | 内存溢出 |
100 次样本可能不多，但大体上我们也能比较出不同类型的高斯模糊之前的区别，及其适用场景：
总体上，NativeBlur 和 RSBlur 的耗时会少于 JavaBlur 和 StackBlur
JavaBlur 和 StackBlur 方式，如果先对 Bitmap 进行缩小，再高斯模糊，最后再放大，耗时会大大缩短
radius 增大会增加耗时，但影响不大，但视图呈现效果会越模糊
scale 对原图缩小倍数越多，耗时越短，但视图呈现效果同样会越模糊
分辨率越高的图片，高斯模糊的就越耗时
对于大图而言，如果要使用 JavaBlur 或 StackBlur，最好设置 scale 先缩小再模糊，否则将非常耗时且容易内存溢出
如果已经通过 scale 方式进行优化，那么最好 radius 值可以相对小一点，否则两者的值都大会对图片的模糊效果特别强烈，也许会过了头
性能优化
高斯模糊的优化考虑点，其实就三个：
选择不同的高斯模糊方式
通过 scale 对原图先缩小，再模糊，最后再放大方式
优化高斯模糊算法
最后一点就不考虑了，毕竟难度太大。那么，其实就剩下两种，要么是从高斯模糊的方案上选择，要么从待模糊的图片上做手脚。
虽然有四种高斯模糊方案，但每种都有各自优缺点：
RSBlur 在低端机上可能无法兼容
NativeBlur 需要生成对应 CPU 架构的 so 文件支持
JavaBlur 和 StackBlur 耗时会较长
优化的考虑点大体上这几种：
大体上，使用 NativeBlur 或者 RSBlur 即可，如果出现一些问题，那么此时可考虑切到 JavaBlur 或 StackBlur 方案，但记得结合 scale 方式优化处理。
如果高斯模糊的图片有实时性要求，要求模糊得同步进行处理，主线程后续的工作需要等待高斯模糊后才能够处理的话，那么尽量选择 scale 方式进行优化，减少耗时。
如果对实时性没要求，但对图片模糊程度有要求，那其实，只要后台异步去进行高斯模糊即可，此时 scale 可不用缩小太多，而利用 radius 来控制模糊效果，以达到理想的要求。
如果两者都有要求，那就自行尝试寻找折中点吧。
最后说一点，因为已经封装成组件库了，RSBlur 也是引入的 support 包，so 文件也打包好了，那么使用这两种方案足够满足绝大部分场景了，所以，没有特意指定，组件默认的方案为 RSBlur。
需求场景
为什么要二次封装？那肯定是因为有自己的各种需求场景的，我的需求如下：
要能够对当前页面（Activity）截图后，进行模糊
要能够对 drawable 资源图片进行模糊、或者对指定 View 的视图进行模糊
模糊完成后，要能够自动以淡入的动画方式显示在指定的控件上
存在这种需求场景：对当前界面截图、并且模糊，模糊后的图片展示的时机可能在其他界面，因此需要支持缓存功能，可以根据指定 cacheKey 值获取缓存
当然，可以根据各种配置使用高斯模糊，当不指定配置时，有默认配置
总结一下，其实封装要做的事也就是要实现：
截图、缓存、淡入动画、默认配置
可以的话，组件最好可以达到，其他人在不看文档，不看源码前提下，以最少的成本接入直接上手使用
实现
截图、缓存、动画这些都属于纯功能代码的封装了，具体就不说了。
这里想来讲讲，如何设计，可以让其他人以最少的成本接入直接上手使用。
我的想法是，利用 AndroidStudio 的代码提示功能，具体的说就是，你只需要了解组件的入口是 DBlur 即可，至于后续怎么使用，全靠 AndroidStudio 来提示，跟着 AndroidStudio 走就行。
例如：
当敲完 DBlur. 时，会弹出代码提示框，入口很少，是吧，就两个，看命名也能猜到作用：getCacheBitmap() 明显是用来取缓存的，那么要高斯模糊自然是另外一个入口 source()，这个方法有多个重载函数，看参数，其实也能知道，这就对应着要模糊的图片的不同来源类型，如：
直接传入 Bitmap 对其进行模糊
传入 Activity/View，内部会对这个界面/控件进行截图后再模糊
传入 resId，对 drawable 资源图片进行模糊
那么，可能想问了，哪里进行高斯模糊配置，哪里设置同步或异步，哪里注册回调等等。别急，既然只给你开了一个入口，那么就跟着入口走下去，自然会一步步引导你走到最后。如：
第一步、第二步该做什么，我都给你规定好了，你也只能按照步骤一步步来。想要设置高斯模糊配置，你得先指定图片来源，才能进入第二步，在这里，可以进行的配置也都给你列出来了，想要哪个，直接设置即可。
如：
mode()，modeRs()，modeNative() 等等类似 mode 开头的方法，用于指定要使用哪种高斯模糊方案，一共四种，每种内部都有提供对应的常量标志，但如果你不知道哪里找，那么直接调用 modeXXX 方法即可。
radius() 用于设置高斯模糊计算的半径，内部默认为 4。
sampling() 用于设置对原图的缩小比例，内部默认为 8，即默认先缩小 8 倍，再模糊，最后再放大。
cache() 用于设置缓存此次模糊后的图片，没有调用默认不缓存。
animAlpha() 用于设置使用淡入动画，需要结合 intoTarget() 使用，否则不生效。
intoTarget() 用于设置模糊完成后，自动显示到指定控件上。
另外，看每个方法返回的类名，其实这个过程都是在设置配置项，如果有对 Builder 模式了解的话，应该清楚，这个大多用来解决构造函数参数过多的场景，最后一般都会有一个 build() 或者 create() 类型的方法。参考的是 Android 源码中 AlertDialog。
也就是说，要进入下一个步骤，需要调用 build() 方法，如：
显然，已经到最后一个步骤了，这里就是发起高斯模糊工作的地方了。
doBlur() 会指定此次高斯模糊工作异步进行，所以需要注册回调的在这里传入。
doBlurSync() 指定高斯模糊同步进行，模糊后的 Bitmap 直接返回。
至此，接入结束。
使用这个高斯模糊的组件，只需要知道 DBlur 入口，其他都跟随着 AndroidStudio 代码提示一步步往下走即可，当然你也可以直接看源码，注释里也写得蛮清楚的了。
这个就是我的想法，能力不足，只能想出这种方案，如果有哪里需要改进，哪里不合理，或者有其他思路，欢迎指点一下。
使用示例
compile 'com.dasu.image:blur:0.0.4'
//使用默认配置，最短调用链
Bitmap bitmap = DBlur.source(MainActivity.this).build().doBlurSync();
//同步模糊，将imageView控制的视图进行模糊，完成后自动显示到 imageView1 控件上，以淡入动画方式
DBlur.source(imageView).intoTarget(imageView1).animAlpha().build().doBlurSync();
//异步模糊，将drawable资源文件中的图片以 NATIVE 方式进行模糊，注册回调，完成时手动显示到 imageView1 控件上
DBlur.source(this, R.drawable.background).mode(BlurConfig.MODE_NATIVE).build()
.doBlur(new OnBlurListener() {
@Override
public void onBlurSuccess(Bitmap bitmap) {
imageView1.setImageBitmap(bitmap);
}
@Override
public void onBlurFailed() {
//do something
}});
https://github.com/woshidasusu/base-module/tree/master/blur
喜欢 就关注吧，欢迎投稿！