分析性能瓶颈

可以使用 Execution Statistics 视图来分析程序中各个方法的运行时间。打开该视图的方式是，数据收集进程上点右键，选择以 Execution Statistics 方式打开。

在该视图中，显示了所有调用到的方法及其运行时间。运行时间有多种表示方法。常用到的是“cumulative time”。该时间表示了这个方法调用的总耗时，其中包含其调用其他方法的时间。

我们 MyShop 插件的运行结果如上图所示。可以看到，getProductDir 方法耗时长。而该方法的作用是打开一个文件选择对话框，等待用户的选择，等选择完成后再关闭对话框。因此其时中包含了等待用户选择的部分。这当然应该在 我们的性能分析中排除在外。除此之外耗费时间长的是 parseContent 方法。该方法用于从包含产品信息的 XML 文件中获取真正的产品信息数据。双击该方法查看该方法调用的详细数据。

需要注意的是，在下面的 Selected method invokes 表格中，显示结果是通过我们设置的过滤器过滤后的结果。在上面的结果中，我们可以看到，我们自己的方法调用花费的时间都很小。由此可见，消耗时间更多的地方是在 XML 解析的方法中。

解决性能问题并验证修改

通过对上面运行数据的分析，我们的结论是，对性能影响大的是 XML 的解析。而根据得到的数据，24 条商品数据的获取已经需要 0.5s 的时间，而在正常使用中的商品数量则会达到根本不可忍受的程度。通过对代码的分析，我们得知目前的 XML 解析使用的是 DOM 的分析方

式，而在我们的应用中只有 XML 的读操作而没有写操作。在这种方式下，SAX 的解析方式效率要更高。因此我们可以将 XML 解析部分的代码改为 SAX 方式。

    创建 ProductSAXParser 类

创建该类实现我们的 ProductParser 接口并继承自 DefaultHandler 接口完成大部分的分析逻辑。

    实现 Parser 方法

实现 ProductParser 接口和 DefaultHandler 定义的方法完成解析逻辑。

    更改 XML 解析方式

在父类 ShopView 中更改调用的解析器为我们新创建的 SAX 实现。

具体的代码可参考本文附件所带的示例代码。

修改好代码并按照上面的步骤从新运行数据分析，可以看到，现在的性能已经大为改观：

可以看到，XML 解析方法的运行时间已经由 0.5s 左右缩短到了大约 0.057s。