U性能规范.docxVIP

用友软件股份有限公司研发过程U9性能规范文件编号：U9-SE-CD-WF-003版本号：V1.0修改状态：编写人：张红斌、尹明君、黄卫审核人：翟宇翔批准人：黄涛批准时间：2006-10-30适用对象该规范适用于U9设计人员和开发人员。版本记录此部分要记录该文档形成过程中的历次版本变更过程及变更的内容版本修改与参与人修改时间修改原因修改概述审批人1.0张红斌、尹明君、黄卫2006/06/10原始文档建立1.1张红斌2007/01/29补充内容ToEntityData消耗A.B代替A.B.ID新的EntityFinder.IsExists方法UI禁用Entity对象使用throw而不是throw e1.2张红斌2008/03/10形成U9 V1.1性能规范补充U9编程模型1.1.14节至1.1.17节相关文档此部分包含对该文档起指导与约束作用的相关文档以及预计在该文档指导与约束下将要建立的文档。约定标有 ★ 的条目表示强制性规范。性能规范细则基础篇C#语言垃圾回收垃圾回收是现代语言的标志之一。垃圾回收解放了手工管理对象释放的工作，提高了程序的健壮性，但副作用就是程序代码可能对于对象创建变得随意。避免不必要的对象创建由于垃圾回收的代价较高，所以C#程序开发要遵循的一个基本原则就是避免不必要的对象创建。以下列举一些常见的情形。避免循环创建对象 ★如果对象并不会随每次循环而改变状态，那么在循环中反复创建对象将带来性能损耗。例如下例：高效的做法是将builder对象提到循环外面创建。在需要的逻辑分支中创建对象如果对象只在某些逻辑分支中才被用到，那么应只在该逻辑分支中创建对象。例如：正确的做法是：使用常量避免创建对象如下例，程序中存在大量new decimal(0)的代码，这会导致小对象频繁创建及回收：正确的做法是使用Decimal.Zero常量。另外，我们也可以学习这个设计手法，应用到类似场景中。使用StringBuilder做字符串连接请参见1.2.1节。不要使用空析构函数 ★如果类包含析构函数，则创建对象时会在Finalize 队列中添加对象的引用，以保证当对象无法可达时，仍然可以调用到Finalize方法。垃圾回收器在运行期间，会启动一个低优先级的线程处理该队列。相比之下，没有析构函数的对象就没有这些消耗。如果析构函数为空，这个消耗就毫无意义，只会导致性能降低！因此，我们要求不要使用空的析构函数。从实际情况看，许多是曾经在析构函数中包含有处理代码，但后来因为种种原因被注释掉或者删除掉了，只留下了一个空壳。此时应注意把析构函数本身注释掉或者删除掉。实现IDisposable接口垃圾回收事实上只支持托管内存的回收，对于其它的非托管资源，例如Windows GDI句柄或数据库连接，在析构函数中释放资源有很大问题。原因是垃圾回收依赖于内存紧张情况，虽然数据库连接可能已濒临耗尽，但如果内存还很充足的话，垃圾回收是不会运行的。C#的IDisposable接口是一种显式释放资源的机制。通过提供using语句，还简化了使用方式（编译器自动生成try..finally块，并在finally块中调用Dispose方法）。对于申请了非托管资源的对象，应为其实现IDisposable接口，以保证资源一旦超出using语句范围，即得到及时释放。这对于构造健壮且性能优良的程序非常有意义！为防止对象的Dispose方法不被调用的情况发生，一般还要提供析构函数，两者调用一个处理资源释放的公共方法。同时，Dispose方法应调用System.GC.SuppressFinalize(this)，告诉垃圾回收器无需再处理Finalize方法了。String操作使用StringBuilder做字符串连接String是不变类，使用+操作连接字符串会导致创建一个新的字符串。如果字符串连接次数不是固定的，例如在一个循环中，则应该使用StringBuilder类来做字符串连接工作。因为StringBuilder内部有一个StringBuffer，连接操作不会每次分配新的字符串空间。只有当连接后的字符串超出Buffer大小时，才会申请新的Buffer空间。典型代码如下：StringBuilder sb = new StringBuilder(256);for (int i=0; i Results.Count; i++){ sb.Append (Results[i]);}而如果连接次数是固定的并且只有几次，此时应该直接用+号连接，保持程序简洁易读。实际上，编译器已经做了优化，会依据加号次数调用不同参数个数的String.Concat方法。例如：String str = str1+str2+str3+str4;会被编译为String.Concat(str1,str2,str3, st