使用NSAttributedString进行HTML解析

When we decided to rewrite and redesign the orders list screen, we also wanted to use small pieces of html strings for some part of each order cell information we provide. This approach could give us little freedom to change colors, fonts, order statuses etc. dynamically. This means, we need to parse multiple html strings for every cell.

当我们决定重写和重新设计订单列表屏幕时，我们还希望对提供的每个订单单元信息的某些部分使用一小段html字符串。 这种方法可能给我们几乎没有自由来动态更改颜色，字体，订单状态等。 这意味着，我们需要为每个单元格解析多个html字符串。

We started to face a few issues at that point, since the “every cell” is the important keyword here. As we used to configure table cells with mostly prepared data, we just pass the required data to cell classes, inside the cellForRow delegate method.

那时我们开始面临一些问题，因为“每个单元”是这里的重要关键字。 当我们使用大多数准备的数据来配置表单元格时，我们只是将所需的数据传递到cellForRow委托方法内部的单元格类中。

There are 3 important points to be considered, especially when parsing and displaying html data in cells.

需要考虑3个重要点，尤其是在单元格中解析和显示html数据时。

NSAttributedString的初始用法 (Initial usage of NSAttributedString)

At the very first call of NSAttributedString for parsing the html data, iOS is allocating a few threads, especially the JavaScriptCore and WebThread ones. This indicates that WebKit is just used to parse the html under the hood.

在首次调用NSAttributedString解析html数据时，iOS正在分配一些线程，尤其是JavaScriptCore和WebThread 。 这表明WebKit仅用于解析引擎盖下的html。

So it means WebKit and other necessary modules are building up which takes really a good amount of time.

因此，这意味着正在建立WebKit和其他必要的模块，这确实需要大量时间。

Of course, the time spent for first parsing operation depends on the html string, but it can be up to 1 second for a mid-sized html. Apparently, it’s not possible to avoid it but at least we can keep it in mind to avoid blocking the application flow.

当然，第一次解析操作所花费的时间取决于html字符串，但是对于中型html来说，最长可能需要1秒钟 。 显然，这是不可能避免的，但是至少我们可以记住它以避免阻塞应用程序流。

Thankfully, it just takes that much time and memory, just for the first time. When you try to parse another html data with NSAttributedString, it uses some sort of internal cache for consecutive calls and takes reasonable milliseconds (around 1/10 seconds of the initial call.)

值得庆幸的是，这仅是第一次就花了那么多时间和内存。 当您尝试使用NSAttributedString解析另一个html数据时，它对连续调用使用某种内部缓存，并且需要花费一定的毫秒数(大约是初始调用的1/10秒)。

连续解析调用 (Consecutive parsing calls)

As we mentioned, consecutive parsing operations are also not so cheap. It could take around 0.02 second for each mid size html data. So this means if you try to parse the html in every cellForRow, it’s very likely to see some delay on scrolling actions.

正如我们提到的，连续的解析操作也不是那么便宜。 每个中等大小的html数据大约需要0.02秒。 因此，这意味着如果您尝试解析每个cellForRow中的html，则很有可能会看到滚动动作的延迟。

For our specific case at the orders list screen, we fetch the orders by indicating the page size and number. Then we resolved the scrolling issue by parsing the HTML beforehand, right after the fetch is completed (also a loader icon is shown at that moment). And then store the NSAttributedString objects in ViewModels.

对于特定情况，在订单列表屏幕上，我们通过指示页面大小和页码来获取订单。 然后，我们在获取完成后立即解析HTML，从而解决了滚动问题(此时还会显示一个加载器图标)。 然后将NSAttributedString对象存储在ViewModels中。

主线程是必需的 (Main Thread is required)

Since using NSAttributedString with NSHTMLTextDocumentType requires WebKit importer and is not a thread safe operation, it just needs to be run on the main thread. This brings another thing to keep in mind that every html parsing operation requires to block the main thread, or user interactions in other words. Depending on the amount of HTML data, it would make sense to consider this delay and tackle by showing a loader, or just splitting the html data if possible in your case.

由于将NSAttributedString与NSHTMLTextDocumentType 一起使用需要WebKit导入程序，并且不是线程安全的操作，因此只需要在主线程上运行即可。 这就需要记住另一件事，每个html解析操作都需要阻塞主线程，或者换句话说就是用户交互。 根据HTML数据的数量，可以通过显示加载程序或在可能的情况下仅拆分html数据来考虑这种延迟并加以解决。