進一步比較還是能看出一些不同的。最值得注意的有：

• 在 iOS 上沒有 NSTypesetter 和 NSGlyphGenerator 這兩個類。在 Mac OS 上有很多方法來定制排版，在 iOS 中被極大地簡化了，去掉了一些抽象概念，并將這個過程合并到 NSLayoutManager 中來。保留下來的是少數的代理方法，以用來更改文本布局和斷行行為。

• 這些 Cocoa 的類移植到 iOS 系統(tǒng)后新增了幾個非常便利的功能。在 Cocoa 中，必須手工地將確定的區(qū)域從 Text Container 分離出來（見上）。而 UIKit 類提供了一個簡單的 exclusionPaths 屬性就可以做到這一點。

• 有些功能未能提供，比如，內嵌表格，以及對非圖像的附件的支持。

盡管有這些區(qū)別，總的來說系統(tǒng)還是一樣的。NSTextStorage 在兩個系統(tǒng)是是一模一樣的，NSLayoutManager 和 NSTextContainer 也沒有太大的不同。這些變動，在沒有太多去除對一些特例的支持的情況下，看來（某些情況下大大地）使文本系統(tǒng)的使用變得更為容易。我認為這是件好事。

事后回顧我從 Apple 工程師那里得到的關于將 Cocoa 文本系統(tǒng)移植到 iOS 的答案，我們可以得到一些背景信息。拖到現在并削減功能的原因很簡單：性能、性能、性能。文本布局可能是極度昂貴的任務——內存方面、電量方面以及時間方面——特別是在移動設備上。Apple 必須采用更簡單的解決方案，并等到處理能力能夠至少部分支持一個完善的文本布局引擎。

示例

為了說明 TextKit 的能力，我創(chuàng)建了一個小的演示項目，你可以在 GitHub 上找到它。在這個演示程序中，我只完成了一些以前不容易完成的功能。我必須承認寫這些代碼只花了我禮拜天的一個上午的時間；如果以前要做同樣的事情，我得花幾天甚至幾個星期。

TextKit 包括了超過 100 個方法，一篇文章根本沒辦法盡數涉及。而事實上，大多數時候，你需要的僅僅是一個正確的方法，TextKit 的使用和定制性也仍有待探索。所以我決定做四個更小的演示程序，而非一個大的演示程序來展示所有功能。每個演示程序中，我試著演示針對不同的方面和不同的類進行定制。

演示程序1：配置

讓我們從最簡單的開始：配置文本系統(tǒng)。正如你在上面 TextKit 簡圖中看到的，NSTextStorage、NSLayoutManager 和 NSTextContainer 之間的箭頭都是有兩個頭的。我試圖描述它們的關系是 1 對 N 的關系。就是那樣：一個 Text Storage 可以擁有多個 Layout Manager，一個 Layout Manager 也可以擁有多個 Text Container。這些多重性帶來了很好的特性：

• 將多個 Layout Manager 附加到同一個 Text Storage 上，可以產生相同文本的多種視覺表現，而且可以把它們放到一起來顯示。每一個表現都有獨立的位置和大小。如果相應的 Text View 可編輯，那么在某個 Text View 上做的所有修改都會馬上反映到所有 Text View 上。
• 將多個 Text Container 附加到同一個 Layout Manager 上，這樣可以將一個文本分布到多個視圖展現出來。很有用的一個例子，基于頁面的布局：每個頁面包含一個單獨的 Text View。所有這些視圖的 Text Container 都引用同一個 Layout Manager，這時這個 Layout Manager 就可以將文本分布到這些視圖上來顯示。

在 Storyboard 或者 Interface 文件中實例化 UITextView 時，它會預配置一個文本系統(tǒng)：一個 Text Storage，引用一個 Layout Manager，而后者又引用一個 Text Container。同樣地，一個文本系統(tǒng)棧也可以通過代碼直接創(chuàng)建：

NSTextStorage *textStorage = [NSTextStorage new];

NSLayoutManager *layoutManager = [NSLayoutManager new];
[textStorage addLayoutManager: layoutManager];

NSTextContainer *textContainer = [NSTextContainer new];
[layoutManager addTextContainer: textContainer];

UITextView *textView = [[UITextView alloc] initWithFrame:someFrame
                                                                     textContainer:textContainer];

這是最簡單的方式。手工創(chuàng)建一個文本系統(tǒng)，唯一需要記住的事情是你的 View Controller 必須 retain 這個 Text Storage。在棧底的 Text View 只保留了對 Text Storage 和 Layout Manager 的弱引用。當 Text Storage 被釋放時，Layout Manager 也被釋放了，這樣留給 Text View 的就只有一個斷開的 Text Container 了。

這個規(guī)則有一個例外。只有從一個 interface 文件或 storyboard 實例化一個 Text View 時，Text View 確實會自動 retain Text Storage。框架使用了一些黑魔法以確保所有的對象都被 retain，而無需手動建立一個 retain 環(huán)。

記住這些之后，創(chuàng)建一個更高級的設置也非常簡單。假設在一個視圖里面依舊有一個從 nib 實例化的 Text View，叫做 originalTextView。增加對相同文本的第二個文本視圖只需要復制上面的代碼，并重用 originalTextView 的 Text Storage：

NSTextStorage *sharedTextStorage = originalTextView.textStorage;

NSLayoutManager *otherLayoutManager = [NSLayoutManager new];
[sharedTextStorage addLayoutManager: otherLayoutManager];

NSTextContainer *otherTextContainer = [NSTextContainer new];
[otherLayoutManager addTextContainer: otherTextContainer];

UITextView *otherTextView = [[UITextView alloc] initWithFrame:someFrame
                                                textContainer:otherTextContainer];

將第二個 Text Container 附加到 Layout Manager 也差不多。比方說我們希望上面例子中的文本填充兩個 Text View，而非一個。簡單：

NSTextContainer *thirdTextContainer = [NSTextContainer new];
[otherLayoutManager addTextContainer: thirdTextContainer];

UITextView *thirdTextView = [[UITextView alloc] initWithFrame:someFrame
                                                textContainer:thirdTextContainer];

但有一點需要注意：由于在 otherTextView 中的 Text Container 可以無限地調整大小，thirdTextView 永遠不會得到任何文本。因此，我們必須指定文本應該從一個視圖回流到其它視圖，而不應該調整大小或者滾動：

otherTextView.scrollEnabled = NO;

不幸的是，看來將多個 Text Container 附加到一個 Layout Manager 會禁用編輯功能。如果必須保留編輯功能的話，那么一個 Text Container 只能附加到一個 Layout Manager 上。

想要一個這個配置的可運行的例子的話，請在前面提到的 TextKitDemo 中查看 “Configuration” 標簽頁。

演示程序2：語法高亮

如果配置 Text View 不是那么令人激動，那么這里有更有趣的：語法高亮！

看看 TextKit 組件的責任劃分，就很清楚語法高亮應該由 Text Storage 實現。因為 NSTextStorage 是一個類簇³，創(chuàng)建它的子類需要做不少工作。我的想法是建立一個復合對象：實現所有的方法，但只是將對它們的調用轉發(fā)給一個實際的實例，將輸入輸出參數或者結果修改為希望的樣子。

NSTextStorage 繼承自 NSMutableAttributedString，并且必須實現以下四個方法——兩個 getter 和兩個 setter：

- (NSString *)string;
- (NSDictionary *)attributesAtIndex:(NSUInteger)location
                     effectiveRange:(NSRangePointer)range;
- (void)replaceCharactersInRange:(NSRange)range withString:(NSString *)str;
- (void)setAttributes:(NSDictionary *)attrs range:(NSRange)range;

一個類簇的子類的復合對象的實現也相當簡單。首先，找到一個滿足所有要求的最簡單的類。在我們的例子中，它是 NSMutableAttributedString，我們用它作為實現自定義存儲的實現：

@implementation TKDHighlightingTextStorage
{
    NSMutableAttributedString *_imp;
}

- (id)init
{
    self = [super init];
    if (self) {
        _imp = [NSMutableAttributedString new];
    }
    return self;
}

有了這個對象，只需要一行代碼就可以實現兩個 getter 方法：

- (NSString *)string
{
    return _imp.string;
}

- (NSDictionary *)attributesAtIndex:(NSUInteger)location effectiveRange:(NSRangePointer)range
{
    return [_imp attributesAtIndex:location effectiveRange:range];
}

實現兩個 setter 方法也幾乎同樣簡單。但也有一個小麻煩：Text Storage 需要通知它的 Layout Manager 變化發(fā)生了。因此 settter 方法必須也要調用 -edited:range:changeInLegth: 并傳給它變化的描述。聽起來更糟糕，實現變成：

- (void)replaceCharactersInRange:(NSRange)range withString:(NSString *)str
{
    [_imp replaceCharactersInRange:range withString:str];
    [self edited:NSTextStorageEditedCharacters range:range
                                      changeInLength:(NSInteger)str.length - (NSInteger)range.length];
}

- (void)setAttributes:(NSDictionary *)attrs range:(NSRange)range
{
    [_imp setAttributes:attrs range:range];
    [self edited:NSTextStorageEditedAttributes range:range changeInLength:0];
}

就這樣，我們在文本系統(tǒng)棧里面有了一個 Text Storage 的全功能替換版本。在從 Interface 文件中載入時，可以像這樣將它插入文本視圖——但是記住從一個實例變量引用 Text Storage：

_textStorage = [TKDHighlightingTextStorage new];
[_textStorage addLayoutManager: self.textView.layoutManager];

到目前為止，一切都很好。我們設法插入了一個自定義的文本存儲，接下來我們需要真正高亮文本的某些部分了?，F在，一個簡單的高亮應該就是夠了：我們希望將所有 iWords 的顏色變成紅色——也就是那些以小寫“i”開頭，后面跟著一個大寫字母的單詞。

一個方便實現高亮的辦法是覆蓋 -processEditing。每次文本存儲有修改時，這個方法都自動被調用。每次編輯后，NSTextStorage 會用這個方法來清理字符串。例如，有些字符無法用選定的字體顯示時，Text Storage 使用一個可以顯示它們的字體來進行替換。

和其它一樣，為 iWords 增加一個簡單的高亮也相當簡單。我們覆蓋 -processEditing，調用父類的實現，并設置一個正則表達式來查找單詞：

- (void)processEditing
{
    [super processEditing];

    static NSRegularExpression *iExpression;
    NSString *pattern = @"i[\\p{Alphabetic}&&\\p{Uppercase}][\\p{Alphabetic}]+";
    iExpression = iExpression ?: [NSRegularExpression regularExpressionWithPattern:pattern
                                                                           options:0
                                                                             error:NULL];

然后，首先清除之前的所有高亮：

    NSRange paragaphRange = [self.string paragraphRangeForRange: self.editedRange];
    [self removeAttribute:NSForegroundColorAttributeName range:paragaphRange];

其次遍歷所有的樣式匹配項并高亮它們：

    [iExpression enumerateMatchesInString:self.string
                                  options:0 range:paragaphRange
                               usingBlock:^(NSTextCheckingResult *result, NSMatchingFlags flags, BOOL *stop)
    {
        [self addAttribute:NSForegroundColorAttributeName value:[UIColor redColor] range:result.range];
    }];
}

就是這樣。我們創(chuàng)建了一個支持語法高亮的動態(tài) Text View。當用戶鍵入時，高亮將被實時應用。而且這只需幾行代碼?？岚桑?/p>

http://wiki.jikexueyuan.com/project/objc/images/5-6.png" alt="" />

請注意僅僅使用 edited range 是不夠的。例如，當手動鍵入 iWords，只有一個單詞的第三個字符被鍵入后，正則表達式才開始匹配。但那時 editedRange 僅包含第三個字符，因此所有的處理只會影響這一個字符。通過重新處理整個段落可以解決這個問題，這樣既完成高亮功能，又不會太過影響性能。

想要一個可以運行的 Demo 的話，請在前面提到的 TextKitDemo 中查看“Highlighting”標簽頁。

演示程序3：布局修改

如前所述，Layout Manager 是核心的布局主力。Mac OS 上 NSTypesetter 的高度可定制功能被并入 iOS 上的 NSLayoutManager。雖然 TextKit 不具備像 Cocoa 文本系統(tǒng)那樣的完全可定制性，但它提供很多代理方法來允許做一些調整。如前所述，TextKit 與 CoreText 更緊密地集成在一起，主要是基于性能方面的考慮。但是兩個文本系統(tǒng)的理念在一定程度上是不一樣的：

Cocoa 文本系統(tǒng)：在 Mac OS上，性能不是問題，設計考量的全部是靈活性?？赡苁沁@樣：“這個東西可以做這個事情。如果你想的話，你可以覆蓋它。性能不是問題。你也可以提供完全由自己實現的字符到字形的轉換，去做吧…”

TextKit：性能看來真是個問題。理念（起碼現在）更多的是像這樣：“我們用簡單但是高性能的方法實現了這個功能。這是結果，但是我們給你一個機會去更改它的一些東西。但是你只能在不太損害性能的地方進行修改?！?/p>

理念的東西就講這么多，現在讓我們來搞些實際的東西。例如，調整行高如何？聽起來不可思議，但是在之前的 iOS 發(fā)布版上調整行高需要使用黑科技或者私有 API。幸運的是，現在（再一次）不用那么費腦子了。設置 Layout Manager 的代理并實現僅僅一個方法即可：

- (CGFloat)      layoutManager:(NSLayoutManager *)layoutManager
  lineSpacingAfterGlyphAtIndex:(NSUInteger)glyphIndex
  withProposedLineFragmentRect:(CGRect)rect
{
    return floorf(glyphIndex / 100);
}

在以上的代碼中，我修改了行間距，讓它與文本長度同時增長。這導致頂部的行比底部的行排列得更緊密。我承認這沒什么實際的用處，但是它是可以做到的（而且肯定會有更實用的用例的）。

好，來一個更現實的場景。假設你的文本中有鏈接，你不希望這些鏈接被斷行分割。如果可能的話，一個 URL 應該始終顯示為一個整體，一個單一的文本片段。沒有什么比這更簡單的了。

首先，就像前面討論過的那樣，我們使用自定義的 Text Storage。但是，它尋找鏈接并將其標記，而不是檢測 iWords，如下：

static NSDataDetector *linkDetector;
linkDetector = linkDetector ?: [[NSDataDetector alloc] initWithTypes:NSTextCheckingTypeLink error:NULL];

NSRange paragaphRange = [self.string paragraphRangeForRange: NSMakeRange(range.location, str.length)];
[self removeAttribute:NSLinkAttributeName range:paragaphRange];

[linkDetector enumerateMatchesInString:self.string
                               options:0
                                 range:paragaphRange
                            usingBlock:^(NSTextCheckingResult *result, NSMatchingFlags flags, BOOL *stop)
{
    [self addAttribute:NSLinkAttributeName value:result.URL range:result.range];
}];

有了這個，改變斷行行為就只需要實現一個 Layout Manager 的代理方法：

- (BOOL)layoutManager:(NSLayoutManager *)layoutManager shouldBreakLineByWordBeforeCharacterAtIndex:(NSUInteger)charIndex
{
    NSRange range;
    NSURL *linkURL = [layoutManager.textStorage attribute:NSLinkAttributeName
                                                  atIndex:charIndex
                                           effectiveRange:&range];

    return !(linkURL && charIndex > range.location && charIndex <= NSMaxRange(range));   

想要一個可運行的例子的話，請在前面提到的 TextKitDemo 中查看“Layout”標簽頁。以下是截屏：

http://wiki.jikexueyuan.com/project/objc/images/5-7.png" alt="" />

順便說一句，上面截屏里面的綠色輪廓線是無法用 TextKit 實現的。在這個演示程序中，我用了個小技巧來在 Layout Manager 的子類中給文本畫輪廓線。以特定的方法來擴展 TextKit 的繪制功能也不是件難事，你一定要看看！

演示程序4：文本交互

前面已經涉及到了 NSTextStorage 和 NSLayoutManager，最后一個演示程序將涉及 NSTextContainer。這個類并不復雜，而且它除了指定文本可不可以放置在某個地方外，什么都沒做。

不要將文本放置在某些區(qū)域，這是很常見的需求，例如，在雜志應用中。對于這種情況，iOS 上的 NSTextContainer 提供了一個 Mac 開發(fā)者夢寐以求的屬性：exclusionPaths，它允許開發(fā)者設置一個 NSBezierPath 數組來指定不可填充文本的區(qū)域。要了解這到底是什么東西，看一眼下面的截屏：

http://wiki.jikexueyuan.com/project/objc/images/5-8.png" alt="" />

正如你所看到的，所有的文本都放置在藍色橢圓外面。在 Text View 里面實現這個行為很簡單，但是有個小麻煩：Bezier Path 的坐標必須使用容器的坐標系。以下是轉換方法：

- (void)updateExclusionPaths 
{
CGRect ovalFrame = [self.textView convertRect:self.circleView.bounds 
                                                   fromView:self.circleView];

    ovalFrame.origin.x -= self.textView.textContainerInset.left;
    ovalFrame.origin.y -= self.textView.textContainerInset.top;

    UIBezierPath *ovalPath = [UIBezierPath bezierPathWithOvalInRect:ovalFrame];
    self.textView.textContainer.exclusionPaths = @[ovalPath];
}

在這個例子中，我使用了一個用戶可移動的視圖，它可以被自由移動，而文本會實時地圍繞著它重新排版。我們首先將它的 bounds（self.circleView.bounds）轉換到 Text View 的坐標系統(tǒng)。

因為沒有 inset，文本會過于靠近視圖邊界，所以 UITextView 會在離邊界還有幾個點的距離的地方插入它的文本容器。因此，要得到以容器坐標表示的路徑，必須從 origin 中減去這個插入點的坐標。

在此之后，只需將 Bezier Path 設置給 Text Container 即可將對應的區(qū)域排除掉。其它的過程對你來說是透明的，TextKit 會自動處理。

想要一個可運行的例子的話，請在前面提到的 TextKitDemo 中查看“Interaction”標簽頁。作為一個小噱頭，它也包含了一個跟隨當前文本選擇的視圖。因為，你也知道，沒有一個小小的丑陋的煩人的回形針擋住你的話，那還是一個好的文本編輯器演示程序嗎？