尊重版权,未经授权不得转载
本文来自投稿:文章地址:
本篇博客是React Native中比较经典的内容：热更新部署。
Android原生App中我们实现热修复有很多种选择：Tinker、hotFix、Qzone的热更新等等。基本的思路都是大同小异的。React Native中的热更新有点像App的版本更新，也就是根据查询server端的版本和手机端目前App的版本进行对比，然后来执行是否更新的操作。根本原因在于React Native的加载启动机制：React Native会将一系列资源打包成js bundle文件，系统加载js bundle文件，解析并渲染。所以，React Native热更新的根本原理就是更换js bundle文件，并重新加载，新的内容就完美的展示出来了。微软为我们提供了CodePush来简化热更新的操作，但是由于速度等原因在国内并没有备受青睐。本篇内容就以自己服务器来更新的方式实现。
前面简单的说了些基本原理，接下来先上一张具体的更新流程图：
上面流程图中展示了如何实现更新的步骤，可以总结为如下几点：
进入App根据版本检查是否需要更新：
（1）更新：
下载最新JsBundle文件以及所需要的图片资源等，下载完成后解析最新JsBundle文件。
（2）不更新：
判断本地是否还有缓存的JsBundle文件：
本地存在JsBundle，即有过热更新操作。那么App直接加载在缓存目录下的JsBundle文件。
2&不存在：
本地不存在JsBundle，即之前从未有过热更新操作。那么App只能使用初始化时打包在assets目录下的index.android.bundle文件。
Ok，根据上面的流程，我们来看下代码实现过程：
(二).具体实现
2.1.检查是否需要更新
实现步骤即请求服务器中的版本号，然后与本地版本号进行对比，此处我为了代码清晰易懂，直接执行下载更新的流程。
2.2.Android为我们提供了下载工具类：DownLoadManager，我们使用它来执行下载
首先去判断是否存在有下载的更新压缩包，如果有，则先删除旧的，然后下载最新压缩包。
2.3.下载完成后，DownLoadManager会发出一个DownloadManager.ACTION_DOWNLOAD_COMPLETE的广播，在收到广播后，对比下载任务ID
因为我们下载的是Zip压缩文件（Zip压缩文件体积下，有效控制了由于更新文件大以及图片资源占用给用户带来消耗流量的问题），所以我们需要先解压
2.4.解压Zip
2.5.解压完成后，加载最新Bundle和图片资源
如何控制RN加载Bundle的方式呢？没错，0.26版本之后的RN系统在ReactApplication下的ReactNativeHost为我们提供了getJsBundleFile方法，在该方法中默认返回null，即加载assets下的bundle文件。我们可以根据条件来加载不同目录下的bundle文件即可
在当我们下载好最新更新文件后，跳转到RN界面，即会执行getJSBundleFile方法来执行加载Bundle文件的方式。在实际应用当中，我们可以在Splash页面去执行检查更新下载，然后在跳转到RN界面时，最新文件就会呈现出来。
如何获取最新的bundle文件和图片资源呢？我们在RN项目根目执行以下命令来得到bundle文件和图片资源:
react-native bundle --entry-file index.android.js --bundle-output ./bundle/index.android.bundle--platform android--assets-dest./bundle--dev false
（1）--entry
入口js文件，android系统就是index.android.js，系统就是index.ios.js
（2）--bundle-output
生成的bundle文件路径
（3）--platform
（4）--assets-dest
图片资源的输出目录
（5）--dev
是否为开发版本，打正式版的安装包时我们将其赋值为false
执行命令之前，首先要在根目录下创建好bundle文件夹，bundle文件和图片资源将会输出到已创建好的bundle文件夹下。
解压后的最新更新文件：
到此，我们便完成了代码的热更新工作。
(三).优化补丁包更新
大家可能会说，如果bundle太大的情况下怎么办呢？没错，这个问题同样在博客开始也提到了。打包成zip也是为了减小更新文件体积，减少用户流量消耗，同样，我们也可以生成用生成补丁包的方式来进一步减小更新包zip的体积。
初始项目发布时，生成并保留一份index.android.bundle文件。
有版本更新时，生成新的index.android.bundle文件，使用google-diff-match-patch对比两个文件，并生成差异补丁文件。app下载补丁文件，再使用google-diff-match-patch和assets目录下的初始版本合并，生成新的index.android.bundle文件。ok，来看下核心代码：
3.1.生成补丁包
3.2.下载完成，解压后执行mergePatAndAsset方法将Assets目录下的index.android.bundle和pat文件合并
从上述代码中我们看到，合并分为如下过程：
（1）获取Assets目录下的bundle文件，转换为字符串
（2）解析.pat文件将其转换为字符串
（3）调用patch_fromText获取patches补丁包
（4）调用patch_apply方法将第四步中生成patches补丁包与第一步中获取的bundle合并生成新的bundle
（5）保存bundle
3.4.读取pat文件的方法：
3.5.读取Assets目录下的bundle文件：
以上步骤执行完成后，我们就获取到了新的bundle文件，继而加载新的bundle文件，实现React Native热更新。
(四).效果演示
为了演示，先来看更新前的界面：
点击加载最新Bundle，下载最新的，然后加载最新界面：
以上就是使用React Native关于热更新的内容，其实还有很多不足地方，例如对更新文件进行加密，防止被恶意修改等等一些内容还需要不断完善。
整个DEMO实例源代码下载地址:
刚创建的React Native交流九群:,欢迎各位大牛,React Native技术爱好者加入交流!同时博客右侧欢迎微信扫描关注订阅号,移动技术干货,精彩文章技术推送!
尊重原创，转载请注明：From Sky丶清（） 侵权必究！
关注我的订阅号(codedev123),每天推送分享移动开发技术(Android/iOS),React Native技术文章,项目管理,程序猿日常点滴以及精品技术资讯文章(欢迎关注,精彩第一时间推送)。
关注我的微博，可以获得更多精彩内容
在线用户: 2今日访问: 2,936昨日访问: 6,050累计访问: 7,307,650&nbsp>&nbsp
&nbsp>&nbsp
&nbsp>&nbsp
使用React Native开发第一个iOS应用
摘要：来自:http://www.jdon.com/47896这是来自HireArt的TomTang分享他们第一次使用ReactNative开发iOS移动应用。他们的背景是Web开发人员,不是专门的iOS开发人员,虽然,他们也知道Swift或ObjectiveC如何的棒,但是更习惯于使用Ruby和Javascrip,他们的团队开始于2015早期使用Facebook的React,他们认为ReactNative有如下竞争优势:1.一次学习,到处编写,跨设备平台通常都不好,通常为了满足一
来自: http://www.jdon.com/47896
这是来自HireArt的Tom Tang分享他们第一次使用React Native开发iOS移动应用。
他们的背景是Web开发人员,不是专门的iOS开发人员,虽然,他们也知道Swift或Objective C如何的棒,但是更习惯于使用Ruby和Javascrip,他们的团队开始于2015早期使用Facebook的React,他们认为React Native有如下竞争优势:
1.一次学习,到处编写, 跨设备平台通常都不好,通常为了满足一些低级通用标准导致最后结果是次优的,而React Native使用Facebook同样的React.js框架,但是为Android和iOS编写不同的项目,却可以使用同样的一套代码。
2.声明式视图,当他们在Web中使用React时,就非常喜欢React的声明式视图,同样在开发iOS时使用声明式视图意味着更容易可预测的代码和更少的bug。
3.移动flexbox,React Native使用flexbox机会支持所有浏览器
,使得制作布局更加直觉化。 https://css-tricks.com/snippets/css/a-guide-to-flexbox/
当然,除了这些优点化,他们对React Native最初还是有保留意见的:
1. React Native生态圈的限制,初期,基于React Native的各种iOS组件比较少,他们只能自己建立某个SDK(AWS 和Mixpanel).的React Native Bridge。
2.由于React Native升级更快,导致之前的一些代码被遗弃,因此只有在需要新版本新功能才决定升级。
3.网络无法搜索到错误,遭遇一些错误总是前人没有遇到过的,网络上很难查找。
他们还介绍一些组件包:
1. react-native-simple-store ,开始时是使用AsyncStorage,但是发现构建相同的保存和获取功能变得很冗长乏味,太烦人,而这个 Simple Store是基于AsyncStorage 之上构建,能够简单直接访问设备:
Store.get('user').then((user)=& {
// some code }).catch((error) =& {
console.warn(error)
2. react-native-vector-icons ,这是最好的矢量图标工具包,与FontAwesome 和 EvilIcons可以完美地配合使用,MaterialIcons, IonIcons等能通过该包实现:
3. tcomb-form-native ,表单创建使用这个包变得非常容易,你能够定义定制的表单inout类似 键盘或自动纠正等的。
var Person = t.struct({
name: t.String,
// a required string surname: t.maybe(t.String),
// an optional string age: t.Number,
// a required number rememberMe: t.Boolean
// a boolean });
4. react-native-router-flux ,这个包将路由URL变得容易,定义你自己的路由规则,只需要一行代码就可以放入视图:
Actions.dashboard()
最后,Tom Tang也指出使用过程的不可思议奇怪之处,比如,不支持Styling内联,比如有下面CSS Style:
module.exports = StyleSheet.create({
fontSize: 23,
textAlign: 'center',
color: blueText,
fontFamily: 'Avenir',
fontWeight: '700',
padding: 20,
paddingTop: 30,
backgroundColor: '#fff',
borderBottomWidth: 1,
borderBottomColor: '#ccc',
Component.js:
标准的风格如下:
style={Styles.header}
而定制内联风格如下:
style={{color: 'white'}}
他们融合了两种方式的代码:
style={[Styles.header, {color: 'white'}]}
这相当黑了RN,但是不知道有其他什么办法?
另外一个问题是循环Requires/Navigation:这是使用NavigatorIOS时突然发生的,这是在开发某个页面来自哪上一个页面,下面将到哪下一个页面,在iOS中,视图是保存在堆栈中,试图获得一个之前保存在堆栈的组件将导致错误,放入当前组件也会导致一个循环require错误并中断,使用react-native-router-flux 能够解决这个问题,并能以更加合理更扩展性的方式编写路由。
总之,使用React Native开发iOS是一种非常棒的新的开发途径,能够帮助开发团队更快地从Web开发迁移到移动开发。最后他们还在博客中发布以下几个组件开发心得:
1. 登录与权限
2.API和回调
3.使用 RNBridge访问iOS SDK。
[该贴被banq于 14:26修改过]
以上是的内容，更多
的内容，请您使用右上方搜索功能获取相关信息。
若你要投稿、删除文章请联系邮箱：zixun-group@service.aliyun.com,工作人员会在五个工作日内给你回复。
云服务器 ECS
可弹性伸缩、安全稳定、简单易用
&40.8元/月起
预测未发生的攻击
&24元/月起
为您提供0门槛上云实践机会
你可能还喜欢
你可能感兴趣
阿里云教程中心为您免费提供
使用React Native开发第一个iOS应用相关信息，包括
的信息，所有使用React Native开发第一个iOS应用相关内容均不代表阿里云的意见！投稿删除文章请联系邮箱：zixun-group@service.aliyun.com，工作人员会在五个工作日内答复
售前咨询热线
支持与服务
资源和社区
关注阿里云
Internationalreact-native应用被拒，苹果是要杜绝热更吗？ - 知乎19被浏览<strong class="NumberBoard-itemValue" title="分享邀请回答0添加评论分享收藏感谢收起0添加评论分享收藏感谢收起写回答1 个回答被折叠（）react-native应用被拒，苹果是要杜绝热更吗？ - 知乎19被浏览<strong class="NumberBoard-itemValue" title="分享邀请回答0添加评论分享收藏感谢收起RN是一个awesome的技术, facebook很有想法的团队创造出一项新的技术改变了native开发界. 但是RN本身又疑点重重, RN是为了解决什么问题而存在的? 在诞生了一年后, RN又解决了什么问题? 本文通过分析RN的思想, 试图透过技术, 理解动态方案.
RN(React Native)是Facebook推出的mobile开发框架, 使用javascript作为开发的主要语言, 逻辑和样式的处理由javascript完成, 渲染则使用native渲染, 支持Android和iOS两个平台. 对于native开发者, RN通过配置下发能够做到即时生效的上线. 对于web开发者, 能够使用自己熟悉的技术体系做native开发.
一年前, RN推出的时候, 惊艳移动开发业界, 大家都惊呼原来native开发还能这样做 & 跨平台, 动态发布, 简洁的JSX语法, 各种开发工具和调试工具. 我当时也是RN的狂热推崇者, 里面很多思路在当时看来的确是引领了一代创新. 而现在, 在做了一年多native动态性的工作之后, 发现RN的背后问题重重.
问题1 RN是为了解决什么问题而存在的?
观点1 解决跨平台问题
&React Native enables you to build world-class application experiences on native platforms using a consistent developer experience based on JavaScript and React. The focus of React Native is on developer efficiency across all the platforms you care about & learn once, write anywhere. Facebook uses React Native in multiple production apps and will continue investing in React Native.&
摘自, 从这里我们可以看出, 官方是把RN作为一套跨平台的技术方案的,&learn once, write anywhere, 也就是说RN解决了Android, iOS跨平台开发的问题. 但是别忘了, web本身就是跨平台的, HTML, CSS, javascript这些都是.
观点2 解决web体验问题
有人会说, RN是为了解决web开发者在mobile上的性能体验问题. 的确, RN通过使用大量native组件做渲染, 优化了WebKit DOM渲染的性能, 通过batch update和专用线程的设计, 降低javascript和native通信带来的性能开销, 保证主线程的流畅执行. RN的组件loadtime的确比web的好, 因此体验上面, 页面加载更快, 滑动时候局部留白的时间更短, 对用户而言体验效果更好. 但也带来了很多问题.
通常web的开发是建立在W3C完备标准之上, 无论是浏览器中, 还是app中的webview中, 都遵循W3C的一套标准实现. 也就是说web开发不需要关心具体的浏览器是怎样实现的, 只要按照规范开发, 就能跑在各种各样的容器上面, 也是在此基础上, 各种各样的javascript技术蓬勃发展. 反观RN, 官方提供了一套javascript API, 但是和W3C相比, 还不成熟完备. 对于web开发很难说把native这层看为透明的. 或者说, 不改变native完全使用javascript的开发局限性很大. 很可能某个native组件的性能或者功能不满足现有业务需求, 这时就很尴尬, 需要我们深入native的组件. 一旦涉及native组件, 伴随而来的还有版本和兼容等问题. 作为开发而言, 需要熟悉web native和RN框架, 这带来的是开发效率的问题. 但随着官方不断吸纳标准的组件, 这个问题会逐渐变小, 但站在现在, 这个问题的确存在.
站在这个角度上, 如果web开发者也掌握了native开发的技能或者有app开发的支持, 那为什么不直接做成native app? RN的性能和体验和native为主的app还是有差距的. 这里总结下来, RN会提升web体验, 但有一定局限性, 可能成为后面业务发展的瓶颈.
观点3 解决native开发和发布效率问题
有人又会说, native app不能做动态发布, 开发效率低, 而RN可以. 在发布问题上面,&, 因此每次发布都需要通过AppStore审核, 而近期. Android平台上面, 需要解决的是更新率的问题, 目前业界一些插件化动态发布的方案可以完成动态更新, 如手淘的Atlas, 点评的.
开发效率上面如果Android和iOS能够用同一套javascript实现, 在熟悉了RN环境后, 的确可以大幅提升开发效率. 但对于native开发而言, 还是有一定起步成本, 而且还是前面提到的瓶颈问题, 依赖现有native组件的完备程度.
问题2 RN现在解决了什么问题?
按常理讲, 推出技术方案大多基于自身遇到的问题. 但, 而且使用RN的App也大多是小众的App.
相比之下, Facebook的更为抢眼, native端将pageLoad, 交互体验作为最终目标, 提高内容体验. 同时解决内容发布的几个问题, 降低发布门槛, 增加广告收益, 提供数据分析.
RN技术本身并没有什么问题, 问题是各方面都比较好的方案, 在真实业务场景下反而更难用好.
问题3 RN的尴尬源自哪里?
最开始看到javascript+native这种技术, 想到的是端游开发界. 很多端游开发也是使用lua+游戏引擎的技术, lua写逻辑更快, 引擎性能更好. 不同的游戏用多套脚本, 引擎可以持续复用. 这个很像RN解决问题的思路, 但为什么在RN上行不大通呢?
反复的思考后, 觉得根源是在mobile这里. mobile有什么特点? 用户时间碎片化, 单任务. 碎片化怎么理解, 根据, 除了主流的资讯, SNS, 游戏类以外, 一个人使用app次数是分钟级别的, 而使用次数却会有10+次. 单任务怎么理解, 用户在使用手机的时候更难做app切换, 不会像pc中同时开启多个任务去做. 这两个核心的特点决定了, 用户较难以等待, 更容易流失. 所以pageLoad time是很重要的一个指标, 尤其是内容型的页面. 而RN同native相比在pageLoad time上是有很大差距的.
在另一边, 相比web, RN性能虽然比web好, 但灵活程度, 成熟程度远远不如web技术. 而是有web技术开发的业务一般来说对体验的要求有一定容忍. 同时还有Google等在做的专注mobile web page性能的这类项目, 这样RN和web的性能很难拉开大的差距.
这样RN处在了一个不上不下的尴尬位置.
看清问题, 找到解法.
&再 NB 的想法和假设，真正到了实现层面，也必须要落实到具体的用户、需求和场景这三要素上面.&
前面一直在说问题, 不是说不认可RN的技术, 只是不想让大家跟着热潮去入坑, 而关键是要把相关的技术放在一起比较, 看哪个方案适合自己的业务场景.
举个例子, 在有强运营需求的基础功能上, 非常适合用RN来做运营模块. 因为运营的特性是时效性, 到达率, 而基础功能又需要保证稳定的体验. 过去的一年我的团队都在使用native为主+动态模块这种技术, native上提前做好动态模块的支持, 当营销活动点到来时, 可以用RN这种动态技术, 快速响应, 动态上线.
再举个例子, 像做Instant Article这种内容页面, 会有大量的内容, 以几种排版布局展示. 这类的业务的核心是对内容的承载能力, 体验. 像这类的业务应该针对业务的现状和近期发展, 确定适合业务的方案, 并保持对未来的可扩展性. 如果没有运营类的需求场景, pure native的实现可以完全满足需求, 设计后台接口时考虑到布局和组件的扩展性, native上能保证无痛的后续新增和修改布局, 就可以了. 简单的架构也方便后面针对性能瓶颈做持续优化.
总之, 对新技术要保持敏感, 在实际业务的技术选型上还是要保持警惕, 慎重权衡.
阅读(...) 评论()