JSPatch 支持了动态调用 C 函数，无需在编译前桥接每个要调用的 C 函数，只需要在 JS 里调用前声明下这个函数，就可以直接调用：

require('JPEngine').addExtensions(['JPCFunction'])
defineCFunction("malloc", "void *, size_t")
malloc(10)

我们一步步来看看怎样可以做到动态调用 C 函数。

函数地址

首先若要动态调用 C 函数，第一步就是需要通过传入一个函数名字符串找到这个函数地址，这里一个必要的前提条件就是 C 编译后的可执行文件里必须有原函数名的信息，才有可能做到通过函数名字符串找到函数地址。我们写个简单的程序来看看它编译后可执行文件的内容有没有这个信息：

//main.m
void test() {
}

int main() {
  return 0;
}

编译这个文件，并用otool看下它的汇编：
（更多…）

JSPatchX 是 JSPatch Xcode 代码自动补全插件，目前在 github 开源，效果见图：

做完一个开源项目照例写篇文章说明下实现原理，主要目的是让想对这个项目做贡献改进的人可以通过文章更容易地了解这个项目的由来，思路，核心原理和流程，降低参与这个项目开发的门槛。

由来

写 JSPatch 脚本一个不爽的地方就是没有代码补全，而调用 OC 方法时方法名又死长，写起来很不方便。

对此之前做了 JSPatch Convertor，可以自动把 OC 代码转为 JSPatch 脚本，这个工具的使用场景是用 JSPatch 做 hotfix 时，需要重写原 OC 的整个方法，这时用工具把这个方法的 OC 代码直接转为 JS 再进行修改，可以很大地降低工作量，缓解了这个问题。但若要用 JSPatch 开发新功能模块，就不会有 OC 代码可以去转换，这时提高编码效率的唯一方式就是做代码补全插件。

在寻找实现方案的时候得知公司内一牛人 louis 已经实现了 lua 的 XCode 代码补全插件，沟通后还很慷慨地给了源码，省去了很多研究 XCode 代码补全机制的功夫，于是参考他的编码，并且直接用了他 OC 头文件解析的代码，开发了 JSPatchX。所以这个项目算是我与 louis 联合开发的，在此感谢 louis~

插件入门

XCode 有个很坑爹的地方，就是它并不官方支持插件开发，官方没有文档，XCode 也没有开源，但由于 XCode 是 Objective-C 写的，OC 动态性太强大，导致在这么封闭的情况下民间还是可以做出各种插件，其核心开发方式就是：

1. dump 出 Xcode 所有头文件，知道 Xcode 里有哪些类和接口。
2. 通过头文件方法名猜测方法的作用，swizzle 这些方法，插入自己的代码实现插件逻辑。
3. 通过 NSNotificationCenter 监听各种事件的发生。

更详细的开发教程网上有不少文章，有兴趣的自行搜索吧。

起步

对于实现 JS 代码补全这个功能来说，主要分三步：

1. 在编辑 JS 文件时开启代码补全功能。
2. 找到用户输入代码时的回调，按 Xcode 要求组装代码补全对象数组返回。
3. 根据已输入文字对补全对象数组进行过滤

第一步是通过替换 DVTTextCompletionDataSource 类里的 -strategies 方法，在源文件是 JS 时生成一个 IDEIndexCompletionStrategy 对象返回，就可以针对 JS 文件走代码补全逻辑了。

第二步是替换 IDEIndexCompletionStrategy 的 - completionItemsForDocumentLocation:context:highlyLikelyCompletionItems:areDefinitive: 方法，这个方法会在用户输入时被调用，在这里组装好应该出现的补全对象(IDEIndexCompletionItem) 列表返回，Xcode 就会自动应用返回的 items 对输入进行补全。

第三步是在 DVTTextCompletionSession 的 -_setFilteringPrefix:forceFilter: 方法，针对第二步返回的 item 对象根据输入进行过滤。

要让自动补全插件程序跑通，只需实现上述三步。显然核心在第二步如何组装合适的补全对象 completionItem。代码里我们新增了一个 IDEIndexCompletionItem 的子类 JPCompletionItem 去表示，下面统一把这个补全对象称为 completionItem。接下来的问题就是怎样组装这些 completionItem。

实现

先看看我们需要哪些自动补全，概括起来有几种：

1. 可能会被调用到的 OC 方法名
2. JS 上新增的方法名，以及出现的类名
3. JSPatch 自身的一些关键字接口，如 defineClass, require 等
4. 当前 JS 文件里出现过的关键字

前三点应该没有异议，第四点要解释一下，实际上若要做得精细，应该加上 JS 语言本身自带的 API 和关键字(var / Math 函数 / String 函数等)，以及JS 当前作用域上的变量的补全，但这样做一是 API 太多，二是实现复杂，所以用 “当前 JS 文件里出现过的关键字” 代替这两点，只要文件里出现过的单词就会有补全提示，也就是说一些关键字和变量第一次输入时没有提示，但在同个文件第二次输入就有补全提示了，sublime 默认就是这样的补全规则，实际使用效果很好，所以选择用这种简单的方式满足需求。

具体实现上，分三步走，一是解析 OC 头文件，二是解析 JS 文件，三是对解析后的数据进行缓存和组装 completionItem。

解析 OC 头文件

JPObjcFile 负责解析 OC 头文件，因为这里可以认为外部可以调用的 OC 接口都在头文件里，所以只需要解析头文件，这样处理比较简单，解析效率也很高。louis写了个 OC 头文件解析器，把头文件里的 class / protocol / import 解析出来，最终每个头文件都会解析成对应的 JPObjcFile 对象，这个对象保存着文件里 class / protocol 对应的方法的 completionItems，可以按需求直接输出。

解析 JS 文件

JPJSFile 负责解析 JS 文件，这里的解析比较简单，没有用词法语法解析器，而是直接通过正则匹配取出需要的内容，这里通过正则提取了：

1. require() 里的 className
2. defineClass() 里的 className
3. defineClass() 里所有的方法名
4. 文件里所有 keyword

同样每个 JS 文件都会生成一个 JPJSFile 对象，包含了上述提取的元素，并生成和保存了方法名和keyword对应的 completionItems列表。

组装和缓存

解决了单个 OC / JS 文件的解析，接着就是决定解析哪些文件，以什么样的形式缓存和组装返回给XCode。

JPObjcIndex

先看看 OC 的解析，JPObjcIndex 负责 OC 头文件的解析，JS 可能调用到的 OC 代码只存在于两个地方，一是系统framework，二是项目里的代码，对这些 OC 头文件要以什么样的方式解析呢？这里有两个选择:

1. 只解析与当前编辑的 JS 文件相关的 OC 头文件
2. 一次性把所有文件都解析好，再进行筛选

若要用方案1，只解析与当前编辑的 JS 文件相关的文件，则需要知道 JS 文件引用到了哪些 OC 文件，需要像 OC 代码那样有 #import 其他文件的规则，而 JSPatch 的规则是调用 OC 代码时不需要 import OC 文件，只需要通过 require(‘className') 接口引入类，所以线索只有 require() 里的类名，而在还没解析时是不清楚类名和 OC 文件的对应关系的，无法知道当前 JS 文件依赖了哪些 OC 头文件，所以这里只能选择一次性把所有 OC 头文件都解析好。

JPObjcIndex 默认扫描了 Foundation 和 UIKit 这两个 framework 里的所有头文件，以及当前项目里的所有 OC 头文件，在 JPObjcIndex 里以 className 为 key 进行缓存，对外提供通过 className 去取这些类相应 completionItem 的接口。

JPJSIndex

对于 JS 文件，为了简单起见，同样采用了一次性解析全部文件的方式。JPJSIndex 做了以下这些事：

1. 解析所有 JS 文件，生成一个个对应的 JPJSFile 对象，缓存起来。
2. 取出每个 JPJSFile 里解析的 require() 以及 defineClass() 的 className，去 JPObjcIndex 取这些 Class 对应的 completionItems。
3. 取出每个 JPJSFile 解析好的 method completionItems。
4. 取出每个 JPJSFile 解析好的 keyword completionItems。
5. 本地 keyword.plist 定义了 JSPatch 常用的一些自动补全关键字，例如 defineClass, CGRect 等，在这里取出这些数据并生成 completionItems。
6. 把 2-5 步里的 completionItems 分成两种类型，keyword 类型和 method 类型，缓存起来并返回给 XCode。
7. 当有 JS 文件保存时，重新对这个文件生成 JPJSFile 对象，并重做 2-6 步。

第6步分出来的两种类型应用于两种场景，method 类型会在 JS 输入 . 要进行方法调用时出现，这个类型里所有的 completionItem 都是方法，包括 OC 头文件定义的方法以及 JS 里解析的方法。keyword 类型则是其他的像类名/语句关键字等这些非方法，在平常输入中出现。

在没有 JS 文件保存时，用户编辑 JS 代码每一次输入走到补全逻辑时，JPJSIndex 都是直接返回内存里已组装好的 completionItems 列表，没有其他操作，提高操作性能。第7步虽然在有文件保存时重新做了 2-6 步对数据进行重新组装，但这个过程不涉及文件解析，只需要取内存里解析好的数据进行组装，并且文件保存不会那么频繁，所以性能上没有太大问题。

整个流程就是这样，实际上很简单，总结起来就是解析所有 OC 头文件，解析所有 JS 文件，组装并缓存好 completionItem 返回。

不足

做这个项目的想法是先用最简单的方式快速做出来，满足80%的需求，导致会有一些不足，例如

1. 没有做 JS 语法解析，没有做细致的筛选规则，粗暴地全部提示。
2. 没有补全 include 的其他 JS 文件里的全局变量。
3. defineClass 里写定义方法时，若要覆盖 OC 原有方法，没有方法名补全（因为方法名只有在 . 后才有补全）
4. 没有加上除了 Foundation 和 UIKit 以外的 framework。

欢迎一起改进 JSPatchX，完善这些不足~

JSPatch 开源以来大部分被用于 hotfix，替换原生方法修复线上bug，但实际上 JSPatch 一直拥有动态添加功能模块的能力，因为 JSPatch 可以创建和调用任意 OC 类和方法，完全可以用 JSPatch 写功能模块，然后动态下发加载。只是之前在性能和开发体验上有些问题，还没有太多这方面的应用。这次 JSPatch 做了较大的更新，扫除这些问题，让用纯 JS 写功能模块变得实用。这里有个用 JS 写的 Dribbble 客户端 Demo，可以体验下效果。

来看看这次更新做了什么。

性能优化

通过工具可以看到使用 JSPatch 写功能模块时，耗时较多的点在于 JS 和 OC 的通信，以及通信过程中参数的转换，于是在这块寻找优化点。写功能时需要新增很多类和方法，例如：

defineClass('JPDribbbleView:UIView', {
  renderItem: function(item) {
    ...
  },
})

defineClass('JPDribbbleViewController:UIViewController', {
  render: function(){
    var view = JPDribbbleView.alloc().init();
    view.renderItem(item);
  }
});

上面两个都是新增的类，两个方法也是新增的，按之前的流程，这里的定义会传入 OC，在 OC 生成这两个类，并在这个类上添加这里定义的方法，调用时进入 OC 寻找这些方法调用。

（更多…）

看了 Limboy(文章1 文章2) 和 Casa (文章) 对 iOS 组件化方案的讨论，写篇文章梳理下思路。

首先我觉得”组件”在这里不太合适，因为按我理解组件是指比较小的功能块，这些组件不需要多少组件间通信，没什么依赖，也就不需要做什么其他处理，面向对象就能搞定。而这里提到的是较大粒度的业务功能，我们习惯称为”模块”。为了方便表述，下面模块和组件代表同一个意思，都是指较大粒度的业务模块。

一个 APP 有多个模块，模块之间会通信，互相调用，例如微信读书有 书籍详情 想法列表 阅读器 发现卡片 等等模块，这些模块会互相调用，例如 书籍详情要调起阅读器和想法列表，阅读器要调起想法列表和书籍详情，等等，一般我们是怎样调用呢，以阅读器为例，会这样写：

（更多…）

简介

JSPatch Convertor 可以自动把 Objective-C 代码转为 JSPatch 脚本。

JSPatch 是以方法为单位进行代码替换的，若 OC 上某个方法里有一行出了bug，就需要把这个方法用 JS 重写一遍才能进行替换，这就需要很多人工把 Objective-C 代码翻译成 JS 的过程，而这种代码转换的过程遵循着固定的模式，应该是可以做到自动完成的，于是想尝试实现这样的代码自动转换工具，从 Objective-C 自动转为 JSPatch 脚本。

方案 / Antlr

做这样的代码转换工具，最简单的实现方式是什么？最初考虑是否能用正则表达式搞定，如果可以那是最简单的，后来发现像 方法声明 / get property / NSArray / NSString 等这些是可以用正则处理的，但需要匹配括号的像 block / 方法调用 /set property 这些难以用正则处理，于是只能转向其他途径。

Antlr

接下来的思路是对 Objective-C 进行词法语法解析，再遍历语法树生成对应的 JS 代码。Objective-C 词法语法解析 clang 可以做到 ，但在找方案过程中发现了 antlr 这个神器，以及为 antlr 定制的几乎所有语言的语法描述文件，更符合我的需求。antlr 可以根据语法描述文件生成对应的词法语法解析程序，生成的程序可以是 Java / Python / C# / JavaScript 这四种之一。

也就是说，我们拿 ObjC.g4 这个语法文件，就可以通过 antlr 生成 Objective-C 语法解析程序，程序语言可以在上述四种语言中任挑，我挑选的是 JavaScript，生成的程序可以在 [这里] 看到。官方文档有生成的流程和使用方法，可以自己试下。
（更多…）