为受限环境编程

为台式机或服务器编写代码时，开发者一般不必刻意关注内存使用情况、堆栈深度或 CPU 负担。 但相对而言，此类资源在大多数 BREW™ 设备中都相当有限。 如果您不注意这些方面，您的应用程序或服务可能会崩溃或无法运行。

有若干一般性的技术，可能会有所帮助。 概述如下：

优化内存使用
尝试使用数据要求的最小内存单元并将小项目合并到较大的容器中。 例如，可以使用字中的单个位，而不是使用布尔型标记的单个 INT。 请记住对于不同的数据类型编译器所分配的空间量。 将小项目（如 CHAR）合并到一?

注意堆栈上的分配内容
避免递归，尽量保持较短的函数调用深度。 除了较小的标量类型外，最好在堆上分配内存，而不是在堆栈上声明变量。

使用应用程序数据结构
如果您有几个声明了缓冲区的函数，请考虑使用应用程序数据结构中的缓冲区。 （通过分析调用序列，可以确定所需的最小缓冲区数。） 使用应用程序数据结构，可以从一开始分配内存。这样可以通过删除多余的分配序列和错误检查而简化代码。

不要使用紧密循环
运行 RTOS 的大多数设备使用监视器来检查线程或进程的运行状况，即如果进程处于活动状态且情况良好，则必须定期向监视器汇报情况，表示它仍处于良好状态。 如果进程或线程不向监视器汇报情况，则监视器会认为进程或线程出现了不良情况并会采取行动。

REX OS 有类似功能。 如果 BREW 应用程序占用太多 CPU，并且不作让步以便电话上的另一任务得以执行，则电话会重置。

不要使用数据的繁忙循环和轮询，这一点十分重要。 例如，BREW 应用程序中的 while (1) {} 会引起电话重置。 始终使用事件驱动技术。 因为数据服务的优先级比 BREW 应用程序低（以 UI 优先级运行）轮询数据会阻碍数据传输。 一般说来，您的应用程序应该避免不向主事件循环返回执行流的循环（HandleEvent 函数）。 此时，如果没有未完成事件，则 BREW 任务应该让位于另一等待调度的任务。

始终检查确保内存分配成功
您必须始终检查 MALLOC 函数或任何返回指针的函数的返回值。 因为在电话中比在模拟器中执行时更可能耗尽内存，务必检查返回 null 的指针。

• ·微软欲起诉谷歌Chrome浏览器垄断
• ·精选ERP以技术为纲
• ·技术答疑：AC.NET标准会计软件--《会稽山》单机专业版[图]
• ·AC.NET标准会计软件--《会稽山》下载安装与操作流程
• ·敏捷开发和高级别CMMI

• ·Siemens PLM Software 技术技巧（12）[组图]
• ·Siemens PLM Software 技术技巧（11）[组图]
• ·用ANSYS计算变压器箱体涡流，可以加阻抗边界条件吗
• ·企业为什么要实施易拓软件
• ·网络管理系统的进步[图]