Symbian Skill

 Symbian Skill
分类： Symbian 2008-12-10 11:28 396人阅读 评论(0) 收藏 举报
编码诀窍 

以下是您在编写代码时应该记住的一些一般诀窍。 

1. 确保您的应用程序能够对系统关机事件做出响应。在您的AppUi::HandleCommandL()方法中，必须要对EEikCmdExit（以及任何特定平台相关的事件，例如Series 60 上的EAknSoftkeyBack）做出响应。 

2. 要对外来系统事件做出响应。请牢记，您的应用程序是在一个多任务电话系统上运行，您需要将注意力集中于刚获得的/丢失的事件上，以确保当用户获得一个高优 先级的通知时您能够做出正确响应。例如，正打进来的电话会干扰您的应用程序的运行，这时应确保您已保存了系统状态和数据（即：您需要对标准的“背景”事件 采取适当的行动——请参阅SDK）。一般说来，系统框架会处理这个问题，您不需要采取任何特殊行动——但一定要确保您没有妨碍系统框架的正常操作。 

3. 内存处理是Symbian OS 需要考虑的一个重要课题。在这一点上，应注意电话有时会不同于模拟器。因此在将您的应用程序呈交给“Symbian 认证签名”进行测试之前，务必确保已在实际电话设备上测试了您的程序。 

4. 内存堆栈空间有限！应尽可能将对象放到内存堆中，而不要放到栈里。KERN-EXEC 3 异常（panic）发生的主要原因之一就是栈的破坏/溢出。 

5. 应用程序发生异常(panic) 表明您的代码中一定有错误。以下是一些主要、常见的错误： 

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

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

• ‘重复删除’——例如，没有正确的从CleanupStack上Pop()出已经被销毁的对象，造成CleanupStack以后试图再次删除它。或者使用过一个对象之后将其删除但忘记将其值设成NULL，从而在析构函数又试图删除一次。 

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

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

CMyClass::~CMyClass() 

{ 

iSomeServer->Close(); 

delete iSomeServer; 

} 

应该如下编写代码: 

CMyClass::~CMyClass() 

{ 

if (iSomeServer) 

{ 

iSomeServer->Close(); 

delete iSomeServer; 

} 

} 

• 在NULL 指针上调用函数。 

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

例如：把一个栈变量传送到一个异步函数的回调(callback) 里。在系统资源不够的情况下，得体的处理失效情况是非常重要的。最受限制的资源通常是系统RAM，因此您需要注意正确的处理内存不足的情况。采用‘两段构 造方法’和如下所述的CleanupStack 机制，对这种防御性编程来说是必不可少和极其重要的。 

7. 对带“R”字头、具备Close()方法的类，总是使用CleanupClosePushL()。这将确保当Leave 事件发生时，它们会被恰当的清除。例如： 

RFile file; 

User::LeaveIfError(file.Open(…)); 

CleanupClosePushL(file); 

… 

CleanupStack::PopAndDestroy(&file); 

对用Release()或Destroy()的‘R’ 类，亦可使用 

CleanupDeletePushL()及 

CleanupReleasePushL()来取代Close()。 

8. 另外，请记住CleanupStack 机制是可扩展的，面对所有Leave 事件，都可以用它来有效的清除任何对象。即使您需要处理的是较复杂的情况，也不应该忽略采用正规的清理机制。欲进一步了解TCleanupItem，请参 阅Symbian OS Library 文档。 

9. 倘若您意图对HBufC 变量重新分配资源，在清除它们之后，总是将其设为NULL。由于HBufC 的资源分配或其再分配可能会导致Leave 事件的发生，从而可能会出现析构函数试图删除已经不存在的HBufC变量的情况。当然，对于任何由堆分配资源的变量而言都应如此，对HBufC 变量采取此做法更是已经成为普遍的使用模式。 

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

常见的编码错误是： 

TRAPD(err, DoSomethingL()); 

if (err == KErrNone || err ==KErrNotFound) 

{ 

// Do something else 

} 

这意味着其他错误码都被忽略。然而，倘若您非用上述模式不可，应采用Leave 机制来处理其他错误： 

TRAPD(err, DoSomethingL()); 

if (err == KErrNone || err ==KErrNotFound) 

{ 

// Do something else 

} 

else 

User::Leave(err); 

11. 不要延误将对象PushL()到CleanupStack 上。所有新创建的对象（成员变量除外）应被立即压入该堆 

栈。例如，下面的作法是错的： 

void doExampleL() 

{ 

CSomeObject* myObject1=new (ELeave)CSomeObject; 

CSomeObject* myObject2=new (ELeave)CSomeObject;… 

// Do something here with thevariables 

CleanupStack::PushL(myObject1); 

CleanupStack::PushL(myObject2); 

// Do something more with the variables… 

CleanupStack::PopAndDestroy(2); 

// myObject2, myObject1 

} 

因为myObject2 的创建可能失败，造成myObject1“悬”在那里不能被清理。应该这样来实现： 

void doExampleL() 

{ 

CSomeObject* myObject1=new (ELeave)CSomeObject; 

CleanupStack::PushL(myObject1); 

CSomeObject* myObject2=new (ELeave)CSomeObject; 

CleanupStack::PushL(myObject2); 

… 

// Do something here with the variables… 

CleanupStack::PopAndDestroy(2); 

// myObject2, myObject1 

} 

12. 注意，那些名称有大写字母C 结尾的函数（例如NewLC()）会自动把其对象置于CleanupStack。您不应该自己来将这些对象压入CleanupStack，否则该对象会入栈两次。当您创建非成员变量并为其分配内存时，这些由C 结尾的函数很有用。 

13.“两段构造方法”是Symbian OS 内存管理的关键部分。基本原则是Symbian OS 中的构造函数或析构函数永远不应该发生Leave。倘若一个C++ 构造函数Leave，构造过程未完成的对象得不到清理，因为还没有生成指针指向该对象。为此，SymbianOS 中的构造函数仅将该对象实例化，而后调用该对象的ConstructL()函数，在其中将成员数据实例化。一旦ConstructL()发生Leave， 标准的析构函数将被调用来清除所有至此已被成功分配的成员变量。在您的编码中照用这一设计模式来防止内存泄漏，至为关键。当您写每一行代码时，都应该问自 己：“ 这一行代码能否发生Leave ？”假如回答为“是”，则应考虑“是否所有资源都将被释放？”。 

14. 编码中请勿使用_L()宏——而应使用_LIT()。_L()自Symbian OS v5 起已是‘不推荐使用’（deprecated），它的问题在于它将调用TPtrC(const TText*)构造函数，该构造函数会调用strlen()函数来计算该字串的长度。虽然这不会带来额外的RAM 开销，却会在运行时占用更多CPU 周期。相反，宏_LIT()直接创建了一个在编译时就全部实例化的对象，节省了构造TPtrC 的CPU 开销。当然，您首先应该考虑的是否应该使用硬编码的字符串常量，因为当您将来地方化(localize)您的程序时，这种常量类型的描述符 

(descriptor) 可能需要重新编码。 

15. 当在函数参数中使用描述符(descriptor) 时，应缺省使用基类。在大多数情况下，以const TDesC& 形 

式来传递描述符。对可修改的描述符，则应使用TDes&。 

16. 当在函数中传递或返回对象时，应确保如果您拥有该对象的所有权，您应负责将其清除！ Symbian 采取的约定是：函数中的指针表示所有权转移到调用者，而使用引用则表示被传递对象的所有权仍属于原所 

有者。 

17. Active Objects 是Symbian OS 的重要特性之一。请仔细研究SDK 文档、Symbian Developer Network 白皮书，以充分理解其工作原理。下面是一些有用的窍门： 

• 在RunL()内无需使用TRAP()。Active Scheduler本身会TRAP 函数RunL()并在其发生Leave 时调用CActive::RunError()。• 为此，您应实现自己的RunError()函数来处理从RunL()的Leave 事件。 

• 保证RunL()操作尽可能简短。长时间运行的RunL()将阻塞其他Active Objects。 

• 总是实现DoCancel()函数，总是在AO 析构函数中调用Cancel()。 

18. 您应尽可能利用Active Object 框架机制。对于使用电池供电的设备，在一个循环中紧密不断地进行轮流检测(polling) 是极其不适当的，将带来大量耗电。写游戏时，对此尤需特别注意，详情参阅Symbian 

Developer Network 网站的技术文档（www.symbian.com/developer/techlib/papers/porting_3D_games/XenGames_paper.pdf）。 

19. ViewSrv 11 异常对于繁忙运行的程序（例如游戏）是一个潜在的问题。当您的，或者其他任何程序中的ViewSrv active object 不能及时响应View Server 时就会导致此种异常。典型的最长回应时间是10-20 秒。FAQ-0900 有详细解释，FAQ-0920 有针对如何避免此类问题的实用技巧。二者均可从www3.symbian.com/faq.nsf 网页上的Symbian OSFAQ 数据库获取。 

20. 您无需使用HBufC::Des()来进入一个HBufC 对象。只需采用* 操作符来为HBufC 对象解除引用(dereference)。这对于向某个接受TDesC&（上文的推荐做法）的函数传递HBufC 参数时尤其有用。 

21. 当使用标准的程序.INI 文件的功能时，（即在您的应用UI 类中使用Application()->OpenIniFileLC();API 时），确保将版本号信息写入流(stream) 中。这样使您能够在未来新版本的程序中建立新的流，意味着即使某个最终用户将来安装您的软件的新版本时，不会因为在旧的.INI 文件中找不到正确配置或流时发生异常。 

22. 在您的程序中实现框架类(framework class) 时要小心。应该始终从所提供的平台相关的框架类中继承。例如，对UIQ 而言，不要从CEikAppUi 继承您的AppUi 类，而应从CQikAppUi 继承。所有的应用基类（CQikAppUi、CQikApplication、CQikDocument）添加的功能支持更广的框架范围来保证应用程序正 确运行。 

测试诀窍 

1. 最重要的测试诀窍是，在用模拟器时(emulator)，正确的退出您的程序，而不是仅仅简单地关闭整个模拟器。在调试模式中，在应用程序框架(applicationframework)的关闭函数前后有内存及句柄检测代码， 

当您退出应用程序时，此代码将被调用，从而可检测到是否有内存泄漏或遗留句柄（例如R 对象）发生。 

对UIQ 程序而言，为此目的习惯上在调试模式里提供一个Exit 菜单选项。 

2. 另外一个至关重要的诀窍是在发布您的程序之前确保在.PKG 文件中包含了正确的平台相关信息。相关平台相关信息字符串的详情请参照该平台的SDK。www3.symbian.com/faq.nsf 上的Symbian OS FAQ 数 

据库中的FAQ-0853 提供了有用的相关信息。 

3. 在写.PKG 文件时，也要确保恰当的使用了“!:/”语法。一般来说，您的应用程序应可从最终用户手机中的任何盘中安装、运行。仅有极少量的文件需要放置于C:/ 盘中（例如.INI 文件）。 

调试诀窍 

1. 总应先使用模拟器调试；大部分同时发生在模拟器与硬件上的问题，使用模拟器调试会容易得多。 

2. 在编写和调试新的控制类时，把iEikonEnv->WsSession().SetAutoFlush(ETrue)置于您的AppUi 的ConstructL()函数中。这意味着gc draw 指令会在模拟器中立即显示，而不是在下一次冲刷(flush)视窗服务器客户端缓冲时。编辑WSINI.INI 文件（/epoc32/release/winscw/udeb/system/data/），确保不存在关键字FLICKERFREEREDRAW。这 意味着您可以逐步运行draw 代码，并看到每行代码的效果。然而，应确保此行代码不留在发布的软件中，因为这会影响性能。 

3. 应定时对源文件运行LeaveScan 工具。该工具可以检测到所有可以Leave 的函数，并在其名称不以L 结尾时报错，并提醒源文件中潜在的缺陷或疏忽。在检查哪些代码应被允许Leave，并确保已正确处理此状况时，该工具非常有效。参见 www3.symbian.com/faq.nsf 上的Symbian OS FAQ 数据库里的FAQ-0291，下载该工具并进一步了解。 

4. 如果您的程序在正常关闭时因内存泄漏而发生异常，在MS Visual Studio 中可将泄漏的地址转换为CBase*类型，从而查看该泄漏对象的类型。 

5. 最近为对Symbian OS 开发者提供了新的功能：设备上调试（on-target debugging）。虽然不是所有的SDK及工具均已具备此功能，但大多数最近发布的SDK 及IDE 支持此功能。如可使用此功能，请在发布您的程序前使用它来检测任何潜在的手机硬件相关的缺陷。进一步的信息，请阅读SDK 及IDE 文档。 

6. 确保‘Just in Time’调试被启用： 

• 确保在文件“/epoc32/data/epoc.ini”里删除了宏“JustInTime 0” 

• 注册表值做如下设定： 

[HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/Windows NT/CurrentVersion/AeDebug]"UserDebuggerHotKey"=dword:00000000"Debugger"="/"C://apps//Metrowerks//bin//IDE.exe/" -p %ld -e %ld""Auto"="0"20 

7. 审阅%Temp%epocwind.out 所含的纠错讯息。 

8. 使用所有可用的开发工具，包括Lint、Leavesan、HookLogger、Panix、D_EXC 来检查内存泄漏及其他错误。这些工具及其他更多有用的工具可在SymbianDeveloper Network 下载（www.symbian.com/developer/downloads/tools.html）。 

9. FAQ-1344 教您如何诊断并调试违反平台安全(KErrPermissionDenied) 的故障，这有助于识别您的程序所缺少的权限(capability)。  --------------------编程问答-------------------- 总结得挺好,谢谢楼主

补充：移动开发 ,  Symbian