关于微信红包，开发者们来讨论点干货把（动态黑科技相关）

其实当时微信红包出来的时候，我就跟同事在讨论微信这个需求的实现方式，本来也有意在论坛发帖讨论，无奈事情比较多就搁置了。直到今天 @yxjxx 来问我微信这个功能的具体实现方式，又一次提起了我的兴趣，所以就来坛子里发帖大家讨论讨论。

---

*我这里主要针对我上述的第二种情况（动态黑科技）来讨论 iOS 的实现方式。*

## 技术可行性（可行性来源）
- Objc 自带的 Runtime 机制
- JSPatch + Javascript
- wax + Lua
- JavaScriptCore （未接触）

相信 Runtime 这种小黑科技对于很多开发者都已经不陌生了，它提供的动态生成类、对象、方法，动态性简直屌的一笔，但是我玩了挺久，也只能实现布局的动态性，逻辑的动态性下发依赖客户端的框架搭建，其实主要就是无法完成一个 IMP 的下发。
自然而然， Runtime 的缺陷引出了后面几个框架： JSPatch+JavaScript ， Wax+Lua 。这两个框架都可以通过脚本语言，动态下发逻辑，与 Runtime 的结合更是发生了许多奇妙的变化，相信许多用 JSPatch 搭建 JSBridge 联通 H5 与 Native 的人都与我有着同样的感受：这特么实在是叼。至于 Wax+Lua 可能认识的人稍微少了点，但是同样具有超屌的动态性。

## 具体实现方式的剖析

首先，单单从微信这个应用来看，我刚开始的直觉是它肯定不会用这样的黑科技。理由太简单了，像微信这么一个谨慎的不能更谨慎的应用，发布任何一个需求都是考虑再考虑，怎么会突然出现这么大的一个临时需求，还这么紧急要线上发布，想想都不可能。更不用说无论哪个动态化实现方案都存在缺陷和漏洞，不稳定性比 Native 高太多。

然而后来微信红包出现的一系列 Bug 戳瞎了我的狗眼。。。

### Bug 列表
1. 请求图片没有使用 HTTPS ，并且图片也没有加密
2. 低端机型上（ iPhone4 ），滤镜蒙层会出现加载缓慢导致可以直接查看图片的 Bug
3. 点击进入个人页面，选择某一条红包照片，在出现的照片状态页面可以点击下面的 TextField 直接评论（虽然也会弹出浮层说要付钱才能评论，但是键盘可以弹出来，可以打字可以发送成功）
4. 如果按照第三点做，原照片主人如果回复你，在消息界面可以直接打开红包照片，并且没有滤镜蒙层
5. 红包数额每次点击都不一样（不知道算不算 Bug ，反正我觉得是）

我觉得上述 Bug 都是正常测试流程和回归流程可以发现的 Bug ，难道微信在发布一个新版本的时候都不会对新功能进行系统回归测试么，这个真的是太捉急了。

### 私以为评判技术方向决定性的一点
一个非常关键的 Bug ：上述第三条，微信应该都已经发现这个 Bug 了，因为在点击 TextField 的时候，可以看到有弹层，但是没有把键盘响应事件给去掉！！！这个实在是太关键了，这个 Bug 没发现我打死都不信，微信开发者我不打你你过来跟我说这个弹层是怎么回事。所以我认为，并不是微信不知道这个 Bug ，而是**知道了没办法！**，*因为微信在用动态化方案对这个点击事件进行 Hook 并替换方法的时候，没有办法替换完全，点击事件仍然传递到了系统 TextField 上，导致键盘被响应打开！*，这个是我认为微信使用动态化方案的非常重要的一点！有兴趣的同学可以跟我一起深挖通过 JSPatch 或者 Wax 来 Hook 方法时产生的不可抗后果。
其实其他 Bug 也有佐证微信使用动态化方案的例子（比如：不使用 HTTPS 是因为涉及到网络库，对于微信的架构伤害太大，不敢用脚本语言完成），但是上述这个，真的是一个致命的因素。

装逼装的好累，每次都写这么多，反正根据微信的这些 Bug ，以及 Bug 产生的原因，我认为微信这次功能使用的是动态化方案，感谢看完全文。

经朋友提醒，那天红包照片下午和晚上的功能实现有差异：

晚上加上了“中奖”功能，多点击照片几次可以中奖，不用付钱就可以看照片。

这个功能不仅要在服务端做改动，客户端我认为是需要相应改动的。而且我觉得这个改动非常大可能是临时需求（配合某官微说微信涉黄），客户端预埋的可能性真不太大。

---

抛开是否是热更新完成的功能不说，微信如此高效的完成新需求的迭代发布上线，需求的上线时间维度从月级到了小时级，对于 iOS 和 Android 的开发者来说，有没有点细思极恐的味道