推薦：怎樣使用XML實現多渠道接入網站的構架
一.背景在現在的網站中，接入的渠道是越來越多了，技術也是越來越先進，WAP, SMS,EMAIL, 傳統的Web, Socket等等，如果連數據庫和LDAP也算接入的話，那在設計之中需要擴展的空間要做到很好 很好

序言

本文所提及的VTD-XML并非本文作者原創，作者只是對它進行介紹。

問題

通常當我們提起XML的使用時，最頭痛的部分便是XML的verbosity與XML的解析速度，當需要處理大XML文件時這個問題便變得格外嚴重。我在這里提及的，便是如何優化XML處理速度的話題。

當我們選擇處理XML文件的時候，我們大致上有兩種選擇：

DOM，這是W3C的標準模型，它將XML的結構信息以樹形的方式構建，提供了遍歷這顆樹的接口與方法。
SAX，一種低級的parser，逐元素的向前只讀處理，不含有結構信息。
以上兩種選擇都各有利弊，但是都不是特別好的解決方案，它們的優缺點如下：

DOM

優點：易用性強，因為所有的XML結構信息都存在于內存中，并且遍歷簡單，支持XPath。

缺點：Parsing速度太慢，內存占用過高（原文件的5x~10x），對于大文件來說幾乎不可能使用。

SAX

優點：Parsing速度快，內存占用不與XML的大小相聯系（可以做到XML漲內存不漲）。

缺點：易用性差，因為沒有結構信息，并且無法遍歷，不支持XPath。如果需要結構的話只能讀一點構造一點，這樣的可維護性特別的差。
我們可以看出，基本上DOM與SAX是正好相反的兩個極端，但是任何一個都不能很好的滿足我們的大部分要求，我們需要找出另外一種處理方法來。注意XML的效率問題并不是XML本身的問題，而是處理XML的Parser的問題，就像我們在上面看到的兩種方法有不同的效率權衡一樣。

思考

我們很喜歡類似DOM的使用方法，因為我們可以遍歷，這意味著可以支持XPath，大大增強了易用性，但是DOM的效率很低。就像我們已經知道，效率問題出在處理機制上。那么，DOM到底有哪些方面影響了它的效率呢？下面讓我們來做一個全面的解剖：

在當今大多數基于虛擬機（托管，或任何類似機制）技術的平臺下，對象的創建銷毀是一個耗時的作業（這里值得主要是Garbage Collection的耗時），DOM機制中所運用的大量的對象創建銷毀無疑是影響其效率的原因之一（會引發過多的Garbage Collection）。

每個對象都會額外有32bits用來存儲它的內存地址，當像DOM一樣擁有大量對象的時候這個額外開支也是不小的。

引起以上兩個問題的最主要的效率問題在于，DOM與SAX都是extractive parsing模式，這種解析模式注定了DOM與SAX都需要大量的創建（銷毀）對象，引起效率問題。所謂的extractive parsing就是說在解析XML時，DOM或SAX會提取一部分原文件（一般來說是一個字符串），然后在內存中進行解析構建（輸出自然就是一個或一些對象了）。拿DOM這個例子來說，DOM會將每一個element, attribute, processing-instruction, comment等等都解析成對象并給與結構，這就是所謂的extractive parsing。

由extractive的問題帶來的另一個問題便是更新效率，在DOM中（SAX因為不支持更新所以根本不提它），每一次需要做改動時，我們要做的就是將對象的信息再解析回XML的字符串，注意這個解析是個完整的解析，也就是說，原文件并沒有被利用，而是直接將DOM模型重新完整解析成XML字符串。換句話講，也就是DOM并不支持Incremental Update（增量更新）。

另一個很可能不被注意到的“小”問題便是XML的編碼，無論是何種解析方法都需要能夠處理XML的編碼，也就是說，在讀取的時候解碼，在寫入的時候編碼。DOM的另一個效率問題便是當我對于一個大XML只想做很小的一塊兒修改的時候它也必須首先將整個文件進行解碼，然后構建結構。無形中又是一個開銷。

讓我們來總結一下問題，簡單的講DOM的效率問題主要出在它的extractive parsing模式上（SAX也是一樣，有同樣的問題），由此引發了一系列相關問題，如果可以擊破這些效率瓶頸的話那么可以想象XML的處理效率將進一步的得到提高。如果XML的易用性與處理效率得到飛躍性的提高的話，那么XML的應用范圍，應用模式將得到更一步的升華，或許由此可以產生出許許多多精彩的以前連想都沒有想過的基于XML的產品來。

分享：解讀從實際應用中了解WML
學習自然語言的最好方法就是溶入相應的語言環境在交流中學習，學習一種編程語言的最好方法就是看例程。為了幫助大家建立wml應用的第一印象，所以請大家先看第一個例子: