闲谈 iOS 的动态化

这篇文章不聊具体的技术内容,只是蹭蹭今天 iOS 领域最大的一个热点,关于一些应用收到 Apple 警告的问题。

我今天刚起床的时候,iOS 圈就炸锅了,很多开发者纷纷表示收到了 Apple 的警告邮件,邮件内容在网上随处可看,在这里我就不贴了。大体意思是说该应用使用了一些动态技术,让应用在审核之后出现一些不一样的功能,从而越过审核去实现更新,警告开发者对代码进行一些检查,去掉这样的实现。

实际上这是一个历史悠久,错综复杂,没有一个统一标准的事情。聊这个事情要从一个很古老的项目开始(我们直接略过不谈 Hybrid 架构的应用,就谈 Native 动态化)。

# 「始作俑者」Wax

最早要从 Wax 这个项目开始说,大家都知道 Objective-C 有着非常强大的动态特性。比如说:

  • 运行时构造类和方法
  • 运行时替换方法的实现

实际上这两个能力是非常恐怖的,他可以让 Cocoa 项目做很多类似黑魔法的事情,简单说就是可以让 Objective-C 像脚本语言那样,文本即代码,无须编译。后来出现了一个叫做 Wax 的项目(这个项目目前由阿里巴巴维护),这个项目打出的口号是用 Lua 来写 iOS 原生应用,当然现实中没有人会这样干,因为写起来实在是太痛苦了。但是鉴于 iOS 应用审核比写 Wax 还痛苦,所以 Wax 成为了做 HotFix 的最佳选择。

这个项目的做法是通过加载 Lua 脚本,动态的生成 Objective-C 的方法,通常用来替换掉出了问题的那个,Lua 脚本是可以动态下发的,所以也就实现了修复线上 bug 的使命。

当然,Wax 用起来是极为痛苦的,尤其是和 Objective-C 的类型转换。

# 后来居上的 JSPatch

iOS 7 的时候 Apple 推出了 JavaScriptCore,这是一个非常有趣的框架,他是 JS 与原生交互的桥梁,让你在原生和 JS 之间穿梭自如,现在 iOS 平台各种动态技术大多都是基于此。

JSCore 推出不久之后,一个更优秀的项目诞生了:由 bang 写的 JSPatch。这个项目无疑从各种角度碾压了 Wax,并且 JS 也比 Lua 更为人熟知,所以也就迅速替代 Wax 成为了热修复的主流选择。

JSPatch 的接入成本非常低,对项目的影响也非常小,不需要引入额外的脚本解释器(因为已经有 JSCore 了),并且 JS 写起来真的比 Lua 要爽很多。

# 异军突起的 React Native 和 Weex

时间继续在走,以 React Native 和 Weex 为代表的各种项目开始冒出来了,他们主要的想法并不是给项目做热修复,而是有更宏大的想法:使用脚本来编写 App 的主要功能。

在 RN 和 Weex 一类的技术里面,JavaScript 是实现原生代码的一种 DSL,通过 Bundle 里面或者下发的 js 文件,原生代码会解析 js 之后做界面渲染的工作。

我个人并没有玩过 RN,但因为在阿里工作过的原因有使用过一段时间 Weex,我个人的感觉是这样的技术驱动力来自于对动态运营的极高要求。

# PY 交易的小程序

技术上并无重大创新但是更为大胆的做法出现了,他直接告诉苹果:我们打算在微信上面加载别的程序,并且起了个名字叫做小程序。小程序推出之后,腾讯和苹果相安无事,我估计这里面是有一些 PY 交易的,事实上从某些角度来说小程序是直接违反 App Store 现存的条款的,但是反正微信就是没事。

# 吊胃口的 DynamicCocoa 和 OCScript

这个其实没有太多好说的,毕竟大家的胃口已经被吊的差不多了,而且按这个样子应该会继续吊下去。

简单说这两个更为激进的方案,希望能够把 JS -> ObjC 这一步都给省了,直接写 ObjC,然后转换到他们自己的一种中间代码,这样的话不需要引入新的学习成本。

PS:作为一行代码都没有就已经 1k 小星星的 repo 来说,DynamicCocoa 这波不亏。

# 动态化的动机在哪里

各种技术的诞生都伴随着各种各样的原因,我们在聊动态化的时候,往往伴随着以下这么几个动机:

  • 动态修复线上 bug
  • 逃避审核,调用私有方法
  • 跨平台开发
  • 开发周期太短,运营需求变化太大

很多历史证明跨平台开发(除了游戏以外)基本是比较扯淡的事情,纯粹这样做的应用大多不会有什么特别的优势,逃避审核和调用私有方法方面也只是少数人才会做的事情。那么修复 bug 和应对需求变化,就成了(国内)很多团队研究这些技术的主流原因。

事实上这件事情在国内外是可以形成鲜明的对比的,这是一个怪现象:

  • 国内应用热衷于做 HotFix
  • 国外应用热衷于做 Code Review

国内的团队总是很急,总是要什么需求就要立刻要,有些甚至是产品经理随意去验证自己的想法,完全不尊重软件研发客观规律的做法。而 App Store 的 Review 是要时间的,所以就开始各种开脑洞想要绕过这个过程。

而很多国外的项目(比如说我现在参与的 Outlook Mobile)完全没有任何动态技术,但是 Code Review 却很严格,开发的周期也比较长,更希望能把问题扼杀在摇篮里。

# 严重之处

其实今天这件事情出来的时候我是表示很震惊的,正如所有 Apple 告诉你的事情一样,这件事情的严重之处在于他的「模糊」,没有人明确的知道 Apple 到底在反对什么,他告诉你很多个可能性,让你自己去找有问题的地方。其实就像中国电影审片一样,没有标准就是最难的标准,甚至有时候会很靠运气。

Apple 在审核条款里面是明确表示不能加载动态的下发脚本,改变应用本身的意图。但是这个定义其实是非常非常含糊的,我认为这不是一个可以明确执行的定义。

  • 什么叫脚本?什么叫程序?
  • 什么样的程度叫做改变了应用本身的意图?
  • 游戏加载脚本是业界通行的做法,Apple 会禁止吗?
  • 为什么 WebView 里面加载 js 就可以呢?
  • 通过 Web 和 Native 来区分是否是动态加载程序这是对的分类吗?
  • 微信小程序到底有什么样的 PY 交易?(逃

总之这件事无论从各种角度来看,都很苹果。

就像飞机上不能携带超过 100ml 的水一样,根本原因是因为安检无法低成本的分辨是否易燃易爆,所以 Apple 非常广泛的发了这样的「震慑」邮件。

# 这样有用吗?

由于 Objective-C 夸张的动态性,其实我们很早就知道,Apple 从技术层面比较难完全防止掉这样事情的发生。

甚至退一步讲,完全不用任何动态技术,也不用任何私有 API,都可以让应用在审核期间看起来和用户用起来是完全不一样的,这种用一个开关来控制的小把戏我想大家都心知肚明。我想 Apple 真正痛恨的应该是这种欺骗,所以他只能尽可能的让这种「变化」还处于他的掌控之中。

毕竟如果一个应用只剩下一个「壳」的话,动态技术可以加载任何内容,App 审核也就形同虚设了,作为一个很有控制欲的公司,这种失控是苹果真正痛恨的。

# 后续发展

从目前来看,Apple 主要针对的是 JSPatch 和 Rollout 一类的热修复框架,这类框架的特点是可以下发后执行任意的 Native Code,而以做 Feature 为主的 React Native 和 Weex 并未被针对。

我个人非常期待这件事的进展,JavaScriptCore 作为一个非常有用的框架,我不希望就这样废掉。甚至我们可以发现,Apple Music 很多地方就是用 JS 实现的,这一点非常有趣。

我希望 Apple 可以在较劲之后找到一个平衡的点,减少自身 SDK 的 bug,加快审核的响应速度,开放一点。

而我们应该做的,就是上线前保证质量,并且祈祷遇到合格的产品经理。(逃

- EOF -

「真诚赞赏,手留余香」
2 人赞赏
林小狗
艾洛克
文章被以下专栏收录
26 条评论
推荐阅读