代码性能调整的12个问题.doc

　　代码性能调整的12个问题 　　本文译自：.neance-tuning-code 　　应用程序运行正常，可以执行用户或客户所需的所有任务，并不意味着程序在任何方面都是完美的。使用性能分析工具，比如profiler，我们就能明白程序在内部是如何运行的，在速度、内存占用、电量使用等方面的情况。 　　能降低你的应用程序性能的问题有许多，下面我将列举一些： 　　问题1： DLL用法优化 　　在Symbian，按链接方式可分为两种类型的链接库： 静态接口的dll和多态接口的dll。通常应用程序与许多dll静态链接，需要这些dll与否取决于不同的用况，但所有的依赖dll都装入内存将会降低应用程序性能，这是因为应用程序或服务程序的静态依赖对自由内存有很大影响。通过把逻辑相关的功能分割成动态可装载的部件会将静态依赖减小到最少。 void RuntimeLoadDllL() 　　{ 　　RFs fileSession; 　　User::LeaveIfError(fileSession.Connect()); 　　TFileName dllName; 　　　　　　If ( SomeCondition ) 　　　　{ 　　　　....... 　　　　dllName = KDllNameOne; 　　　　} 　　　　　 else 　　　　{ 　　　　......... 　　　　dllName = KDllNameTe); 　　　　　 ..................... 　　fileSession.Close(); 　　} void LoadDllL(const TFileName aLibName) 　　{ 　　RLibrary lib; 　　User::LeaveIfErrorlib.Load(aLibName)); 　　..... 　　}　　E也提供了一种标准的机制可在运行时装入指定的实现。 　　问题2： 检查TRAP的使用情况 　　TRAP的使用应尽量少，TRAP会消耗比你以为的要多的资源。因为导致内核执行机构调用TTrap::Trap()和TTrap::UnTrap()，以及在运行时分配一个结构存放当前堆栈上下文以便万一发生leave事件时回退到之前的状态。若你的类含有超过6个以上TRAP，意味着class设计不正确，需要重新设计。只要可能，就把TRAP移到函数调用的更外层。 　　问题3： 检查服务的使用与优化 　　应用程序启动时马上连接到服务是不可取的（当连接到瞬时服务时），因为这将导致连锁反应，多个服务程序的依赖部件会装入内存。如果服务很少使用，这种方法可以看作是无效的资源使用。随需连接到瞬时服务总是明智的。应当以这样的方式来设计，客户API的实现总是与实际的服务实现相分离，这样，当客户端程序链接到客户API库，就不会自动装载服务程序依赖项，而这应发生在服务程序真正启动时。 　　在设计服务程序时总是考虑它的使用情况和运行时需要的各种资源。假定服务提供三个功能，比如读、写和通知，读/写不是很频繁的操作。这种情况下，最好分成两个服务，一个提供重量级功能，诸如读/写/替换等，将被按客户端需要转载/卸载，另外一个提供轻量级的通知服务。 　　问题4： 压缩可执行程序 　　在应用程序的MMP文件使用presstarget声明指出目标可执行文件应该被压缩。通过这样做，可执行文件的代码和数据段以Huffman+LZ77算法压缩。这将使得存储的可执行文件在文件系统中使用更少的空间。在被装入时，可执行文件装载器解压这个文件。所有的可执行文件不应该被解压，只有那些占用大量空间的可选择解压。 　　问题5： 文件扫描 　　如果盘符已知，那么总是在文件路径指定驱动盘符。若没指定盘符，将以标准的Symbian OS顺讯搜索所有可用的驱动盘。若你的文件在Z:，那么你将有极大的损失，因为Z:总是最后才搜索到。 　　问题6： 检查内存使用优化 　　在S60应用程序，缺省的线程堆栈大小只有8kb，因此只有很小的对象才该在栈上创建，并尽可能早地从栈中移除。除了基本类型，我们应该总是以引用传递参数而不是按值。大对象和数组的创建应该在堆中完成，并尽可能减小自动变量的生命周期。 　　问题7： 检查缺省参数的使用 　　若我们为函数参数声明了缺省值，额外的代码将被编译器生成，这可能也是一个费用。若缺省值常用，那么值得重载这个方法，而不是提供缺省参数值。 void MyFunction( TInt aCounterVal, TInt aParamLength = 2); Can be Length );问题8： 检查引用和指针的使用情况 　　避免按值传递大对象，总是引用或指针优先。除