H5、React Native、Native应用对比分析
@王利华,vczero “存在即合理”。凡是存在的,都是合乎规律的。任何新事物的产生总要的它的道理;任何新事物的发展总是有着取代旧事物的能力。React Native来的正是时候,一则是因为H5发展到一定程度的受限;二则是移动市场的迅速崛起强调团队快速响应和迭代;三则是用户的体验被放大,用户要求极致的快感,除非你牛x(例如:12306最近修改手机号需要用户自己发短信接收验证码)。 最近三四年间,国内外的前端与全栈开发者社区都在坚持不懈地追寻使用JavaScript与HTML、CSS技术体系开发App内场景的核心工程技术。这种技术,在国内很多公司与团队中,被通称为H5。——童遥 这段是取自童老师给小二我新书作的序,没有断章取义的意思。很清楚,H5并不是狭义的HTML5新标签和API,而是工程化的“In App” technology。 iOS/Android ——原生应用(都懂得,不解释)。 React Native —— React & Native ,应运而生! 一、React Native的出现
React Native的出现,似乎是扛起的反H5的旗子。就像当年Facebook放弃H5,全部转向Native一样。这一点,我们需要认同和保持高度的清醒。那么,React Native是否又是在吞食Native的领地呢?技术的发展,是用户风向标的导向起的作用。任何一门技术的出现,都是当时用户需求的体现。 我们应该从以下几点看待React Native的出现。 "鉴往知来"——从过去的教训中总结经验,从用户的角度开拓未来 HTML5vsReact Native?HTML5:React Native 二、3款应用效果
注:以下所有对比均在iOS平台下 三、工程方案
为了评估3种方案的技术优势和弱势。我们需要开发功能大致相似的App。这里,我们使用了“豆瓣”的API来开发“豆搜”应用。该应用能够搜索“图书”、“音乐”、“电影”。想当年,豆瓣以“图书评论”走红,尤其是12年当红!豆瓣是一个清新文艺的社区,一个“慢公司”。最近有一则网传消息,注意是网传——“传京东投1.5亿美元控股豆瓣”。今天,不聊豆瓣,我们要聊一个工程化的问题。 我们需要将3款App的功能做到一致,同时需要保持技术要点一致。比如React Native这里使用了TabBar,那么Native我们也必须使用TabBar。简单而言就是:功能一致,组件 & API一致。我们功能如下图所示: 1、H5方案 2、React Native 3、Native(iOS) 四、对比分析
很多时候,新技术的采用最希望看到的是数据,而不是简单说“用户体验棒,开发效率高,维护成本低”。不过,生活中也有这样的同学,知一二而能窥全貌。当然,本人生性胆小,也没有那么多的表哥和隔壁的老王,所以不敢早下定论,不敢太放肆。赵本山在《大笑江湖》中有句名言“May the force be with you”(别太放肆,没什么用)。因此,从以下几个方面做一个简单的对比。 ----------提纲------------ 1、开发方式
(1)代码结构 2、性能 & 体验
(1)内存 3、更新 & 维护
(1)更新能力 1、开发方式
很多人说React Native的代码不好看,不好理解。那是因为前端工程师都熟悉了Web的开发方式。怎么解决这个问题呢,可以先看看iOS代码,断定不熟悉iOS的同学心里会默念“一万匹**马奔腾”。那时候,你再看React Native,你会觉得使用React Native开发App是件多么美好的事!OK,我们先来看下三者在开始“一款简单App”的代码结构。 (2)UI布局 //JSX <ScrollView style={styles.flex_1}> <View style={[styles.search,styles.row]}> <View style={styles.flex_1}> <Search placeholder="请输入图书的名称" onChangeText={this._changeText}/> </View> <TouchableOpacity style={styles.btn} onPress={this._search}> <Text style={styles.fontFFF}>搜索</Text> </TouchableOpacity> </View> { this.state.show ? <ListView dataSource={this.state.dataSource} renderRow={this._renderRow} /> : Util.loading } </ScrollView> //样式 var styles = StyleSheet.create({ flex_1:{ flex:1,marginTop:5 },search:{ paddingLeft:5,paddingRight:5,height:45 },btn:{ width:50,backgroundColor:'#0091FF',justifyContent:'center',alignItems:'center' },fontFFF:{ color:'#fff' },row:{ flexDirection:'row' } }); 而Native布局就有种让你想吐的感觉,尤其是iOS的布局。这里不是指采用xib或者Storyboard,而是单纯的代码,例如添加一个文本: UILabel *publisher = [[UILabel alloc]init]; publisher.frame = CGRectMake(bookImgWidth + 10,50,200,30); publisher.textColor = [UIColor colorWithRed:0.400 green:0.400 blue:0.435 alpha:1]; publisher.font = [UIFont fontWithName:@"Heiti TC" size:13]; publisher.text = obj[@"publisher"]; [item addSubview:publisher]; 总结:React Native既综合了Web布局的优势,采用了FlexBox和JSX,又使用了Native原生组件。比如我们使用一个文本组件。 (3)UI截面图 当然,我们就会想,能够完全调用原生组件呢?那样性能是否更好? (4)路由/Navigation getCurrentRoutes() - returns the current list of routes jumpBack() - Jump backward without unmounting the current scene jumpForward() - Jump forward to the next scene in the route stack jumpTo(route) - Transition to an existing scene without unmounting push(route) - Navigate forward to a new scene,squashing any scenes that you could jumpForward to pop() - Transition back and unmount the current scene replace(route) - Replace the current scene with a new route replaceAtIndex(route,index) - Replace a scene as specified by an index replacePrevious(route) - Replace the previous scene immediatelyResetRouteStack(routeStack) - Reset every scene with an array of routes popToRoute(route) - Pop to a particular scene,as specified by its route. All scenes after it will be unmounted popToTop() - Pop to the first scene in the stack,unmounting every other scene 相对Native而言,这些接口更Native还是很相似的。 //iOS UINavigationController //相对Web而言,不用自己去实现路由,并且路由更加清晰 [self.navigationController pushViewController:detail animated:YES]; "豆搜" WebApp路由(基于AngularJS)如下: "豆搜" React Native版本导航如下: "豆搜" iOS版本导航代码如下: 总结:React Native封装的导航控制更容易理解。 (5)第三方生态链 2、性能 & 体验
我们都很关注一款App性能。因此测试和体验App的性能很重要。以下测试,都是基于相同的case。 我们再来看下Hybird App的情况。App已启动,占用内存35~55M;同样,跑了2min以上,结果如下图: 最后,看下React Native的情况。App启动占用内存35~60M,同样跑2min以上,结果如下图: 总结:React Native和Web View在简单App上相差不大。二者主要:内存消耗主要是在网页数据上。 (2)CPU 总结:CPU使用率大体相近,React Native的占用率低于Native。 (3)动画 (4)安装包体积 React Native: Native React Native框架包大小 相比快速迭代和热更新,比Native多了811KB一点都不重要,我们将图片素材、静态资源线上更新缓存起来即可减少很多体积。 (5)Big ListView & Scroll 性能 (6)真机体验 总结:Native/React Native的体验相对而言更流畅。 3、更新 & 维护
(1)更新能力 (2)维护成本 总结:React Native 统一了开发人员技术栈,代码维护相对容易。 五、综合
(1)代码结构: React Native更为合理,组件化程度高(2)CPU:React Native居中。 (3)动画:React Native动画需求基本满足。 (4)安装包体积:React Native框架打包后,811KB。相比热更新,可以忽略和考虑资源规划。 (5)Big ListView (6)真机体验:Native >= React Native > H5/Hybrid (1)更新能力: H5/Hybird > React Native > Native |