现时网上的Duilib资源回顾

本篇在博客园的地址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)。

今期先到这里。

我还有 逆向通达信系列 。

未经允许不得转载:大白鲨游戏网 » 现时网上的Duilib资源回顾