5 理 解 .NET Compact Framew ork 与性能优化 本章内容 开发常识 理解精简版CLR 引擎 .NET Compact Framew ork 性能统计表 以编码方式检测性能 性能指导 尽管移动设备确实在硬件和操作系统方面获得飞跃性的改进，但它仍受原始的电力供应的制约，因此，对性能的考虑在开发过程中就显得尤为重要。同样，对依赖电池的设备来说，不仅出于对性能的考虑，而且还由于电池容量的问题，要尽量减少消耗。 本章将讨论编写良好性能代码的各种原则。要取得良好的性能，关键是在开发过程中尽早确立性能目标，还要理解公共语言运行库(CLR)的内存管理，并避免在内存中产生不必要的“垃圾”。理解程序运行过程中运行库的工作情况与如何才能尽量减少运行库的开销同样重要。 5.1 开 发 常 识 在某些圈子里，开发者会把性能当作主要的驱动因素，应用能够想到的每一种优化措施，不顾一切地加速进程运行，这是一个误区。让代码快速运行没错，但目标应该是明确您的程序需要多快。 例如，如果您的应用程序需要3s 来执行某项操作(例如，连接到服务器，进行登录验证)，且用户欣然接受，那么花时间来使这个操作更快并没有多大意义。在这种情况下，用户的接受程度决定了实现那种情况下所需要的性能标准。满足用户接受的性能标准才是程序的运行速度唯一的驱动力。如果需要更多因素来帮助您进行决策，那么，考虑下面几个问题：上一个版本运行速度有多快？竞争对手的产品运行速度多快？此外，决定是否继续优化代码的唯一评判标准，应该是用户是否接受这个速度。如果用户使用您的产品比之前用过的任何方法(包括手动操作)都方便，且速度与其他同类产品持平，那就没有必要再做优化。 在撰写功能规格说明书时，应该指定最低的性能要求和理想的性能要求，同时要避免仅用“这个功能一定要快”这样的句子来描述对某个功能的速度要求。不幸的是，很多开发者在写了很多代码之后才发现他们的代码不够快，只好再尝试着去优化代码，希望能够在性能上有所改进。为了避免事后的麻烦，必须在开发进程前期指明对性能的要求，并列举客户的各种期望值。测试过程中要不断地验证那些功能是否满足规格说明书的要求，并要考虑代码更改是否会对结果产生负面影响。 良好性能的程序代码不是事后设计出来的。例如，一个涉及在 ListView 加载选项的功能。实现这个功能后，发现加载 10 000 条选项花费的时间长得难以接受。那么，您是希望试图对每个方法...
