JSPatch开源经验分享

Posted 2021-04-30 移动开发前线

（题图来自Lex Tang的Dribble）

嘉宾介绍

bang，腾讯ios高级工程师，开源项目JSPatch作者。目前在腾讯做微信读书iOS端。

先介绍一下 JSPatch (https://github.com/bang590/JSPatch)，JSPatch 是 iOS App 动态更新库，引入后即可以用 JS 调用和替换原生任意方法，普遍用于动态下发脚本实时修复线上 Bug，目前微信微博百度地图美团等 1200 个以上 App 已接入使用。部分接入APP列表：http://using.jspatch.org

JSPatch 在还没投入使用时就就在 github 开源，因为开源社区的推动和帮助才会有今天较完善的版本和广泛的使用。目前在 Github 上有4k+ star，25位社区成员贡献过代码，算是较活跃的开源项目。

回顾起来，对 JSPatch 这个项目来说，能推动起来主要有三点：有用，完善，推广。

有用

对于一个给别人使用的开源项目来说，项目有没有用自然是最重要的，有用的意思包括：1.是否有需求 2.项目是否很好地满足了需求。

对 JSPatch 来说这两点都是符合的，第1点，iOS App发展到今天，越来越多的 App 需要动态部署技术，无需等待周期不定的苹果审核，实时修复线上bug，对线上产品有更多控制力，对很多 App 开发都很有诱惑力。第2点，初期的 JSPatch 已经基本能满足这个需求。

满足了这两点，就可以开始做推广。

推广

一般开源项目的推广会两个方式，一是线上文章，二是线下分享。我主要的方式是通过文章，我觉得一篇文章能触达的用户会比线下分享多很多，当然线下分享也很值得做，只是之前一直没精力，接下来会尝试。

文章最好不是单纯介绍这个开源项目，而是让看了的人即使不用你的开源库，也觉得有收获的技术文章。对于 JSPatch 项目来说会有一些黑魔法和脑洞，所以写了一些 JSPatch 原理解析文章，即使不使用 JSPatch 的人，相信也可以从文章中得到一些收获，这样才会获得传播。

对于其他开源项目，如果原理解析不好写，也可以挖掘一些点，回想做这个项目的思路，例如按类似 [面临的问题 - 业界解决方案 - 他们的缺陷 - 我的项目的优势 - 实现] 这样的思路去写，也会对人有所帮助。我们团队的几个开源项目也写了这样的文章：wereadteam.github.io。

线上的推广除了文章还有其他形式，例如视频教学，在线直播，微信群分享之类，还没成为主流，有时间会尝试一下。现在就在尝试微信群分享:) 

完善

当项目初步推广起来后，越来越多的人使用，就会碰到越来越多的问题，也就会促使项目不断进行完善。开源项目的完善改进不止是代码，对 JSPatch 来说分成很多部分：

1.核心代码。这自然是最重要的部分，修bug填坑，完善功能，必不可少。

2.文档。平时开发 App 不会写文档，但开源项目一定要有文档，而且文档越全面越好，JSPatch 撰写了大量文档，包括每个新功能都会有文档描述。

3.测试用例。测试用例保证项目健壮性，让项目靠谱用起来放心，JSPatch 对大部分功能都写了测试用例。

4.社区。人们使用开源项目最担心的是使用过程有什么问题没人解答，查不到资料。丰富的文档可以部分解决这个问题，此外还需要完善社区支持，包括github issue支持，stackoverflow问答，交流群等，对于扩展性高的开源项目最理想的是做出一个生态环境，像 React JQuery 这类。JSPatch在这方面只做了 github issue 和 QQ 群交流支持，继续完善中。

5.周边。对于JSPatch这样的项目还会有一些周边扩展和工具的完善，JSPatch 提供了像脚本加密下载、多文件include、回退脚本这些周边功能，以及JSPatch Convertor 这样的工具。

有用/推广/完善这三点实际上会形成一个正循环：有用 + 推广 -> 多人用 -> 踩坑 -> 完善(填坑 动力) -> 更好用 -> 更多人用 -> …. 可以说 JSPatch 就是这样运作起来的。

理念

此外，对于 JSPatch 这个项目，我有一些个人理念，用乔布斯的话来说就是：保持精巧，保持好用。

JSPatch 通过几个月的迭代，增加了不少功能，但到现在仍然保持十分小巧的身型，只有三个文件，1600 行 OC 和 90 行 JS 代码，做到这样其实是需要一点删繁去简的心思和理念支撑的。

保持好用方面，除了上面说的满足需求，完善功能，还包括使用起来的体验。对给外部使用的接口我会再三思考，尽量做好。新功能的添加不会影响旧接口，甚至功能也要让位接口，例如要支持给类添加任意参数类型的方法，最简单的是在defineClass接口把这些信息传过去，但这破坏了原有接口，也让这个接口变得很别扭，所以一直没支持，直到有人想出优雅的解决方法“defineProtocol”。接口也要尽量做到好用，例如 defineProtocol 接口不会让使用者传入晦涩的“typeEncode”，而是直接传类型名，在引擎内部做一次转换。

在自己做的新功能，以及 merge 贡献者的 PR 时，都会根据这个理念再三考虑。这样做的好处是让人感觉使用成本低，也就更多人使用，更早进入上面说的循环。一直希望 JSPatch 可以给人一种“核弹头”的感觉，小巧的体积蕴藏巨大的能量。

平台

再说一下 jspatch.com 平台，这个平台提供了 JSPatch 脚本后台托管，版本管理，加解密，灰度条件下发等功能，从开源项目到提供服务平台，思路是很自然的，我想把 hotfix 做到最好，让 JSPatch 使用成本进一步降低，那做一个平台提供这些使用时必不可少的功能是自然的思路，能力范围内能做到就尝试做了。

这个平台接入的 APP 需要不断询问后台是否有脚本更新，接入的人多了后服务器开销成本高，所以一直用内测邀请的方式控制人数，最近为了开放注册做了超出免费额度后收费，这还只是个尝试，最主要的还是推广 JSPatch 的使用，使用的人数多了以后再探索进一步发展。

最后再说下两个问题：苹果审核风险和大公司开源竞争。

风险

JSPatch 有人一直担心审核风险的问题，虽然审核文档上写着下发 JS 可执行代码是可以接受的。但实际上苹果审核很微妙，有经验的人都知道它的审核规则很难捉摸，不同时刻都不一样，有时候人品占据因素更大。

实际上要 APP 完全不能动态化是不可能的，只要能连接后台，一个后台标识下发就能开启和关闭功能，苹果根本不知道，大量 APP 都是这样做的。即使没有 JSPatch，因为OC runtime，APP也可以根据后台下发的字符串做到动态修改任意方法，只是麻烦点。所以苹果对这块是没有办法的，审核规则也很难制定，而 JSPatch 本身主要是用来修复 bug，提高APP质量，情理上说苹果是不会拒绝的。

按我的猜测，苹果会对那些看起来“图谋不轨”的APP会重点关注动态下发这块，像提供视频下载功能，赚钱游戏，积分墙，外挂之类的APP，他们会在审核通过后下发标识或脚本修改功能，这些接入 JSPatch 可能会有风险，而看起来意图正常的APP就不会特别关注。

这是我对苹果善意的猜测，实际上现在大量 APP 接入 JSPatch，也只听说过一例被拒绝。如果跟我想的不一样，苹果要封杀 JSPatch，实际上也是封杀不了的，因为 JSPatch 没有使用私有API，他最多只能通过扫描关键字检测，只需要把关键字改了就没事了。

大公司

关于大公司竞争，川哥提了个问题：如何在大公司统治的开源环境中生存壮大？Facebook、Google出的开源项目都会受到追捧，人们也会本能的相信他们多一些，这样和他们有竞争性的开源项目的处境就很不利。如果 Facebook 出了一个类似 JSPatch 的开源项目，会如何应对？

确实人们对大公司出的开源项目信任度会高一些，但这种优势只在大型框架上，大型框架的使用成本很高，需要很多社区生态支持，特别是像React Native这种类型的项目，没有社区生态支持是搞不了的，个人项目很难做到，这点大公司有优势。而一些解决特定小问题，小而美，使用成本低的开源项目，个人也可以做得很好，大公司并没有很大优势。

开源项目是要有人用才能生长起来的，而个人做大型开源框架的问题就是初期没人使用，也就生长不起来。但小而美使用成本低的项目，只要做到前面说的几个点，就可以慢慢让更多人用起来，生长起来，而且小项目关键点少，在这块已经有很完善的解决方案的情况下，除非有重大突破，否则大公司再做一个一样的已经没什么意义了，开源项目毕竟不是创业产品，大公司不会恶意竞争。典型的案例是 jQuery 和 AFNetworking。

所以开源项目应对大公司竞争的方法就是尽快让项目成长起来，也就回到前面说的几点：有用(+使用成本低)->推广->完善。

QA环节

Q：方便说说你们远景目标么？是打算发展成大平台盈利？

A：没有那么长的远景目标哈，JSPatch目前短期发展目标分两个，一是继续完善修复 bug 功能，完善 JSPatch.com 平台，服务更多 APP，二是完善 JSPatch 周边设施和解决一些性能问题，让 JSPatch 可以很好地胜任动态添加功能模块。

Q：对issue里面不看文档就问的问题怎么看？是否占用了很多精力?

A：会集中处理issue，遇到文档有的问题就贴个链接后直接close，也不会占用很多精力。

Q：JSPatch目前是否具备增加或者删除一个.h .m文件？在使用过程中你们有没有遇到什么大的bug可以跟我们分享下吗？

A：删不了。大的bug方面死锁和webview失效那个可能算吧，http://blog.cnbang.net/tech/3038/ 这篇文章有记录。

Q：之前没了解过，开发周期相对原生态需要来说是怎样的？也就是说开发效率怎样？是否支持debug?

A：目前修bug的话可以直接写JS，也可以写OC代码后用 JSPatchConvertor (https://github.com/bang590/JSPatchConvertor ) 工具转成 JS。支持通过safari断点调试(https://github.com/bang590/JSPatch/wiki/JS-断点调试 )

Q：请问JSPatch对性能的影响有多大，怎么评估的？

A：因为 JSPatch 原理是runtime调用，调用和替换方法时涉及字符串处理，通过字符串查找相应Selector IMP去调用，以及处理参数类型，这个过程会比原生直接调方法慢很多。评估方式一是写大量调用对比耗时，二是做一个实际复杂度不一的 tableView 跟 OC 原生对比 fps，这个还没做。

Q：JSPatch有什么竞品吗？为什么不考虑创业提供专业的热修复服务？

A：JSPatch的竞品是 waxPatch，目前由阿里维护，手Q也在用。热修复我能提供的只是平台，各公司 APP 出现问题都会有原班程序员去写脚本修复，目前我觉得这个需求还没达到能创业的程度;

Q：最开始需要动态修复方案的时候有没有考虑过直接用wax，为什么要选择做一个新的?

A：最开始我在捣鼓 JSPatch 时还不知道有 wax，后来知道了，但当时它年久失修，好几年没更新，官方版连block/arm64都不支持，需要另外去找其他人的实现，用起来会有挺多坑，另外 iOS 自带JS引擎，JS 语言也更流行，能用 JS 写是更好的。

Q：JSPatch的安全性，是怎么做的？

A：安全问题当时写了篇文章(http://blog.cnbang.net/tech/2879/ )，应该说得比较清楚了。

Q：JSPatch的英文文档是你自己写的么？

A：是自己写的，英文不好所以一直没更新，英文真是个硬伤，如果一些JSPatch相关文章能用英语写一遍的话在国外应该会更多人用。

Q：有没有考虑做安卓版本的patch？

A：安卓版本的 patch 现在似乎已经有几个很完善解决方案了，就不再造轮子了。

Q：JSPatch可以调用swift的方法吗？

A：文档有的，需要 swift 类继承自 NSObject，私有成员用 dynamic 才行。

Q：请问建议完全用JSPatch写项目吗？有多大风险？

A：完全用 JSPatch 写项目是没必要，如果是说完全用JSPatch添加功能的话，目前可能会遇到两个问题：1.开发效率，没有代码补全功能写起来比较慢 2.运行效率，像复杂 tableView 滚动这类可能会看得出性能低。接下来会尝试解决这两个问题。

• 国外iOS大牛的分享经验和对Swift的看法

• 移动携程App架构优化之旅

• 从案例学Rxandroid开发（上）

欢迎大家关注：