听说 JSPatch 不能用了?
Posted bestswifter
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了听说 JSPatch 不能用了?相关的知识,希望对你有一定的参考价值。
本着深入理解苹果爸爸文档,贯彻落实苹果精神的原则,我们斟酌一下正文的三段话。
第一段话先重点强调了苹果的审核政策,然后描述了现在违规的两种情况:动态更新、调用私有 API。
第二段话强调了私有 API 存在的安全性,容易遇到 MITM 攻击。
第三段话则提出了对开发者的警告,检查是否存在上述类型的代码。
Weex/RN/JSpatch 谁会倒霉
我们知道 Weex 和 RN 主要用来做热更新和跨平台开发,而 JSPatch 更偏向于修复 bug,动态执行代码,这是 Weex/RN 不具备的能力,他们的端能力是预埋的,受限的。
想要弄明白 Weex/RN 和 JSPatch 谁会倒霉,就要搞明白苹果到底在禁什么,是调用私有 API 的能力还是热更新能力?
从篇幅上看, 苹果重点强调了私有 API 的风险,而我的判断恰好相反,我认为苹果真正的目标其实是应用程序热更新的能力,或者说是苹果的生态系统。
首先,调用私有 API 的能力一直都存在,还会继续存在下去。封掉了 JSPatch 我还可以自己撸一套动态执行代码的框架,或者干脆在本地做混淆。对于苹果来说,调用私有 API 的风险也并大到无法接受,远远小于生态遭受破坏带来的后果。
其次,热更新绕过了苹果的审核流程,使得苹果无法控制 APP 的内容和质量,更失去了控制应用分发的能力。而热更新的技术以 Weex/RN 为代表,直接抛弃了苹果现有的 OC/Swift 语言和 Cocoa 框架,大量开发者转而学习 JS 语法和 UI 框架。开发者的流失是一家非常看重软件生态和开发者生态的公司无法接受的事情。
最后,我们假设苹果的目的是禁止应用热更新,那么他肯定不能直接对外公布:“热更新技术影响到了我们公司的生态利益”,而是选择了一个看上去比较合理的理由:“禁止调用私有 API,防止 MITM 攻击” 来掩人耳目。
所以根据笔者的判断,Weex/RN 有可能首当其冲,而主要用来热修复的 JSPatch 也会受到影响。也许有的开发者会申诉我只用来修 bug,但一旦开了先例, 人的欲望都是无穷的,每个人都会说:“我只蹭蹭不进去”。
当然以上都是笔者私下的猜测,具体的执行标准还是要看苹果的后续通知。然而据我所知,很多大公司(包括阿里、饿了么等)的领导层都在紧急讨论对策。不论如何,打苹果政策的擦边球,风险总是存在的,一旦业务体量大,受到的影响也会比较大。
苹果的目的
总结一下苹果的目的
控制 app 内容审核权,控制分发渠道
控制原生语言、框架的使用场景, 保护开发者资源
如果说苹果还有点小心眼的话,那么禁用了 OC 的动态性,大家用 Swift 的积极性就更高了。
Swift 大法好!
以上是关于听说 JSPatch 不能用了?的主要内容,如果未能解决你的问题,请参考以下文章