在iOS工程中如何选择最佳的XML解析器

在iOS开发中解析XML有多种选择。iOS就自带了两个不同的库可供选择，并且还有许多受欢迎的第三方库可用，例如TBXML, TouchXML, KissXML, TinyXML, 和 GDataXML. 面对如此多的XML解析器，开发者如何选择呢？

最近我一直在考虑这些解析器，最终，对苹果提供的XMLPerformance实例进行了一下扩展，让其能够使用上面提到的各个库，以了解它们的工作情况，并对比它们之间的性能。在此，我就分享一下我的收获，希望对你有所帮助。

本文中，我将对上述iOS中比较流行的库的功能和性能进行详细的比较，并介绍在解析XML时，如何在这些解析器中做出选择，我也会给出一个示例工程来演示如何使用上面提到的每个库来读取XML数据。

对XMLPerformance 程序进行了扩展以对第三方库进行比较

SAX vs. DOM

在开始之前，我先来介绍一下XML解析器之间的重要区别: 是SAX还是DOM解析器。

• SAX解析器是在解析XML树的过程中，你的代码会收到相关解析的通知，你负责跟踪解析的状态，并跟踪你希望构造的任意对象。
• DOM解析器则是读取整个xml document，并在内存中构建一份相关数据，你可以在内存中查找不同的elements。并且可以使用XPath来查询指定的内容。

下面，就来讨论一下各个库吧！

iOS中最受欢迎的XML解析器

根据我的调查，下面是iOS中比较受欢迎的一些XML解析器，每个解析器我都做了简短的介绍：

• NSXMLParser 是iOS SDK默认包含的一个SAX解析器。它是用Objective-C写的，使用起来非常简单，不过针对DOM则没那么简单了。
• libxml2 是一个开源的库，iOS SDK中也默认包含了该库。由于它是基于C的API，所以在使用上要比NSXML复杂一点。该库支持DOM 和SAX 两种解析处理。libxml2 对SAX 的处理非常出色，它有一个独特的功能，就是可以边读数据边解析。例如，你可以从网络中读取一个很大的XML文档，在数据下载的过程中，你可以将读取到的数据显示给用户，而不用等到数据全部下载完毕。
• TBXML 是一个轻量级的DOM XML解析器，它的目标是消耗最少的资源，以最快的速度来解析XML。为了节约时间，该库不做验证处理，不支持XPath，并且是只读的——也就是通过解析器，你只能读取XML，不能对XML进行修改。
• TouchXML 是一个NSXML风格的DOM XML解析器。跟TBXML一样，该解析器也是只读的，不过该解析器是支持XPath的
• KissXML 是另外一个NSSXML风格的DOM XML解析器，实际上该解析器是基于TouchXML的。他与TouchXML最大的不同点就是KissXML 支持XML的编辑和写操作。 
• TinyXML 是一个小型的基于C的DOM XML解析器，它只有4个c文件和2个头文件。该解析器支持XML的读写操作，但是本身不支持XPath功能。不过，可以通过TinyXpath库让其支持XPath。
• GDataXML 同样是另外一个NSSXML风格的DOM XML解析器， 是Google开发的Objective-C客户端库的一部分。该解析器由一个M文件和一个头文件组成，它支持XML文档的读写，以及XPath查询。

下面我们开始比较这些库！

XML解析器性能比较程序

苹果提供的示例程序XMLPerformance是对NSXML和libxml2 APIs解析一个约900KB的XML文档(包含iTunes中top 300首歌曲信息)所花时间的比较。

示例程序允许我们选择一种解析方法对XML文档进行解析，程序会统计下载文件所花费的时间，以及解析数据库中文件的时间。你可以到统计画面查看每种解析方法平均下载和解析的时间。

我就在想，通过该程序来测试不同APIs的性能是一个好主意。因此我对该示例程序进行了扩展，以能够测试上面提到的所有解析器。如果想要在你的设备中试验一下效果，你可以通过下面的链接下载最新的工程。该工程同样展示了如何使用上面提到的每一个解析器！

下载最新的XMLPerformance工程

工程说明：如果解析器中支持XPath，我将单独的用XPath进行查找。因为在实际的编码过程中，我认为XPath代表着解析器的一种使用方法。当然，XPath一般要比手动查找XML树慢得多。所以，也把XPath测试纳入各解析器的对比中。

因此，无论如何 — 我将在这里对提供的示例代码在我的设备上的执行性能进行讨论，不过，你在使用解析器时，可能根据具体的情况，随时都会修改相关的代码。

XML解析器性能比较

下面这个图表是各个解析器在我的设备中(iPhone 3Gs)解析XML文档的速度。

如上图所示，NSXMLParser是最慢的。而TBXML是最快的，因为TBXML针对只读，做了解析上时间消耗的优化。

另我感到很惊讶的是TBXML和其它一些DOM解析器的性能要比libxml2′s SAX解析器快，原本我以为libxml2′s SAX解析器应该是最快的。对此，我没有深入研究，不过我猜测libxml2′s SAX解析器慢的原因可能是在SAX解析中，需要频繁的进行字符串比较。

当然，我们不能因为看到上面这个图就对libxml2′s SAX解析器感到失望。记住，libxml2′s SAX解析器是这里提到的所有解析器中唯一一个边读边解析的库 — 因此解析器在数据还没有下载完的时候，就可以开始解析了。

下面这个图显示的是各个解析器内存使用的峰值情况(这些数据是在运行各种解析器时，从Object Allocations tool获取到的)：

从上图，我们可以看出DOM类型的解析器要比SAX类型解析器消耗更多内存（TBXML除外—效率确实不错）。当处理很大的文档时，这是需要特别考虑的。在iOS中程序可以使用的内容是有限制的。

上图，我们可以看出libxml2′s SAX解析器在考虑内存使用方面，是最佳的选择。

最后，我用一个图表来做总结：不同解析器之间的区别。

* =结合TinyXPath

选择哪个呢？

选择使用哪个XML解析器实际上是取决于你要解析的内容。

• 如果你只是用来读取小型的XML文档（而小型XML数据对性能影响不大）。可能你还希望能够支持XPath，并在Objective-C中容易使用。那么我建议你选择使用TouchXML, KissXML, 或GDataXML都可以。
• 如果你希望能够对小型XML数据进行读写（小型XML数据对性能影响不大），并且易于使用。并且支持XPath，利用Objective-C实现的。那么我建议你使用KissXML 或GDataXML。
• 如果你想要读取非常大的XML文档（此时性能是一个非常关键的问题）。那么根据具体情况，你应该考虑使用libxml2 SAX, TBXML或libxml DOM。

我没有提到的呢？

• NSXML：如果你在处理一些小型的XML文档，而你不希望在工程中引入第三方库，那么NSXML是个正常的选择。
• TinyXML：针对中等大小的尺寸，这也是一个不错的选择，特别是如果你熟悉C和相关API，那么将之前的代码移至到iOS中非常容易。

何去何从？

如果你想要看看GDataXML是如何使用的，可以看看我写的这篇文章：iOS中如何利用GDataXML对XML文档进行读写。

如果你有什么疑问，可以联系我！

本文由破船译自：raywenderlich