C++博客-C++ & Embed-随笔分类-Embed/Wincehttp://www.cppblog.com/KGen/category/12527.htmlzh-cnFri, 25 Apr 2014 08:23:01 GMTFri, 25 Apr 2014 08:23:01 GMT60嵌入式OS的选择http://www.cppblog.com/KGen/archive/2014/04/22/206675.html眩晕:C++ & Embed眩晕:C++ & EmbedTue, 22 Apr 2014 06:23:00 GMThttp://www.cppblog.com/KGen/archive/2014/04/22/206675.htmlhttp://www.cppblog.com/KGen/comments/206675.htmlhttp://www.cppblog.com/KGen/archive/2014/04/22/206675.html#Feedback0http://www.cppblog.com/KGen/comments/commentRss/206675.htmlhttp://www.cppblog.com/KGen/services/trackbacks/206675.html
10年前如果是想进入车载多媒体，导航，手持PDA设备，智能终端，SMARTPHONE等产品领域的公司，在没有积累的情况下大多会选择WINCE平台。
这一平台有着相对而言较为丰富的开发资源和一个不错的图形界面，来自厂商的支持虽然不够给力但也不是特别的糟糕。
相比而言很多抱着嵌入式Linux，TRON等系统不放到厂商尝到了苦头之后在07年前后考虑转向WINCE平台。不过像SANYO还没等转已经没有了，然后就没有了然后。

在ARM11被广泛应用之后微软显然落后了一大截。逐渐的安卓系统在各种领域被广泛的应用，开发的门槛比起嵌入式Linux和Wince时代大大降低。
魅族也从定制WINCE的系统转为定制安卓系统，新兴的没有技术积累的公司很快的在新平台上完成了弯道超车。大量的旧的，相对封闭的系统开始退出这个舞台。

前几天和芯片厂商聊了聊。感觉目前抱着Windows mobile/Windows embed不放的都是些有基础的厂商，大概都是10年前做得比较好的那一拨。有自己的Know-How，有自行编写的大量的库类。短期来看让这些企业放弃的现有资产的话，放弃成本是非常高的。包括大量的已经在设备上稳定运行的应用，不仅仅开发生产的企业要放弃，End User（也就是客户）也要放弃。

最近微软在WP8.1上很下功夫，发力向IOS，安卓等系统进行追赶。换言之在Windows Embed的其它产品线上就不是很下功夫。对于依然在使用旧的WINCE平台的企业来说，或许主动的适应显然比被动的被环境等待从而被环境淘汰要积极得多。

]]>DirectUIHWND:Windows界面编程的终点?http://www.cppblog.com/KGen/archive/2009/12/19/103533.html眩晕:C++ & Embed眩晕:C++ & EmbedSat, 19 Dec 2009 09:43:00 GMThttp://www.cppblog.com/KGen/archive/2009/12/19/103533.htmlhttp://www.cppblog.com/KGen/comments/103533.htmlhttp://www.cppblog.com/KGen/archive/2009/12/19/103533.html#Feedback3http://www.cppblog.com/KGen/comments/commentRss/103533.htmlhttp://www.cppblog.com/KGen/services/trackbacks/103533.html昨天查找了一些界面库的资料，忽然有种豁然开朗的感觉。关键字是“DirectUIHWND”。

众所周知，在Windows界面开发中，使用VC中一般的控件很难达成好的界面效果。同时，控件的功能和效率都很难令人满意。

在今年的开发中，决定在Wince上实现一个符合MVC的应用框架。其中View层搭建在MFC框架之上。所有的“窗体”、“控件”都从CWnd继承，
拥有自己的消息循环和DC。
这个设计的主要问题是：
1.内存占用。
2.运行时效率。
3.无法有效的进行双缓绘图。
4.各控件的GDI对象相关操作过于频繁造成内存碎片。

经过多次改进，当前的设计方式已经改为：
1.只有一个实际窗体。保持全局DC和相关的一些GDI对象。统一管理、操作。
2.各逻辑窗体、控件不继承自CWnd。刷新等操作完全由实际窗体进行。
3.实际窗体与逻辑窗体配合，实现各逻辑窗体的消息响应机制。

这种设计方法，正好与DirectUIHWND的基本设计思想暗合。

下面是DirectUIHWND相关的一些信息：
“DirectUIHWND”，意为Paint on parent dc directly。 即子窗口不以窗口句柄的形式创建，只是逻辑上的窗口，绘制在父窗口之上。这种方式最大的好处在于可以很方便的构建高效，绚丽的界面。国外如微软，国内如腾讯，百度等公司的客户端产品多采用这种方式来界面，从而很好的将界面和逻辑分离，同时易于实现各种超炫的界面效果如换色，换肤，透明等。DirectUI界面库旨在满足客户端界面快速开发的需要，同时融入业界领先的皮肤技术，为用户创建更加高效，专业的界面。

绕了这么大一圈，结果竟是殊途同归。当发现这些信息的时候，界面库已经基本修改完毕。


]]>Wince下的内存问题http://www.cppblog.com/KGen/archive/2009/12/10/102925.html眩晕:C++ & Embed眩晕:C++ & EmbedThu, 10 Dec 2009 08:20:00 GMThttp://www.cppblog.com/KGen/archive/2009/12/10/102925.htmlhttp://www.cppblog.com/KGen/comments/102925.htmlhttp://www.cppblog.com/KGen/archive/2009/12/10/102925.html#Feedback0http://www.cppblog.com/KGen/comments/commentRss/102925.htmlhttp://www.cppblog.com/KGen/services/trackbacks/102925.html幸福感是有机会完全掌握程序的命运，痛苦则发生在命运偏离了设计的轨道。

内存问题是多种多样的，过去非常关注内存泄露问题，对内存碎片问题完全没有概念。在新设备的开发中，由于界面部分大量涉及到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操作。

问题还在解决中……

]]>