app实现热更新

咱们博客不能用markdown,我写在csdn了,地址http://blog.csdn.net/zhuchuanwu2013/article/details/51262718,

本人之前从事ios原生开发,自去年11月接触react-native,就对其“learn once, write anywhere”,深深吸引,我们公司开发的是一款在线定制衣服的软件“魔幻工厂”,说到底其实还是一款电商平台app,说到电商就离不开各种搞活动,原先所有的编码都是object-c实现的,这样每次搞活动就要发新版,每次都搞的十分狼狈,筋疲力尽!而且每次上线前都需要其他部门的极力配合,这样就极大的消耗的公司的资源。 在自己摸索了一段时间之后,我决定找一些和搞活动有关或逻辑可能会经常变再或者非常容易出问题的界面迁移到react-native实现,就这样我们试探性的搞了一些界面,比如“魔幻工厂”的首页、个人中心、设置、客服等界面。集成到项目之后,总体感觉还ok,当然这其中遇到许多许多“深坑”,这里不一一列举,以后会单独拿出来总结一下遇到的问题。这里重点讲述react-native的热更新,其实只有实现了热更新,才能随心所欲的修改想修改的内容。 其实原理很简单啦,就是远程提供打包好的bundle,app下载后重新加载即可!这里我们选择使用微软的“codepush”,没有过多要求的话,单纯一个下载bundle、重新加载的功能的话,自己实现起来也不麻烦啦。

codepush官网http://microsoft.github.io/code-push/index.html,集成也十分简单。没有官网控制台,只能安装code=push-cli进行管理项目,

1、安装npm install -g code-push-cli

2、注册账号code-push register,会给你一个token 拿到token进行登录

3、登陆之后,添加需要发布热更新的app名称 这里我添加的叫“wanna” code-push app add “wanna“

到这一步,我们会得到两个key,一个是发布环境下用的,一个是测试环境下用的,记录好两个key。我们现在只是在微软的服务器上注册了一个账号、添加了一个叫“wanna“的app而已,下面我们需要把codepush的sdk引入到我们的项目中。

微软对有两个sdk,一个是针对Cordova的,另一个是针对react-native的,显然我们需要的是react-native的sdk。

1、进入项目根目录下运行 npm install –save react-native-code-push@latest

2、由于我们是原生app后来集成的react-native,所以直接可以通过cocoapods安装到工程中,打开Podfile,添加

pod'CodePush',:path => './node_modules/react-native-code-push'

3、pod install

4、appDelegate添加

#ifdef DEBUG

    self.jsCodeLocation = [NSURL URLWithString:@”http://192.168.1.103:8081/index.ios.bundle?platform=ios”];

#else

    self.jsCodeLocation = [CodePush bundleURLForResource:@”index”];

#endif

5、infoplist里面添加 <key>CodePushDeploymentKey</key> <string>添加完app之后,服务器给你的key,参照最上面第三步(注意这里要选择是正式版的key还是测试版的key,不是发布到appstore可以用Staging的key)</string>

至此,配置完成,然后,让我们立马领略下热更新的魅力吧: 命令行里面输入code-push

可以看到code-push各个命令,

1、code-push release wanna ./bundle/index.jsbundle 1.20.1 –mandatory true

wanna代表我们要更新的项目名称,就是前面我们注册的index.jsbundle是我们要更新的内容,1.20.1是我们在appstore发布的版本号,注意这个地方是我们程序二进制文件的版本号,其实这句命令就是:更新wanna 1.20.1的版本二进制文件,只有1.20.1的版本才能收到更新。最后面的参数是是否强制更新。这段命令没有指定更新的环境是正式环境还是测试环境,默认的是测试环境,如果要发布到正式环境需要指定一下 code-push release wanna ./bundle/index.jsbundle 1.20.1 -d "Production" –mandatory true。 后面还可以在后面添加参数比如1.20.1版本的多少用户可以更新–rollout 20,代表百分之20的wanna 1.20.1的用户可以收到这个更新

2、发布更新之后,比如上面,我们发布更新到了1.20.1的测试版本,更新百分之20的用户,可是我们发布完成之后,想更新百分之30的用户:

code-push patch wanna 1.20.1 –rollout 20

当然还可以改变其他参数啦 patch命令就是更改参数的,目前对patch的理解就是这样。

3、还会遇到这样的场景,我们不能一下子直接更新到正式版吧,因为app如果用户量很大,我们没有经过测试环境这一道关,直接发给用户 总会心里七上八下,顺利还好,万一有问题,找地方哭都找不到地方……比如更新之后,正式版app挂了,这个时候我们想先发布到测试版更新 没问题的时候在发布到正式版,其实上面的更新就是发布到测试版1.20.1。假设上面发到测试版之后,发现一切ok,可以发布到正式版,我们想 如果你去命令行输入 code-push release wanna ./bundle/index.jsbundle 1.20.1 -d "Production" –mandatory true 你会得到错误提示,大体内容就是这个 文件服务器已经有了,不能再发布了。卧槽,这该咋搞?测试版的发布不能搞到正式版吗?答案是肯定的 code-push promote <appName> <sourceDeploymentName> <destDeploymentName>

promote命令 目前我的理解就是把测试环境copy到正式环境,当然你也可以反祈祷而为

4、千防万防,悲催的事情还是发生了,我们发布到正式版的更新居然发生了大面积的崩溃,直接让我们“魔幻工厂”损失好几个亿啊,卧槽,这是要开除“Peter”的节奏,为了防止这种“Peter”式的悲剧发生。code-push提供了回滚机制 code-push rollback <appName> <deploymentName> code-push rollback MyApp Production 目前我的理解是会回滚到上一版本,并未用过该命令,因为我不是“Peter” 5、当然我们发布了不少版本,想看看我们发布了多少更新,咋看?人家网站上没有管理后台。莫愁,人家用命令行管理了,多么吊炸天 code-push deployment history <appName> <deploymentName>

6、还一个需要解释下,上面图中的Active:表示安装你发布更新的,并当前活跃的,Total就是一共多少人安装了这一版,Rollbacks 是安装过程中遇到问题的数量,也就是安装失败的数量

刚开始写博客,比较粗糙写的还,当然也肯定有写的不准确或不对的地方,请大家指正。qq:1317272927 native交流群:317120818 青岛市崂山区松岭路青岛国际创新园 b-12 青岛酷特智能股份有限公司

发表评论

电子邮件地址不会被公开。 必填项已用*标注