React-native如何变为移动端的弄潮儿
转载本文需注明出处:EAWorld,违者必究。
引言:
随着移动端对用户体验要求越来越友好,以及企业对代码能够跨平台执行的迫切需求。React-Native因此应运而生,从出生就一直备受关注。
开发周期的缩短,开发成本和维护成本的降低,简单的代码热更新机制等优点被各大中小企业所钟爱。活跃的社区服务,以及丰富的三方插件都为React-Native注入了强大的生命力。本文将和大家一起找寻React-Native如此火热的原由。
一、React-native的发展
众所周知,React-native是由Facebook开源的一门技术。它的出现也是经历了种种尝试与摸索。Facebook在客户端2.0版本的时候,将主要页面使用web来实现。
网上得知:大约是在2011年,android还在2.3版本、ios还在5.0版本。当时手机硬件和软件优化相对比较差,用户体验一塌糊涂、怨声载道。Facebook无奈只能换成原生来实现。Facebook作为混合应用开发的先驱和探索者,这次失败为React-native的孕育种下了希望种子。失败是成功之母,这句话说的一点没错。React-native想法的出现大约是在2013年一个极客大会上提出的。2014年7月Facebook自己开始实现并尝试使用该项技术,一直到2015年3月份,React-native的ios版本横空出现在世人眼中,同年9月,React-native的android版本也相继亮相世人。React-native大概的发展历程如下:
二、React-native使用案例
RN较H5而言,有以下优势:
1.页面加载速度:React-native号称是99%接近原生体验,它是写js代码,映射原生去渲染页面,页面渲染速度和原生是差不多的。但是H5就不一样,特别依赖手机的硬件配置,ios对H5应用的支持还可以,但是安卓就差太多。安卓里面一些高端机型运行H5应用还可以,但是大部分机型都是会有点卡顿,尤其是像加载图片这种比较消耗资源的操作,H5的页面渲染速度和React-native就会有很明显的差别。
2.机型适配:例如H5对于现在的iPhone x刘海屏的适配就比较麻烦。还有对于很多安卓机型H5并不能做很好的适配。
3.动画效果:H5的动画是通过css和js实现的,对于一些复杂的动画实现相对是比价困难的,也是比较消耗内存的。React-native自身提供了实现动画的API,如果为了过于追求动画的流畅度,React-native还可以借助原生去实现,原生封装出来空间来供给React-native使用。
相对于原生来说,RN也是具有优势的:
1.热更新:做移动开发的都知道,苹果的审核一直让大家很头疼。原生对于紧急的业务开发完成之后,还必须等待苹果的审核才能上线,这个时候React-native就体现出来它的优势,在不碰及原生代码的时候,可以直接通过热更新js代码来实现实时发布。React-native可以很好的支持线上业务功快速迭代和随时更新发布。
2.开发效率:React-native有20%的代码是原生代码,80%的代码为可以复用的js代码,这样大大缩短了开发周期,为企业节省了发开成本。
3.维护成本低:如果业务仅仅涉及到js代码的修改,在APP开发需求少的情况下,一个React-native工程师就可以很好的维护本该APP,同时又为企业节省了维护成本(即使刚开始该工程师不会原生开发,但是经过长时间的锻炼,或多或少都会一点)。
4. 学习成本低:React-native使得之前做前端的工程师可以快速的参与APP的开发,降低了学习成本。
5. 扩展性强:React-native提供了自定义原生控件以供js调用渲染的API,这使得它的扩展性极其强大。
此外,RN还具有其特殊的背景优势:
1.React-native作为Facebook的“亲儿子”,依靠这棵大树,让这个技术一直在不断的完善。
2.React-native本身是开源的,所有的源代码都是可以看到的。React-native从开源道现在就备受关注,React-native是历史上第一个没到正式版本,github却有7w+星星的项目。社区的组件得益库也已经比较丰富,社区活跃度比较高。对于很多复杂的组件,我们都不需要重复再去造轮子。
三、React-native使用案例
案例一:三个月重构两个APP
当时公司在进行后台重构的同时,CTO也打算把APP使用React-native进行重构一遍。我一个做安卓的和两个ios的一起边学边做,摸着石头过河,我们用了三个月时间完成APP重构。主要功能涉及到聊天,微信分享等业务功能。然后因为特殊原因自己离开,APP由两个ios进行维护以及新功能迭代(自己在走之前教会ios同事安卓的打包和发布)。再到后来另一个ios同事也离开做前端去了,就剩下一个人。在公司需求少的情况下,他一个维护这个APP已经是绰绰有余(药店帮手)
案例二:使用RN效率提升
在两个APP开发人员,开发维护三个APP,并且公司的需求迭代特别频繁的背景下。如果没有使用React-native这个技术,公司一个月的需求我评估使用原生两个人最少需要两个月,甚至更长。但是使用React-native之后,任务是两个人均摊的,并且彼此的代码都可以看懂,这大大加快我们的开发速度。
那么,企业选择RN的原因有哪些呢?我认为有如下几点:
使用React-native之后,代码更新方便以此来满足紧急。当业务需求少的时候,APP较少的人员就可以维护。
隐藏价值:如果公司使用React技术栈,那么前端人员经过较短的学习时间就可以快速参与到APP开发当中,同样APP开发人员经过较短时间学习就可以进入前端开发中,这样极大的对人才进行了复用。这就是为什么那么多小公司如此钟爱使用React-native技术进行APP开发。极大的缩短了开发周期短。
同时也有一部分大公司使用React-native和原生进行混合开发,React-native页面嵌在原生里面。我个人觉得他们这做的原因是:对于经常需求修改的页面使用H5体验又不好,使用原生热更新比较困难,结合这两点,React-native就理所当然的成了最好的选择。
当然,也不能盲目选择,应该辩证的看待RN。我们上面列举了那么多React-native的优点,但是并不代表我们就能完完全全抛弃原生。React-native并不是一个完美的技术方案,它也有其自身的缺点。所以对于React-native技术选择,需要企业考虑学习成本,开发成本,维护成本,以及企业自身的业务等等实际情况来评估是否选择React-native这门技术。
四、展望
现在很多游戏APP都开始使用React-native来做壳。一些大公司也在逐步将一些业务使用React-native来替换。React-native依靠Facebook这个亲‘爸爸’,版本迭代特别快,也一直在不断完善中。
Facebook现在的口号是:
Learn once,Write anywhere。
我认为会有那么一天实现
Write once,run anywhere。
关于作者:范涛,普元React-native开发工程师,毕业于长沙理工大学,专注于使用React-native开发APP,负责太平洋保险APP内部保险箱务RN改造业务。
关于EAWorld:微服务,DevOps,数据治理,移动架构原创技术分享。长按二维码关注!
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
Netty解决粘包和拆包问题的四种方案
在RPC框架中,粘包和拆包问题是必须解决一个问题,因为RPC框架中,各个微服务相互之间都是维系了一个TCP长连接,比如dubbo就是一个全双工的长连接。由于微服务往对方发送信息的时候,所有的请求都是使用的同一个连接,这样就会产生粘包和拆包的问题。本文首先会对粘包和拆包问题进行描述,然后介绍其常用的解决方案,最后会对Netty提供的几种解决方案进行讲解。这里说明一下,由于oschina将“jie ma qi”认定为敏感文字,因而本文统一使用“解码一器”表示该含义 1. 粘包和拆包 产生粘包和拆包问题的主要原因是,操作系统在发送TCP数据的时候,底层会有一个缓冲区,例如1024个字节大小,如果一次请求发送的数据量比较小,没达到缓冲区大小,TCP则会将多个请求合并为同一个请求进行发送,这就形成了粘包问题;如果一次请求发送的数据量比较大,超过了缓冲区大小,TCP就会将其拆分为多次发送,这就是拆包,也就是将一个大的包拆分为多个小包进行发送。如下图展示了粘包和拆包的一个示意图: 上图中演示了粘包和拆包的三种情况: A和B两个包都刚好满足TCP缓冲区的大小,或者说其等待时间已经达到TCP等待时长,从...
- 下一篇
码上用它开始Flutter混合开发——FlutterBoost
摘要:具有一定规模的App通常有一套成熟通用的基础库,尤其是阿里系App,一般需要依赖很多体系内的基础库。 开源地址:https://github.com/alibaba/flutter_boost 为什么要混合方案 具有一定规模的App通常有一套成熟通用的基础库,尤其是阿里系App,一般需要依赖很多体系内的基础库。那么使用Flutter重新从头开发App的成本和风险都较高。所以在Native App进行渐进式迁移是Flutter技术在现有Native App进行应用的稳健型方式。 闲鱼在实践中沉淀出一套自己的混合技术方案。在此过程中,我们跟Google Flutter团队进行着密切的沟通,听取了官方的一些建议,同时也针对我们业务具体情况进行方案的选型以及具体的实现。 官方提出的混合方案 1基本原理 Flutter技术链主要由C++实现的Flutter Engine和Dart实现的Framework组成(其配套的编译和构建工具我们这里不参与讨论)。Flutter Engine负责线程管理,Dart VM状态管理和Dart代码加载等工作。而Dart代码所实现的Framework则是业务接...
相关文章
文章评论
共有0条评论来说两句吧...