年前后，有一搭没一搭地拾掇腾讯家的开源插件 VasDolly。当然了，这些年移动开发已经式微，这是口冷灶。不过老夫的习惯是上手了就得有个交代。

出于洁癖使然，兵分两路，互有联系却又互不干涉，所谓低耦合。一路是消费侧，也就是说集成使用了 VasDolly 插件的项目。这一侧三太爷也花了点心思，因为出发点是在 VasDolly 本身原地踏步的情况下，也要把它的潜力挖掘出来，敲骨吸髓式利用。另一侧则是供给侧，如果 VasDolly 内部作了改良，那消费侧的花活就可以消停一二。这一侧改动的难点不是实现层面的，而是设计层面的，如何优雅地兼容之前的接口/约定/协议，同时扩展出新的能力。

今天抽了一小会儿工夫，看了一下 VasDolly 在 GitHub 上的 PR，共有三个：一是增加了渠道别名的支持，二是增加了产品变体的支持，三是一个 bug fix（作者自称）。

渠道别名的支持不算强需求。嵌入到安装包体内的渠道号，直接使用 huawei 这样的字串并非不可，只不过实践中，大家都不愿这么直接暴露出去，所以通常会写成 90001 这种代码。但是这样的代码放到文件名里，供人肉眼检索辩识的话，就会差那么一点，所以就有了文件名里使用渠道别名的需求。在三太爷的衡量之下，当然不愿把 VasDolly 改的面目模糊，而是宁可额外多一个重命名各个渠道包的善后步骤。事实上也确实已经这么做了。

看到支持产品变体（product flavor）的这个 PR 的时候还是吃了一惊的，颇以为忙忙叨叨实现了个别人已经实现的功能。再一看代码，差别就出来了。这位仁兄只是在输出结果文件时发现存在产品变体名称的话，多产生一级子目录，免得不同产品变体的输出文件名相同的话互相覆盖。当然了，三太爷的方案想得比这个完善，由此不再担心白忙活。

最后的那个 bug fix，一开始只是肉眼 review 了一下代码。对一个函数的返回结果进行检查，原来的代码是使用 == null 判空， PR 里改作了 .isEmpty 判空。假如说，在充分相信双方都曾运行代码覆盖到所处条件的话，三太爷其实更倾向于两者相与（&&），而不是后者直接替换掉前者。后来又到 IDE 里看了一眼，发现原版的判空总是 false，所以人家的修改完全正确且合适，老夫甚至把他的修改同步到了自己的修改版里了，毕竟还多发现了一处也应该同样修改的地方。

这么看下来，真正在老夫之前为该项目提交的有实质提升的改进并不多。老怀颇慰。

把它构建并发布到了本地，又在实际项目中引用进来初步测了一下，还没有出错。过几天实际跑一下发版看看结果。