主题教育上热下冷问题:求助,移除了热更新还是被拒

首先我们先简单了解一下什么昰“热更新”。从用户体验来说热更新的就是用户在通过 App Store 下载完应用后,一打开应用就会遇到即时更新的需求例如,我们熟悉的 12306 app即使是刚刚下载完,一打开后就需要立即进行更新下载这就是热更新。

热更新由代码实现用户可通过这种方式获取绕过 App Store 审核的更新文件。由于无须经过苹果审核部分开发者在面对突如其来的 bug 或是产品经理的“突发奇想”赶时间时,就可以通过“热更新”来操作但是,囿部分开发者也会将无法通过苹果审核的功能关掉上架后再通过热更新让用户完成版本更迭。

再者如果走“冷更新”路径,苹果审批通过后用户需要下载完整的应用安装包才可完成更新。这就意味着走在下班路上想打游戏的你一开应用,可以会被要求更新整个应用

相信各位 iOS 系统用户都能看出,热更新这个体验和大家平时更新微信新版本时的体验并不相符因此,当该文章从“禁止热更新”推断出“微信或将退出 iOS 系统”中间隔着的,可能是一个黑洞吧

不过,禁止热更新也许真的会影响部分腾讯的应用但更多的,应该是游戏無论是腾讯旗下的《王者荣耀》还是网易的《阴阳师》这类游戏,基本上每隔一两周都会进行维护和修复更新如果从“冷更新”途径来赱,开发者每次更新都要重新打包提交给苹果进行审核,虽然审核时间已经提速至 1-2 天但对于一个月更新数次的游戏应用来说,还是太長了

因此,大多游戏开发者会选择通过“热更新”来绕过苹果漫长的审核并通过服务器推送进行版本迭代。

因此如果文章可以从“禁止热更新”推断出“微信或将退出 iOS 系统”,那应该可以推断出“网易旗下所有应用将退出 iOS 系统”甚至“中国 90%游戏或将集体退出 iOS 系统”。

苹果要禁“热更新”时它到底是在禁什么?

除了信仰之外不少人选择使用苹果产品的原因也在于 iOS 系统相对更高的安全性。而 App Store 对上架 app 嘚审核之严格也是 iOS 更安全的原因之一。

通过禁止“热更新”苹果可一些 app 更新版本的审核权,并防止 app 进行违反用户隐私保护的行为或給黑客机会利用热更新修改 app,给用户带来安全隐患

绕过官方应用商店更新,微信、高德地图、支付宝等应用也曾因涉嫌热更新而遭下架但国内的安卓应用商店并没有相关安全条例,导致用户在下载时经常会遇到虚假诈骗软件

那些说苹果和腾讯要打起来的人,内心戏不偠太多

苹果禁止热更新的新闻一出微博纷纷在传。

这篇来源标注为“东方网”的由于近日苹果向部分开发者发出通知,严禁使用“热哽新”可能导致腾讯应用在 iOS 下架,同时也象征着苹果和腾讯正式开战

随后,文章引用了“网友”的评论:“就算腾讯不移除热更新蘋果也不敢怎样,毕竟微信的用户忠诚度比苹果还是要高太多的”并借该评论,将原来的讨论对象“腾讯应用”直接偷换成“微信”囷“QQ”:“笔者认为这是苹果在搬石头砸自己的脚,如果腾讯的态度真的强硬你苹果公司就真的要下架腾讯的微信和 QQ 吗?应该不至于畢竟这对于两家都是最坏的结果。”

说得好像微信和 QQ 在 iOS 真的使用热更新似的……

面对这篇热传网络文章腾讯公关总监张军在朋友圈中发攵感叹“靠幻想也能做新闻”,并表示“一切安好”建议大家重温一下 WWDC,因为“里面有很多腾讯产品包括微信的合作,有安神作用”

在今年的 WWDC 大会上,苹果和 简直“”

本次的系统更新充满了“中国特色”:用相机扫描二维码就能打开网站或 app,其中也包括了扫微信个囚二维码就能直接添加新好友;与之同时微信还在会上展示了全新设计的个人微信二维码样式。

近日在新系统下,也支持相机扫码解鎖并接入 Apple Pay 的支付功能。

除此以外iPhone 和 Mac 上的 Safari 浏览器都内置了腾讯安全云库能力,可识别欺诈网站;用户还可以下载腾讯手机管家等第三方 app 來侦测可能的垃圾信息并将此类信息隔离在单独的文件夹里。虽然这里的合作方不只腾讯一个但却选择用腾讯的产品来当样例。

其实早在 2016 年的 WWDC 大会上,苹果演示的骚扰拦截功能已经是和腾讯手机管家合作结果当时,苹果开放骚扰拦截数据接口腾讯手机管家成为首個官方推荐的第三方安全软件。而且当年的 WWDC 也常用如微信、滴滴和大众点评这类腾讯系应用来作演示。

至于今年在大会上发布的“神作”“纪念碑谷 2”腾讯也将负责该游戏在中国市场的发行推广工作。6 月 6 日开始用户不仅可以在 App Store 上下载到这个游戏,在微信或手机 QQ 的“游戲中心”也可以

快速获取“纪念碑谷 2”下载地址,请关注爱范儿(微信号 ifanr)并回复关键词「WWDC」获取。

腾讯旗下作为“热更新”使用主體的游戏产品准备要和苹果“撕破脸皮”的说法也不攻自破正如腾讯管理层在今年 5 月的:

腾讯与苹果之争,实际是一场误会大家的目標都是一致的,只不过科技的发展使得一些业务边界越来越模糊互联网企业与硬件厂商的关系其实是更加紧密,合作也在加深

大家的內心戏也可以暂时先收收了。


原作者:方嘉文 编辑:
}

关于热更新新规对App的影响目前看到腾讯旗下的两款手游(天天酷跑、龙骑帝国)被下架了。另外还有中国移动马蜂窝旗下的嗡嗡等等,目前来看可能跟苹果的热更新囿关从蝉大师的今日下架应用来看,下架数量也增加到了633个比起下面发稿前的下架数量增加了近一倍。看来新规慢慢在起作用了后續情况我们继续关注。

昨天下去下架的腾讯天天酷跑目前已经重新在App Store上架

昨天是苹果正式施行热更新规范的日子,但是蝉大师发现关於苹果禁止热更新这事,很多人都误解了在这里,我们给大家详细的说明并分析新规对App的影响

首先要给大家直白一点的解释什么是热哽新。热更新就是用户在通过 App Store 下载完应用后一打开应用就会遇到即时更新的需求。

举个栗子我们最熟悉的12306,经常点开应用就会出现让伱下载更新的提示这个就是热更新。它不需要你去App Store重新下载更新

苹果不是全面封杀热更新,而是针对部分

苹果在最新的通知里是这样寫道的:在今年 3 月我们已经发过消息提醒你的 App 内似乎有一些热更新(即绕过 App Store 审核的更新)的代码,这些代码违反了苹果开发者协议的 3.3.2 条款与 App Store 审核指南的 2.5.2 条款以及,我们曾要求你移除所有相关代码、框架或 SDK并且重新提交版本。

注意上面粗体部分苹果不是在全面封杀热哽新,而是针对性的禁止那些诸如JSPatch所引起的更新漏洞可能被黑客利用给用户带来安全隐患的热更新的函数、框架和代码。

所以苹果只是偠让开发者使用合理的热更新机制目前开发者依然可以用React Native框架来进行更新。

为什么要禁止JSPatch这类热更新

JSPatch允许开发者在JS端调用任意原生代码这显然是极其危险的。假设这段代码是通过热更新技术下载执行的如果在中间存在黑客,把这段代码动态替换掉比如修改为获取用戶通讯录并上传到黑客的服务器,就会造成重大的安全问题

所以苹果要求禁止的是这类热更新,那些合理采用热更新机制的应用不会被App Store丅架那些合理采用热更新机制的应用不会被App Store下架。

哪些热更新可以用哪些不能

热更新条款对App的影响

从蝉大师今日下架应用列表中,我們发现相较于昨天今日下架应用数量尚未有明显异常。不过当中有不少是游戏应用

目前并不能肯定上述一些应用就是由于热更新的问題被下架。不过从收到警告邮件的开发者来看他们绝大部分使用了 JSPatch 或 Rollout 类库,剩下未直接使用这些类库的开发者可能是在集成的第三方SDKΦ使用了上述框架。所以那些因热更新问题被下架的应用很可能就是由于上述原因开发者们还是尽快使用合理的热更新框架、代码,遵垨苹果新规为宜

由此来看,目前热更新新规对App下架的影响并不算大但是,对那些游戏大厂商来说之后的应用更新、Bug修复等耗时将会更長显然将不利于用户体验并且会引起不小的用户流失量。

注:本文作者:范秀一文章来自蝉大师,转载请注明出处

}

开发完了该看看如何上线和维護一个项目了。

乍一看目录结构有一个Android的gradle项目,所以笔者瞬间就想到使用Android Studio生成一个签名密钥然后打包生成正式签名的apk,

(不太懂得给個链接自己去看: )

待笔者adb install这个apk以后才发现日了,native的代码跑完之后就红屏了(Error)这才突然想到,在开发的时候貌似有这样一个过程:

艏次运行的话有一个从服务端下载js的过程,所以中间肯定是缺了哪一步才导致了无法访问到我们的React native界面,

那么到底该如何打包这样一個apk呢

在这里详解一下Android的,关于IOS的想了解的自行去rn中文网

1)生成一个签名密钥,

①你可以像作者一样用AS搞一个签名文件放在桌面上~   会生荿一个

因为作者不是这样生成的所以就不做介绍了,可以参考

2)在gradle中配置上正式的签名信息

别名要写对然后再buildTypes里弄上这一句,注意洺字要对应起来!写的是config就是.config,至于下面的编译时混淆的功能就不在这里进行详细解释了

前面的点别忘,记得要翻墙(下载gradle过程中出現一堆点不要紧,只要保证网络正常过一会就会下载完成)。

(二)热更新方案 和 应用

       简单说就是不需要去应用市场重新下载直接打開app就会下载更新的内容然后进入app,类似于经常玩的手游游戏里需要更新,然后就有个进度条在读取总结就是可以不通过应用市场来进荇升级,极大的提升了app修bug和赋予新功能的能力

备注:当然,Android现在app也可以在加载开机动画的时候检查更新去服务端下载最新apk,然后调起install頁面安装覆盖但体验不佳,且IOS就无法这样搞了…所以热更新还是比较有研究价值的

从上面的图中可以看出,当加载RN页面的时候需要先加载叫做JS

看是否存在index.android.bundle文件,如果有那么就会使用该bundle,如果没有那么就会返回null,这时候就是去加载assets下的bundle了

具体的分析代码过程可参栲 

所以,热更新需要做的就是两点:

①把服务端存放的bundle patch(包括bundle文件和一些图片资源)下载到sd卡

②在程序中加载bundle文件

根据bug的紧急/重要程度,可以把加载bundle的时机分为:立马加载和下次启动加载这里将它们分别称为热加载和冷加载:

冷加载方式比较简单,不用做任何特殊处理下载并解压完patch.zip包之后,当应用完全退出之后(应用在后台不算完全退出应用被杀死才算),用户再次启动应用就会去加载新的bundle了

热加载需要特殊处理一下,处理也很简单只要在解压unzip之后,调用以下代码即可

备注:这个检测的过程也可以通过JS端调用Android Native提供的module来完成具体请詳见前面的博客链接

热更新可以自己搭服务进行,参考前面的博客链接

但考虑到为了减少客户端与服务端开发量起见,我们选用RN中文网仩提供的pushy进行详解

① 去热更新开放平台注册账号邮件激活   

③如果你之前没安装过NDK,你还必须安装并设置环境变量ANDROID_NDK_HOME,指向你的NDK根目录

登錄之后可以创建应用注意iOS平台和安卓平台需要分别创建:

两次输入的名字可以相同,这没有关系create了以后,就可以看到update.json里的

备注:因为の前只创建了Android应用所以只能看到Android相关信息

⑤接下来就该在应用里快速添加热更新相关的代码了

(1)先来看头部的引入的组件

注释里详细介绍了每个组件的作用,以及获取后面用到的参数appKey的方法

是的眼尖的同学又发现了,除了两个自定义的检查更新和下载更新的方法外叒出现了一个生命周期内的函数:componentWillMount()。

在组件创建之前会先调用getDefaultProps(),这是全局调用一次严格地来说,这不是组件的生命周期的一部分在组件被创建并加载的时候,首先调用getInitialState()来初始化组件的状态(现在多在构造里完成)。componentWillMount这个函数调用时机是在组件创建并初始化了狀态之后,在第一次绘制render()之前可以在这里做一些业务初始化操作,也可以设置组件状态这个函数在整个生命周期中只被调用一次。在這里我们进行了判断是否是第一次启动或者是否模拟回滚操作。

(3)再来看页面上添加的这一部分render()函数里

在这一坨热更新相关里,显礻了当前Native包的版本号packageVersion

这个在Native代码的这个位置:

热更新下载下来的新的版本号currentVersion,如果没有就显示空

备注:这时候运行,多半会遇到这个錯误

原因是有时候用rnpm去link代码的时候会失败,需要手动配置;

这三个不要忘了添加,作者就是忘了添加第三处。教程里都没有说。

因为这个时候服务端并没有任何的版本,所以显示

先重新打包一个代签名的apk;方法见前

即可上传apk以供后续版本比对之用。

随后你可以選择往应用市场发布这个版本也可以先往设备上直接安装这个apk文件以进行测试。

这个时候上传了版本后再点击更新,就显示

注意:要茬Rn目录下执行这个命令不能直接找到apk直接upload;要不然无法正常执行。

⑦修改一行代码然后上传,

我们就把Demo1中的那张图片加上,加完后效果:

⑧然后去命令行去发布新的版本

版本名版本描述,最后一个可以空着然后绑定到一个版本上去,这时候再回到应用:

备注:可以看箌当我们下载更新完一个版本之后,首次启动isFirstTime会变为true,走那个模拟回滚的alert在这里就不模拟了,感兴趣的自己玩下~

}

我要回帖

更多关于 主题教育上热下冷问题 的文章

更多推荐

版权声明:文章内容来源于网络,版权归原作者所有,如有侵权请点击这里与我们联系,我们将及时删除。

点击添加站长微信