.net cf下的代码性能优化

图形和用户界面部分：

        1：位图对象,通常情况下，把位图对象最为绘制图像或者部分图像的临时空间是有用的。如果你的移动设备应用需要临时空间来作画，这是好的，但是要避免在绘制周期内创建和处理多个位图。通常情况下较好的办法是有一个可以作为公共资源反复使用的草图空间，而不要持续的创建和注销临时位图。草稿位图应该具有你所需要的最大空间。如果草稿位图再绘制之前需要清除，可以调用Graphic.Clear（），这是很容易能够很快完成，确认再任何时间内，每个位图只装入一个实例，如果你的应用有多个同样的位图资源或拷贝装载，这会造成大量的内存资源浪费

      2：Graphic对象，如果你正在一个位图上连续绘画，这可能需要缓存屏幕外位图的Graphic对象和屏幕上的目标位图的Graphic对象。这样将避免持续的分配和释放这些对象。再绘图循环中，应该不要为一个位图或者Form多次分配Graphic对象，理想状态下，你应该完全避免分配和注销它们。

   3：字体，brush，pen，ImageAttributes：有一种错误的理解，在小范围内过度的管理资源的生命周期而忽略了他们在大范围的可用性。移动设备上的条件很苛刻，因为与桌面的Framework不同，.net CF没有刷子和钢笔的静态版本，解决这个问题的方法是创建你自己的全局对象。这样再应用绘画需要时，可始终使用它们。你应该检查应用绘画循环中的代码，同时查找重复创建的资源并把这些多余的部分删除掉。

   4：对象的值类型。再绘制代码中最普通的类型是Rectangle结构，使用类型是非常有效的，因为它们能被分配到栈上，但是类型也能被作为对象看待，可以把它们放入数据或者集合中或把它们传递到可以接收对象的任何地方。仔细观察你使用的类型并确信没有通过它们的boxing和unboxing盲目的把它们持续分配和释放到对象中。

String：

1：字符串是不可变的。这个奇特的词不可变清楚的说明一个字符串的文本数据在内存中是不可变的。改变字符串中的数据的任何代码操作实际上是创建了一个新的字符串。当字符串不再被任何“活着的”变量引用的时候，它是垃圾

2：当你想要引用字符串的一些子集的时候，使用字符串的整数索引将更高效。因为字符串是再一个字符数组中的数据，很容易使用索引来获得数据。

3：当你在循环中构建一个字符新串的时候，一定考虑使用Stringbuilder对象

一些编写优良性能代码的好方法：

1：制定一个有意识的和前置的决定来管理你的移动应用的内存。不要允许移动设备应用的内存模型变成一种被动或者随意的设计，对什么应保存再内存里，何时它将被废除作出一个明确的说明

2：定义无联系的应用状态，并确定每个状态所要求的资源。状态机方法再执行这种内存管理方面非常有用。移动设备应用应该维护一个状态和状态转换行为的特定列表和状态转换行为，这样使你又能力调整应用的内存使用

3：不要害怕缓存公共资源。保持尽可能少的应用的稳定状态的内存的使用应该是一个目标，但这不应该以抛弃有用的对象为代价，如果你不得不持续地重新创建和注销关键的对象，这些对象就应该被缓存，来避免这种内存波动。考虑用一个资源分配器类来为应用的其他部分分配，缓存，释放和管理资源。这个分配器类可以将分配资源从分配和销毁中分离。如果你有一个主要的分配器，你应用代码的其余部分不需要担心分配和注销策略，同时，你的资源分配器可以通过调整，用不同的状态适应引用

4：对任何不是马上完成的任务，使用等待光标给用户一些反馈

5：用真实世界数据的尺寸和连接模型开发和测试。

6：注意使用图像的维数，如今一般的图像是相当打的，不能被有效的显示再移动设备屏幕上，把这些图像移动到网络上浪费时间，把他们装入到内存中浪费额外的内存，把它们存储到移动设备上浪费空间。一个0.5m图像数据装入内存中相当于成百上千非成像的数据所占用的内存；500k的像素想到那个与5000000个整数。如果有可能的话，再下载它们之前，把图像维数减少到与目标设备的显示能力相匹配，如果这不可能而且高分辨率图像需要装入到内存中，马上考虑在内存中生成较小分辨率的拷贝同时释放大容量的原图像这样你的应用不会没有必要的占用大量内存了。

7：发现预处理数据的方法，对于图形代码，XML代码和其他需要被执行的大量代码，这是正确的，你在预加工中投入的工作越多，你再运行事件上花费的执行事件就越少。

 

（以上大部分内容出自博文视点的《编写移动代码》，加上几个月来在项目中的感同身受，特别截取感觉非常值得回味的一些要点，一起分享）