本篇在博客园的地址https://www.cnblogs.com/bbqzsl/p/18187099
回顾一下现时网上的资源。
原生 https://github.com/duilib，
Ultimate https://github.com/qdtroy/DuiLib_Ultimate
腾讯 https://github.com/tencentyun/TIMSDK/tree/master/cross-platform/Windows/IMApp/Basic/duilib
网易 https://github.com/netease-im/NIM_Duilib_Framework/tree/master/duilib
主体框架2019年截止。
腾讯cross-platform/Windows/IMApp/Basic/duilib止于2019年开放的5.4.666版的TIMSDK。只能通过tag切换旧旧旧版。
最后一个开放的5.6.12版在路径Windows/Demo/Basic/duilib，时间止于2021年8月31日。
网易开源版也止于2019年。
比较了一下，网易版对原生 改动很大，去除了CDuiString，全部用std::wstring。腾讯在TIMSDK的版本是基于DuiLib_Ultimate而不是原生的duilib。根据我逆向的CControlUI结构，现在WeChat使用的duilib是基于原生版的。DuiLib_Ultimate与原生两个版区别的最大特征在于，CControlUI结构使用了5个EventSource还是7个EventSource。
通过WeChat的日志跟踪路径，WeChat不与其它产品共享代码，他们有一个专门子项目WeUIEngine，而非TIMSDK。架构应该可以参考网易的NIM_Duilib_Framework框架。注意是框架设计不是代码。
WeChat版的duilib，改动CControlUI成一个大而累赘的庞物，从CContainerUI的RTTI信息可以看到，CControlUI是一个2816字节的大基类。CDuiString的确是一个累赘，尤其Unicode下，大小是132字节。而且这个基类一共使用了17个CDuiString。大厂的我不懂。后面的继承类如CLabelUI就更加趋向于使用std::wstring。反正现在的电脑没有16GB内存都不算电脑。
经过逆向后就可以对UI进行操作了。
WeChat使用了Chromium::base的MessagePumpForUI，简单来说就相当于用win32有窗口消息实现仿如iOS的dispatcher, 如我们熟悉的这个调用dispatch_async(dispatch_get_main_queue(), ^{ // update UI })。Chromium这项目，每个版本系列的代码都不同程序的重构，所以可以通过一些类来确认出WeChat所使用的版本是6系列的。也可以推断出WeUIEngine开发的年份。现在这年，Chromium或cef的多线程任务框架也应该是用到烂大街的了吧。
有这个东西，就等于方便我使用，于是我就不客气使用它向UI主线程投递代码执行。进行测试，运行MessageBox显示当前线程的ID。所以我已经先逆向了需要的东西。下面演示一下。
it works。消息框在主线程376中执行了。
那么WeChat是怎么用它的呢，我原本以为WeChat会用它大作为一下，我的意思是有多一点用途，没想到却只是为了完成一个单一的UI功能，动画，或者说是动画的计时器。
先来找出dispatch任务的地方，只要跟踪这里，就可是知道WeChat都向这里Post了些什么代码。无它，将DebugBreak作为任务PostTask到MessagePumpForUI。通过调用栈就可以找出来了。再通过逆向分析出绑定的执行地址。
绑定的执行地址是base::RepeatingTimer，全部都只有定时任务。下面再来逆向分析都是些什么定时任务。我也想知道刷新扫码，工作线程有没有使用MessagePumpForUI将请求结果更新到UI。
定时器任务只有一个， 就是CPaintManagerUI::DelayPaint，名字是我起的，功能就是Paint，目的是动画，还有增加或减少Paint的频度。即使我刷新了几次重新扫码，也没有收到别的任务。也就是工作线程没有通过Chromium::base的任务框架进行dispatch_async(ui_update)。
今期先到这里。
我还有逆向通达信系列。