2.5 其他硬件限制
- 处理器的能力不是很强，图形处理器很少
- 算术处理器也少，最好不要用浮点运算，用整型代替。相似的，避免使用64位的整数。因为他们都要影响run-time的性能和内存消耗的开销
- 一些设备上只有有限的屏幕解析度，大小和色深
- 只能手机上的键盘的数目也是有限的

2.6 应用程序开发：开发工具和过程
N/A

3. S60 应用程序框架
S60的UI框架（"Avkon"）扩展了Symbian OS的应用程序框架（“Uikon"）。典型的有如下几个部分组成：Application，Application Document， Application UI， Application View。

通常游戏程序还会有个game engine。通常的建议是要把game的逻辑和UI显示相分离，以便于从用，但是他们之间还是存在一定的耦合，因为UI要接受和相应用户的输入。

对于有多个screen的游戏有两种方法来做，第一就是用多个view来显示，第二是用一个view。后者如果game有很多的screen的话就会要设计一个复杂的状态机。通常我们会把游戏划分成多个逻辑上的view。

4. The Game Loop and Use of Timers
4.1 The Game Loop
几乎每个游戏都有个game loop，因为这是游戏代码最重要的一个部分。

典型的一个游戏循环就是一个事件处理方法，其周期性的被应用程序主view的定时器调用。事件处理句柄调用游戏engine更新游戏的状态和显示。

4.2 Timers
在SymbianOS中，最缺乏的几项服务之一就是timing services，这里OS并不支持底层的timer interrupts，它只提供一个核心端的时间发生器，其最大的发生频率是64Hz，模拟器上，最大的tick rate是10Hz，这使得程序的测试更加烦琐。系统中的最大tick rate可以通过访问UserHal::TickPeriod来获得。

Symbian OS v9.1之后的版本是real-time的，所以能提供一个更好的定时器。虽然标准的定时器还是1/64秒，但是你可以通过 User::AfterHighRes和RTimer::HighRes来获得更好的定时，其提供了1ms的定时。

Symbian OS提供了三个定时器概念，定义在e32hal.h中，可以参见下面的图表：


核心端的timer可以通过访问RTimer来获得，它是一个指向系统端服务的句柄。它提供了一个简单的API来发送三个不同的时间事件：在一段给定时间后的事件，在一个给定时间上的事件以及an event which completes at a given fraction of a second.为了更方便的使用RTimer，Symbian OS提供了一个抽象的活动对象：CTimer，它封装了RTimer的使用，在上图中也能看出，CTimer中必定有RTimer的存在。

用户只需要从CTimer派生类即可，另外还需要重载RunL函数，它在一个请求被完成时进行调用。因为是非强占性的，所以在时间片上可能有延时，造成不准确，我们应该尽量减少RunL中代码运行的时间。此外我们还应该把处理时间片的活动对象的优先级提到最高，以防止其他对象切入。

在 SymbianOS中，提供了两个CTimer的派生类：CPeriodic和CHeartbeat，CPeriodic中，事件的间隔在 microseconds中，而CHeartbeat中，间隔在一秒的片段中，这定义在TTimerLockSpec枚举中。最小的时间片段是1/12 秒，CHeartbeat提供了一个方法来与系统时间同步，当有timer event遗漏时，它的回调函数Synchronize就会被调用，从而给应用程序一个途径采取修正措施。

定时器的优先级和AS的负荷影响定时器的准确性。不要在定时器事件之间把AS拖入到一个长期运行的计算中去；定时器中活动对象的优先级应该低点并且间隔要切合实际一点（比如：不要是1ms）。所有的这些都必须要考虑到，否则会产生ViewSrv11错误，当一个活动对象事件处理句柄霸占了线程AS循环和应用程序的ViewSrv致使AO不能及时的相应。