众所周知，RichEdir强大在于其图文混排（在这里不跟Word、HTML比），其中的图替换为动态图的核心问题就归结于如何高效刷新。我们知道GDI操作是最消耗CPU的，所以刷新整个RichEdit窗口是不可取的，其副作用会导致更严重的闪烁问题。解决问题的思路很简单：类似于拖拽时候在屏幕绘制异或线，我们的动画重绘时不请求RichEdit，而直接在其窗口的DC上绘制当前动画帧，此时缺少是如何确定该OLE的位置，这个是所有问题的关键。先看下面这幅图：

假定1-5全部都是GIF图片，非GIF可以暂时无视，这个后面大家会非常清楚如何处理。在这个过程中，2不见了，而4是新出现的。对于4新出现时，RichEdit自身肯定会触发其：

Draw(
    DWORD dwDrawAspect, LONG lindex, void* pvAspect,
    DVTARGETDEVICE* ptd, HDC hicTargetDev, HDC hdcDraw,
    LPCRECTL prcBounds, LPCRECTL prcWBounds,
    BOOL (__stdcall *pfnContinue)(DWORD_PTR dwContinue),
    DWORD_PTR dwContinue)

这个时候，我们知道新的GIF图片进入可视区，可以把它添加到集合中。对于2的动画触发时间到来时，我们可以确定其位置且与可视区比对，发现其不再可视区，则从集合中移除。这样就可以得到一个接近于（略大于）当前视口中的动画控件集合，当有新的动画触发时间到来时，我们可以先检查其是否在可视区，如果不在则不用GDI操作，仅仅更新其当前帧。当然这些工作你也可以不做，但是在动画控件数量大的时候效率可能略有下降，主要是查找的过程（索引、位置）比较耗时。

如何确定一个OLE的位置呢？由于我们插入OLE都使用了REO_BELOWBASELINE标志，也就是跟当前行的底部对齐，所以OLE左下角位置的精确度对我们来说很重要。看下图：

假设图中黑框是一个OLE对象，其字符索引为CPN，假定第N+1行的第一个字符索引为CPN1，那么OLE左下角坐标={PosFromChar(CPN).x, PosFromChar(CPN1).y }，PosFromChar这个是RichEdit提供的。问题的关键是最后一行怎么计算？此时没有第N+1行。对于这种特殊情况，主要是Y坐标的计算，可以这样考虑：Y=RichEdit内容高度-滚动条位置。猜测: 计算内容高度可能比较耗时，故QQ的聊天消息显示部分强制在底部加了一行，以避免这种情况出现。

得到左下角位置以后，可能你会觉得就万事大吉了。错！还有一个关键点！我们可以通过OLE的接口GetExtent得到其大小，然而这个大小没有考虑缩放比例，所以你需要根据当前缩放比例进行计算，而这个计算牵扯到浮点数运算，过程中的来回不仅麻烦而且不精确，所以OLE的可视大小要想非常精确是不能通过计算来的。我们前面知道OLE绘制的时候会传入可视范围，假如我们保存下来是不是就可以解决问题了呢？当然，显然，你可以试试！

这些问题主要原因是RichEdit的很多接口方法没有暴露，而Win8的SDK会做重大升级，很多之前的问题都会变成不是问题，或许还会引起更多的新特性，但是动画本身的逻辑还是需要自己实现，或者会简单许多，至于多少我还尚不清楚，但是目前来看这种方案效率足够！ 

到了这里，核心技术应该大白天下，整个过程，我追求了位置的精准度，并据此获得最小可视集合进行刷新优化。

最新SDK&Demo，参见：http://code.google.com/p/im-solution/。希望你会喜欢！

很近没有更新了，闲话少说，直奔主题。

微软做任何技术的思路：在实现一个标准的时候，往往预留出一个通用的扩展机制。呃，貌似很多大公司都是如此，通过扩展把开发者跟自己捆绑。举例：微软的ie可以嵌入ActiveX控件、可以用BHO扩展；richedit中支持OLE扩展。这种扩展机制主要是基于其OLE框架，这也是微软操作系统框架的基石。开发层面目前的趋势是，淡化OLE强调.NET，有一种无奈叫骑虎难下，有一种错误叫脱离群众，在开发平台、技术百花齐放，开发资源极大丰富的今天，开发者对微软的依赖已经不那么强烈，以至于现在的Windows开发者有点小苦逼，尤其是C++开发者有一种被抛弃的感觉，扯远了。

谈谈OLE/COM/ACTIVEX的关系。很模糊，有一些说不清，有历史原因，也有普及程度关系。侯捷说玩模板有三境界：会用标准库，读懂标准库源码，会用模板做设计。我觉得COM相关的也是如此，使用COM组件往往是容易。我的理解：OLE是技术规范，COM是语言规范，而ACTIVEX则是用这2东东来实做的可服用组件的称谓。对于OLE的支撑主要在MFC库中，而ATL库则是更纯粹的OLE/COM框架。MFC跟OFFICE有一衣带水的关系，OFFICE的应用框架促使着MFC的发展（早期如此，但UI方面早已分道扬镳），OFFICE的应用模型也就是MFC的应用开发模型。

之所以提及MFC又OFFICE，只是想说通用的扩展机制没有那么多条条框框，即便是ACTIVEX框架这种东西。对于OLE实践，也就是微软最热衷，其中Windows操作系统和OFFICE系列软件要最典型，其它则很牵强。OLE技术标准接口只有极少数是必须实现，而大部分则是可选实现或者部分实现，其中richedit更是如此。OLE对服务器和客户端都做了行为规范，如果一方（一般是服务器）自行决定如何实施，则另一方也只需对应实现。

呃，我说了这么多，只是为了阐述我的险恶用心，或许没人明白。ATL框架定义了四个标准导出函数用于规范注册、反注册、加载、卸载，这些跟实际的OLE功能无关，尤其是在richedit扩展中。或许你在网上诸多示例中看到用ATL模板创建一个控件然后如何简单的插入位图就以为掌握了核心科技，那么我就要泼冷水了，这些东西无关大局。既然Windows能用OLE搭建框架，既然MFC可以实践OLE，那么我们也可以用纯正的C++代码玩OLE，我的意思无非就是没必要遵循ATL，也没必要一定去注册一个东西，问题的核心不是这些东西，目前我们仅仅是为了插入一个动画。

Richedit是一个不完全的OLE实践，前面提到能完全实践OLE的框架不多。因为richedit实现了图文混排，所以在IM领域很受欢迎，尤其是早期（现在基于chromium的扩展或许可以改变现状）。Richedit是一个容器，可以容纳OLE控件进入，典型的扩展就是动画控件。基于ATL框架开发，你可以实现一个标准的控件，但当你面对一个非标准的容器时，那些条条框框显得不是那么重要，这也是为什么能做好动画控件不容易的原因。

根据我的调查（呃，通过实践，通过QueryInterface观察），我发现实现一个richedit中的动画控件只需要实现二个接口：IOleObject、IViewObject2，前者为了融入到richedit环境中，后者为了渲染显示。由于richedit默认只喜好无窗口模式，所以针对IOleInPlaceSiteWindowless之类的，你去实现意义也不大，因为人家容器不认你，当然还有IPersist系列接口，对于标准的环境有用（比如IDE），但这里并不是很需要，所以认清核心问题能减少很多困惑。更显然的是我的控件没有用ATL框架，因为此控件脱离了richedit环境生存的意义也不大，更有甚者我没必要让使其成为标准（也没可能），仅仅是为了在一个系统中的richedit中更好地展示。实现的接口越少，引入的麻烦越少，这样才能使精力集中在主要问题上。

综上所述，我的控件是一个C++类，只实现了两个接口：

其中大部分接口都可以无视，因为我们只需要这个控件在richedit中能够占位（长宽），能够展示（效率关键），至于其他的可编程、在位激活、对象识别都不重要。我观察了QQ的动画控件，呃，比现在网上流行的要改变很多（网上内容没有与时俱进）。现在的`QQ的动画控件很简单（后面会讲述如何找到这个控件），看起来只是作为一个占位工具，如何触发动画则是由host控制。观其接口：

IrichFrameObj的作用我不是很理解，居然一个接口都没有，而后者模糊的能够理解一些：src大概就是动画图片路径，auto系列是为了动态缩放。现在的QQ只允许一个自定义动画，依据老衲猜测，因为自定义动画往往是截图，比较大，在一行容易引起点击时视图跳跃。再有其他的属性是为了识别所用，无法推测具体行为。

呃，事情看起来没有那么复杂，的确，我只实现了2个接口，而其中大部分也都是返回E_NOTIMPL，因为richedit确实没有那么标准，你实现的再标准也无济于事。当然richeit也在更新，win8的sdk对其改动最大，但win7的sdk也暴露了一些更早的功能，这或许是目前实现的最大亮点（技术含量，高风险高回报，一般人难以置信）。

对于动画控件阐述到此为止，或许很多人会很失望，但也仅仅如此，因为它本身什么都没有，尤其是在你真正明白之后，所以这里或许你会很失望，但是真正的内容就这么多，我也不知怎么添油加醋。

最后一个建议，希望尊重所有的玩技术的：

1、中国官本位思想很严重，技术搞得不错（或许是运气）立马转管理

2、文人相轻

3、资本运作，体制运作，技术作用不明显

4、吃饱肚皮，难以维系理想

大道无形，大音希声，牛叉的技术很多都是巧工，而真正的产业才是大无畏的研发，我们只不过在投机取巧。

Windows平台上实现时钟的方式五花八门，你可以使用窗口相关的SetTimer来设置一个时钟，也可以自己开辟线程来做等待触发模拟时钟，而Chromium封装的要更加C++对象化一些：依托Windows窗口消息，抽象出延迟任务的概念。这种手法几年前我也曾经考虑过，只是对其中下次最短触发时间计算以及更新的算法和设计都有力不从心，最终得出的是误差很大的精简版：选择固定的最小时间片为最小触发单位，对很小的时间间隔误差很明显。

Windows有Timer Queues用来实现高效的异步时钟，比较奇怪的是这组API用的貌似并不多。我们知道每个进程都有一个默认的线程池，可以在其中执行一些Work Items，时钟队列和等待操作也都会用到这个线程池。timer-queue中的timers创建和销毁都很轻量高效，因此我选择了它。

每个OLE图片对象在设置图片之后，如果发现是多帧的，就需要启动动画，创建时钟：

这里timer_是返回值，返回新建的时钟对象，可以在OLE对象销毁或者回调函数中进行删除，而删除操作会等待回调执行完毕才返回。传递TimerQueue为NULL表示使用系统的队列。Period为0表示只触发一次，触发时间为image_->GetFrameDelay(current_frame_)。由于回调函数WaitOrTimerCallback是在线程池的线程中执行，所以更新操作需要同步到动画图片的创建线程中。callback_parameter_包含有上一节提及的ThreadState对象以及动画OLE对象指针，ThreadState创建的时候会同时创建一个隐藏窗口用于工作者线程向UI线程同步操作：

下面是UpdatePictureFrame的实现：

这样绕一大圈子，是为了利用Timer Queues的同时保证图片的更新操作是在UI线程中执行，因为图片被插入也是发生在UI线程，即动画控件创建于UI线程，为了避免加锁带来的麻烦以及死锁的可能性，不应该轻易去加锁，尽量利用操作系统提供的基础设施来实现。这里需要注意的是隐藏窗口接收到kMessageUpdatePictureFrame消息时，richedit窗口可能已不存在或者动画控件已经销毁，因此使用指针前，需要判断对象是否还存在：

首先是图片解码器的选择。一般来讲有几种选择：1、组装各种开源库，如libpng, libjpg, giflib等，支持什么格式就得添加对应的解码器；2、开源解码包，如freeimage，没用过但听说也很不错；3、GDI+，支持图片格式广泛，接口简单，性能一般。当然还有其它方式，大抵差不多。我选择的是GDI+，图简便好用，且目前微软支持的OS上都是自带的，无需发布？!。对QQ的程序集DLL进行分析，发现其中贯穿了各种解码技术，有直接采用开源库的，也有依赖GDI+的，不知道是历史遗留问题，还是各个部门之间技术偏好，抑或是另有玄机。扯到技术偏好，让我头疼的就是程序员在项目中随意的引入库，解决同一个问题，往往看到不同的人用不同的技术，甚至同一个人在不同的项目中造不同的轮子，有时候没法说服别人，只能罢了。

GDI+的初始化需要注意一件事情：不要在DLL入口处加载或卸载GDI+，否则会发生锁死现象，具体可查阅msdn。

考虑到高性能的界面中可能会采用多线程UI，因此我建立了ThreadState的TLS对象，所有的数据都存储在这个对象中，同步线程消息是通过惯用手法之隐藏窗口来保证。时至今日，或者早1、2年，我才深刻理解mfc库设计时的那些state管理结构体的用处。GDI+的初始化在ThreadState构造函数中调用，正好避免了加载冲突这个问题。TLS对象的销毁技巧来自谷歌的chromium源码中的base库里的tls实现，原始出处来自CodeProject：http://www.codeproject.com/threads/tls.asp。嗯，其实牛逼的程序员也是纵览乾坤，吸取精华。提到CodeProject，顺带提一下我的学习历程，早期疯狂的泡这个网站，几乎VC方面的东西都把玩过，形成了自己的点状知识积累，类似的有CodeGuru、vckbase（现在已经成为广告站了）；之后是 sourceforge、codegoogle、codeplex 找一些小的项目研究，形成自己的线状知识结构；再后来就是大型的源码阅读，偶尔会去谷歌讨论组、微软新闻组看一些疑难杂症问题，构成了自己的面状知识体系。每个人都有自己的学习方法论，这里仅仅是分享我自己的。很多东西都已经看上去有些过时，现在的年轻程序员可能接触的是stackoverflow、github等。

GDI+中的Image是抽象接口，为了方便使用，增加了一层简易封装IMImage，主要接口如下：

通过uri加载图片，GDI+对本地图片的加载非常简单，Image::FromFile可以直接返回；对于网络图片，需要先通过WinINet下载到本地，然后再加载。

由于使用了tls技术，这里的引用计数实现很简单，就是++、-- 操作。曾经有人告诉我引用技术是为了解决多线程中对象的生命周期问题，我欲与否认。引用计数只是为了解决对象的生命周期问题，而这种情况往往在多线程中出现，因此多线程中或多或少会用到引用计数。

IMImage类可以简单的返回一些GDI+的Image对象提供的图片信息，而GetImage需要多做一些事情。对于包含多帧图片的文件，在绘制的时候需要通过GDI+的Image::SelectActiveFrame方法选择当前帧，该操作非常耗时，因此在加载图片的时候，发现如果是多帧的，我们需要额外的decode_image_来解码存放每一帧图像，这样除第一次渲染比较耗时外，后面的获取都是非常快的。

再增加一个IMImageService，管理整个系统中用到的IMImage对象，接口很简单：

需要图像就找它要，用完之后记得释放即可。

这样就完成了图片的管理，目前来说足够用，也非常简单，不是么？

在我实作的同时，大量使用了搜索引擎和谷歌技术论坛。我没有找到直接答案，然而各种扑朔迷离的线索总是恍恍惚惚带着我走向最终的胜利，让我再次体会到成功贵在坚持不懈。在自认为差不多满意的时候，通过跟同事的探讨，我横下心继续追求完美，相信自己做的不会比QQ的实现差。

目前完成了大纲中的高效动画实现部分，这部分耗时1周，另外加上前2周的工作之外时间的技术调用。接口基于IRichEditOle，也就是说只要符合RichEdit实现规范的都支持，包括窗口的和无窗口的。那什么是符合RichEdit实现规范呢，就是符合RichEdit窗口实现的方式，特指无窗口的RichEdit实现。你可能说我不知道如何实现无窗口的RichEdit，这个不要紧，我以后会做。后面的文章我会陆续把第一部分实现进行详细讲解，同时实现第二部分。

效果图：

高效动画实现

高效图片管理

高效时钟

动画控件

高效动画刷新

拖拽剪切粘贴支持

Process Monitor

QQ动画组件分析

ClipSpy

QQ的剪切板格式分析

IDataObject

Xml序列化反序列化

拖拽

粘贴

OLE扩展

仿QQ新闻摘要
...

研究背景

自职业生涯起到现在，我参与过三个im类产品，其中我主要负责的是界面库开发。众所周知，im软件中有一个非常重要的控件用于消息展示，实现方式无外乎基于richedit（目前这一类为主要方式，代表：QQ）、基于webbrowser（代表：GTalk），可能会有基于WebKit的，我没有刻意去搜集。很多时候对于相对简单的情况，比如在游戏中，完全可以自己绘制。

我曾经模仿过GTalk的实现方式，由于当时自己经验欠缺以及与公司写页面的人沟通上的问题，效果不是那么满意，仅仅够用，后来自己离开也没再继续做这方面研究。机制上这种方式是可行的，native端事情不多。

后来的工作中，主要是基于richedit在做，都是安排其他人负责。在开发过程中，遇到种种问题，用过各种不优雅的“伎俩”，由于欠缺OLE知识，做的人很痛苦，找不到乐趣。微软官方有一个例子，然而只披露了使用技巧的冰山一角；codeproject也有少的可怜的几个例子，经不住商业化应用；互联网搜索的一些文章大多都是简单的插入图片等，聊胜于无。

《基于Chrome开源提取的界面开发框架》系列文章获得了不少支持，在提取过程中我自己也成长很多。抽取出来的引擎要想用于商业化开发，我个人觉得欠缺的主要是富文本渲染这一块，这使我开始研究richedit。断断续续，期间各种事情，几经放弃。后来一个网友在这个问题上又找到我，临时的帮助他解决问题之后，不禁感叹，为什么互联网上找不到一个优雅的解决方案甚至是深入的介绍？

网友megax的文章http://www.cppblog.com/megax/archive/2012/03/22/168601.html中关于制作编辑器方面知识提及的http://www.catch22.net/tuts/neatpad让我着实佩服，老外对待研究的态度真的很严谨，分享的开发性和持续性方面远远胜于我们。系列文章中的绝大多数概念知识我都接触过，然而很多没有深究，经验远远不如文章主人。

Richedit的研究的大部分知识都在OLE方面。现在计算机的发展，技术的百花齐放，使得Windows平台不再那么大行其道，Windows技术也不再那么不可一世，Mfc越来越被抛弃，Windows程序员诚惶诚恐，新生代早早把自己定位在更炫更酷更激情的技术平台。在Windows Native开发没有彻底失宠前，我打算把自己死啃得来的OLE知识发挥“余热”，对richedit这个东西应用于im领域的问题解决一下，希望对其他人有帮助，也希望没有重复造轮子。

研究目标

Richedit是Windows底层的组件，甚至在2004年泄漏的Win2K代码中都没有，它是独立于edit组件的，而edit位于ntuser中，亦相当底层，虽在泄漏代码中出现，然而抽取出来的可能性不大。从某种角度来讲，Reactos 就是抄袭的这份代码，明眼人可以从其死灰复燃的更新列表中发觉。很奇怪的是Reactos 的代码中有richedit，我也移植过，只是后来发现功能实在太弱，无可用性，遂放弃，至于Wine 是不是抄袭这份代码，我无从得知，也没精力再去跟踪。

Richedit 的接口相当稳定，我在Win8中试验过完全兼容，我想它应该会持续很久，所以值得去好好研究一把。

《基于Chrome开源提取的界面开发框架》的view框架，如果能有一个rtf格式的渲染利器，配以ole的展示，我想足以成为互联网商业开发的UI解决方案。

Richedit 就机制上来讲跟WebKit一样，或者应该反过来说。Richedit窗口本身是对ITextServices的封装，实现ITextHost接口与ITextServices交互提供平台支持。ITextServices的支持分两大类：基于文本的ITextDocument和基于ole的IRichEditOle。作为ole容器，提供的功能主要通过实现几个接口完成的，包括：IOleClientSite、IAdviseSink、IOleInPlaceSite，缺省的Richedit 貌似不支持定位激活，想要达到激活效果必须支持最后一个接口。与剪贴板和拖拽数据打交道需要支持统一数据传输接口IDataObject。

研究主要参考对象为QQ，目标为：支持粘贴格式、动画ole控件、定制ole菜单、拖拽、文本操纵、窗口/无窗口的统一支持等，我会在下一篇列出详细的大纲。

已做工作

OLE标准提供了大量工业化标准接口以及繁杂的交互规范，事实上除了微软（以office系列产品为典范），鲜有软件全盘实施。可以说MFC的大部分工作都是用在实现OLE，所以其臃肿大抵源于此，不得不臃肿，早些年我接触wtl后得出，MFC - WTL == OLE，或许还有一些打印等方面设施，但我不觉得这些是主要特性。以我现在眼光来看待，把MFC拆分开，其集合类、打印框架、COM支持、OLE支持、文档/视图/框架模板（尽管现在用的极少，大多在行业软件领域）、进程/线程/模块状态管理等，都还不错，呃…，貌似我快把它说全了，不好意思，我的老毛病又犯了，其实在心底，我还有那么一点不舍，即便我很多年没有用它开发商业软件了。我从MFC学到的东西太多太多，以至于我不肯说它的坏话。

再一次，我选择了从MFC中抽取代码。我尝试过直接使用MFC，静态链接以便偷偷的不告诉别人，以免“破坏形象”。但我不觉得我能做到，原因就是整个MFC耦合的比较紧密，我不想或者无法使用整个框架来对外提供服务，所以我不得不制造小轮子。我也试过直接实现，但是工作量还真不小，我怕自己等不及，故再次祭出看家本领，顺藤摸瓜，牵出一个支持OLE的最小内核，经过1-2周我能腾出的时间，终于做到了，于是我写下了开篇，后面我需要把整个思路刻画出来。下面是一个示例，插入浏览器，支持定位激活：

这个例子不具备任何说明性，只是用来测试最小的OLE内核框架是否可以工作。

测试的接口如下：

这一篇到此为止！依然是闲话多，干货少。我会努力的！