更多腾讯海量技术文章，请关注腾讯云技术社区：https://cloud.tencent.com/community

作者：王拥军

最近大家都在讨论苹果封杀热更新，觉得苹果手又痒痒了，为了赚钱，无所不用其极。

大家担心一堆游戏要玩不了了，甚至担心微信小程序要完蛋了，更奇葩的还有担心 12306 也不能用了。

作为软件工程师，笔者尝试揣测一下苹果封杀热更新的初衷，以及对行业可能的影响。

我们首先从“APP”和“更新”这两个东东来说，业内人士请直接跳到第 4 段开始。

— 1 —

APP，即 application 的缩写，中文翻译为应用程序。苹果手机上的应用，属于面向用户的终端应用，属于一种计算机应用程序（软件）。

板砖机时代，手机里也有程序，比如俄罗斯方块，这个程序是定死的，不可改变，甚至关机之后，连自己的游戏积分也没了。这就像是小商小贩使用的计算器，功能是定死的，而且无法保存任何历史数据。

这种程序定死的设备，除了早期的板砖机、计算器、游戏机、还有 VCD、DVD、MP3 播放器等等。

小霸王游戏机，想玩什么游戏，必须要买游戏卡，游戏软件是固化在游戏卡里边的。

VCD、DVD、MP3，程序软件是定死的，有些能解码 MP3，有些能解码 MP4，但要解码的音视频内容则存储在碟片上。

小霸王游戏机的主机，相当于计算机硬件系统（处理器、内存等）；

包含有多种游戏的游戏卡，相当于计算机的软件程序，电脑上用软盘、硬盘、光盘存储，游戏机上用游戏卡存储；

包含有音视频内容的碟片，相当于需要处理的各种数据。

这里我们划分了三个角色：看得见摸得着的硬件设备、完成不同任务的软件程序、数据。

DVD/MP3/MP4 的硬件和软件都是定死的，唯一可以更换的就是数据碟片或内存内容，除了看电影，我们不能指望 DVD 干别的。

游戏机还好，可以通过更改游戏卡玩不同的游戏，只不过，特定游戏卡里的游戏是定死的，不能改变。

— 2 —

再来说更新的问题。

相比 VCD 和游戏机，电脑的功能更强大，可以安装不同的应用程序。

在互联网普及之前，如果我们需要购买新的应用程序，就必须要通过购买对应的软盘、光盘，或者优盘。

互联网普及后，我们可以在网络上下载应用程序，比如说 QQ。

最开始的时候，QQ 各个版本的更新，都需要我们手动从 QQ 网站下载，然后手动安装更新。

后来，为了解决版本更新的问题，几乎所有软件都提供了自动下载、自动更新的功能。

刚开始的时候，应用软件将自己整体更新，后来，随着应用软件越来越复杂，体量越来越大，逐渐采取“部分更新”的策略，即：将自己的一部分功能更新。

— 3 —

回头来看苹果手机上的软件更新。

苹果商店有个设置，可以自动更新应用程序，比如微信有了新版本，苹果手机会在晚上的时候帮我们自动下载更新到最新版本的微信。

这个更新动作，是由苹果手机做出的，而不是微信做出的。

尽管最近几年的苹果系统都是默认自动更新，但是，依然有不少用户停用自动更新，选择手动更新应用软件。更何况，整个应用软件的更新，耗费流量比较大，时间也比较长，尤其是动辄几百兆的手机游戏。

问题来了：微信要做一个新的广告，某个游戏要更新一个游戏场景，如果采用更新整个应用程序的方案，代价太高。

于是，软件供应商（微信或游戏）开始采用电脑上常用的“部分更新”策略，自己对自己进行一部分功能的更新，不更新整个应用程序。

从更新方式上，显然，苹果商店的自动更新，所有应用软件依然来自于苹果商店，都是经过苹果审核后的应用软件，因此，这种方式肯定是苹果自己主推的。

— 4 —

热更新的风险

应用软件自己对自己的热更新，无论整体还是部分，既然电脑上可以，苹果手机上为什么就不允许呢？

应用软件自己对自己的热更新，虽然具有很大的便利性，但对用户来讲，具有巨大的“未知风险”。

首先，静默安装导致的用户知情权和控制权风险。比如电脑上，安装一个软件之后，过不多久，就会发现这个软件越来越大，甚至默默的替我们安装了一大堆别的软件。

其次，从好的方面讲，苹果的审核策略保证了所有苹果手机上的软件能够按照苹果设定的用户体验发展，否则的话，真不知道手机的左上角右上角会多出多少小图标，没准时不时的右下角弹出个广告框。

再次，未经审核的软件，是否具有安全风险也未可知。尽管苹果的审核解决不了所有的安全问题，但至少能够解决大部分的安全问题。

还有，未经审核的软件，自己偷偷增加了赚钱的功能，竟然不给苹果分享，当然苹果不乐意了。

所以，无论是从用户体验还是从商业利益的角度，苹果都有很强的欲望禁止应用程序的热更新。

— 5 —

热更新的必要性

然而，如同上边所述的案例，微信要换个广告，游戏要更新个场景，这个需求是存在的。

于是，在保证应用软件的体验、安全、利益的前提下，提供软件的更新，就成为苹果审核的诉求。

所以，以下几种热更新，显然是苹果允许的。

1、数据更新。比如说 12306 更新一下全国的铁路客车时刻表，这只是对数据的更新，应用软件本身的功能并没有发生更改。

2、配置的更新。比如说某些 APP 通过更新图片、颜色来更新外观界面，甚至更新各个按钮的位置。

3、脚本（此处的脚本有歧义）的更新。比如游戏里增加一个故事脚本。

以上这些更新，并没有扩大整个应用程序的功能范围，尽管某些界面的更新会导致用户体验的问题，但不会对安全性、商业利益造成冲击，所以，苹果不会限制。

— 6 —

典型的热更新

以下几种典型的热更新，是否能够通过审核，完全取决于实现的方式，而不是外在的功能。

1、广告更新。

如果仅仅是更新广告内容，显然只是对数据进行更新，并没有对软件功能进行更新，因此是允许的。

如果更改了广告的展现方式，则要区分是用何种技术手段实现的。如果多种广告方式是提前代码里规划好的，只是通过更新配置来更新广告方式，则是允许的。

2、微信小程序

最近微信小程序的功能扩展的非常频繁，从微信推送的说明来看，显然，微信小程序能够调用到的功能和接口都是微信提前定死的，小程序必须通过微信来调用操作系统功能，而无法调用微信不提供的功能。

这就相当于：浏览器里边的 H5 页面，无论如何，都是需要通过浏览器来间接调用系统功能的，而无法直接获取到系统接口权限。

因此，微信小程序是安全的，也是苹果允许的。

3、游戏

游戏是个重灾区。

举个例子来说：要在游戏里搭建一个崭新的城市。

如果游戏引擎中搭建城市的方式是通过配置文件的更改，那么，这些游戏基本上问题不大。

如果游戏引擎中搭建城市的方式是通过一段软件程序直接搭建，那么，风险就比较高了。

如果游戏引擎本身提供的间接接口有限，为了扩展的便利性而提供了直接访问底层系统接口的能力，那么，这种风险就非常高了。

— 7 —

封杀的矛头是什么？

从苹果发送给各个开发者的邮件可以看出，封杀针对的是那些提供系统底层接口访问能力的“热更新框架”，而不是针对“热更新”这个行为。

换句话说：苹果封杀的不是热更新，封杀的是不受控制的底层接口访问。

比如：performSelector、method_exchangeImplementations，这两个方法，提供了访问任何底层接口的能力。审核的时候，应用程序不通过这些方法访问某些敏感性的接口，而审核通过之后，应用程序通过热更新来调用某些对安全有风险的敏感接口。

那么，为什么许多热更新框架要提供这个能力呢？

热更新的目的，当然是为了更改软件的某些数据、配置甚至某些流程、逻辑。

然而，作为一个框架，如果要通过中间件的方式（比如微信对小程序，浏览器对 H5）完美支持所有软件的功能需求，显然要做大量的工作，几乎要将所有苹果允许的系统接口全都封装一遍，这几乎是不可能实现的。

于是，就有了两种结果：要么瞄准某些行业，提供远小于系统完整功能的局部功能；要么，干脆提供一种穿透中间件直达任何系统底层接口的能力。

前一种方案，当然会导致此类框架的应用范围受到极大限制。

后一种方案，虽然满足了所有行业软件开发商的需要，但必然会导致软件功能在审核之后的完全不可控。包括影响系统及用户数据的安全，以及规避苹果对收费提成的诉求。所以，自然会遭到苹果竭尽全力的封杀。

— 8 —

通过上述分析，可以得出一个结论：

如果软件对系统接口的调用在审核期间是完备的，不存在审核之后新增系统接口的可能，那么，无论是否存在热更新，都是允许的。

如果软件对系统接口的调用，尤其是某些敏感接口的调用，在审核之后动态加载，这种方式一定是会被否决的。

同样的，如果软件使用了具备上述能力的框架、SDK 等第三方代码或组件，尽管自己没有调用敏感接口，但由于存在“调用敏感接口的可行性”，因此也是会被否决的。

对于游戏引擎来说，过于通用化的游戏引擎，风险是比较高的，因为游戏引擎开发商为了通用性极有可能会提供不受控制的直达系统接口的访问能力。

从工作量上来说，实现同样的热更新，如果客户端软件做的事情越多，那么，可控的范围越高；客户端软件做的事情越少，那么，为了扩展性，不受控制的范围就越广，风险也就越高。

说句不太好听的话：有什么大不了的功能更新，不能提前在客户端布局好的？非要用这种完全扩展能力的热更新框架？

“没准哪一天我们需要新增大的功能呢？”

苹果审核现在已经够快的了，这么重大的功能，连三天的提前量都预留不出来么？

“突然出了 bug 怎么解决？”

出了 bug，难道没有什么策略能够提前避免或者规避出现这么严重的 bug 么？非要通过热更新？如果连热更新自己都挂了，又该怎么办？

软件工程师是喜欢自由的，不希望受到太多约束。

然而，既然是“工程师”，就要明白：所有“工程”都是有标准有流程的。

一个上万零器件的机器，99%的零件都是标准化的。而且，从机器开始正式使用之前，所有的故障预案都已经做好了。

不能等着软件出现故障了才寻找解决方案，而是在软件分发出去之前，就要有出故障之后的预案。

甚至，一个标准的软件，一大半的代码是在规避故障，以及收集信息以供出现故障之后迅速定位、解决。

除了故障的预防、定位和解决，任何工程的扩展性，尤其是软件的扩展性和延续性，也是一个软件架构是否足够成熟的标志。

相对于面向大型机构的商业软件，苹果手机上面向普通用户的大部分终端软件，还有很多地方值得改进。