ObjC 中国 - 插件

插件是给你已经发布的 App 增加功能的一个好办法，Mac 上的 App 支持插件已经有很长的历史了，比如 Adobe Photoshop，在 1991 年的 version 2.0 就开始支持了。

在以前的 OS X 系统中，给你的 App 在运行时动态载入可执行代码比较困难。现在，在 NSBundle 的帮助和你的一些前瞻性思维的帮助下下，它从未如此简单。

包 (Bundles) 和接口 (Interfaces)

如果你打开 Xcode 5 并且创建一个新项目，你会看见 OS X 选项卡下有一个 "Application Plug-in" 的分类和 "System Plug-in" 的分类，从 Screen Savers 到 Image Units，在 Xcode 里面一共有 12 中不同的模板可以编写 App 的插件。如果你点击 "Framework & Library" 的选项卡，你将可以看见一个 Bundle 条目。我会在今天探索一个非常简单的的项目，那就是在一个修改过的 TextEdit 里面加入加载 bundle 的功能。

注意：Apple 称这些为 plug-ins ，而通常大家更喜欢用 plugins 称呼。为了一致性，在开发和 UI 相关的东西的时候，我想用和平台一致的 plug-in 称呼会更好。虽然在应用的 UI 里你会看到 "plug-ins"，但是在这篇文章和代码里面，我会用 plugin。（同时我偶尔会混用 bundle 和 plugin 这两个词。）(译者注：在本译文中会把 plugin 统一翻译成插件，伟大的中文)

什么是 bundle ？如果你创建一个 Xcode 的 bundle 模版项目，你会发现它内容并不多。当构建它的时候你会得到一个很像构建 App 时产生的目录 —— 一个 Contents 目录，里面包含了 Info.plist 和 Resource 目录。如果你在你的项目下加入了新的类，你可以看见包含一个可执行文件的 MacOS 目录。Bundle 工程里缺少的一个东西是 main() 函数。它是被宿主 App 调用执行的。

为 TextEdit 加入 Plugin 支持

我会介绍两种插件的方式，第一个用最少的工作来为你的 app 加入插件支持，希望让你知道实现这个有多简单。

第二个技术有点复杂，它展现来一个为你的 app 加入插件的合理的方式，这可以使你不会在未来陷入到被锁死在某一种实现的窘境中。

本文章的项目文件仍然会放在 GitHub 供大家参考。

在 TextEdit 中扫描 Bundle

请打开 "01 TextEdit" 目录下面的 TextEdit.xcodeproj 工程，同时浏览它里面包含的代码。

这个改写过的 TextEdit 里面有三个简单的组成部分：扫描 bundle，加载 bundle，并且添加了调用 bundle 的 UI。

打开 Controller.m，你可以看见 -(void)loadPlugins 方法 (它在 applicationDidFinishLaunching: 中被调用)。

loadPlugins 方法在你的界面菜单右侧加入了一个新的 NSMenuItem，来为你调用你的插件提供一个入口（通常你会在 MainMenu.xib 做这件事情并且链接 outlets，但是我们这次偷下懒）。然后获得你的插件目录（在 ~/Library/Application Support/Text Edit/Plug-Ins/ ）下，并且扫描这个目录。

 NSString *pluginsFolder = [self pluginsFolder];
 NSFileManager *fm = [NSFileManager defaultManager];

 NSError *outErr;
 for (NSString *item in [fm contentsOfDirectoryAtPath:pluginsFolder error:&outErr]) {

     if (![item hasSuffix:@".bundle"]) {
         continue;
     }

     NSString *bundlePath = [pluginsFolder stringByAppendingPathComponent:item];

     NSBundle *b = [NSBundle bundleWithPath:bundlePath];

     if (!b) {
         NSLog(@"Could not make a bundle from %@", bundlePath);
         continue;
     }

     id <TextEditPlugin> plugin = [[b principalClass] new];

     NSMenuItem *item = [pluginsMenu addItemWithTitle:[plugin menuItemTitle] action:@selector(pluginMenuItemCalledAction:) keyEquivalent:@""];

     [item setRepresentedObject:plugin];

 }

到目前，看起来是非常简单的。扫描插件目录，确保得到的是一个 .bundle 文件（你当然不希望载入 .DS_Store 文件），然后用 NSBundle 载入你找到的 bundle 并且实例化里面的类。

你会注意到一个 TextEditPlugin 的 protocol 的引用。在 TextEditMisc.h 能找它的定义:

 @protocol TextEditPlugin <NSObject>
 - (NSString*)menuItemTitle;
 - (void)actionCalledWithTextView:(NSTextView*)textView inDocument:(id)document;
 @end

这说明你实例化的类需要响应这两个方法。你可以验证这个类是否响应这两个方法（这是一个好主意），但是简单起见，我们现在就不这样做了。

OK，你在 bundle 里面调用的 principalClass 方法是什么呢？当你创建一个 Bundle 的时候，你可以在里面创建一个或者多个类，同时你需要让 TextEdit 知道哪一个类需要被实例化。为了帮助宿主 App 调用，你可以在 Info.plist 文件加入一个 NSPrincipalClass 的键，同时设置它的值为实现插件方法的类的名字。你可以用 [NSBundle principalClass] 方便地从 NSPrincipalClass 的值里面寻找并创建这个类。

继续：在 Plug-Ins 菜单加入一个新的按钮，设置 action 为 pluginMenuItemCalledAction:，并且设置它表示你已经实例化的对象。

注意你没有在 menu item 里面设置一个target。如果一个menu item的目标是nil，那么它会寻找响应链，来寻找第一个实现 pluginMenuItemCalledAction: 方法的对象。如果它找不到，那么这个菜单选项将会不能用。

举一个例子，实现 pluginMenuItemCalledAction 的最好的地方是在 Document 的 window controller 类中。打开 DocumentWindowController.m，然后定位到到 pluginMenuItemCalledAction

- (void)pluginMenuItemCalledAction:(id)sender {
    id <TextEditPlugin>plugin = [sender representedObject];
    [plugin actionCalledWithTextView:[self firstTextView] inDocument:[self document]];
}

代码本身很清晰，搜集插件实例，调用 actionCalledWithTextView:inDocument: 方法（被定义在 protocol 里面的），运行你插件里面的代码。

插件一瞥

打开 "01 MarkYellow" 工程看一下。这是一个 Xcode (通过OS X ▸ Framework & Library ▸ Bundle template 建立) 的标准工程，里面只添加了一个类：TEMarkYellow。

如果你打开 MarkYellow-Info.plist，你可以看到 NSPrincipalClass 的值设置成了上面提到的 TEMarkYellow。

接着，打开 TEMarkYellow.m，你将会看见定义在协议里面的方法。一个返回你插件的名字，就是在 menu 里面显示的那个，更有意思的是另外一个方法 (actionCalledWithTextView:inDocument:)，它把所有选中的文字变成黄色的背景。

- (void)actionCalledWithTextView:(NSTextView*)textView inDocument:(id)document {
    if ([textView selectedRange].length) {

        NSMutableAttributedString *ats = [[[textView textStorage] attributedSubstringFromRange:[textView selectedRange]] mutableCopy];

        [ats addAttribute:NSBackgroundColorAttributeName value:[NSColor yellowColor] range:NSMakeRange(0, [ats length])];

        //  先测试text view是否能改变文字内容，这样可以自动做正确的撤销操作。

        By asking the text view if you can change the text first, it will automatically do the right thing to enable undoing of attribute changes
        if ([textView shouldChangeTextInRange:[textView selectedRange] replacementString:[ats string]]) {
            [[textView textStorage] replaceCharactersInRange:[textView selectedRange] withAttributedString:ats];
            [textView didChangeText];
        }
    }
}

运行 TextEdit （它会创建Plug-Ins目录），然后构建 MarkYellow 工程。把 MarkYellow.bundle 丢到你的 ~/Library/Application Support/Text Edit/Plug-Ins/ 目录下面，重启你的 TextEdit 应用。

一切看起来都很好，扫描，加载，插入一个菜单，然后，当你使用菜单项的时候，传递到参数到插件里面。试一试，点击 Plug-Ins ▸ Mark Selected Text Yellow，选择的文字的背景颜色就变成黄色的了。

这真是令人惊叹，但是其实它很脆弱，也不够先进。

所以关掉这两个项目，扔进废纸篓，然后尝试忘掉它们吧。

好的，但是如何改进呢

上述的途径有什么问题？

Bundle 中只有一个方法被调用。对于插件的作者来说太不方便了。有没有更简单的方法为 bundle 加入更多功能和菜单按钮呢？
这不是一个有前瞻性的做法，在插件里面硬编码特定的方法名字固定了一些操作，让我们重新来写这个工程，让插件能做的事情更多吧。

这一次，我们先从 bundle 开始探究。打开 02 MarkYellow 里面的 xcodeproj 工程，定位到 TEMarkYellow.m，你马上可以看见这里有更多代码，同时它也做了更多事情。

这里实现了一个接收一个 interface 作为参数的 pluginDidLoad: 方法，而不是返回插件名字的方法。你可以用它来告诉 TextEdit 你的方法名字和调用它们的时候使用的 selector ，以及一个帮助存储一些特别的文本操作的状态的 user object。

这个插件从单一行为变成了实现了三个操作：一个把你的文本变成黄色，一个把你的文字变成蓝色，一个把你选中的文本作为 AppleScript 运行。我们充分发挥了 userObject 这个参数的优点，所以只需要实现两个方法。

这个方法比第一种有扩展性。然而，它也增加了 app 端的复杂度。

为TextEdit加入更多功能

打开 02 TextEdit 看看 Controler.m , 它没有做太多事情。但是它在 applicationDidFinishLaunching: 设置了一个新的类，叫 PluginManager，打开 PluginManager.m 并且导航到 －loadPlugins 里面。

这个和刚才的 -loadPlugins 几乎一样，只不过代替了原来使用 for 循环加入菜单项，现在只对从 bundle 中取到的 principalClass 进行初始化，然后调用了 pluginDidLoad:，以此来驱动影响 TextEdit 的执行。

看一下 -addPluginsMenuWithTitle:…，我们在这里创建了菜单项。并且这里不再设置菜单项的 representedObject 为插件实例本身，而是实例化一个 helper 类 (PluginTarget)，同时关联了对 text aciton 和 friends 的引用，然后设置它为菜单项的 representedObject 以备使用。

然而，设置到菜单项的 selector 仍然还是 pluginMenuItemCalledAction:，可以在 DocumentWindowController.m 里面看看这个方法到底干了什么:

- (void)pluginMenuItemCalledAction:(id)sender {

    PluginTarget *p = [sender representedObject];

    NSMethodSignature *ms = [[p target] methodSignatureForSelector:[p action]];
    NSInvocation *invocation = [NSInvocation invocationWithMethodSignature:ms];

    NSTextView *tv = [self firstTextView];
    id document = [self document];
    id userObject = [p userObject];

    [invocation setTarget:[p target]];
    [invocation setSelector:[p action]];
    [invocation setArgument:&tv atIndex:2];
    [invocation setArgument:&document atIndex:3];
    [invocation setArgument:&userObject atIndex:4];
    [invocation invoke];
}

因为你要处理更多信息，所以这个版本相比之前的实现有一点复杂，创建一个 NSInvocation，设置它的参数，然后从插件的实例里面调用它。

宿主 (app) 端需要更多工作，但是对于插件的作者来说写插件更加灵活了。

下一步干什么

基于这个接口，你可以写一个插件，加载其他的自定义的插件。假设你想要加入让你的用户用 Javascript 写插件的功能，那么在 pluginDidLoad 调用之后，扫描指定目录下面的 js 文件，在 addPluginsMenuWithTitle:… 中为每一个 js 文件增加对应的条目，然后，当插件被调用的时候，可以用 JavaScriptCore 来执行对应的脚本。你也可以用 Python，Ruby，Lua 来做这些事情（我之前做过这些事情）。

最后，关于安全

“插件让安全的人抽搐” — 匿名

一个显而易见但是容易被忽略的事情是安全。当你在你的进程里面加载一个可执行的 bundle 的时候，你相当于在说：“这里有一把我房间的钥匙，确保走的时候关上灯灯，不要把牛奶喝光，无论你干什么都请把火盆放在外面。” 你需要相信插件的作者不会犯错，但是有可能事与愿违。

可能会发生什么糟糕的情况呢？一个实现的不好的的插件可以占用所有可用的内存，让 CPU 占用始终保持 100%，crash 一大堆东西。或许有的家伙写了一个看起来很好的插件，但是一个月以后，它的代码把你的联系人数据库偷偷发给第三方……我还能举出很多例子，我相信你懂的...

如何解决这个问题？你可以在单独的地址空间运行你的插件（解决 crash 问题，同时可能可以解决内存和 cpu 问题），同时强制插件到沙盒里面运行。（如果你正确地确认插件的权限，那么你的联系人数据库就不会被读取了）。我一时就能想到很多方法，但是最好的解决方法是使用苹果的 XPC。

我把探索的过程留给读者，但是你在处理插件的时候应该一直有安全性的观念。当然，把一个插件放在沙盒里面或者另外一个进程里面会缺少一些乐趣，并且增加一些工作量，所以这对于你的 App 或许没那么重要。

原文 Plugins