symbian开发22条经验总结 收藏Word格式.docx

symbian开发22条经验总结 收藏Word格式.docx

《symbian开发22条经验总结 收藏Word格式.docx》由会员分享，可在线阅读，更多相关《symbian开发22条经验总结 收藏Word格式.docx（5页珍藏版）》请在冰豆网上搜索。

在这一点上，应注意电话有时会不同于模拟器。

因此在将您的应用程序呈交给“Symbian认证签名”进行测试之前，务必确保已经在实际电话设备上测试了您的程序。

　　4、内存堆栈空间有限!

应尽可能将对象放到内存堆中，而不要放到栈里。

KERN-EXEC3异常（panic）发生的主要原因之一就是栈的破坏/溢出。

　　5、应用程序发生异常（panic）表明您的代码中一定有错误。

以下是一些主要的、常见的错误：

　　Ⅰ：

忘记将非对象成员、被分配到堆的变量加到CleanupStack上。

　　Ⅱ：

将成员变量放到CleanupStack上—这一点要千万避免（在析构函数中将这些变量删除就可以了）。

　　Ⅲ：

“重复删除”--例如，没有正确的从CleanupStack上Pop（）出已经被销毁的对象，造成CleanupStack以后试图再次删除它。

或者使用过一个对象之后将其删除但忘记将其值设成NULL，从而在析构函数里又试图删除一次。

　　Ⅳ：

用可能不存在于您的析构函数中的变量调用函数。

例如，以下代码可能导致异常因为有可能您在分配内存之前您的对象已经被销毁，或者在应用程序的另一处已经删除了该内存，这样iSomeServer就会处于NULL：

　　CMyClass:

~CMyClass（）

　　{

　　iSomeServer->

Close（）;

　　deleteiSomeServer;

　　}

　　应该如下编写该代码：

　　If（iSomeServer）

　　Ⅴ：

在NULL指针上调用函数。

　　Ⅵ：

函数调用另一个函数，而其使用的变量已经超出范畴，例如：

　　把一个栈变量传送到一个异步函数的回调（callback）里。

　　6、在系统资源不够的情况下，得体的处理失效情况是非常重要的。

最受限制的资源通常是系统RAM，因此您需要注意正确的处理内存不足的情况。

采用“两端构造方法”和如下所述的CleanupStack机制，对这种防御性编程来说是必不可少和极其重要的。

　　7、对带“R”字头、具备Close（）方法的类，总是使用CleanupClosePushL（）。

这将确保当Leave事件发生时，它们会被恰当的清除。

例如：

　　RFilefile;

　　User:

LeaveIfError（file.Open（…））;

　　CleanupClosePushL（file）;

　　…

　　CleanupStack:

PopAndDestroy（&

file）;

　　对用Release（）或Destroy（）的“R”类，亦可使用CleanupDeletePushL（）及CleanupRelasePushL（）来取代Close（）。

　　8、另外，请记住CleanupStack机制是可扩展的，面对所有Leave事件，都可以用它来有效的清除任何对象。

即使您需要处理的是较复杂的情况，也不应该忽略采用正规的清理机制。

欲进一步了解TCleanupItem,请参阅SymbianOSLibrary文档。

　　9、倘若您意图对HBufC变量重新分配资源，在清除它们之后，总是将其设为NULL。

由于HBufC的资源分配或其再分配可能会导致Leave事件的发生，从而可能会出现析构函数试图删除已经不存在的HBufC变量的情况。

当然，对于任何由堆分配资源的变量而言都应如此，对HBufC变量采取此做法更是已经成为普遍的使用模式。

　　10、当必须采用自己的TRAP时，请忽略所有的报错。

常见的编码错误是：

　　TRAPD（err,DoSomethingL（））;

　　If（err==KErrNone||err==KErrNotFound）

　　//Dosomethingelse

　　这意味着其他错误码都被忽略。

然而，倘若您非用上述模式不可，应采用Leave机制来处理其他错误：

　　If（err==KErrNone||err==KerrNotFound）

　　else

Leave（err）;

　　⒒、不要延迟将对象PushL（）到CleanupStack上。

所有新创建的对象（成员变量除外）应被立即压入该堆栈。

例如，下面的做法是错的：

　　VoiddoExampleL（）

　　CSomeObject*myObject1=new（ELeave）CSomeObject;

　　CSomeObject*myObject2=new（ELeave）CSomeObject;

　　//Dosomethingherewiththevariables

PushL（myObject1）;

PushL（myObject2）;

　　//Dosomethingmorewiththevariables

PopAndDestroy

（2）;

　　//myObject2,myObject1

　　因为myObject2的创建可能失败，造成myObject1”悬”在那里不能被清理。

应该这样来实现：

　　12、注意，那些名称有大写字母C结尾的函数（例如NewLC（））会自动把其对象置于CleanupStack。

您不应该自己来将这些对象压入CleanupStack,否则该对象会入栈两次。

当您创建非成员变量并为其分配内存时，这些由C结尾的函数很有用。

　　13、“两端构造方法”是SymbianOS内存管理的关键部分。

基本原则是SymbianOS中的构造函数或析构函数永远不应该发生Leave。

倘若一个C++构造函数Leave，构造过程未完成的对象得不到清理，因为还没有生成指针指向该对象。

为此，SymbianOS中的构造函数仅将该对象实例化，而后调用该对象的ConstructL（）函数，在其中将成员数据实例化。

一旦ConstructL（）发生Leave，标准的析构函数将被调用来清除所有至此已被成功分配的成员变量。

在您的编码中照用这一设计模式来防止内存泄漏，至为关键。

当您写每一行代码时，都应该问自己：

“这一行代码能否发生Leave?

”假如回答为“是”，则应考虑“是否所有资源都将被释放?

”。

　　14、编码中请勿使用_L（）宏---而应使用_LIT（）。

_L（）自SymbianOSV5起已是“不推荐使用”（deprecated），它的问题在于它将调用TPtrC（constTText*）构造函数，该构造函数会调用strlen（）函数来计算该字串的长度。

虽然这不会带来额外的RAM开销，却会在运行时占用更多CPU周期。

相反，宏_LIT（）直接创建了一个在编译时就全部实例化的对象，节省了构造TPtrC的CPU开销。

当然，您首先应该考虑的是否应该使用硬编码的字符串常量，因为当您将来地方化（localize）您的程序时，这种常量类型的描述符（descriptor）可能需要重新编码（我觉得作者这里写的有问题，_LIT（）及_L（）定义的是常量字符串，并非描述符，它不能够用描述符的一些通用的方法，只有调用_LIT（）和_L（）重载的（）运算符才会变成constTDesC&

类型的描述符，并使TDesC的一些通用方法可用---孙东风注）。

　　15、当在函数参数中使用描述符（descriptor）时，应缺省使用基类。

在大多数情况下，以constTDesC&

形式来传递描述符。

对可修改的描述符，则应使用TDes&

。

　　16、当在函数中传递或返回对象时，应确保如果您拥有该对象的所有权，您应负责将其清除!

Symbian采取的约定是：

函数中的指针表示所有权转移到调用者，而使用引用则表示被传递对象的所有权仍属于原所有者。

　　17、ActiveObjects是SymbianOS的重要特性之一。

请仔细研究SDK文档、SymbianDeveloperNetWork白皮书，以充分理解其工作原理。

下面有一些有用的窍门：

在RunL（）内无需使用TRAP（）。

ActiveScheduler本身会TRAP函数RunL（）并在其发Leave时调用CActive:

RunError（）。

为此，您应实现自己的RunError（）函数来处理从RunL（）的Leave事件。

保证RunL（）操作尽可能简短。

长时间运行的RunL（）将阻塞其他ActiveObjects。

总是实现DoCancel（）函数，总是在AO析构函数中调用Cancel（）。

　　18、您应尽可能利用ActiveObject框架机制。

对于使用电池供电的设备，在一个循环中紧密不断地进行轮流检测（polling）是极其不适当的，将带来大量耗电。

写游戏时，对此尤需特别注意，详情参阅SymbianDeveloperNetwork网站的技术文档：

　　.../XenGames_paper.pdf

　　19、ViewSrv11异常对于繁忙运行的程序（例如游戏）是一个潜在的问题。

当您的，或者其他任何程序中的ViewSrvactiveobject不能及时响应ViewServer时就会导致此种异常。

典型的最长回应时间是10-20秒。

FAQ-0900有详细解释，FAQ-0920有针对如何避免此类问题的实用技巧。

二者均可从OSFAQ数据库获取。

　　20、您无需使用HBufC:

Des（）来进入一个HBufC对象。

只需采用*操作符来为HBufC对象解除引用（dereference）。

这对于向某个接受TDesC&

（上文的推荐做法）的函数传递HBufC参数时尤其有用。

　　21、.当使用标准的程序.INI文件的功能时（即在您的应用UI类中使用Application（）->

OpenIniFileLC（）;

API时），确保将版本号信息写入流（stream）中。

这样使您能够在未来新版本的程序中建立新的流，意味着即使某个最终用户将来安装您的软件的新版本时，不会因为在旧的.INI文件中找不到正确配置或流时发生异常。

　　22.、在您的程序中实现框架类（frameworkclass）时要小心。

应该始终从所提供的平台相关的框架类中继承。

例如，对UIQ而言，不要从CQikAppUi继承。

所有的应用基类（CQikAppUi、CQikApplication、CQikDocument）添加的功能支持更广的框架范围来保证应用程序正确运行。

本文来自CSDN博客，转载请标明出处：