ExpensesApp早先的版本使用了一个向量来存储ExpenseInfo的实例，这些实例代表着存储在应用程序数据仓里的记录。尽管作为可管理的集合，这是一个相当简单的选择，但是向量非常耗资源。这在一个内存有限的环境下，例如移动设备上，不是件好事。

正如你可以从Listing A上的ExpenseInfo.LoadExpenses看到的那样，Expreses MIDlet现在在内存中使用一个对象数组来存储数据库记录。有了这个改变，我就能够在ExpensesApp每次典型的运行中（启动应用程序，再加入一个新的开销）减少将近10K的内存占用。这听起来好像不多，但是当你和这样一个平台，它是以几十千字节作为总的可用内存的衡量尺度，打交道的时候，这就是个不小的数目了。而且，我还重写了重复使用双流阅读器对象的方法，而没有在循环迭代的过程中重建它们，这和以前不一样。

原来的处理开销的应用程序对资源的共享做得也不好。它不响应pauseApp事件，这是在用户切到另一个应用程序时要作出的响应――清空内存。这是糟糕的网络移动设备中最差的一种。通过释放被expenseItems数组占用的内存，这个应用程序现在能够更好地处理pauseApp。这个改变也迫使了其他方面的变化：如果有必要，startApp事件处理器也必须要重建数组（Listing B）。先前的文章可以知道：startApp不仅会在MIDlet初始启动时进行，还会在从暂停转换到活动状态时进行。如果有必要的话，我们可以通过删除pauseApp里的用户接口对象来释放一些额外的内存。

解决同步的问题

先前版本的ExpensesApp除了有内存使用的问题外，还有一些数据同步的问题。你可以从上次的文章里回忆起这些，但是我已经在下面把它们列出来了，毕竟离现在已经有些日子了：

使用RMS的记录变更通知系统就可以很容易地解决这些数据同步的问题，这个通知系统是集成在RecordListener接口中的。让我们来仔细看看这个接口。

通过RecondListener来发布记录变更通知

现在Expenses主类实现了一个新的接口，RecordListener。这个接口提供了应用程序记录仓变化的通知。RecondListener接口有三个方法，这三个方法都接受代表记录仓和受影响记录的ID号的自变量。

将一个正在执行的类传递到RecordStore的方法addRecordListener，你就能建立一个RecordListener。正如你所预料到的，多个RecordListeners可以被加入到单个的RecordStore中去。

ExpensesApp在本质上使用同样的方法处理这些侦听事件中的每一件，你可以在Listing C看到。添加和删除事件处理程序清除lsMain列表的内容，然后重建expenseItems数组，最后从暂存区里取出数据重建lsMain，以反映出变化。变更事件处理器则相反，只是简单的重建expenseItems数组，因为一条更新过的记录不会影响显示在lsMain里的项目。同时因为我并不关心事件发生之外的其他任何事，所以我就不用对每次事件所收到的RecordStore和ID号自变量做任何事。

除了能为保持MIDlet和本地数据仓同步提供一个简单的方法外，RecordListener API在处理能够独立地从远程数据库完成更新的应用程序时，就便显出了自己的作用。我将在探索J2ME系列的最后一部分里向你展示，这是如何通过普通连接网络完成的。