在这个系列的前一篇文章里，我们在开发样本应用程序ExpensesApp时，已经介绍了j2me的用户界面（UI）控制，持续存储以及记录排序API。在本文中，我们将使用记录改变通知API，改进一下ExpensesApp，使它减少对内存的需求，纠正一些数据错误。下载最新的ExpensesApp源代码之后，我们就可以开始了。
ExpensesApp早先的版本使用了一个向量来存储ExpenseInfo的实例，这些实例代表着存储在应用程序数据仓里的记录。尽管作为可管理的集合，这是一个相当简单的选择，但是向量非常耗资源。这在一个内存有限的环境下，例如移动设备上，不是件好事。
正如你可以从Listing A上的ExpenseInfo.LoadExpenses看到的那样，Expreses MIDlet现在在内存中使用一个对象数组来存储数据库记录。有了这个改变，我就能够在ExpensesApp每次典型的运行中（启动应用程序，再加入一个新的开销）减少将近10K的内存占用。这听起来好像不多，但是当你和这样一个平台，它是以几十千字节作为总的可用内存的衡量尺度，打交道的时候，这就是个不小的数目了。而且，我还重写了重复使用双流阅读器对象的方法，而没有在循环迭代的过程中重建它们，这和以前不一样。
原来的处理开销的应用程序对资源的共享做得也不好。它不响应pauseApp事件，这是在用户切到另一个应用程序时要作出的响应――清空内存。这是糟糕的网络移动设备中最差的一种。通过释放被expenseItems数组占用的内存，这个应用程序现在能够更好地处理pauseApp。这个改变也迫使了其他方面的变化：如果有必要，startApp事件处理器也必须要重建数组（Listing B）。先前的文章可以知道：startApp不仅会在MIDlet初始启动时进行，还会在从暂停转换到活动状态时进行。如果有必要的话，我们可以通过删除pauseApp里的用户接口对象来释放一些额外的内存。
