第一回. 真的了解.NET Compact Framework吗？
  
  作为系列文章的开篇，有必要先详细了解一下基于CE.NET的.NET Compact Framework(以后简称.NET CF)，本文叙述了.NET CF的设计目标，架构特征和执行环境。
  
  .NET CF的目标在哪里？
  
  1. 专为设备设计的便携式小型.NET CLR
  
  具有.NET Framework的子集属性，支持多种语言开发。我们知道，在英文里面“便携式”对应的单词是Portable，这个Portable我们可以从两方面理解：一方面，.NET CF工作在一个灵活的，移动的，资源有限的环境下；另一层意思则体现在.NET CF本身的特性上，比如说它与OS的宽松耦合，OS管与CLR托管的不同就在这里。从编程的角度Portable体现在很多“和谐”的方面，比如I/O内存映射，比如仅支持Unicode编码等等。
  
  2. 与Visual Studio系列IDE高度兼容
  
  不仅仅是编译，调试托管和非托管的代码，在Visual Studio 2008中你还可以通过Device Security Manager来为已连接的设备管理证书和设置安全级别。甚至可以编程访问模拟器资源。
  
  3. 与主机的操作系统有良好的共存性
  
  这个共存性是多方面的，包括应用程序的执行模型，内存管理，用户输入和UI接口。这些在后面的文章中您都会接触到。
  
  当然还有一些要求是.NET CF做不到的，暂时也不是它的目标，为了不使大家对.NET CF的要求太“苛刻”，我觉得必须把这些“非目标”也列举出来：
  
  1. Compact VS. Full
  
  .NET CF不是对桌面版本.NET Framework的部分简单平移，把.NET Framework完整移植到移动设备上并不是.NET CF的目标，尽管表面上看起来有些内容和完整版的.NET Framework是一致的，但是其实现方式可能很不一样。
  
  2. 实时性
  
  Windows Mobile是一个32位的民用操作系统，你不能要求它和VxWorks一样工作！
  
  .NET CF也并没有提供对强实时性的支持(问题是您真的需要那么高的实时性吗？)。
  
  3. 语言支持
  
  .NET CF目前支持的开发语言并不像完整版本的那么丰富，目前比较流行的是C/C++，C#和VB。但是.NET CF完全支持精简版本的ECMA CLI Profile，这意味着你也可以为更多的语言编写针对.NET CF的编译器。
  
  .NET CF的结构模型
  .NET CF 的架构跟完整版的.NET Fx有相似之处，同时又具有自己特色，如图表 1所示。
  
  图表 1 .NET CF Architecture
  
  最下面的是硬件层，由于图幅有限，我仅列出了主要的一些硬件，而这所有的硬件都是由Windows CE 操作系统所控制的，WinCE提供了内存管理规范和用于加载可执行文件的Program Loader，Program Loader负责将可执行文件Push到内存中并启动它。当然，WinCE作为操作系统还有很多其他职能，比如线程管理，绘制窗体，相应来自GUI的事件，管理网络连接等等。
  
  作为使用.NET CF的程序员，我们主要关注的是图中虚线以上的部分，现在来看看.NET CF 的Common Language Runtime(CLR)，图中灰色背景的方框表示.NET CF CLR。
  
  用Native Code(如C/C++)编写的基于WinCE的程序，直接被编译成CPU可以识别的指令，但是依赖WinCE去加载它们并提供所需的服务。而CLR是一个用来托管应用程序的平台，托管的应用程序被编译成Microsoft Intermediate Language(MSIL)，IL在这里提供了一个与CPU松耦合的机会，CLR根据不同的CPU体系结构将IL编译成不同的CPU指令，这一点在行为上与桌面版的CLR是一致的。
  
  有一点要弄清的是托管的EXEs或者DLLs是由IL构成的，并不能被CPU直接执行，而是需要被CLR编译成适用于本地CPU的指令或者是本地代码。可见，CLR的工作是执行托管代码，这个过程就是托管代码本地化并被执行的过程，简单来讲，它包括以下步骤：
  
  1. 将IL从文件系统加载到内存中。
  
  2. 这些IL中的部分或全部将被转化成本地代码供CPU执行
  
  3. 如果这些IL引用了某些DLL的内容，则当DLL被找到并正确加载后，这些被用到的部分也会被转化成本地代码并被执行。
  
  可见这个Just In Time Compiler在CLR的运行中扮演着十分重要的角色。在.NET Compact Framework中有两种形式的JIT编译器，iJIT和sJIT：
  
  iJIT适用于所有的CPU，如ARM，MIPS，SHx和X86等。iJIT较简单，编译的速度也比较快，但是它编译出来的本地代码并不像sJIT那样经过优化的。
  
  sJIT编译器是ARM指令体系下特有的，它充分利用了AMR处理器的优势。虽然编译速度不及iJIT，但是编译后的代码在第二次运行的时候会迅速得多。
  
  所以在编写应用程序的时候你应当考虑到你的程序是否是专为基于ARM的设备而设计，或是有考虑到用户的机器可能是一台性能一般的MIPS。
  
  默认状况下，仅当无法使用sJIT　Compiler的时候，CLR才会选择使用iJIT的方式。这样做的原因是，通常在程序执行过程中，花在JIT编译上的时间和执行程序的时间相比是微不足道的。
  
  需要注意的是在我们的程序当中应当避免额外的JIT行为，因为有些情况下，这会明显影响到应用程序的运行速度，当然，要做到这一点需要您对CLR有一定的认识。JIT按需编译，并尝试对编译后的代码在程序生命周期内进行保留，这样下一次调用的时候就不必再执行JIT了。说是尝试是不考虑内存的缘故，这样的缓存不会无限制的进行下去，当内存不够用时，CLR会逐方法的将JIT过的代码清除掉，这就是所谓的 Code Pitching。清除掉之后再次调用该方法CLR就会重新进行JIT编译。有趣的是这个Pitch的过程也是智能化的，哪些最不常用的方法的JITed Code会被最先清除。
  
  如果我们的程序编写不当，在某些极端情况下，重复的JIT可能会出现在一个循环中，每一次循环都将重新JIT一次，这显然会使性能大打折扣，而且很可能使你的程序因此down掉。
  
  性能问题在今后的文章中还会专门介绍。
  
  用一句话概括图表1，可以说“是.NET CF CLR使得.NET应用程序得以运行在各种不同的基于Windows CE.NET的移动设备上”。
  
  Compact CLR VS. Full CLR
  对于习惯了桌面应用的程序员，有必要了解一下精简版的.NET CF与完成版本的.NET CF有哪些不同。
  
  首先从体系结构上，.NET CF CLR与桌面版本的CLR不尽相同。从图表一我们看到，.NET CF CLR 构建在Platform Abstraction Layer(PAL)之上，PAL位于执行引擎与OS之间，将