[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"content-ios-disable-hotfix-and-the-future-of-web":3,"$fx3yse3bc9xp1":20},{"id":4,"type":5,"slug":6,"title":7,"date":8,"category":9,"tags":10,"body_markdown":12,"permalink":13,"excerpt_src":13,"media_type":13,"media_title":13,"media_author":13,"media_url":13,"rating":13,"layout":13,"pv":14,"admin_only":14,"created_at":15,"updated_at":15,"deleted_at":13,"status":16,"html":17,"excerpt":18,"cover":19},171,"article","ios-disable-hotfix-and-the-future-of-web","【蹭热点】从iOS禁用热更新扯到web的未来","2017-03-09 09:24","web",[11,9],"热更新","\n昨天发生了一件不大不小的事情：有相当多的iOS开发者收到了来自苹果的警告邮件，大意是“你的app有动态修改应用逻辑的行为”。说得更通俗一些，就是能绕过app store的发版审核机制，直接进行更新的app基本都收到了警告。\n\n按理说，这其实是一件于情于理都没什么好争辩的事情，毕竟发版本要经过审核是白纸黑字定下的规则。但是这件事情却掀起了轩然大波，甚至连React-Native和Weex都一瞬间有种人人自危的感觉。这到底是为什么呢？\n\n## 审核之痛\n\n首先，为什么有这么多人在明知冒险的情况下仍然会选择使用热更新的方式呢？主要的原因还是苹果的版本发布审核太慢，据说7天以上是家常便饭。试想，一个app发出去，发现有一个bug，用户居然需要一周以上的时候才能更新到修复版本，这个在当前中国互联网环境下确实是不太适用的，所以热更新才能大行其道。\n\n当然，也有一部分人完全是动了歪心思，先合法地上架app，然后再修修修改已上架的app行为，偷偷摸摸做些见不得人的事情。\n\n## web缺席\n\n既然热更新是如此迫切的需求，那难道就没有更好的方案吗？比如……web？天生就热更新，不好么？\n\n当然好。可是web的性能和体验这么差，大部分情况下属于不得已的情况下才会考虑的方案。所以在移动互联网的崛起中，web基本是缺席的。而且这个现象并没有任何好转的迹象。\n\n\u003C!-- more -->\n\n## web在互联网的地位\n\n这一段标题党了，既然都缺席了，还谈何地位？曾经有一段时间，web在移动互联网的应用是很被看好的，也就是HTML5红遍大江南北那几年，随着各种native API（定位、加速计、电池等）的到位和各种hybrid方案的成熟，web一度有要将Android和iOS直接干下马的气势。\n\n然而，时间终将会说明一切。事实证明，一个大而全的web体系并不适合在移动互联网使用。\n\n在《To a Dark Future》一文（见公众号菜单）中，我曾经说过，web标准体系是一个非常繁杂的体系，即使是想在页面上显示一个文本，也会面临一堆的事务需要处理。 同时，由于web标准关注点的迷失，一些长久以来无法很好在web中完成的东西现在仍然缺位。这导致web在移动互联网时代有着天然的性能和体验缺陷，而且短期内看不到有利好的趋势。\n\n## A New Web?\n\n既然大而全的web体系并不适合在移动互联网使用，那是否有替代方案呢？\n\nGoogle给了一个方向，就是PWA。但是思路仍然是在web上做加法。如果这个东西推广成功了，那么至少web可以解决一个老大难的资源加载问题。然而，由于标准制订牵涉到各方利益，目前来看，这个标准基本上不可能推广到iOS中。从昨天的苹果警告热更新应用中更可以明显的感觉到这一信号：苹果不希望自己的应用生态被侵入，而如入PWA能落地，无疑是一个巨大的威胁。\n\n微信也给了一个方向，就是小程序。很多人看完小程序都会有一个感觉：这和web不是同一个东西吗？从技术的角度上来说，小程序之所以和web撇清关系，就是希望抛开繁杂的web体系，重建一个微信自己的新web，而这个新web中什么特性保留什么特性抛弃完全是微信自己掌控。控件不满足需求时新建一种，性能有问题时改一下实现，甚至改一下API也不是什么大事。关于小程序和web的技术考量，我在知乎《微信小程序为什么不用HTML5、CSS，自己搞了个WXML、WXSS，很多框架用不了，好处一点不知道？》这个问题下有详细回答，可[点击查看](\u002Farticle\u002Ftech\u002F2017\u002Fwhy-mini-program-use-self-developed-tech-stack.html)。\n\n## Future\n\n未来会怎样？我在[Dark Future](\u002Farticle\u002Fweb\u002F2017\u002Fto-a-dark-future.html)一文中表示对web前端持悲观态度。\n\n但是……（对，按套路，肯定有但是的……）热更新的需求仍然无比旺盛。如果苹果继续保持审核时的傲骄姿势的话，新web还一定会出现，但既然叫新web，也就跟现有的web没有太大关系了，但这也许是web唯一的出路。\n",null,0,"2026-08-28 04:37:17","published","\u003Cp>昨天发生了一件不大不小的事情：有相当多的iOS开发者收到了来自苹果的警告邮件，大意是“你的app有动态修改应用逻辑的行为”。说得更通俗一些，就是能绕过app store的发版审核机制，直接进行更新的app基本都收到了警告。\u003C\u002Fp>\n\u003Cp>按理说，这其实是一件于情于理都没什么好争辩的事情，毕竟发版本要经过审核是白纸黑字定下的规则。但是这件事情却掀起了轩然大波，甚至连React-Native和Weex都一瞬间有种人人自危的感觉。这到底是为什么呢？\u003C\u002Fp>\n\u003Ch2>审核之痛\u003C\u002Fh2>\n\u003Cp>首先，为什么有这么多人在明知冒险的情况下仍然会选择使用热更新的方式呢？主要的原因还是苹果的版本发布审核太慢，据说7天以上是家常便饭。试想，一个app发出去，发现有一个bug，用户居然需要一周以上的时候才能更新到修复版本，这个在当前中国互联网环境下确实是不太适用的，所以热更新才能大行其道。\u003C\u002Fp>\n\u003Cp>当然，也有一部分人完全是动了歪心思，先合法地上架app，然后再修修修改已上架的app行为，偷偷摸摸做些见不得人的事情。\u003C\u002Fp>\n\u003Ch2>web缺席\u003C\u002Fh2>\n\u003Cp>既然热更新是如此迫切的需求，那难道就没有更好的方案吗？比如……web？天生就热更新，不好么？\u003C\u002Fp>\n\u003Cp>当然好。可是web的性能和体验这么差，大部分情况下属于不得已的情况下才会考虑的方案。所以在移动互联网的崛起中，web基本是缺席的。而且这个现象并没有任何好转的迹象。\u003C\u002Fp>\n\u003Ch2>web在互联网的地位\u003C\u002Fh2>\n\u003Cp>这一段标题党了，既然都缺席了，还谈何地位？曾经有一段时间，web在移动互联网的应用是很被看好的，也就是HTML5红遍大江南北那几年，随着各种native API（定位、加速计、电池等）的到位和各种hybrid方案的成熟，web一度有要将Android和iOS直接干下马的气势。\u003C\u002Fp>\n\u003Cp>然而，时间终将会说明一切。事实证明，一个大而全的web体系并不适合在移动互联网使用。\u003C\u002Fp>\n\u003Cp>在《To a Dark Future》一文（见公众号菜单）中，我曾经说过，web标准体系是一个非常繁杂的体系，即使是想在页面上显示一个文本，也会面临一堆的事务需要处理。 同时，由于web标准关注点的迷失，一些长久以来无法很好在web中完成的东西现在仍然缺位。这导致web在移动互联网时代有着天然的性能和体验缺陷，而且短期内看不到有利好的趋势。\u003C\u002Fp>\n\u003Ch2>A New Web?\u003C\u002Fh2>\n\u003Cp>既然大而全的web体系并不适合在移动互联网使用，那是否有替代方案呢？\u003C\u002Fp>\n\u003Cp>Google给了一个方向，就是PWA。但是思路仍然是在web上做加法。如果这个东西推广成功了，那么至少web可以解决一个老大难的资源加载问题。然而，由于标准制订牵涉到各方利益，目前来看，这个标准基本上不可能推广到iOS中。从昨天的苹果警告热更新应用中更可以明显的感觉到这一信号：苹果不希望自己的应用生态被侵入，而如入PWA能落地，无疑是一个巨大的威胁。\u003C\u002Fp>\n\u003Cp>微信也给了一个方向，就是小程序。很多人看完小程序都会有一个感觉：这和web不是同一个东西吗？从技术的角度上来说，小程序之所以和web撇清关系，就是希望抛开繁杂的web体系，重建一个微信自己的新web，而这个新web中什么特性保留什么特性抛弃完全是微信自己掌控。控件不满足需求时新建一种，性能有问题时改一下实现，甚至改一下API也不是什么大事。关于小程序和web的技术考量，我在知乎《微信小程序为什么不用HTML5、CSS，自己搞了个WXML、WXSS，很多框架用不了，好处一点不知道？》这个问题下有详细回答，可\u003Ca href=\"\u002Farticle\u002Ftech\u002F2017\u002Fwhy-mini-program-use-self-developed-tech-stack.html\">点击查看\u003C\u002Fa>。\u003C\u002Fp>\n\u003Ch2>Future\u003C\u002Fh2>\n\u003Cp>未来会怎样？我在\u003Ca href=\"\u002Farticle\u002Fweb\u002F2017\u002Fto-a-dark-future.html\">Dark Future\u003C\u002Fa>一文中表示对web前端持悲观态度。\u003C\u002Fp>\n\u003Cp>但是……（对，按套路，肯定有但是的……）热更新的需求仍然无比旺盛。如果苹果继续保持审核时的傲骄姿势的话，新web还一定会出现，但既然叫新web，也就跟现有的web没有太大关系了，但这也许是web唯一的出路。\u003C\u002Fp>\n","\u003Cp>昨天发生了一件不大不小的事情：有相当多的iOS开发者收到了来自苹果的警告邮件，大意是“你的app有动态修改应用逻辑的行为”。说得更通俗一些，就是能绕过app store的发版审核机制，直接进行更新的app基本都收到了警告。\u003C\u002Fp>\n\u003Cp>按理说，这其实是一件于情于理都没什么好争辩的事情，毕竟发版本要经过审核是白纸黑字定下的规则。但是这件事情却掀起了轩然大波，甚至连React-Native和Weex都一瞬间有种人人自危的感觉。这到底是为什么呢？\u003C\u002Fp>\n\u003Ch2>审核之痛\u003C\u002Fh2>\n\u003Cp>首先，为什么有这么多人在明知冒险的情况下仍然会选择使用热更新的方式呢？主要的原因还是苹果的版本发布审核太慢，据说7天以上是家常便饭。试想，一个app发出去，发现有一个bug，用户居然需要一周以上的时候才能更新到修复版本，这个在当前中国互联网环境下确实是不太适用的，所以热更新才能大行其道。\u003C\u002Fp>\n\u003Cp>当然，也有一部分人完全是动了歪心思，先合法地上架app，然后再修修修改已上架的app行为，偷偷摸摸做些见不得人的事情。\u003C\u002Fp>\n\u003Ch2>web缺席\u003C\u002Fh2>\n\u003Cp>既然热更新是如此迫切的需求，那难道就没有更好的方案吗？比如……web？天生就热更新，不好么？\u003C\u002Fp>\n\u003Cp>当然好。可是web的性能和体验这么差，大部分情况下属于不得已的情况下才会考虑的方案。所以在移动互联网的崛起中，web基本是缺席的。而且这个现象并没有任何好转的迹象。\u003C\u002Fp>\n","",{"total":14,"totalRoots":14,"comments":21,"pv":14},[]]