1主要OSの状況を市場の視点から見る
この部分の前に書いた記事「今後のモバイルデバイスの開発動向」ですでにわかりやすく説明されているので、ここでは繰り返しません。
しかし、Windows Embedded Compact 7 と Android オペレーティング システムは、魔法の剣や宝剣として川や湖に投げ込まれたと結論付けることができます。この2つの「武器」を使いこなすことで、きっと自分に自信を持つことができるでしょう。
2 オペレーティングシステムの策定
2.1 Windows Embeded Compactのオペレーティング システムの定式化
マイクロソフトは、Windows Embedded Compactのインストール ツール。インストール中に Platform Builder オプションが表示されます。このツールは、オペレーティング システムを切り取って作成するために使用されます。WindowsEmbedded Compact は、カスタマイズ可能なオペレーティング システムです。Microsoft は、オペレーティング システム自体の一部やドライバー モジュールなど、このオペレーティング システムの各モジュールをオプションのコンポーネントとしてユーザーに提供します。ユーザーは、Platform Builder を使用して、一部のコンポーネントを簡単に追加および削除できます。たとえば、マルチメディア ライブラリが含まれているかどうか、IE ブラウザが含まれているかどうか、.Net Compact Framework ランタイムをサポートしているかどうか、タッチ スクリーンや Bluetooth が含まれているかどうかなどです。Microsoft は、強力な Visual Studio 2008 開発環境を提供します。また、Visual Studio2005 バージョンからは、Platform Builder が統合されました。インターフェイス部分の開発を除いて、その他はすべて VS2008 プラットフォーム上で実行されます。オペレーティング システムの策定の目的は、特定のプラットフォームのオペレーティング システムの要件に従って書かれたドライバーを策定し、アプリケーション開発者が使用できるように、特定のプラットフォームの開発に適した SDK (ソフトウェア開発キット) をエクスポートすることです。VS2008——Platform Builder は、これをうまく達成するのに役立ちます。もちろん、オペレーティング システムの開発の場合に限り、オペレーティング システム開発者は追加の特定の API (アプリケーション プログラミング インターフェイス) インターフェイスと DDI (デバイス ドライバー インターフェイス) インターフェイスを実装するだけで済みます。これらはすべて、BSP (ボード サポート パッケージ) パッケージと共通モジュール コードの整合性を構築するための前提条件です。
2.2 Android オペレーティング システムの開発
Android OSの開発には、Linux環境のソースコード直下で開発する方法と、ソースコードを使わずにSDKを使用して開発する方法があります。ほとんどのユーザーにとって、SDK 開発を選択することが最善の方法です。アプリケーション開発者は、低レベルの詳細をすべて気にする必要はありません。SDKの策定はOSメーカーの主な仕事であり、コンパイルプロセスはLinux上で完全に完了します。Android カーネルの Linux と従来の Linux の違いについて、Linux のコードの半分を含むオペレーティング システムが Android という名前に変更されたのはなぜですか? まだ一言: Android は Linux ではありません。何が違うのかは明確には言えませんが、Googleの公式サイトも見てみてください。Android のシステム構造は次のとおりです。
図1
図 1 に示すように、Android システムは公式には 4 層に分かれていますが、組み込みシステムの開発では、上からアプリケーション層、アプリケーション フレームワーク層、システム ランタイム層、Linux カーネル層、ハードウェア抽象化層の 5 層として扱う必要があります。オペレーティング システム開発者は、Linux システム構造と Andriod アプリケーション フレームワークをより包括的に理解する必要があります。アプリケーション プログラム開発インターフェイスを作成し、特定の機能を備えたアプリケーション プログラム API の作成を完了します。その中でもAndroid開発はSDK開発とSDK開発に分かれます。NDK（ネイティブデリバリーキット）の開発。しかし、Google の現在のサポートと開発の難しさを考慮すると、SDK が依然として第一の選択肢です。Android 用のオペレーティング システムの構築は 2 つの部分に分かれており、1 つはハードウェア上で動作するシステム ランタイム ライブラリとカーネルのコンパイルで、もう 1 つはアプリケーション開発者に適した SDK のコンパイルです。公式 Web サイトでは一般的なバイナリ SDK が提供されていますが、一般に特定の開発ニーズを完全に満たすことはできません。オペレーティング システムの開発者は、要件に従って独自のモジュールと API インターフェイスを開発し、Android フレームワークに従う必要があります。
3ドライバー書き込み
いわゆるデバイス ドライバーは、物理層と仮想デバイスとオペレーティング システムの間の通信を担当するソフトウェア モジュールです。一部のデバイス ドライバーは、ネットワーク アダプター、ディスプレイ アダプター、マウス、キーボード、シリアル ポート、ストレージ デバイスなどの周辺ハードウェアを制御します。他のドライバー デバイスは、ターゲット プラットフォームに接続するハードウェア バスを制御し、一部のドライバーはファイル システムなどの仮想デバイスを制御します。
3.1 Windows Embedded Compactのドライバー モデル
Winodws Embedded Compact の場合、各デバイス ドライバーは、対応するハードウェアの機能をパッケージ化して抽象化します。デバイス ドライバーの役割は、オペレーティング システムとアプリケーションが API を介してハードウェアにアクセスできるようにすることです。これにより、オペレーティング システムとアプリケーションは、ハードウェアの実装特性を考慮することなくハードウェアを使用できるようになります。ほとんどすべてのデバイス ドライバーはこのような一般的な定義を満たす必要がありますが、デバイス ドライバーの実装はユーザーにとって非常に柔軟であり、同じ機能を持つデバイス ドライバーには複数の実装方法が存在することが多いため、一部の特殊な機能やデバイス ドライバーの内部定義は他のデバイスとは大きく異なります。どの実装方法がプロジェクト開発に最適ですか? これは主に次の点に依存します。
1. デバイスドライバーがサポートするハードウェアの複雑さ。
2. デバイス ドライバーと OS およびアプリケーションの間のインターフェイスはどのように定義されていますか?
3. ドライバーの実装が既存の機能を再利用するかどうか。
4. アプリケーションがユーザー空間で実行されるかカーネル空間で実行されるか。
これらの要素は、製品要件と開発の優先順位によって決まります。もちろん、ドライバーを作成する前に、WindowsEmbeded Compact 7 のドライバー モデルと構造を明確に理解する必要があります。
Windows Embeded Compact 7 では、ドライバーの種類に基づいて、ドライバーをローカル (ネイティブ) ドライバーとストリーミング (ストリーム) ドライバーの 2 つのカテゴリに分類します。これら 2 つのドライバーの違いは何ですか? ここでいくつかのポイントをまとめます。
1: 制御対象デバイスに関する限り、デバイスの種類ではなく、ユーザーに公開されるインターフェイスのみに基づいています。
2: ローカル デバイス ドライバーはカーネル空間で実行され、効率が比較的高く、OS を通じてハードウェアを直接処理します。ストリーミング ドライバーはユーザー空間でのみ実行できます。
3: ローカル デバイス ドライバーには独自の API セットがありますが、ストリーミング デバイス ドライバーにはデバイスを操作するための API 関数が 13 個しかありません。
以下はドライバー分類のモデル図です。
図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 的品性。希望这篇文章能能对你有所帮助。