1 市场角度观看各大操作系统的局势
关于这部分内容之前写的一篇《未来移动设备发展的趋势》的文章已经讲得比较清楚，这里不再赘述。
不过可以很确切的得出结论：Windows Embedded Compact 7和Android 操作系统在江湖中已经铸造成一把魔剑和宝刀。使用这两种“武器”定会帮你笑傲江湖的。
2 操作系统的制定
2.1 Windows Embeded Compact的操作系统制定
微软会提供一个Windows Embedded Compact的安装工具，在安装的时候会出现一个Platform Builder 选项，这个工具是用来裁减和制定操作系统的。对于WindowsEmbedded
Compact 来说，它是个可裁减可制定的操作系统——微软把这个操作系统的每个模块以可选的组件方式提供给用户，包括操作系统本身的部分和驱动模块。用户可以使用Platfom Builder 很方便的对一些组件进行添加和删除。例如：是否包含多媒体库，是否包含IE浏览器，是否对 .Net Compact Framework 运行时的支持，是否包含触摸屏，蓝牙等等。微软提供了强大的Visual Studio 2008 开发环境。并且从Visual Studio2005版本开始就把Platform Builder 集成进去。除过界面部分的开发外，其他全都在VS2008平台上进行。操作系统的制定的目的就是把编写好的驱动根据需求制定出特定平台的操作系统，然后再导出适合特定平台开发的SDK（Software
Develepment Kit）共应用程序开发者使用。VS2008——Platform Builder 能帮你很好的完成这点。当然，只针对操作系统的制定来说，操作系统制定人员只需要额外实现一些用于特定的API（Aplication Programing Interface）接口和DDI（Device Driver Interface）接口即可。这一切的要建立的BSP(Board Support Package)包和公用模块代码完整性的前提。
2.2 Android的操作系统的制定
Android操作系统的开发有两种方式，一种是用于直接在Linux环境的源码下开发，一种是不用源码开发，使用SDK开发。对于大多用户来说选用SDK开发是最佳的方式。应用程序开发者不需要关注底层的每个细节。SDK的制定是操作系统制定者的首要任务，其编译的过程是完全在Linux底下完成的。至于Android
内核的Linux 到底和传统的Linux有什么样的区别，为什么把一半代码都是Linux的操作系统却改名为Android？还是一句话：Android不是Linux。有何区别非一言能说清楚，还望查看谷歌官方网站。如下为Android的系统结构：
图1
如图1 所示官方把Android系统分为4层，对于开发嵌入式系统来说我们要当5层看待，从上到下依次为：应用层,应用程序框架层，系统运行库层，Linux内核层，硬件抽象层。对于操作系统制定者来说，必须得对Linux的系统结构和Andriod应用程序框架有比较全面的认识。制定应用程序开发接口，完成特定功能的应用程序API的制定。其中Android的开发分为SDK开发和NDK（NativeDelelopment
Kit）开发。但对于google 目前的支持和开发的难度上来讲，SDK还是首选。操作系统的制定对于Android来说分为两部分，一部分是编译出运行于硬件上的系统运行库和内核，另一部分是编译出适合应用程序开发人员使用的SDK，官方网站提供通用的二进制SDK，但一般都不能完全满足特定的开发需求。需要操作系统制定者根据需求，遵循Android的框架来制定自己的模块和API接口。
3 驱动的编写
所谓的设备驱动，就是负责物理层和虚拟设备与操作系统进行通信的软件模块。一些设备驱动控制外围硬件，如网络适配器，显示适配器，鼠标，键盘，串口，存储设备。而另一些驱动设备控制硬件总线，而总线再连接目标平台，还有一些驱动控制虚拟设备，如文件系统。
3.1 Windows Embedded Compact的驱动模型
对于Winodws Embedded Compact来说，每个设备驱动都会包装和抽象出它所对应硬件的功能,而设备驱动的作用是能够使得操作系统和应用程序能通过API来访问硬件。这样就使得操作系统和应用程序在不需要考虑硬件的实现特性上来使用硬件。几乎每个设备驱动要满足这样一个通用的定义，但是一些专用特性和你的设备驱动内部的定义会和其他设备有很大的区别，因为设备驱动的实现方式对于我们用户来说是非常灵活的，往往同一种功能的设备驱动会有多种实现方式可选，到底哪种实现方式最适合于我们的项目开发呢？这主要取决于以下几点：
1．你的设备驱动程序所支持的硬件的复杂度。
2. 你的设备驱动与OS和应用程序的接口是怎样定义的。
3. 你的驱动程序的实现是否会再利用现有的功能。
4. 你的应用程序是要运行在用户空间还是内核空间。
这些因素依次由你的产品需求和你的开发优先权来决定。当然，在写驱动程序之前，必须得很清楚WindowsEmbeded Compact 7 的驱动模型和结构。
从驱动的种类来说，Windows Embeded Compact 7把驱动分为两类，即：本地（Native）驱动和流式(Stream)驱动。这两个驱动有什么区别呢？ 这里我归纳几点 ：
1：从控制的设备来说，仅仅是依照其暴露给用户的接口，而不是设备的种类。
2：本地设备驱动会在内核空间运行，效率相对来说高，直接通过OS来与硬件打交道。而流式驱动程序只能运行在用户空间。
3：本地设备驱动有自己的API集， 而流式设备驱动仅仅拥有13个API函数来对设备进行操作。
以下为驱动分类的一个模型图：
图2
这个图也很好的解释了如上所述。其中GWES 和Device Manager 分别为内核的两个进程。其中GWES主要负责图像，窗口，事件，子系统。而Device Mangager毫无疑问是设备管理器的意思，流式驱动只能通过此模块来与硬件打交道。
从驱动的实现方式层次结构来分，我们把Windows Embeded Compact 的驱动又分为分层模式和单体模式。到底什么是分层模式和单体模式呢？操作系统是通过设备驱动接口来直接或间接的调用硬件的，而对于操作系统来说驱动暴露给其仅仅是设备驱动接口，而设备驱动接口怎么与硬件进行交互，当然你可以直接把设备驱动接口直接关联到底层硬件上，这就是所谓的单体模式，单体模式的效率最高，但代码可重用性太差。还有另一种实现方式就是在设备驱动接口和硬件之间再建立两层接口——模块设备驱动和平台设备驱动。模块设备驱动共设备驱动接口来调用，而平台设备驱动实现相关硬件接口。而模块设备驱动和平台设备驱动再通过设备驱动服务接口来进行关联。具体的模型图如下所示：
图3
上图中的名词解释：
DDI：Device Driver Interface 设备驱动接口
MDD：Model Device Driver 模块设备驱动
DDSI：Device Driver Service Interface 设备驱动服务接口
PDD: Platform Device driver 平台设备驱动
相信大家看到这里已经明白了设备驱动结构的实现方式。
从驱动运行的空间又可把驱动分为内核模式驱动和用户模式驱动。内核模式驱动在内核中运行，用户模式驱动在用户进程中运行。用户模式驱动的优势就是当相应的驱动失败时只影响当前加载它的进程，然而内核模式驱动的失败会影响整个操作系统。内核模式的优势是运行效率优于用户模式。尽管内核模式驱动会限制调用内核API，但内核模式驱动也拥有访问整个硬件和内核空间的权限。被GWES和文件系统加载的驱动只能运行在内核模式下。而Device
Manager（设备驱动管理器）即加载内核模式驱动又加载用户模式驱动，但是你是不能把本地驱动运行于用户模式的。用户模式驱动只限定于流式驱动。但每种类型的驱动即可以以多层结构实现又可以以单体结构实现。
还有一种驱动模型及为总线型驱动，具体请参照微软的官方网站。
不管是那种类型的驱动，其加载方式均可以在系统启动时加载或者动态的加载，如当某个设备插入时动态加载驱动，这样可以有效的节省系统内存空间。在编写Windows Embedded Compact 的驱动时，我们到底如何实现我们的驱动？这是我们关系的最重要的问题。而Windows Embedded Compact 并没有限制我们必须严格按某种方式实现，具体怎么实现，权利在你手中——你得根据你的开发需求和实现优先权酌情考虑。
3.2 Android 的驱动模型。
Android的内核部分就是采用了Linux 的内核，具体版本是从Linux2.6内核开始的。在编写Android驱动时和Linux驱动没有本质的差别。所以对于Android驱动的编写实际我们要讨论的是Linux的驱动模型。
Linux是单体内核系统，驱动是内核的组成部分。设备驱动一般情况都是在内核空间的，编写设备驱动即为在内核空间作业的过程。当然有一部分驱动是可以在用户空间的，这仅仅限定于硬件寄存器和内存的映射，对某个进程给予特权就可访问内核映射的某个虚拟内存从而访问硬件。但效率是很低的。而且会有很多限制。所以我们一般情况说及Linux驱动，说的是内核驱动。作为一个驱动开发工程师，通常了解熟悉内核的机制可以很好的帮助我们理解设备的运行原理,
帮助我们很容易的调试驱动程序，解决Bug。
在编写Linux驱动时，更强调访问硬件的一种机制，而不是方法的定义，即给操作系统提供硬件的访问能力，而不是这些功能是怎么使用。当编写驱动时，程序员应该关注这样的基本概念：写内核代码去访问硬件，而不是从用户角度提供方法，因为不同的用户有不同的需求。把访问硬件的能力通过内核的机制提供给系统运行时的应用程序开发者，这是编写驱动的核心。
你也可以从另外一个角度来看驱动：及它就是介于实际设备和应用程序（这里的应用对于Android不是直接面对应用程序开发的，而是系统运行时库层）之间的一层软件。驱动的特权角色允许驱动开发者精确的选择设备如何呈现给应用程序开发者：即不同的驱动提供不同的能力，即使相同的设备。实际的驱动设计是在多种考虑下寻找一种平衡。例如一个单独的设备驱动可能同时被不同的用户所使用，驱动开发人员完全有自由决定怎样处理一致性问题。
Linux设备驱动通常被分为三种类型：字符驱动，块驱动和网络驱动。这也不不是一个严格的分类。如下为内核的模型图：
图4
如下逐个来解释这三种驱动定义：
字符型驱动是能够被字节流所访问的驱动；字符型驱动至少会实现open,close ,read 和write的系统调用。如控制台（/dev/console）和串口（/dev/ttyS0 等一系列）都是字符型驱动。字符型驱动是通过文件系统节点来访问的，例如/dev/tty1 和/dev/lp0。文件系统和字符驱动唯一不同的表象是文件系统你可以进入打开后退，并且嵌套节点，而字符驱动节点仅仅是一个数据通道的节点，你通过这个节点可以连续的访问数据。
块设备其实和字符设备很类似，也是通过文件系统/dev下的结点来访问的。块设备就是一个设备（即磁盘）能够主持文件系统。Linux系统允许应用程序像字符设备一样来读写块设备。字符设备驱动和块设备驱动唯一不同的是数据被内核管理的方式，每个块设备都是通过文件系统结点来访问的，对用户来说他们之间的不同是一目了然的，块设备驱动与字符设备驱动对于内核来说有完全不同的接口。
最后在介绍网络驱动，任何网络事务都是通过接口来建立，接口可以使得一个设备能够与另一个设备进行交换数据。通常接口是一个硬件设备，但也可能是软件模拟，如环回接口。网络接口负责传送和接收数据包，网络接口是通过内核子系统来驱动。很多的网络链接（尤其是使用TCP）是面向流的，但是网络设备实际上被设计用于包的传输和接收。网络驱动不会知道任何个体的链接，只是负责对包的处理。
如果不是面向流的设计，网络设备并不会被很容易的就像/dev/tty1 这样被映射成文件系统结点。但是继承传统的UNIX风格，仍然会给其分配一个独一无二（如\eth0）的名字。但是这个名字绝对不是访问文件系统的入口点，网络设备驱动和内核的信息传输与字符驱动和块设备驱动是完全不同的。
综上所述,一般情况,字符设备驱动适合于连续访问的比较简单的设备驱动,字符驱动不支持随机访问,如磁盘空间。而块设备能涵盖字符型设备驱动所提供的功能，但操作和实现机制比字符型设备复杂，但块设备支持突发性访问，随机性访问，适合大量数据吞吐和随机访问，所以块设备适合于如磁盘数据读取，DMA通道。
而我们把在开发过程中遇到的基于协议的网络传输通常以网络设备驱动模型实现。
在开发设备驱动时，上面已经提到过，是完全的内核的开发，您所能用到的API 全是内核提供的API， 你拥有对内核的所有访问权限，内核是否稳定这一要务就完全掌握到你的手中。在编写Linux设备驱动之前，你得对设备驱动的构架有个整体全面而又细微的理解，并且最好能够深入理解Linux的内核机制，这样才能编写出健壮的内核驱动程序。
4 应用程序的开发
4.1 Windows Embedded Compact的应用程序开发
WindowsEmbedded Compact和wince 6之前的版本相比已经发生了新技术的突破，从性能和开发方式上来讲，都已趋向于本质的区别。这可能也是到第7个版本，微软改名的一大原因吧。从这个名字我把它翻译成中文为“Windows嵌入式袖珍”可以领略到微软对它的定位。
从效率上讲，之前微软一直把.net (.Net Compact Framework )技术应用于wince 中,而且支持各种版本的.Net Compact Framework，也大量的宣传他的优点，但是从Windows Embedded Compact 开始，就主张建议我们使用NativeC++
来做应用程序开发（而且在使用SilverLight时，也只能使用native C++），并且不支持Manage C++（一种被托管的C++ 技术）。但在制定操作系统时还会有个选项是否包含.Net CompactFramework 3.5。 用户若基于这个框架开发的应用程序还是可以在Windows EmbeddedCompact上运行的。另外一点，微软集成了多年良好的编程防范的MFC框架在 Windows Embedded Compact 上已经不不再建议使用。从这些举措我们可以清楚地认识到这个袖珍的名副其实。
从开发方式上看，Windows Embedded Compact 引进Silver Light 技术，把设计者和开发者用一种XAML（微软自己开发的XML的扩展语言）语言来分开，懂得对UI设计的人员完全可以不懂得C++ ，面向对象或C#语言，而做逻辑开发者可以倾心关注与功能的逻辑性而没有必要再完全掌握美工方面的技巧。
同样作UI 界面的设计者也不必关注于应用程序的逻辑性。而却能让这两者之间无缝连接。 同时微软自行开发的用于Silver Light技术的Expression Blend 效果之绚丽和易操作性让人扼腕兴叹。
从开发要掌握的技术上看，界面UI设计人员必须掌握开发工具Expression Blend 的使用，XAML语言（号称也是编程届最简单的语言）的使用，并且有深刻的宏观设计思想，面向对象设计思想，模块化设计思想，美术感官设计思想。对于开发者来说（以后就把界面开发人称为设计者，把应用程序开发人称为开发者），要求更高，若想成为出色的开发者，要有设计者除过美工思想外的所有思想和技巧，并且有严格的逻辑性和熟练掌握C++
开发语言，了解C#语言，熟练掌握WindowsEmbedded Compact 的API接口，掌握进程间通信，线程间通信 同步互斥， 中断，文件系统，等操作系统知识。另外还要懂得数据库技术。知道的越多你的开发技巧和经验就越丰富，这当然对你的项目有很大的决定性作用，往往一个项目的成与败，完与缺很大上取决于开发人员。
4.2 Android的应用程序开发
首先简单的介绍一下Android的历史，Android 不是一个新发明，是Google 利用开源社区的资源，把Sun这么多年呕心沥血的成就在硬件发展到一定可承载程度的前提条件下整合重构出来的一套开源操作系统。起初1.0 版本到2.3 版本都是倾心为手机打造的操作系统，而3.0 版本主要针对平板电脑，4.0
版本把手机与平板电脑集合与一起，并且增加了很多新的特色，如可制定更改Widget大小，面部识别解锁功能，语音文字转换技术等等。
从效率上来讲，Linux内核是一个准实时操作系统（按实时的等级把操作系统的实时性通常划分为：强实时，准实时，弱实时操作系统）。传统的Java中J2ME是其实是针对移动设备来开发的。一个很有制约性的不能使得J2ME 得一普遍使用的根本原因是效率非常低，硬件没有发展到一定阶段的情况软件往往不能取得突破性的发展。Java语言的设计初衷是利用虚拟机技术使得Java编写的程序只要有虚拟机运行的机器就一定能够运行起来。Android
正好也继承了这点，Android起初是使用Java技术在Linux之上构建虚拟机来支撑Java的运行，使得使用Java编写的应用程序可以在任何的Android系统上运行而不需要在特定的平台上编译，但也牺牲了一定效率。当然google在这方面做了很大的优化。所以编写Android的应用程序开发者必须熟练掌握Java语言，若想深入一点也必须掌握C++,C语言来新增应用程序框架特性，构建Linux运行时。后期Google 也在完善推行NDK（NativeDevelopment Kit）的开发，这会提高系统的运行效率，但是NDK的开发还是很有难度很很多不完善的地方，很大一部分功能目前还是不支持的。
从开发方式上看，Android也是把设计者和开发者使用XML分离的技术使得应用程序的开发分工更加明确，同时也支持第三方软件InflexionUI Express, 这和Windows Embedded Compact 的开发模式不相上下。这里不做过多介绍。
从开发要掌握的技术看，设计者掌握一些第三方工具的使用和XML语言描述UI的技巧，开发者必须掌握Java和C++。 和Windows Embedded Compact的要求类似。
5 最后总结
Android 操作系统由于开源社区给予了更多的包容性，加上强大的Linux内核做基石，它更像一座豪华的允许任何天才般的工匠去铸造的宫殿，而WindowsEmbedded Compact 则就像微软描述的那样“嵌入式的袖珍”。它更像一座微软精心打造的美丽而又精致的小别墅。最后再用两句诗来做一形容：海纳百川有容乃大，壁立千仞无欲则刚。这正是Android
和Windows Embedded Compact 的品性。希望这篇文章能能对你有所帮助。