有点难集中注意力做一件事。

滑动窗口是 TCP 协议中非常重要的一个概念。

TCP 在解决可靠传输以及包乱序这个问题的时，引入了 Sliding Window 。

滑动窗口分为接受窗口和发送窗口。

TCP 头有一个字段叫 Window ，这个字段是接收端告诉发送端自己还有多少缓冲区可以接收数据。Window 是一个 16bit 位字段，代表的是窗口字节容量，也就是TCP的标准窗口最大为 2^16 -1 = 65535 个字节。

• LastByteAcked 被接收端 Ack 过的位置，只要被 Ack 过才算是真正的发送成功
• LastByteSent 表示已经发送了，但是没有收到 Ack
• LastByteWritten 上层应用正在写的地方

• LastByteRead 缓冲区中读到的位置
• NextByteExpected 收到的连续包的最后一个位置
• LastByteRcved 收到包的最后一个位置，中间可能有一些数据没有到达

• 接收端在 ACK 中返回自己的 Window 为 最大缓存区大小 MaxRcvBuffer - LastByteRcvd -1
• 发送端根据该字段大小控制数据发送的多少

对于发送方来说，任何时候它缓存区中的数据都可以分为四类：

1. 已经发送并且收到了发送端 ACK 的
2. 发送但是没有收到发送端 ACK 的
3. 未发送但是发送端允许发送的
4. 未发送且发送端不允许发送的

当收到发送端的 ACK 时，对之前的数据重新分类：

当收到的 ACK = 36 时窗口滑动。

拥塞避免算法

为什么会设计这么一个算法？

TCP 通过滑动窗口来控制流量，但是控制的仅仅是收发两端的流量数据，并不知道当前网络中发生了什么，如果不清楚当前网络的情况，当网络出现延时情况时，大量数据都需要重传，网络中的将出现非常多的重传数据，这样又会导致更多的包丢失。

TCP 就是像一个交通法则，管理约束着所有在公路网上行驶的车辆，避免出现大规模的堵塞现象。

该规则主要有四个算法：

(cwnd 全称 Congestion Window)

慢启动 Slow Start

表面意思比较好理解，

买了一个馒头，吃了之后发现不够饱。又买了两个，还是不够饱，再买四个吃… 别问我为什么一开始不买十个，一开始我也不知道我要吃几个才饱。只能是慢慢试探自己的胃。

具体一开始买几个吃，以及吃不饱之后再买几个吃，这个就比较有讲究了。目前知道是这个增长速度是指数形式的。

拥塞避免 Congestion Avoidance

ssthresh (slow start threshold)，是一个上限，当 cwnd >= ssthresh 时，就会进入拥塞避免算法，该值一般是 65535 字节。

之前说过，慢算法是指数上涨，而拥塞避免算法是线性上涨。

还是吃馒头，当吃到一定个数时，觉得有点饱了，但是还没到完全吃不下的地步，可又能再按照之前的方式增加，否则就太浪费了，那么就调整算法，相对的减缓增加的数量。

拥塞发生

当 RTO （Retransmission TimeOut） 超时，重传数据包，此时参数发生改变：

1. sshthresh = cwnd/2
2. cwnd 重置为 1
3. 重新进入慢启动过程

因为丢包现象严重时，需要快速减少在网络上传输的包，然后重新观察网络状况。

Fast Retransmit 算法，收到 3 个 duplicate ACK 时就开启重传，因为还能收到 ACK 所以认为没那么严重，减少的量也没上上面那种大：

1. cwnd = cwnd/2
2. sshthresh = cwnd
3. 进入快速恢复算法 —— Fast Recovery

快速恢复 Fast Recovery

TCP Reno ：

快速重传和快速恢复算法一般同时使用。快速恢复算法是认为，你还有 3 个 Duplicated Acks 说明网络也不那么糟糕，所以没有必要像 RTO 超时那么强烈。此前的参数：

1. cwnd = cwnd/2
2. sshthresh = cwnd

Fast Recovery 算法启动：

1. cwnd = sshthresh + 3 * MSS （ 3 的意思是确认有 3 个数据包被收到了）
2. 重传 Duplicated ACKs 指定的数据包
3. 如果再收到 duplicated Acks，那么 cwnd = cwnd + 1
4. 如果收到了新的 Ack，那么，cwnd = sshthresh ，然后就进入了拥塞避免的算法了

参考链接：

https://www.zhihu.com/question/32255109
http://www.tcpipguide.com/free/t_TCPSlidingWindowAcknowledgmentSystemForDataTranspo-6.htm
https://coolshell.cn/articles/11609.html
https://www.cnblogs.com/luoquan/p/4886345.html

为什么是三次而不是两次或者四次？ 因为两次太少，四次浪费，三次是保证双方相互明确对方能收能发的最低值。

理论上多少次握手这个可信的通道都是建立不起来的，但是通过三次握手至少可以确认它是可用的，往上加握手次数只是在提高这个可信的程度。

说是三次握手其实不够准确，因为其实就是两次握手两次确认，只是其中一方将握手和确认合并在了一块。或者说其实只是一次握手，毕竟是 three-way handshake，而不是 three handshakes ，有三个步骤的一次握手。

TCP 协议中大致分为五类报文：

1. SYN 建立连接（Synchronize
2. Data 数据传输
3. FIN 断开连接（Finish
4. Reset 重置连接
5. ACK 确认连接（Acknowledgement

这图已经将三次握手的过程，画的非常清楚了，只需要知道一点，就是这个 seq 是什么，有什么用？

seq ： 是由操作系统动态随机选取的一个 32 位长的序列号，该序列号是为了告诉对方哪些数据是合法的，因为之后的数据都会在此基础上增加。

TCP 握手，握的是什么，就是交换双方的数据原点的序列号，也是就是这个 seq 。

来看看，如果我们换成四次握手是怎么样的：

1. A 发送 SYN + A’seq
2. B 接收 A 的连接请求，记录 A’seq 到本地，命名 B 的 ACK 为 A’seq + 1
3. B 发送 SYN + B’s seq
4. A 接收到 B 的同步信号，记录 B’seq 到本地，命名 A 的 ACK 为 B’seq + 1

其中 2 和 3 可以合并为一个步骤。

那么如果 4 这个步骤中 A 的 ACK ，B 没有收到会怎么样呢？

A 不会重传这个 ACK ，而是 B 在没有收到 A 的 ACK 时，会不断的重传自己的 seq 直到接收的 A 的 ACK 为止。

如果换成两次握手又会是怎么样？

1. A 发送 SYN + A’seq
2. B 发送 SYN + B’seq + ACK

由于最后少了 A 的 ACK ，所以 B 不确定 A 是否真的收到了 B 的 seq ，可能 B 的 seq 发送失败了，那么这次握手其实是不成功的，但是双方都不清楚。

四次挥手

了解了三次握手之后再理解四次挥手就简单许多。

为什么挥手比握手多一次呢？多的这一次做了什么？

看上图可以很直观的知道，关闭请求是客户端发出的，当客户端发出关闭请求时，服务端可能还有数据没有传输完成，所以会先发一个收到关闭请求的 ack ，等数据全部传输完成之后再发送 FIN，其它三步骤和三次握手基本一样。

这里有个比较有意思的东西，在客户端发送了最后的 ACK 包之后，会等待 2MSL ，这个 2MSL 是什么，为什么最后需要等待 2MSL 呢？

MSL（Maximum Segment Lifetime），报文最大生存时间，任何报文在网络上超过该时长都会被丢弃。

等待 2MSL 的目的就是担心最后一个 ACK 包对方没有收到，因为如果对方真的没有收到这个 ACK 就会重新发送之前的 FIN，那么此时就需要再次发送 ACK ，然后重置等待时间为 2MSL ，直到对方不发送 FIN 默认就是收到了 ACK 。

Consistency 一致性
所有节点访问到的都是同一份最新的数据

Availablity 可用性
每次请求都能获取到响应，不一定是最新的

Partition tolerance 分区容错性
由于网络原因，两台不同服务器可能没法通信

CAP 理论说的是，由于网络通信的问题，所以分区容错性是一定存在的，那么在此基础上 C 和 A 是不能够共存的。

为什么不能够共存呢？

举个例子：

G1 和 G2 是两台服务器，上面存在一条共同的记录 V0，现在一个用户向服务器发起一个写入请求，将 V0 修改为 V1，G1 修改完成后返回确认指令。

但是如果用户这时候向 G2 发起读的请求就会返回 V0：

那么这样就不能够保证一致性了，所以为了保证一性质，可以在用户向 G1 发起写入请求时，G1 与 G2 之间进行数据同步，并上锁，不允许用户访问该数据，当同步完成之后才给用户返回写入完成的指令。这时用户再向 G2 发起读的请求，由于 G1 已经和 G2 同步过数据，所以读取到数据是 V1：

这样就能够解决一致性的问题了。也就是说按照这种方案可以同时满足 C 和 P 。

但是在 G1 与 G2 同步的过程中，如果有用户请求 G2 读取数据，那么由于此时 G1 和 G2 在同步数据，该数据属于上锁状态，暂时不允许被读，否则会返回 V0 这种过期数据。所以这时的 G2 是不可用的，不满足可用性这个特点。

反之，如果在 G1 和 G2 同步的过程中，不对该数据上锁，那么用户访问 G2 就会返回 V0 这条过期数据，虽然数据可能不是最新数据，但是 G2 至少是处于可响应的状态，那么这样就能够同时满足 A 和 P ，不满足 C。

到处可以看出 CAP 三者中，最多只能是 CA 或者 CP。

当然，如果存在这么一个服务器，它的运算和存储能力都是无穷大，并且网络通信都是百分之百畅通且无延时，那么也就不需要分布式这个系统了。这样在一定程度上也是满足了 CAP 三者。

图片来源：https://mwhittaker.github.io/blog/an_illustrated_proof_of_the_cap_theorem/

先大抵说说故事。

在一个靠近西雅图的海岛上，住着美国人以及一些日裔，人们靠种草莓或者出海捕鱼为生，一切看起来都是那么祥和太平。

美丽的日裔少女初枝和邻家男孩伊什梅尔（美国人）青梅竹马，互生情愫，一起在海边嬉戏，在香山树洞中接吻…

但女孩因为自己的身份（日裔），心生芥蒂，从不在公众场合与伊什梅尔相认。

这份平静持续到日本偷袭了珍珠港。所有岛上的日裔都要被送出岛。那时候少女刚满 18 岁，离别前的一天，又是在香杉树洞中，他进入了她的身体，不过她推开了他，他说他们还是会在一起的，可能就是在战争结束后，他说他爱她。不过她却表示自己很迷茫。她不知道他们的未来，也不知道她对他的感情是否就是爱情。

岛上的日裔们被送去了沙漠中的集中营，在营中，她收到了他的信，他说他非常的想她，不过被她母亲发现了。不论是在什么角度，她母亲都觉得他们不合适，少女同意了，其实在她心里，她也是觉得他们不是一类人，她写了一信给他，说是他们不合适，以后就别联系了。

在集中营里她认识了她的丈夫宫本天道，也是从那个海岛上来了，后来他们在集中营里结了婚。

战争结束后，初枝夫妇回到了海岛上，伊什梅尔也回来了，不过战争带走了他的一只胳膊，当他看到自己的日思夜想的心上人成了别人老婆，还有了孩子，他无 FUCK 可说。

事情发生在一个雾蒙蒙的黎明，渔民们出海捕鱼，包括宫本。他在捕鱼时发现一艘渔船因为电池耗尽在海上漂泊，他给了渔船的主人卡尔自己的备用电池。他们分开后不久，卡尔的船被突如其来的一艘货船的巨浪打到，他不慎掉落水中，溺死在了自己的渔网里。

第二天有人发现了死在渔网中的卡尔，在调查中，许多的线索都指向天道，很多人也认为就是天道谋杀了卡尔。天道则是认为自己是日裔，不想多辩解什么，静静的等待审判到临。

伊什梅尔作为本地报社的负责人也出庭了，他还是忘不掉初枝，在法庭看到身为被告人妻子的她还是很是心动。在无意间他看到了一份只有他发现的资料，就是那艘货船的路线，他明白这份资料将在一定程度上，可以直接让天道无罪释放。

法庭上，就因为种族的问题，那些美国人潜意识里面就认定，天道就是杀人凶手，因为他长了一副日本人的脸。起诉人律师也刻意强调这件事。

那份资料在伊什梅尔口袋中躺了一整天之后，还是被交到了法官手里，天道被无罪释放了。

故事的叙述形式是穿插进行的，文章伊始就正在法庭接受审判的天道，之后又写伊什梅尔看到初枝回忆起小时候的场景。过去和现在的场景回来的交错进行。

书名雪落香杉树，有种异常纯洁的唯美。在香山树下他们相识相爱，也是在香山树下，他们相互分别。如果她是美国人，或许事情就是完全另一番景象了。可惜没有如果。

许多人觉得爱情可以跨越种族，跨越阶级，甚至跨越性别，却不知这些跨越之间存在着多么大的鸿沟。电视剧我的娜塔莎中日本女护士伊田纪子和庞天德半个世纪的苦恋，电影泰坦尼克号中 Rose 和 Jack 这对来着不同阶层的年轻人短暂的狂欢，平凡的世界中青梅竹马的穷小子少安与官二代润叶的无奈妥协，电影断背山中深爱对方的杰克和恩尼斯迫于现实的选择… 从现实到文学，此类例子数不胜数，以前有个老师和对我们说，婚姻中最重要的一点是门当户对，我一直都是嗤之以鼻，现在，在一定程度上，对当年老师说的话，我还是很支持理解的。

可以说自己变的世俗了，另一个角度来看，也是成长了。

单从爱情这条线就可以看出本书的想要表达的那个意思。我想作者和读者都是很期待有情人终成眷属吧。纯白的雪轻轻的落在香杉树上，微暖的树洞中，悸动的两人互述相思，一切都是那么美好。可惜事不如人愿，从初枝和伊什梅尔在那个时期出生，他们的血脉似乎就决定了，他们是不可能的。

书中有一个场景，那是战争结束后，伊什梅尔第一次在海岛上看到初枝，在一个商铺中，初枝抱着自己的孩子，伊什梅尔看着自己心爱的女人有了自己的家庭，感受着断臂的隐隐作痛，想到自己的断臂就是拜日本人所赐，他不禁愤怒的对初枝骂道，日本鬼子！

伊什梅尔尚且如此，岛上的其他美国人呢？

因而那场对于宫本天道的审判从一开始就是不公正的，许多人看着那副日本人的面孔，即使他是美国人，即使二战他也为美国人奋战沙场，可从骨子里，偏见就是挥之不去，始终存在。

或许有人该为那战争买单，但绝不是他们。难道只因为血脉就另眼相看？

全文，文笔细腻柔美，小岛的风景写的太好了。译者水平也好，翻译的很棒。另外，书本封面设计的有味道。

是否想过只用键盘就能完成浏览网页的日常需求？

我想其中最为困难的一点莫过于面对网页中茫茫多的超链接，用键盘基本是拿它没辙的吧。

当然，有了 Vimium ，就可以一战。

下面是按 f 键之后的网页，这时候只需要输入指定的字母就能自动跳转到对应的网页中。

一般网页跳转有两种方式，就是另起一个 tab 加载网页和在本 tab 加载网页，这两者 Vimium 都考虑到了，分别是 F(shift + f) 和 f 。

Vimium 有非常多的快捷键，只有想不到，没有做不到，这里说说我用到频率最多的几个。

直接输入问号会出现 Vimium 常用的快捷键，如下图:

上面列举了一些常用的快捷键。

Tab 切换

使用 Chrome 时切换 Tab 太频繁了。从最开始的 control + tab 从左到右一个一个切换到后来的 ⌥ + ⌘ + ← 或者 ⌥ + ⌘ + → 自由的左右切换 tab ，不过我觉得快捷键的位置还是有点儿变扭，毕竟方向键不好按到。Vimium 提供了更加方便的组合方式，通过 J(shift + j) 或者 K (shift + k) 自由的左右切换。

滚动

一点点向下浏览 j

一点点向上浏览 k

很多点很多点向下浏览 d （down）

很多点很多点向上浏览 u （up）

去顶部 gg

去底部 G(shift + g)

打开关闭

关闭当前界面 x （其实系统自带的也已经很不错了 ⌘ + w ）

打开上一个被关闭的界面 X（shift + x），这对组合很不错啊。（这个需求其实很常用，之前一直用系统自带的，shift + ⌘ + t）

打开一个新的 tab t ，不过其实熟悉了一些打开方式之后，新打开一个 tab 这个步骤基本是没用的。 （系统自带的是⌘ + t）

将粘贴板上的地址在新的 tab 中打开 P(shift + p)

将粘贴板上的地址在当前的 tab 中打开 p

返回上一个界面 H(shift + h）

去到下一个界面 L(shift + l）

效果和用鼠标点这个是一样的：

打开历史浏览或者书签或者直接 Google 在新的 tab 中 O(shift + o)

打开历史浏览或者书签或者直接 Google 在当前界面 o

有点类似 Alfred

最后

一般新建 tab 的都是在原有快捷键上加个 shift，也就是小写换成大写，方便记忆，很人性化。这个在原有的系统中，就是点击超级链接的时候，按住 ⌘ 再点，也能达到同样的效果。

Vimium 的快捷键不仅很多，而且设计的非常的人性化，许多常用的按键都是设计在触手可及的地方，像是浏览网页的 j、k、d、u 等等按键。

不过也有几个我觉得是 bug 的地方，所有的快捷键在非正常网页的地方都不起作用，例如在 OneTab 的界面或者是浏览器程序扩展界面按 J、K 之类的根本没用，有点不爽。

以及一些界面 F 和 f 的超级链接显示效果会有点距离的误差。

总的来说，还是很棒的，不过也要多使用熟悉吧。

compileSdkVersion

它告诉 Gradle 使用哪个 Android SDK 版本来运行你的应用，要使用当然要先下载。

重点： 修改 compileSdkVersion 并不会改变运行的时候的行为，但是有可能会出现新的编译问题，例如 compileSdkVersion 版本改成很低之后，出现如下的编译问题：

1
2

Error:(53, 30) 错误: -source 1.6 中不支持 diamond 运算符
(请使用 -source 7 或更高版本以启用 diamond 运算符)

虽然它纯粹只是在编译的时候使用，但是官方强烈建议我们使用最新的 SDK 进行编译，因为这样可以使用新的编译检查避免很多问题。

没有道理不用最新的啊？

buildeToolsVersion

前面我们说了 compileSdkVersion 是我们SDK的版本号，也就是 API Level，例如 API-19、API-20、API-21 等等。

buildeToolsVersion 是我们构建工具的版本，其中包括了打包工具 aapt、dx 等等。这个工具的目录位于..your_sdk_path/build-tools/XX.XX.XX。

minSdkVersion

这个概念相对非常好理解。就是该应用的最低要求。例如我们应用的 minSdkVersion 是 10 。 那么最高只支持 9 的手机是不能够安装这个应用的。

该设置的好处在开发也起到一个好处，在你使用了高于 minSdkVersion 的 API 时会警告你。

相对来说越低越好，但是许多时候，一些技术在低版本的设配上很难实现，这种时候是去做兼容还是舍弃就要好好决定了。

targetSdkVersion

相对来说，它是这几个概念中最难被理解的。

官方说它有点 interesting ， “targetSdkVersion is the main way Android provides forward compatibility” 。（ targetSdkVersion 是 Android 系统提供前向兼容的主要手段。）

这句话怎么理解呢？

举个例子，如果 API 10 中，有一个 A 方法是输出 “我喜欢你” ,而随着系统的升级，在 API 11 中，A 方法依然存在，但是源码却经过了改变，变成了输出“我喜欢你妈”。这种情况虽然非常少发生，但是还是有可能发生的。

那么这个时候设置 targetSdkVersion 的好处就来了。当设置 targetSdkVersion 为 10 时，系统运行时就会使用 API 10，输出“我喜欢你”；设置 targetSdkVersion 为 11 就会输出“我喜欢你妈”。

这么一解释，是不是就比较能够明白 targetSdkVersion 是 Android 系统提供前向兼容的主要手段 这句话了呢。

虽然 API 不会，但是 API 的行为却发生了变化。虽然一般情况下我们是将 targetSdkVersion 更新成最新的，但是要特别注意，最好是去查看新版 API 中，老的一些方法的变化，否则盲目的更新，可能就会出现 “我喜欢你” 就会变成 “我喜欢你妈” 这样的错误（虽然官方也是极力避免这种情况的发生）。

照上面所说，一般情况下，这三种 Sdk 的版本的关系是这样的
minSdkVersion <= targetSdkVersion <= compileSdkVersion

但是理想上，这三者的关系应该是这样的：

minSdkVersion (lowest possible) <= targetSdkVersion == compileSdkVersion (latest SDK)

参考链接：

buildtoolsVersion vs compileSdkVersion

Android关于buildToolVersion与CompileSdkVersion的区别

关于 SDK 的版本，官网的一些解释。

Android targetSdkVersion 原理

如何选择 compileSdkVersion, minSdkVersion 和 targetSdkVersion

minSdkVersion、targetSdkVersion、compileSdkVersion三者的作用解析

多渠道打包

友盟多渠道打包

友盟在 Github 也有相对应的文档，主要是利用 Android Gradle 中的 ProductFlavor 功能添加的多个渠道。

首先在 AndroidManifest.xml 中添加

1

<meta-data android:value="UMENG_CHANNEL_VALUE" android:name="UMENG_CHANNEL"/>

接着在 app 的 build.gradle 中添加：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

productFlavors {
    anzhi {
        manifestPlaceholders = [UMENG_CHANNEL_VALUE: "anzhi"]
    }
    baidu {
        manifestPlaceholders = [UMENG_CHANNEL_VALUE: "baidu"]
    }
    c360 {
        manifestPlaceholders = [UMENG_CHANNEL_VALUE: "c360"]
    }
    yingyongbao {
        manifestPlaceholders = [UMENG_CHANNEL_VALUE: "yingyongbao"]
    }
    huawei {
        manifestPlaceholders = [UMENG_CHANNEL_VALUE: "huawei"]
    }
    xiaomi {
        manifestPlaceholders = [UMENG_CHANNEL_VALUE: "xiaomi"]
    }
}

上面的配置看起来有点蠢，可以抽取出来，用一个方法来实现：

1
2
3
4
5
6
7
8
9
10
11

productFlavors {
       anzhi {}
       baidu {}
       c360 {}
       yingyongbao {}
       huawei {}
       xiaomi {}
       productFlavors.all { flavor ->
           flavor.manifestPlaceholders = [UMENG_CHANNEL_VALUE: name]
       }
   }

另外，签名的配置肯定不能少，也是在 app 的 build.gradle 文件中：

1
2
3
4
5
6
7
8

signingConfigs {
       release {
           storeFile file("demo.jks")
           storePassword "123123"
           keyAlias "123123"
           keyPassword "123123"
       }
   }

jks 和 keystore 俩文件，前者是 Android Studio 生成的，后者是 Eclipse 生成的，使用的时候两者都是可以的。

在 buildTypes 中加入对生成的 apk 的命名方式：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

android.applicationVariants.all { variant ->
        variant.outputs.each { output ->
            def outputFile = output.outputFile
            if (outputFile != null && outputFile.name.endsWith('.apk')) {
                File outputDirectory = new File(outputFile.parent);
                def fileName
                if (variant.buildType.name == "release") {
//                    fileName = "app_v${defaultConfig.versionName}_${packageTime()}_${variant.productFlavors[0].name}.apk"
                    fileName = "caixiangji_${variant.productFlavors[0].name}.apk"
                } else {
//                    fileName = "app_v${defaultConfig.versionName}_${packageTime()}_beta.apk"
                    fileName = "caixiangji_${variant.productFlavors[0].name}_beta.apk"
                }
                output.outputFile = new File(outputDirectory, fileName)
            }
        }
    }

然后在 AS 自带的 Terminal 下输入：

1

gradlew assembleRelease

不过有可能出现一些问题，我在 mac 下就遇到过，例如：

1

-bash ：gradlew command not found

那么有可能是权限问题，执行

1

sudo chmod +x gradlew

还有，在 mac 下执行当前目录下的命令要在前面加上 “./“。

当然也有可能是你没有配置好环境变量，按步骤设置一遍就好了。

如果一切顺利，那么差不多等上 10 分钟可能就打包好了。其实除了命令行，也可以直接使用图形化窗口操作，双击运行即可。

美团的多渠道打包

Walle ： Android Signature V2 Scheme 签名下的新一代渠道包打包神器。

打包速度相对前者来说，真的是特特别快。

集成步骤 Github 上的文档写的也挺详细的了。

配置build.gradle

在位于项目的根目录 build.gradle 文件中添加Walle Gradle插件的依赖， 如下：

1
2
3
4
5

buildscript {
    dependencies {
        classpath 'com.meituan.android.walle:plugin:1.1.5'
    }
}

并在当前App的 build.gradle 文件中apply这个插件，并添加上用于读取渠道号的AAR

1
2
3
4
5

apply plugin: 'walle'

dependencies {
    compile 'com.meituan.android.walle:library:1.1.5'
}

配置插件

1
2
3
4
5
6
7
8

walle {
    // 指定渠道包的输出路径
    apkOutputFolder = new File("${project.buildDir}/outputs/channels");
    // 定制渠道包的APK的文件名称
    apkFileNameFormat = '${appName}-${packageName}-${channel}-${buildType}-v${versionName}-${versionCode}-${buildTime}.apk';
    // 渠道配置文件
    channelFile = new File("${project.getProjectDir()}/channel")
}

这里是将渠道的配置文件单独抽取出来了，所以需要在 app 文件夹下新建一个文件 channel （ Text 类型），在里面配置渠道的信息，例如：

最后可以打包了，所有渠道的：

1

./gradlew clean assembleReleaseChannels

或者是单独的渠道 (华为)：

1

./gradlew clean assembleReleaseChannels -PchannelList=huawei

也可以直接用界面操作。

3 分钟不到， 10 多个不同渠道的包就打完了。

输出的位置是在 outputs/channels ，也可以自己配置。

多版本，多环境

多渠道使用 Walle 的情况下，我们可以基于 buildTypes 和 productFlavors 使用多版本和多环境的打包。

多版本

基于buildTypes

1. debug:调试版本,无混淆
2. release:发布版本,有混淆、压缩

1
2
3
4
5
6
7
8
9
10
11
12
13
14

buildTypes {
        release {
            minifyEnabled true
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
            signingConfig signingConfigs.test
        }

        debug {
            minifyEnabled false
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'

            signingConfig signingConfigs.test
        }
    }

多环境

基于productFlavors

1. develop:开发环境，开发和自测时使用
2. check:测试环境，克隆一份生产环境的配置，在这里测试通过后，再发布到生产环境。
3. product:生产环境，正式提供服务的。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

productFlavors {
        //开发环境
        develop {
            buildConfigField "int", "ENV_TYPE", "1"
            applicationId 'com.zhanglf.servertest.develop'
            manifestPlaceholders = [
                    app_name: "开-Demo",
                    app_icon: "@mipmap/dev_launcher"
            ]
        }
        //测试环境
        check {
            buildConfigField "int", "ENV_TYPE", "2"
            applicationId 'com.zhanglf.servertest.check'
            manifestPlaceholders = [
                    app_name: "测-Demo",
                    app_icon: "@mipmap/check_launcher"
            ]
        }
        //生产环境
        product {
            buildConfigField "int", "ENV_TYPE", "3"
            applicationId 'com.zhanglf.servertest.product'
            manifestPlaceholders = [
                    app_name: "Demo",
                    app_icon: "@mipmap/pro_launcher"
            ]
        }
    }

在 mainfest 中使用占位符：

1
2

android:icon="${app_icon}"
android:label="${app_name}"

不同渠道 资源替换问题

一种比较想到的方式是就是通过代码的方式获取渠道信息，再通过该信息，分配不同的资源。但是该方式的缺点是，不同的资源在打包的时候都被放进了 apk 中。

1

String channel = WalleChannelReader.getChannel(this.getApplicationContext());

另一种方式就是根据不同的渠道在打包的时候就将对应的资源分配好了，上面的多环境中的 icon 和 app_name 占位符的方式就是如此。

具体实现：

在项目工程的 src 文件夹下创建对应渠道的文件夹，下面存放资源文件，如下：

这样通过不同渠道打包的时候，资源文件会自动覆盖 main 中的资源，而且 main 中的或者是别的渠道中的文件都不会再该渠道的包中出现，从而更加节省空间。

上周六晚和舍友去武林广场吃鱼，在五楼恰巧看到了一家非常不错的书店，整体风格很棒。

名字叫西西弗。我印象中，西方神话中有个经常推石头的人也叫西西什么的。我试着查了下。

果然，百科中这么说的，“西西弗书店” 的名称源于《希腊神话》中的西西弗斯。

这个西西弗斯是怎么样一个人呢？

资料中是这么说的，他绑架了死神，让世间没有了死亡，触犯了众神。为了惩罚他，便要求他把一块巨石推上山顶，而由于那巨石太重了，到了山顶就又滚下山去，于是他就永无止境地做这件事，生命也就这样慢慢消耗殆尽。

据我了解，他聪明盖世，戏耍死神，调皮是一方面。往大了说，他还代表了人类对自身绝望命运的不屈。

我不经想要当一回出卷老师，多揣测一下这书店为什么要以这个人物来命名了。这是想要说明我们可以通过书籍去反抗去进步，让知识改变命运吗，即使可能每天的工作上去就如同滚上山的石头一般，看上去没有用，甚至第二天或者晚上就会又滚下来，但是我们还是要坚持，日复一日。读书即使如此。

写到这，我又想到了一个人，准确说是一个名字，哈利波特系列中的女主，赫敏。

她的名字由来也是有点意思的。（那本书中的人物名称都很有故事）

来源于希腊古神赫尔墨斯，也是一个大智慧者，传说他发明了数字和字母，不过有点点狡猾，还会点膜法，和赫敏真是太贴切了。

说回到主角百妖谱身上来。距离我上次在书店买书(不算上路边打折书摊和二手书店的话)，说实话，我已经没有任何的记忆了。原因很简单，贵。

质量一样，还贵，虽然实体书店经营不易，可是我更不容易啊。而且说实话，这种类型的书，若是没有外人推荐，我是会直接略过的。

正好前几天女朋友在看，还以很快的速度看完了，要知道那人其实不是很爱看书的。主动去找这书看，我想我是不会去的，毕竟那不是我的菜，不过送上门来，额，看了看价格，还是，勉为其难的拿下了。30 多元钱呐，一分都不便宜。就当支持下实体书店了。

真的，不得不说！！我讨厌腰封，又叫书腰，就是这个玩意：

越来越流行，好像没有书腰的书就是二流书似得。以前是新人出书的时候，出版社会添加一些有的没有的算不算奖项的奖项或者推荐语之类的噱头上去吸引读者的，生怕别人不知道这书有多好看。现在是但凡新出的书，再版的书，不论新人旧人，无名人还是大名人，都来这么一套。

我讨厌书腰的一个原因是这东西太碍事了，看书的时候套着多不方便啊。但是直接丢了又会觉得我买的书有点不完整了，而且有些书腰设计的其实并不赖，但是这玩意真的影响平常的阅读，要为这种屁大点事情纠结费心，即使一小会儿，我都非常讨厌。

说回到书的内容。

百妖谱，上面记载了许许多多的妖怪的故事。朋友给我介绍的时候就说过，有点像是夏目友人帐，这个动画片最新的一季好像又开始更新，不过第一季我就看过两集，就没看了。说实话，治愈系的风格，不是我的菜。（那什么，我可是要尝百草，舔苦胆的人，不要治愈，要现实）

我不知道作者目前是否已经写了一百个妖怪了，手上的这本上面一共记载了十个妖怪。书本到手的第二天，也就是周日，和一个同事去图书馆待了小半天，一开始没个像样的地方坐，做在地板上，依靠着窗户，有点犯困，买了杯青柠饮料，发现有点涩，没有第一次的好喝，慢慢悠悠的看了五个故事。

之后每个晚上睡前一个，刚好一周，都看完了，挑两个印象深的说说。

作者说的这些妖怪，大都是各种书籍中有介绍的，根据它们的特征，给它们编了一些可能是恰到好处的所谓治愈系故事。

先说点大致的背景，这是一个六道轮回看得见的世界，设定中妖魔鬼怪，神仙凡人拥有各自的管理者。其中妖的管理者都住在于一个叫桃都的地方，女主桃夭是桃都的一个医生，目前看来，医术高超，战斗力爆表。

女主外出给妖怪看病的过程中，遇到了各种各样的有故事的妖怪。

灰狐就不说了，萌萌的滚滚，就是为了放在身边当小可爱用的。

说两个妖怪的故事，腾根和应声。

腾根，传说中“追恶凶”的十二位神明之一，非俗世之兽，善嗅，能辨仙魔真身，人间善恶自不在话下。

这是一对表面上很恩爱的普通老夫妻，但实际上老奶奶却是老公公（腾根）所要捉拿的要犯。她是蛊虫世家的唯一后嗣，她将家族中唯一存活的蛊种在了他身上，为的是他能一生一世和她在一起，俗不知，他是世间最善辨最懂蛊的人，早已看透这一切，却心甘情愿被她种下这情蛊，只为能与他厮守终身。

既然能遇见个让你不想离开的人，就留下吧。

爱情许多时候就是明知不可行而行之，再或许，看她犯傻也是一件开心快乐的事。

取次花丛懒回顾，半缘修道半缘君。

只能是羡慕他们了。

应声，以应声虫为原型的妖怪。（应该是）

应声虫，百科中这样解释，被认为是引起这种怪病的寄生虫，栖息在人的肚子里。宿主每当发出声音时，肚子里就会有很小的声音效仿，且会越来越大声。

在成语中是用来比喻自己胸无主张，随声附和他人的人。作者这里将它极度化了。

故事比较简单，一个女孩，有点胖，有点自卑，别人说她是猪，她很难过，一直待在家里不出去，加上肚子中有应声虫，慢慢人脚变成了猪脚，甚至长出了猪尾巴。差不多就是这个意思。

这篇写的一般般，却让我思考了许多。

越是弱小的人，越是不自信，越是在乎别人的看法。

自卑来源于他人异样的眼光，更是来源于自身的低微。

他人的鼓励或是批评，或是嘲讽，各式各样，弱小的人往往经常将它们挂在心中，特别是你在乎的人对你的看法，如何学会正确的过滤它们，真是要时间不断磨砺自我心智。还有就是让自己变得更强大。

是的，不要将自己低微到尘埃中，他强任他强,打野来帮忙,他皮任他皮,当他是瓜皮。

或许，可能，唔，我的身体里也寄生了不少的应声虫，它们在我中学时期大量繁殖，却又在大学毕业后不久大量消亡。

势必，我要将它们赶尽杀绝。

做自己。

这本书是前两周在 Amazon 买书的时候，系统推荐给我的，不得不说，推荐的敲到好处，我也一并买下了。

之前看村上春树的书总是耐不下心来，像是《海边的卡夫卡》，《挪威的森林》，只能是大概看懂个大概的故事情节，以及一些表面的我觉得可能是如此的作者想要提现出来的人生感悟，深入的话就不能够了。

所以大学时期我更喜欢看东野圭吾的书，故事性强，可读性高，人性啊立意方面的东西虽说也是不差，但是相比村上春树的文风，就像前几年我在朋友圈说过的，一个是流行，一个是古典。

趣味性方面，东野圭吾的书读起来更有意思一些，比较白话，不费劲，也没有什么深层次的东西（目前我的看法），而且篇幅相对短一点。

自从被安利看了第一本《白夜行》之后便一发不可收拾，图书馆他的作品一连看了十多本，其中最喜欢《恶意》。

之后就开始读村上春树作品。起初读他的书，总是将其当成是一个成就一样的东西，好像看完一本就能点亮一个图标或者是完成人生目标之类的东西，又好像为了能让自己看上去似乎饱读经典，能更好的装逼，实则背道而驰了。

《当我跑步上我在谈些什么》这书名是根据被称为是”美国的契诃夫“作家 雷蒙德·卡佛 的短篇小说 What We Talk About When We Talk About Love 改编而来。记录了一些作者村上春树在跑步时记录的一些想法。由约十个短篇组成，我在午休期间陆陆续续的看完了，说两点让我印象深刻的观点或是想法吧。

说实话，我是才知道，原来村上春树是一名跑者，而且还不弱。连续跑了三十多年，风雨无阻，真是不容易。

这让我想到了另一个牛逼的人物，图灵，计算机天才（真正的计算机之父！），二战大功臣（让战争提前几年结束！）。

他也是一名跑步爱好者，而且强的一匹，业余的成绩与当时的奥运会马拉松冠军成绩相差无几。当问他为什么要跑步时，他说，“我做的工作压力太大，我能把它从内心去除的唯一方式，就是使劲地跑。”可以看这篇文章。

村上春树在跑超级马拉松的时候说，当他迈过四十二公里时，整个人，都发生了微妙的变化，仿佛进入了一个陌生的领域，越往后，越觉得自己不是人了，是一台机器，而且在不断的自我催眠，因为只有机器才能如此一直无止境的奔跑下去。我想那个过程中的肉体应该已经麻木到失去了知觉，思想却同时进入了一个非常纯粹的领域。（没有真正体会过的我只能暗自羡慕了）

村上春树说他在跑步的时候遇到一个问题，我想，这个问题不当只是出现在跑步中，几乎在坚持做所有的事情时都会出现。

总有那么一个时候，你突然想放松了，不想跑了。一开始作者觉得，可能是他跑的还不够久，或者是觉得自己的心态还没调整到位够好，若是专业的选手应该不会有这种问题出现，但是当他去询问一个专业的马拉松运动员时，被问者仿佛用看弱智的眼神看着他，回答道，怎么可能？我也有不想跑的时候啊。

看到这个回答的我和作者当时的感受十分相似，好像是突然轻松了一点。是啊，大家都是人啊，总是有那么一个时候想休息一下，放松一下不是吗。

可，坚持做一件事情的理由许多情况只有一个理由，不做这件事情的理由却是多到数不清。是了，我坚持做这一件事情，理由就一个，为了自己能更加健康一点，但是每天工作都那么累了，而且有可能，今天加班，今天脚疼，今天头晕，今天家里来客人了，今天朋友请喝酒，今天配、陪女朋友出去玩，今天下暴雨呢，今天生日啊，今天健身房没开，今天要看总决赛呢，今天搬家，今天···

我从几周前开始坚持每晚锻炼至少半个小时，到今天，20来天了。那种今天有点特殊，就好好休息一下吧的念头每次锻炼前都在缠着我，庆幸的是，除了昨晚看电影到凌晨，别的时候我都坚持下来了，就算这个月都是加班到我回家都十点了。

看电影到凌晨回家，这也算是不做这件事情的理由了，不是吗？而且我做的还只是室内的运动，若是室外运动或者打断的理由更多。

我有点能明白那种不想去做一件事情而给自己找理由的心理活动。当可以选择的时候，人总是想着做能让自己更加轻松点的事情，感觉又是说到了之前在人是否要有上进心的问题上，自律的问题或者就是所有事情的来源本质吧。

看这本书的时候，我总是有种跃跃欲试的冲动。可惜我要加班没那么多时间去跑步啊，可惜工作都那么累了哪还有什么精力去跑步呢，可惜家附近都是车道什么的找不到好的跑步地点。还是如此，那么多不做这件事情的理由在阻碍着我，而去做这件事的理由就只有，我想去跑。

经常运动的好处就是，作者几十年来从不生病。真是让人羡慕。

他还提到一个比较好玩的想法，他说有些人的体质是天生容易变胖，就比如作者自己，有些人则是天生不容易长胖，就比如作者的妻子，所以一开始作者比较羡慕他老婆，说是造物主的不公。可后来又觉得，从另一个角度来看，自己这样的体质或许是幸运的，因为担心容易变胖所以会适当的去锻炼，而像他妻子体质的人反而会因为怎么吃都没关系疏忽了锻炼。

当然，若是他老婆那种体质的人又有需要时刻锻炼自己的心态，那就非常了不得了。（看到这我，暗暗表扬了下自己，唔，不能骄傲）

最后，我发现看作者的随笔散文之类的玩意更容易了解作者本身，好像我说的是废话。其实若是厉害点的读者，就算看作者写的小说也能够与作者对话，了解作者吧。可惜我还不能够，看小说的时候，更多只能看到主人公的内心想法，而看不出作者的内心想法，特别是老道点的作者，更是捉摸不透。而看随笔就非常直接了，因为主人公就是作者，看起来会让你觉得很亲切，内容方面也是贴近生活，不用去理解虚构小说中的背景时代什么的，太费劲。还有就是像我这样时间都是碎片化的，没什么时间能够投入到一部长篇小说中，这种短短的一篇篇的随笔就是很不错的选择了，收获还不小呢。

这本书算是近期花费最多时间和精力看的熟了，相对来说也是篇幅比较长的。

书是在图书馆凭眼缘找到的，作者和书名在之前可能是略有耳闻，不过不是很清楚，从书架上去下发现村上春树为它写了2万多字的长序，而且还负责将其翻译成了日文版。从序中可以看出他对这本书的称赞和推荐。

一开始我只当成是普通的可能是言情伤感类的小说来看，没想到是一本侦探小说，那更是符合我口味了。

唔，不过看着看着我发觉它和一般的侦探小说可能是有许多不同的地方，将更多的笔墨花在人物性格的刻画上面，对于真正的故事情节，并没有想象中的那么悬疑或者说是有什么地方令人大吃一惊的。（恩？我好肤浅啊。）

许多人说，作者钱德勒那时候写文章已经到了随心所欲，能将所想全都写出来，我想，写作最高的境界无非就是如此了。

可惜，这书，没能够静下心来看，晚上睡前翻翻，虽说是整本都看完了，但是期间更多是觉得有些冗长，没有和作者产生共鸣，也没有体会到别人说的主角马洛那深深的孤独，看完的瞬间最大感受居然是–终于看完了啊，还为此松了一口气。

另外，看书的过程中，我怎么觉得，主角像是一个基佬。为了一个陌生的男的，赴汤蹈火似得，为了自己的职业操守？在被严刑拷打的过程中，装逼常伴他身，很酷。

那种我行我素，无所畏惧的性格但是倒还不错。

听说这本书是作者在照顾病中的妻子时写完的，所以书中也是弥漫着一丝的伤感和离别。

总之，不是很推荐，啊哈哈。

说一声再见，就是死去一点。

生活，被挤压的，只剩 活 了。

希望自己能够充分利用时间，目标不论大小，努力完成。

看书慢一点。

一闪一闪的，是因为我使用全局热键唤出或者隐匿 iTerm2 ，这个软件的一些技巧和配色我之前有做过较为详细的说明。

输入

1
2
3

letter_codes = [ord(ch) for ch in 'WASDRQwasdrq']
actions = ['Up', 'Left', 'Down', 'Right', 'Restart', 'Exit']
actions_dict = dict(zip(letter_codes, actions * 2))

考虑到大小写，所以用数组 WASDRQwasdrq 和 act x 2 中的操作一一对应。

1
2
3
4
5

def get_user_action(keyboard):
    char = "N"
    while char not in actions_dict:
        char = keyboard.getch()
    return actions_dict[char]

除了 N 和 actions_dict 之外的字符输入都是无效的，阻塞循环等待。

矩阵的操作

1
2
3
4
5

def transpose(field):
    return [list(row) for row in zip(*field)]

def invert(field):
    return [row[::-1] for row in field]

分别是用来转置和逆转矩阵用的。（上下操作矩阵用转置，左右才做矩阵用逆转）

棋盘初始化

1
2
3
4
5
6
7

def __init__(self, height=4, width=4, win=2048):
        self.height = height
        self.width = width
        self.win_value = win
        self.score = 0
        self.highscore = 0
        self.reset()

绘制

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

def draw(self, screen):
        help_string1 = '(W)Up (S)Down (A)Left (D)Right'
        help_string2 = '     (R)Restart (Q)Exit'
        gameover_string = '           GAME OVER'
        win_string = '          YOU WIN!'
        def cast(string):
            screen.addstr(string + '\n')

        def draw_hor_separator():
            line = '+' + ('+------' * self.width + '+')[1:]
            separator = defaultdict(lambda: line)
            if not hasattr(draw_hor_separator, "counter"):
                draw_hor_separator.counter = 0
            cast(separator[draw_hor_separator.counter])
            draw_hor_separator.counter += 1

        def draw_row(row):
            cast(''.join('|{: ^5} '.format(num) if num > 0 else '|      ' for num in row) + '|')

        screen.clear()
        cast('SCORE: ' + str(self.score))
        if 0 != self.highscore:
            cast('HIGHSCORE: ' + str(self.highscore))
        for row in self.field:
            draw_hor_separator()
            draw_row(row)
        draw_hor_separator()
        if self.is_win():
            cast(win_string)
        else:
            if self.is_gameover():
                cast(gameover_string)
            else:
                cast(help_string1)
        cast(help_string2)

绘制水平和垂直方向的线条，以及最高分的显示。

棋盘操作

重置

1
2
3
4
5
6
7

def reset(self):
        if self.score > self.highscore:
            self.highscore = self.score
        self.score = 0
        self.field = [[0 for i in range(self.width)] for j in range(self.height)]
        self.spawn()
        self.spawn()

随机添加

1
2
3
4

def spawn(self):
    new_element = 4 if randrange(100) > 89 else 2
    (i,j) = choice([(i,j) for i in range(self.width) for j in range(self.height) if self.field[i][j] == 0])
    self.field[i][j] = new_element

spawn 是卵，繁殖的意思，随机添加 2 或者 4 。

移动

虽然有四个方向的操作，但是通过对矩阵的转置和逆转，我们只要对一个方向进行处理，别的方向上操作，转化过来就行了。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42

def move(self, direction):
        def move_row_left(row):
            def tighten(row): # squeese non-zero elements together
                new_row = [i for i in row if i != 0]
                new_row += [0 for i in range(len(row) - len(new_row))]
                return new_row

            def merge(row):
                pair = False
                new_row = []
                for i in range(len(row)):
                    if pair:
                        new_row.append(2 * row[i])
                        self.score += 2 * row[i]
                        pair = False
                    else:
                        if i + 1 < len(row) and row[i] == row[i + 1]:
                            pair = True
                            new_row.append(0)
                        else:
                            new_row.append(row[i])
                assert len(new_row) == len(row)
                return new_row
            return tighten(merge(tighten(row)))

        moves = {}
        moves['Left']  = lambda field:                              \
                [move_row_left(row) for row in field]
        moves['Right'] = lambda field:                              \
                invert(moves['Left'](invert(field)))
        moves['Up']    = lambda field:                              \
                transpose(moves['Left'](transpose(field)))
        moves['Down']  = lambda field:                              \
                transpose(moves['Right'](transpose(field)))

        if direction in moves:
            if self.move_is_possible(direction):
                self.field = moves[direction](self.field)
                self.spawn()
                return True
            else:
                return False

棋盘的合并都是先消除中间的空格再合并相邻的数字。tighten 是靠拢，merge 是合并。

判断是否能移动

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

def move_is_possible(self, direction):
        def row_is_left_movable(row):
            def change(i): # true if there'll be change in i-th tile
                if row[i] == 0 and row[i + 1] != 0: # Move
                    return True
                if row[i] != 0 and row[i + 1] == row[i]: # Merge
                    return True
                return False
            return any(change(i) for i in range(len(row) - 1))

        check = {}
        check['Left']  = lambda field:                              \
                any(row_is_left_movable(row) for row in field)

        check['Right'] = lambda field:                              \
                 check['Left'](invert(field))

        check['Up']    = lambda field:                              \
                check['Left'](transpose(field))

        check['Down']  = lambda field:                              \
                check['Right'](transpose(field))

        if direction in check:
            return check[direction](self.field)
        else:
            return False

能移动就两种情况，一是有空格，一是有相邻位有相同的数字。

状态

先分析游戏都有哪些的状态，初始化（Init），游戏中（Game），获胜（Win），失败（GameOver），退出（Exit），如下图：

然后各个状态之间通过对应的方法联通。

补充主逻辑的代码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48

def init():
        #重置游戏棋盘
        game_field.reset()
        return 'Game'

    def not_game(state):
        #画出 GameOver 或者 Win 的界面
        game_field.draw(stdscr)
        #读取用户输入得到action，判断是重启游戏还是结束游戏
        action = get_user_action(stdscr)
        responses = defaultdict(lambda: state) #默认是当前状态，没有行为就会一直在当前界面循环
        responses['Restart'], responses['Exit'] = 'Init', 'Exit' #对应不同的行为转换到不同的状态
        return responses[action]

    def game():
        #画出当前棋盘状态
        game_field.draw(stdscr)
        #读取用户输入得到action
        action = get_user_action(stdscr)

        if action == 'Restart':
            return 'Init'
        if action == 'Exit':
            return 'Exit'
        if game_field.move(action): # move successful
            if game_field.is_win():
                return 'Win'
            if game_field.is_gameover():
                return 'Gameover'
        return 'Game'


    state_actions = {
            'Init': init,
            'Win': lambda: not_game('Win'),
            'Gameover': lambda: not_game('Gameover'),
            'Game': game
        }

    curses.use_default_colors()
    game_field = GameField(win=1024)


    state = 'Init'

    #状态机开始循环
    while state != 'Exit':
        state = state_actions[state]()

代码来源

被安利了两次之后还是看了，虽说我也不知道为什么就是不大喜欢民国时期的人情世故。

故事内容相对还是比较简单的。一个上海女学生，毕业没多久参加上海小姐竞选得了个第三名，之后莫名其妙的被大她近二十岁左右的主任（可能叫主人更准确点）包养了（这里说莫名其妙不是指被包养这个事情，因为这现象在当时的上海实在是很常见的，我觉得奇怪的是，这女的刚开始给我的感觉不像是个见两次面就同意被包养的，这个过渡于我来说略显突兀），之后不久新中国成立了，主任死了。女主回老家家待了一段时间，也不知是耐不住寂寞还是想上海了，又回来了，简单学了学，当了个护士，没事和邻居唠唠嗑，打打牌。

两男两女搓起了麻将，再之后也不知是太饥渴了，还是真的入了情，和其中一个男的搞上了，还把肚子弄大了，这男的没担当，靠不住，女主就睡了另一个男的，说这个孩子是他的。

去医院动手术的时候，女主突然决定把孩子生出来，就出了医院。

出来之后遇到了还是学生时候就喜欢她的备胎，这备胎也是喜当爹了，照顾她到生了孩子，真是感动中国十大人物，可惜她并不爱他。

再之后，没什么好说的，备胎在文革的时候，自杀了，女主倒是一直活得好好的，女儿也长大成人，还去了美国，故事就差不多结束了。

书本前几章都是废话，可能是我不懂欣赏，不过这获得了矛盾文学奖的作品，在豆瓣评价却不大理想。

fr@nk 一星 2013-11-23
看完就想把书撕碎了扔到黄浦江里，人物干瘪，关系苍白，剧情狗血，完全是某位中年妇女对逝去年华的压抑却又要涌出的意淫，电影和电视剧的不成功就源自于此，一颗星给王老师靠吃红烧肉拗出来的文笔。

瞌睡的南瓜 一星 2012-06-17
不喜欢的女纸，不痛快的情感，缺底气的情节。看得很辛苦，读完很拧巴。简介说“一个女人四十年的情与爱，被一枝细腻而绚烂的笔写得哀婉动人”，后半句没一个形容词说对的。水木丁那篇评论说得好——王安忆是把女人看扁了。

说实话，文笔细腻还是有的，写景和物的时候，例如前几章的弄堂，流言之类的。写的细腻到我一点都不想看，罗里吧嗦。虽然我知道写这种东西肯定是为了渲染什么悲情气氛，描写旧时上海怎么样的环境场景云云的为之后的情节做铺垫啊什么的狗屁。

对于书名为什么叫 长恨歌 我有点不解，有人说是

大概是因为这个女人一生的爱情都很不成功吧。

在为一种已经远逝了的文化形态谱写一曲无尽的挽歌吧

关于女主一生的爱情不成功，我想，这不都是咎由自取吗？选择被包养的时候就要做好那种准备。另外，我真是看不出来，她是否真的爱过谁。

爱主任？就算真的生活潦倒也十分不愿意将他送她的金条兑换了？未必，连人脸都完全记不得，可能留着那些东西只是为了怀念自己的青春之类的玩意。

爱备胎？好吧，这个所谓的程先生可以直接跳过，从头到尾就只是个备胎。

爱孩子她爹？这个倒是有一点点可能，不过这种男的，真是的太没用了。而且把孩子生下来更多的估计是为了她自己，和他是没太多关系的。

说到把孩子生下来倒是蛮佩服女主的，毕竟备胎跑了之后，她一个人含辛茹苦把孩子养大很不容易。

对于按个时代的女人的描写，我第一个会先到旗袍，提到旗袍一反应是汤唯和张曼玉：

（哈哈，巧的是这两部剧的男主都是梁朝伟）

这书是昨天在图书馆看的，找了接近一个小时快崩溃的时候突然发现的，所以读起来更珍惜一点。

哦，其实一开始我一直以为女二是个同性恋来着，哈哈。说到这，必须说说，书中人物个性的塑造，我觉得不够好,很多角色的行为有点莫名。写到这我查了下作者本人，发现他是个女的。

啊哈哈，我说呢，一开始女主在校期间，和吴佩珍那段写的那么细腻，那么的小肚鸡肠女人心，我当时还佩服这作者还挺懂小女人的，那傲娇写的活灵活现。没想到啊没想到。

若是说，作者的目的就是写那么一个当时上海的较有经典特色女人的缩影，那我觉得她的写的还是很棒的，人物确实很市井。

若是… 那是真是把女人看扁了。

我翻了一下 5 月初，自己定的小目标，发现说了非常多的废话，真正确定的，明确的东西很少。

虽然如此，整个 5 月还做的比较不错的，像是说一个月至少看一本书，这个目标就是超超额完成了，不过像是每周看一个新的小知识点可能就是没有做到。

对于什么早睡之类的目标，这个整体完成度还是不错的，可能是有个别一两个晚上迟了点。

5 月去图书馆看了点书，也借了不少书。

5 月妈妈和姐姐来杭州了，我带她们去了杭州许多地方玩，以及吃了两顿不错的午饭。

5 月公司开了运动会，我拿了跳绳冠军。

5 月部门团建，大家一起去烧烤，玩的挺开心。

5 月买了一个单反，开始学习摄影。

5 月一个人去千岛湖露营过夜，走走停停，拍了不少的照片，还算潇洒。

5 月学了一门新语言 Python ，整理了一些关于它基础笔记，也用它搞了个小游戏。

…

忙碌的 5 月结束了，相信 6 月会过的更加充实，那么就定几个硬性的目标吧。

安卓，饭碗的东西含糊不得。至少每周看一个三方库源码，简单复杂都行。

Python ，至少每周做一个小实验，分析，并记录。

书，至少每周看一本，并写读后感。

电影，一个月至少不快进的看三部 8 分以上作品。

运动，每三天至少两次全身湿一次。

英语！重点项目！至少每两天打卡一次单词，一次口语，以及每天阅读必打卡。另外看完一部英文原著，暂定 月亮与六便士 。

不积跬步无以至千里

好几篇小说合在一块的，重点说几篇印象深的。

(虽然时间是 6 月 2 日，但那只是创建时间，真正写的时间是 6 月 18 日，一把辛酸泪)

阿霞

名唤阿霞的女子，一开始我还以为她是个爱哥哥的奇怪女子（这里说的爱指的是爱情，不是情亲，否则我也不会觉得奇怪了），喜欢上了浪迹天涯的男主。

不过在最终表白的时候（女主要走了，约男主在阁楼相见），男主比较怂包的一脸懵逼，女主就跑了，终。

整体情节很简单，但是对于人物的刻画非常的细腻，女主的热情和害羞写的很生动。

但是，说实话，我不大是很喜欢看这种类型的小说，细节描写虽然很到位，可看多了会让我有种无趣的情绪，我想，这原因肯定是在我身上。

太急切了。我看书，更多的是追求情节的发展和构思的巧妙，迫切的想要看到结果，往往就会错过许多沿途的于我来说或许更加重要更加有意义的风景，没有办法更加投入的去思考和沉浸其中就不能深一层的与作者对话而从体会到更多他们想要传递的有价值的世界观。

初恋

一些资料上是说这个故事的原型就是作者本人。哎，这故事有些地方我很难去舍身处理的理解，涉世尚浅啊，无奈。

小男主喜欢上了一个比较成熟的邻家女孩，她很美，很懂事，是许多小男生追求的对象。

小男主为其倾倒，茶不思，饭不想的。然而并没有什么软用，她喜欢的是小男主他爸爸。

知道真相的我，心中万只草泥马崩腾而过，这什么鬼。不过最后女主还是没和他们中的任何一个在一块就是了。

情节上也是比较简单，更多的笔墨都是花在描写场景和人物心理。

笔法真是好啊，如诗，如画，浪漫，细腻，真挚，深情。不过有点而过于古典了，以至于我这个现代人许多地方很难带入其中，估计是我境界不够。

整体还是比较喜欢的。

春潮

书名是 初恋 ， 貌似这篇 春潮 的篇幅更长些，给我的印象也是最深的，不知道是不是因为它是我最后一篇看的，哈哈。

又是一篇以作者部分自身经历为引子展开的小说（作者很棒棒啊，文中用了不少于四国语言，为翻译人员点赞）。

不得不说，屠格涅夫，笔下的女子性格都非常鲜明，而且而且，女主都好美啊。

全文最重要的一个地方居然省略了，就是男主和控制力超强女躲雨跑到林中小屋那段，一笔带过，以至于我非常难想象控制力超强女在小木屋中对男主做了什么事情，让他放弃了美美的女主，然后懊悔一生。

许多地方，人物之间的情感来的有些莫名奇怪，来也匆匆，去也匆匆的，有点摸不着头脑。

可仔细一想，现实生活中，不正是如此。感情的事情，比起潮水，更加不能够预测，潮起潮落，即使是沙滩上的那些或深或浅的痕迹都是转眼即逝。

他的书，我想短时间我是不会主动看了，内容太少（指的是情节），但是看起来却一点都不轻松，古典的东西，啃起来费劲，而且往往收获和经历成正比（我想我还是太年轻），再则，我慢慢喜欢上看随笔和散文，能够随时拿起放下，这对于工作空忙不定的人来说，非常关键。

在公司书架上借的一本书，作者和书名早有耳闻。

在午休期间陆陆续续翻了百来页，有点坚持不下去了，今天拿去还了。

这书估计，会看我博客的人，不会有人会去看的，就像没几个青少年会去主动看什么 狂人日记 或者 呐喊 之类的书。

本书主要是以猫的角度来讽刺日本那个时代，文人墨客、资本家的虚伪迂腐之类的玩意。

给我的感觉是，和鲁迅有些方面很像，首先人长的有点像，哈哈。

接着是风格，这点真的给我感觉，神似。太多地方给我的感觉很像，特别是那种讽刺的口吻，额，这只能是只可意会不可言传了。

写到这里的时候，我突然想到，这两人有没有交集呢？

这一搜索，吓我一跳：

在知乎上有人这么说：

鲁迅确实深受夏目漱石影响，鲁迅留日期间对其影响最大的作家就是夏目漱石。鲁迅在日本住的屋子就是漱石曾经居住过的。周作人讲，鲁迅非常喜欢夏目漱石的《我是猫》。夏目漱石文学中的讽刺影响了鲁迅的文学观。增田涉在《鲁迅在日本》一书中这样写到：“鲁迅后来所写的小说的作风，与漱石的作风也不相似。但那嘲讽之中的轻妙笔致，则是颇受漱石的影响。”

我百度了一下：

居然还有人专门去研究这个的，也是服了，算是涨姿势了。

关于本书，给我最大的收获除了知道鲁迅和作者有一腿之外，就是收留那只猫的那个所谓教师男主，他的虚伪和傻逼性格，让我印象深刻。怕不是那个时代很多日本人都那样啊。

效果图：

包结构

第一个是 py 文件，第二个是想要转换成字符的图片，第三个输出字符的文档。

导包

1
2

from PIL import Image
import argparse

这两个包前者是 Python 中强大的图片处理工具库，后者是由 optparse 驱动的用来管理命令行参数输入的工具：

1
2
3
4
5
6
7
8
9

This module is an optparse-inspired command-line parsing library that:

    - handles both optional and positional arguments
    - produces highly informative usage messages
    - supports parsers that dispatch to sub-parsers

    # 可处理可选择的和指定位置的参数
    # 能够提取非常有用的信息
    # 支持解析部分参数

获取输入的参数

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

#命令行输入参数处理
parser = argparse.ArgumentParser()

parser.add_argument('file')     #输入文件
parser.add_argument('-o', '--output')   #输出文件
parser.add_argument('--width', type = int, default = 120) #输出字符画宽
parser.add_argument('--height', type = int, default = 120) #输出字符画高

#获取参数
args = parser.parse_args()

IMG = args.file
WIDTH = args.width
HEIGHT = args.height
OUTPUT = args.output

字符集

1

ascii_char = list("$@B%8&WM#*oahkbdpqwmZO0QLCJUYXzcvunxrjft/\|()1{}[]?-_+~<>i!lI;:,\"^`'. ")

这个字符集合可以自己来定义，一般情况下，越长越多，能表示颜色就越多，图片也就更清晰有层次感。

关于灰度

将一张彩色的照片转换成黑白的，用一定的算法，这里用的计算方式：

1

gray = int(0.2126 * r + 0.7152 * g + 0.0722 * b)

映射

将灰度一一对应到定义好的字符集中：

1
2
3
4
5
6
7
8

def get_char(r,g,b,alpha = 256):
    if alpha == 0:
        return ' '
    length = len(ascii_char)
    gray = int(0.2126 * r + 0.7152 * g + 0.0722 * b)

    unit = (256.0 + 1)/length
    return ascii_char[int(gray/unit)]

遍历像素并输出

获取到对应图片，通过 im.getpixel() 方法获取到该图片中每个像素点的色值，再通过之前的灰度映射方法获取到对应的字符，输出到指定的文档中。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

if __name__ == '__main__':

    im = Image.open(IMG)
    im = im.resize((WIDTH,HEIGHT), Image.NEAREST)

    txt = ""

    for i in range(HEIGHT):
        for j in range(WIDTH):
            txt += get_char(*im.getpixel((j,i)))
        txt += '\n'

    print txt

    #字符画输出到文件
    if OUTPUT:
        with open(OUTPUT,'w') as f:
            f.write(txt)
    else:
        with open("output.txt",'w') as f:
            f.write(txt)

运行

到对应的目录下执行命令行就好了

1

python ascii.py img.png

记得要跟上图片的文件名(别的参数可选)

完整代码

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55

#!/usr/bin/env python
# -*- coding: utf-8 -*-

from PIL import Image
import argparse

#命令行输入参数处理
parser = argparse.ArgumentParser()

parser.add_argument('file')     #输入文件
parser.add_argument('-o', '--output')   #输出文件
parser.add_argument('--width', type = int, default = 120) #输出字符画宽
parser.add_argument('--height', type = int, default = 120) #输出字符画高

#获取参数
args = parser.parse_args()

IMG = args.file
WIDTH = args.width
HEIGHT = args.height
OUTPUT = args.output

ascii_char = list("$@B%8&WM#*oahkbdpqwmZO0QLCJUYXzcvunxrjft/\|()1{}[]?-_+~<>i!lI;:,\"^`'. ")

# 将256灰度映射到70个字符上
def get_char(r,g,b,alpha = 256):
    if alpha == 0:
        return ' '
    length = len(ascii_char)
    gray = int(0.2126 * r + 0.7152 * g + 0.0722 * b)

    unit = (256.0 + 1)/length
    return ascii_char[int(gray/unit)]

if __name__ == '__main__':

    im = Image.open(IMG)
    im = im.resize((WIDTH,HEIGHT), Image.NEAREST)

    txt = ""

    for i in range(HEIGHT):
        for j in range(WIDTH):
            txt += get_char(*im.getpixel((j,i)))
        txt += '\n'

    print txt

    #字符画输出到文件
    if OUTPUT:
        with open(OUTPUT,'w') as f:
            f.write(txt)
    else:
        with open("output.txt",'w') as f:
            f.write(txt)

代码来源

这个效果在知乎和 Medium 的 PC 端都有应用。

而且手机端和电脑端都可以通过相同的方式实现这个效果，核心逻辑都是先加载一张放大的缩略图，将其进行模糊处理，同时加载大图并添加一个监听，当大图加载完成的时候，将小图替换成大图。

这里我们直接使用 Glide 图片加载框架。

先简单的写个布局：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout
    xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:tools="http://schemas.android.com/tools"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:orientation="vertical"
    tools:context="com.zhanglf.badgenumberdemo.MainActivity">

    <ImageView
        android:scaleType="fitCenter"
        android:id="@+id/iv_load"
        android:layout_width="400dp"
        android:layout_height="200dp"
        android:layout_gravity="center"
        android:layout_marginTop="40dp"/>
    <ImageView
        android:scaleType="fitCenter"
        android:id="@+id/iv_load2"
        android:layout_width="400dp"
        android:layout_height="200dp"
        android:layout_gravity="center"
        android:layout_marginTop="40dp"/>

    <LinearLayout
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
        android:gravity="center"
        android:orientation="horizontal">

        <Button
            android:id="@+id/bt_load"
            android:layout_width="wrap_content"
            android:layout_height="wrap_content"
            android:layout_gravity="center"
            android:text="LOAD"/>

        <Button
            android:id="@+id/bt_clean"
            android:layout_width="wrap_content"
            android:layout_height="wrap_content"
            android:layout_marginLeft="40dp"
            android:text="CLEAN"/>
    </LinearLayout>
</LinearLayout>

单独封装一个 BlurImageLoader 类来实行图片模糊加载。（其实可以很简洁的，但是我看要传入的参数太多，再则为了试试之前的看的 Builder 设计模式，这里简单封装了一下，其实真的是画蛇添足，傻逼了，也不想改了 T T）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58

public class BlurImageLoader {

    private Context mContext;
    private String mBlurImageUrl;
    private String mNormalImageUrl;
    private ImageView mImageView;

    public static class Builder {
        private final Context mContext;
        private String mBlurImageUrl;
        private String mNormalImageUrl;
        private ImageView mImageView;

        public Builder(Context context) {
            this.mContext = context;
        }

        public Builder Loader(String blurImageUrl, String normalImageUrl) {
            this.mBlurImageUrl = blurImageUrl;
            this.mNormalImageUrl = normalImageUrl;
            return this;
        }

        public Builder into(ImageView targetImageView) {
            this.mImageView = targetImageView;
            return this;
        }

        public BlurImageLoader builder() {
            return new BlurImageLoader(this);
        }
    }

    public BlurImageLoader(Builder builder) {
        mContext = builder.mContext;
        mBlurImageUrl = builder.mBlurImageUrl;
        mNormalImageUrl = builder.mNormalImageUrl;
        mImageView = builder.mImageView;
    }

    /**
     * @param context        Any context, will not be retained.
     * @param imageView      The target to load the resource into.
     * @param blurImageUrl   The thumbnail view of url.
     * @param normalImageUrl The normal view of url
     */

    public void Loader() {
        Glide.with(mContext).load(mBlurImageUrl).bitmapTransform(new BlurTransformation(mContext, 5)).into(new GlideDrawableImageViewTarget(mImageView) {
            @Override
            public void onResourceReady(final GlideDrawable resource, final GlideAnimation<? super GlideDrawable> animation) {
                super.onResourceReady(resource, animation);
                Glide.with(mContext).load(mNormalImageUrl).placeholder(resource).crossFade().into(mImageView);
            }
        });
    }

}

核心代码就是 Loader() 方法了，其中：

.bitmapTransform(new BlurTransformation(mContext, 5)) 这个新建类就是模糊的关键了。

他是我从 glide-transformations 这个强大的 Glide 加载方式辅助工具中的一个类中摘取出来的。

这个类 BlurTransformation ：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104

/**
 * Copyright (C) 2015 Wasabeef
 *
 * Licensed under the Apache License, Version 2.0 (the "License");
 * you may not use this file except in compliance with the License.
 * You may obtain a copy of the License at
 *
 * http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 */

import android.content.Context;
import android.graphics.Bitmap;
import android.graphics.Canvas;
import android.graphics.Paint;
import android.os.Build;
import android.renderscript.RSRuntimeException;

import com.bumptech.glide.Glide;
import com.bumptech.glide.load.Transformation;
import com.bumptech.glide.load.engine.Resource;
import com.bumptech.glide.load.engine.bitmap_recycle.BitmapPool;
import com.bumptech.glide.load.resource.bitmap.BitmapResource;

public class BlurTransformation implements Transformation<Bitmap> {

    private static int MAX_RADIUS = 25;
    private static int DEFAULT_DOWN_SAMPLING = 1;

    private Context mContext;
    private BitmapPool mBitmapPool;

    private int mRadius;
    private int mSampling;

    public BlurTransformation(Context context) {
        this(context, Glide.get(context).getBitmapPool(), MAX_RADIUS, DEFAULT_DOWN_SAMPLING);
    }

    public BlurTransformation(Context context, BitmapPool pool) {
        this(context, pool, MAX_RADIUS, DEFAULT_DOWN_SAMPLING);
    }

    public BlurTransformation(Context context, BitmapPool pool, int radius) {
        this(context, pool, radius, DEFAULT_DOWN_SAMPLING);
    }

    public BlurTransformation(Context context, int radius) {
        this(context, Glide.get(context).getBitmapPool(), radius, DEFAULT_DOWN_SAMPLING);
    }

    public BlurTransformation(Context context, int radius, int sampling) {
        this(context, Glide.get(context).getBitmapPool(), radius, sampling);
    }

    public BlurTransformation(Context context, BitmapPool pool, int radius, int sampling) {
        mContext = context.getApplicationContext();
        mBitmapPool = pool;
        mRadius = radius;
        mSampling = sampling;
    }

    @Override
    public Resource<Bitmap> transform(Resource<Bitmap> resource, int outWidth, int outHeight) {
        Bitmap source = resource.get();

        int width = source.getWidth();
        int height = source.getHeight();
        int scaledWidth = width / mSampling;
        int scaledHeight = height / mSampling;

        Bitmap bitmap = mBitmapPool.get(scaledWidth, scaledHeight, Bitmap.Config.ARGB_8888);
        if (bitmap == null) {
            bitmap = Bitmap.createBitmap(scaledWidth, scaledHeight, Bitmap.Config.ARGB_8888);
        }

        Canvas canvas = new Canvas(bitmap);
        canvas.scale(1 / (float) mSampling, 1 / (float) mSampling);
        Paint paint = new Paint();
        paint.setFlags(Paint.FILTER_BITMAP_FLAG);
        canvas.drawBitmap(source, 0, 0, paint);

        if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.JELLY_BEAN_MR2) {
            try {
                bitmap = RSBlur.blur(mContext, bitmap, mRadius);
            } catch (RSRuntimeException e) {
                bitmap = FastBlur.blur(bitmap, mRadius, true);
            }
        } else {
            bitmap = FastBlur.blur(bitmap, mRadius, true);
        }

        return BitmapResource.obtain(bitmap, mBitmapPool);
    }

    @Override public String getId() {
        return "BlurTransformation(radius=" + mRadius + ", sampling=" + mSampling + ")";
    }
}

他有多种构造方式，常用的就是上面用到的，第一个传入上下文，第二次传入一个 int 值，这个 int 值代表图片的模糊程度。

对模糊程度没有概念的可以看这个网站，自己调整感受一下。

BlurTransformation 类中对 VERSION_CODES 进行判断，大于 18 的采用 RSBlur 进行模糊处理，也就是安卓自带的 ScriptIntrinsicBlur 类。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66

import android.annotation.TargetApi;
import android.content.Context;
import android.graphics.Bitmap;
import android.os.Build;
import android.renderscript.Allocation;
import android.renderscript.Element;
import android.renderscript.RSRuntimeException;
import android.renderscript.RenderScript;
import android.renderscript.ScriptIntrinsicBlur;

/**
 * Copyright (C) 2017 Wasabeef
 *
 * Licensed under the Apache License, Version 2.0 (the "License");
 * you may not use this file except in compliance with the License.
 * You may obtain a copy of the License at
 *
 * http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 */

public class RSBlur {

    @TargetApi(Build.VERSION_CODES.JELLY_BEAN_MR2)
    public static Bitmap blur(Context context, Bitmap bitmap, int radius) throws RSRuntimeException {
        RenderScript rs = null;
        Allocation input = null;
        Allocation output = null;
        ScriptIntrinsicBlur blur = null;
        try {
            rs = RenderScript.create(context);
            rs.setMessageHandler(new RenderScript.RSMessageHandler());
            input = Allocation.createFromBitmap(rs, bitmap, Allocation.MipmapControl.MIPMAP_NONE,
                    Allocation.USAGE_SCRIPT);
            output = Allocation.createTyped(rs, input.getType());
            blur = ScriptIntrinsicBlur.create(rs, Element.U8_4(rs));

            blur.setInput(input);
            blur.setRadius(radius);
            blur.forEach(output);
            output.copyTo(bitmap);
        } finally {
            if (rs != null) {
                rs.destroy();
            }
            if (input != null) {
                input.destroy();
            }
            if (output != null) {
                output.destroy();
            }
            if (blur != null) {
                blur.destroy();
            }
        }

        return bitmap;
    }
}

小于 18 的采用被广为使用的 FastBlur 类：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255

import android.graphics.Bitmap;

/**
 * Copyright (C) 2015 Wasabeef
 *
 * Licensed under the Apache License, Version 2.0 (the "License");
 * you may not use this file except in compliance with the License.
 * You may obtain a copy of the License at
 *
 * http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 */

public class FastBlur {

    public static Bitmap blur(Bitmap sentBitmap, int radius, boolean canReuseInBitmap) {

        // Stack Blur v1.0 from
        // http://www.quasimondo.com/StackBlurForCanvas/StackBlurDemo.html
        //
        // Java Author: Mario Klingemann <mario at quasimondo.com>
        // http://incubator.quasimondo.com
        // created Feburary 29, 2004
        // Android port : Yahel Bouaziz <yahel at kayenko.com>
        // http://www.kayenko.com
        // ported april 5th, 2012

        // This is a compromise between Gaussian Blur and Box blur
        // It creates much better looking blurs than Box Blur, but is
        // 7x faster than my Gaussian Blur implementation.
        //
        // I called it Stack Blur because this describes best how this
        // filter works internally: it creates a kind of moving stack
        // of colors whilst scanning through the image. Thereby it
        // just has to add one new block of color to the right side
        // of the stack and remove the leftmost color. The remaining
        // colors on the topmost layer of the stack are either added on
        // or reduced by one, depending on if they are on the right or
        // on the left side of the stack.
        //
        // If you are using this algorithm in your code please add
        // the following line:
        //
        // Stack Blur Algorithm by Mario Klingemann <mario@quasimondo.com>

        Bitmap bitmap;
        if (canReuseInBitmap) {
            bitmap = sentBitmap;
        } else {
            bitmap = sentBitmap.copy(sentBitmap.getConfig(), true);
        }

        if (radius < 1) {
            return (null);
        }

        int w = bitmap.getWidth();
        int h = bitmap.getHeight();

        int[] pix = new int[w * h];
        bitmap.getPixels(pix, 0, w, 0, 0, w, h);

        int wm = w - 1;
        int hm = h - 1;
        int wh = w * h;
        int div = radius + radius + 1;

        int r[] = new int[wh];
        int g[] = new int[wh];
        int b[] = new int[wh];
        int rsum, gsum, bsum, x, y, i, p, yp, yi, yw;
        int vmin[] = new int[Math.max(w, h)];

        int divsum = (div + 1) >> 1;
        divsum *= divsum;
        int dv[] = new int[256 * divsum];
        for (i = 0; i < 256 * divsum; i++) {
            dv[i] = (i / divsum);
        }

        yw = yi = 0;

        int[][] stack = new int[div][3];
        int stackpointer;
        int stackstart;
        int[] sir;
        int rbs;
        int r1 = radius + 1;
        int routsum, goutsum, boutsum;
        int rinsum, ginsum, binsum;

        for (y = 0; y < h; y++) {
            rinsum = ginsum = binsum = routsum = goutsum = boutsum = rsum = gsum = bsum = 0;
            for (i = -radius; i <= radius; i++) {
                p = pix[yi + Math.min(wm, Math.max(i, 0))];
                sir = stack[i + radius];
                sir[0] = (p & 0xff0000) >> 16;
                sir[1] = (p & 0x00ff00) >> 8;
                sir[2] = (p & 0x0000ff);
                rbs = r1 - Math.abs(i);
                rsum += sir[0] * rbs;
                gsum += sir[1] * rbs;
                bsum += sir[2] * rbs;
                if (i > 0) {
                    rinsum += sir[0];
                    ginsum += sir[1];
                    binsum += sir[2];
                } else {
                    routsum += sir[0];
                    goutsum += sir[1];
                    boutsum += sir[2];
                }
            }
            stackpointer = radius;

            for (x = 0; x < w; x++) {

                r[yi] = dv[rsum];
                g[yi] = dv[gsum];
                b[yi] = dv[bsum];

                rsum -= routsum;
                gsum -= goutsum;
                bsum -= boutsum;

                stackstart = stackpointer - radius + div;
                sir = stack[stackstart % div];

                routsum -= sir[0];
                goutsum -= sir[1];
                boutsum -= sir[2];

                if (y == 0) {
                    vmin[x] = Math.min(x + radius + 1, wm);
                }
                p = pix[yw + vmin[x]];

                sir[0] = (p & 0xff0000) >> 16;
                sir[1] = (p & 0x00ff00) >> 8;
                sir[2] = (p & 0x0000ff);

                rinsum += sir[0];
                ginsum += sir[1];
                binsum += sir[2];

                rsum += rinsum;
                gsum += ginsum;
                bsum += binsum;

                stackpointer = (stackpointer + 1) % div;
                sir = stack[(stackpointer) % div];

                routsum += sir[0];
                goutsum += sir[1];
                boutsum += sir[2];

                rinsum -= sir[0];
                ginsum -= sir[1];
                binsum -= sir[2];

                yi++;
            }
            yw += w;
        }
        for (x = 0; x < w; x++) {
            rinsum = ginsum = binsum = routsum = goutsum = boutsum = rsum = gsum = bsum = 0;
            yp = -radius * w;
            for (i = -radius; i <= radius; i++) {
                yi = Math.max(0, yp) + x;

                sir = stack[i + radius];

                sir[0] = r[yi];
                sir[1] = g[yi];
                sir[2] = b[yi];

                rbs = r1 - Math.abs(i);

                rsum += r[yi] * rbs;
                gsum += g[yi] * rbs;
                bsum += b[yi] * rbs;

                if (i > 0) {
                    rinsum += sir[0];
                    ginsum += sir[1];
                    binsum += sir[2];
                } else {
                    routsum += sir[0];
                    goutsum += sir[1];
                    boutsum += sir[2];
                }

                if (i < hm) {
                    yp += w;
                }
            }
            yi = x;
            stackpointer = radius;
            for (y = 0; y < h; y++) {
                // Preserve alpha channel: ( 0xff000000 & pix[yi] )
                pix[yi] = (0xff000000 & pix[yi]) | (dv[rsum] << 16) | (dv[gsum] << 8) | dv[bsum];

                rsum -= routsum;
                gsum -= goutsum;
                bsum -= boutsum;

                stackstart = stackpointer - radius + div;
                sir = stack[stackstart % div];

                routsum -= sir[0];
                goutsum -= sir[1];
                boutsum -= sir[2];

                if (x == 0) {
                    vmin[y] = Math.min(y + r1, hm) * w;
                }
                p = x + vmin[y];

                sir[0] = r[p];
                sir[1] = g[p];
                sir[2] = b[p];

                rinsum += sir[0];
                ginsum += sir[1];
                binsum += sir[2];

                rsum += rinsum;
                gsum += ginsum;
                bsum += binsum;

                stackpointer = (stackpointer + 1) % div;
                sir = stack[stackpointer];

                routsum += sir[0];
                goutsum += sir[1];
                boutsum += sir[2];

                rinsum -= sir[0];
                ginsum -= sir[1];
                binsum -= sir[2];

                yi += w;
            }
        }

        bitmap.setPixels(pix, 0, w, 0, 0, w, h);

        return (bitmap);
    }
}

获取到了被模糊处理过后的缩略图之后，回到之前的 Loader() 方法中，我们重写了 onResourceReady() ，也就是当缩略图加载完成时，我们将该 resoure （注意这里的 resource 是已经被模糊处理过后的）放到再次调用 Glide图片加载的 .placeholder(resource) 中，当做是第二次加载图片的占位符。这里添加了一个 Glide 自带的过渡动画效果 .crossFade() 渐显。那么当大图加载完成的时候就会成功的替换之前的模糊小图了。

为了试验效果，我们给两个按钮添加点击事件：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

mIvLoad1 = (ImageView) findViewById(R.id.iv_load);
       mIvLoad2 = (ImageView) findViewById(R.id.iv_load2);

       findViewById(R.id.bt_load).setOnClickListener(new View.OnClickListener() {
           @Override
           public void onClick(View v) {
               BlurImageLoader ivLoader1 = new BlurImageLoader.Builder(MainActivity.this).Loader(blurImageUrl1, normalImageUrl1).into(mIvLoad1).builder();
               ivLoader1.Loader();
               BlurImageLoader ivLoader2 = new BlurImageLoader.Builder(MainActivity.this).Loader(blurImageUrl2, normalImageUrl2).into(mIvLoad2).builder();
               ivLoader2.Loader();
           }
       });

       findViewById(R.id.bt_clean).setOnClickListener(new View.OnClickListener() {
           @Override
           public void onClick(View v) {

               Glide.clear(mIvLoad1);
               Glide.clear(mIvLoad2);
               mIvLoad1.setImageBitmap(null);
               mIvLoad2.setImageBitmap(null);
               clearCacheDiskSelf();
               clearCacheMemory();
           }
       });

因为 Glide 自带的缓存效果，所以我们必须清除磁盘和内存的缓存：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

public boolean clearCacheDiskSelf() {
        try {
            if (Looper.myLooper() == Looper.getMainLooper()) {
                new Thread(new Runnable() {
                    @Override
                    public void run() {
                        Glide.get(getApplicationContext()).clearDiskCache();
                    }
                }).start();
            } else {
                Glide.get(getApplicationContext()).clearDiskCache();
            }
            return true;
        } catch (Exception e) {
            e.printStackTrace();
            return false;
        }
    }

    public boolean clearCacheMemory() {
        try {
            if (Looper.myLooper() == Looper.getMainLooper()) { //只能在主线程执行
                Glide.get(getApplicationContext()).clearMemory();
                return true;
            }
        } catch (Exception e) {
            e.printStackTrace();
        }
        return false;
    }

哦，对了，我们要有图片来源才能实验啊，加载一张图片我们需要一张大图和一张小图，这里我的资源是随便打开了一个 Medium 网站上的网页使用浏览器的元素检查功能，然后直接复制了 url ：

我弄了两张图的资源，也就是四张图，为了加载快一点，将其放到了我自己的七牛云中，下面是资源地址：

1
2
3
4

private String blurImageUrl1 = "http://on9hzfn6s.bkt.clouddn.com/zhanglffffff.jpeg";
private String blurImageUrl2 = "http://on9hzfn6s.bkt.clouddn.com/1-_qd4EhIwH.jpeg";
private String normalImageUrl1 = "http://on9hzfn6s.bkt.clouddn.com/zhanglffffffbbb.jpeg";
private String normalImageUrl2 = "http://on9hzfn6s.bkt.clouddn.com/1-_qd4EhIwHbAjqzKPHu8-Ig.jpeg";

然后就大功告成了（之前的效果图故意延时了一秒，这个是没有延时的）。