内存问题并不是单单出现在Wince操作系统上。对于C++程序员来说，手动管理内存既幸福又痛苦。
幸福感是有机会完全掌握程序的命运，痛苦则发生在命运偏离了设计的轨道。
内存问题是多种多样的，过去非常关注内存泄露问题，对内存碎片问题完全没有概念。在新设备的开发中，由于界面部分大量涉及到GDI编程，
在设备开发的初期就开始着手进行界面框架的开发。起初一切都很顺利，构建了一个基于MFC的符合MVC结构的框架。框架也没有出现内存泄露
的迹象。
到了系统测试的阶段，发现某个应用长时间使用后出现内存不足。按照一般惯例，先进行应用程序的内存泄露的查找，未果。然后进行驱动等
层面的排查，也没有发生内存泄露的迹象。最后将问题定位于界面框架的绘图部分。发现频繁的GDI对象的创建和销毁造成了每次以4K为单位的
内存消耗。从网络上查询的结果表明，这种情况是内存碎片造成的。
现在回头再看这一问题，感觉起初实在是对开发的难度估计不足。开发队伍中不是偏底层驱动开发的工程师，就是偏业务开发的工程师。对较为
复杂的应用框架开发大家都没有经验。这样难免出现预想不到的复杂问题。
作为解决方案，其实也很简单，就是一句话，在程序中建立全局内存使用机制，自行监控、管理内存及GDI对象。避免频繁的内存分配和GDI创建、销毁操作。
追记：
1.分配、释放内存时，采用“栈式”。即分配时顺序为1，2，3；释放时顺序则应外3，2，1。这种方式可以有效避免内存碎片。
2.MFC的DC相关操作，如CreateDC,ReleaseDC的频繁成对调用，会造成内存碎片。而SDK的相关操作，则不会产生内存碎片。
3.CFont和CBrush等的DeleteOjbect操作对内存泄露和内存碎片等问题并无实质影响。要注意Select操作，CreateFont操作。
问题还在解决中……