分析性能瓶頸

可以使用 Execution Statistics 視圖來分析程序中各個方法的運行時間。打開該視圖的方式是，數(shù)據(jù)收集進程上點右鍵，選擇以 Execution Statistics 方式打開。

在該視圖中，顯示了所有調(diào)用到的方法及其運行時間。運行時間有多種表示方法。常用到的是“cumulative time”。該時間表示了這個方法調(diào)用的總耗時，其中包含其調(diào)用其他方法的時間。

我們 MyShop 插件的運行結(jié)果如上圖所示�？梢钥吹�，getProductDir 方法耗時長。而該方法的作用是打開一個文件選擇對話框，等待用戶的選擇，等選擇完成后再關(guān)閉對話框。因此其時中包含了等待用戶選擇的部分。這當然應該在 我們的性能分析中排除在外。除此之外耗費時間長的是 parseContent 方法。該方法用于從包含產(chǎn)品信息的 XML 文件中獲取真正的產(chǎn)品信息數(shù)據(jù)。雙擊該方法查看該方法調(diào)用的詳細數(shù)據(jù)。

需要注意的是，在下面的 Selected method invokes 表格中，顯示結(jié)果是通過我們設置的過濾器過濾后的結(jié)果。在上面的結(jié)果中，我們可以看到，我們自己的方法調(diào)用花費的時間都很小。由此可見，消耗時間更多的地方是在 XML 解析的方法中。

解決性能問題并驗證修改

通過對上面運行數(shù)據(jù)的分析，我們的結(jié)論是，對性能影響大的是 XML 的解析。而根據(jù)得到的數(shù)據(jù)，24 條商品數(shù)據(jù)的獲取已經(jīng)需要 0.5s 的時間，而在正常使用中的商品數(shù)量則會達到根本不可忍受的程度。通過對代碼的分析，我們得知目前的 XML 解析使用的是 DOM 的分析方

式，而在我們的應用中只有 XML 的讀操作而沒有寫操作。在這種方式下，SAX 的解析方式效率要更高。因此我們可以將 XML 解析部分的代碼改為 SAX 方式。

    創(chuàng)建 ProductSAXParser 類

創(chuàng)建該類實現(xiàn)我們的 ProductParser 接口并繼承自 DefaultHandler 接口完成大部分的分析邏輯。

    實現(xiàn) Parser 方法

實現(xiàn) ProductParser 接口和 DefaultHandler 定義的方法完成解析邏輯。

    更改 XML 解析方式

在父類 ShopView 中更改調(diào)用的解析器為我們新創(chuàng)建的 SAX 實現(xiàn)。

具體的代碼可參考本文附件所帶的示例代碼。

修改好代碼并按照上面的步驟從新運行數(shù)據(jù)分析，可以看到，現(xiàn)在的性能已經(jīng)大為改觀：

可以看到，XML 解析方法的運行時間已經(jīng)由 0.5s 左右縮短到了大約 0.057s。