为什么要用CoreText（富文本）来取代WebView去显示内容。
主要的原因就WebView有很大的问题，性能，FPS，卡顿，与原生不搭。这些都是大问题。
WebView的缺点
1.直接使用WebView等于是是把某一个页面纯粹当成了Web页面进行渲染，这样的情况被称为“非原生”，不仅会失去渲染速度和交互体验，当一个页面上既有服务器传回的HTML与CSS样式又有原生的UI控件时，UIWebView就会变得特别不好处理，与其他UI控件间的通信也显得很不协调。
2 . WebView是单线程模型，所有的图片的加载只能在主线程上执行，还有是脚本语言的动画，也是考量因素。
3.渲染 WebView不是根据可视范围决定每次的渲染范围，而是根据自身控件的frame大小决定。尝试webview嵌在tableview里，为了让webview跟tableview一起滚动，把webview的大小设为webview里的内容大小，让webview不出滚动条，从而能跟着tableview的滚动条一起滚。这样做的后果是每次webview都一次性渲染整个页面，内存占用多性能很差，而且在放大缩小这个webview时，渲染放大的整个页面更吃力，出现不能忍受的性能。解决办法是让webview定住高度为一整屏iphone的高度，限制了webview每次的渲染范围为可视范围，性能大好。带来的问题是无法随tableview滚动。
4.UIWebView用的是脚本语言，需要逐句解析出来，然而DOM/CSS 排版复杂，在渲染上需要大量计算，才能加载到视图上，和OC在运行时去编译相比起来，脚本语言缺乏效率，而且WebView还能渲染doc，pdf，ppt这样的文件格式，这么一个强大的控件对资源的占用可想而知。UIWebView 笨重难用又不是一天两天了，还有很严重的内存泄漏。
最早做动画都是用 setTimeout/setInterval。
而 setTimeout/setInterval 的处理回调的时间 tick time 精度都在 16ms 左右。
所以，可以想象正常用这两个函数就已经 16 ms了，再加 reflow/repaint/compositing 卡顿或跳帧就是家常便饭了。
CoreText的趋势：
富文本CoreText 占用的内存更少，渲染速度快，可以在后台线程渲染。而 WebView 的内容只能在主线程渲染。基于 CoreText 可以做更细腻的原生交互效果。而 WebView 的交互效果都是用 JavaScript 来实现的，一个简单的按钮按下效果都会有一定程度的卡顿。这也使得新浪微博等主流 App 都放弃使用这种方案。追求卓越流畅度的公司，都开始使用CoreText来取代WebView。
实现思路
把Html+Css字符串直接由服务器传到本地，调用iOS/OS X底层的渲染引擎CoreText去进行渲染。换句话说，这种渲染方式是轻量级的，它去掉了许多Web渲染的繁杂步骤和功能，直接根据Html+Css去渲染图片、文字的样式。当然，根据你的需求，你也可以决定是否处理超链接和显示视频等。此时就有一个很牛逼的类。DTCoreText
解析HTML的相关类，为什么我选择了DTCoreText？
TFHpple- TFHpple 解析html的轻量级框架
RTLabel- RTLabel 基于UILabel类的拓展,能够支持Html标记的富文本显示，它是基于Core Text,因此也支持Core Text上的一些东西
Ono- A sensible way to deal with XML & HTML for iOS & OS X
SwiftyXMLParer- Simple XML Parser implemented in Swift
HTMLKit- An Objective-C framework for your everyday HTML needs.
DTCoreText- 来自澳洲的Oliver Drobnik，秉着开源和分享的精神，为我们提供了完美的框架—DTCoreText。可以解析HTML与CSS最终用CoreText绘制出来，通常用于在一些需要显示富文本的场景下代替低性能的UIWebView。
DT优点太多
DT优点太多，我只说一个原因，DTCoreText从2011年开始发布到GitHub上，一直没有间断过更新，就今天2016年9月4日，Drobnik本人又把DTCoreText更新了一个版本，修复了bug。这个代码一直都还活着，可能很粗糙，没有很好的缓存，可能有一些用的还是老一套的东西，但是这个作者一直没离开这个圈子，DTCoreText依旧充满活力。在我读DTCoreText源码的时候，我明显感到YY大神是看过这套源码的。能从YYLabel的字里行间，包括附件啊，这一套，可能都是跟DTCoreText学习的。
DT的缺点也挺多
1.解析速度虽然很快，但是如果这个HTML的图片量很大的时候，卡顿会非常严重。
2.存在内存泄露，pop出来的时候，内存也不会马上归位，逐渐降低，但是最终还是有内存泄露的情况。
3.JS代码交互不能够使用。
4.相关的资料太少。
作者：DoubleShawn
链接：https://www.jianshu.com/p/6f8162537975
來源：简书
简书著作权归作者所有，任何形式的转载都请联系作者获得授权并注明出处。