Hybrid APP基础篇(二)->Native、Hybrid、React Native、Web App方案的分析比较
说明
Native、Hybrid、React、Web App方案的分析比较
目录
前言
参考来源
前人栽树,后台乘凉,本文参考了以下来源
- 对当前主流hybrid app、web app与native app工具的初步比较与分析
- H5、React Native、Native应用对比分析
- 如何评价 React Native
- 论Web App、Hybrid App以及Native App的设计差异
- H5、React Native、Native应用对比分析
- HybridApp解决方案_No1_混合模式(Hybrid)App开发概述
- 聊聊Web App、Hybrid App与Native App的设计差异
- 微信小程序,大多数人误解的8个问题
前置技术要求
阅读本文前,建议先阅读以下文章
楔子
目前的主流应用程序有四大类型:Native App、Hybrid App、React Native App、Web App。本文分别对这几种方案做一些分析对比
几种APP开发模式
概述
当前的APP开发模式注意有以下四大类型:
- Native App
即传统的原生APP开发模式,Android基于Java语言,底层调用Google的 API;iOS基于OC或者Swift语言,底层调用App官方提供的API。体验最后。
- Web App
即移动端的网站,将页面部署在服务器上,然后用户使用各大浏览器访问。一般泛指 SPA(Single Page Application)模式开发出的网站。体验最差。
- Hybrid App
即混合开发,由Native通过JSBridge等方法提供统一的API,然后用Html5+JS来写实际的逻辑,调用API,这种模式下,由于Android,iOS的API一般有一致性,而且最终的页面也是在webview中显示,所有有跨平台效果
- React Native App
Facebook发起的开源的一套新的APP开发方案,使用JS+部分原生语法来实现功能。初次学习成本较高,但是在入门后,经过良好的封装也能够实现大部分的跨平台。而且体验很好。
脑图地址: http://naotu.baidu.com/file/1eb556f3380e8189be859348527ec518?token=a5a049eb4c618e70
Native App
即原生开发模式,开发出来的是原生程序,不同平台上,Android和iOS的开发方法不同,开发出来的是一个独立的APP,能发布应用商店,有如下优点和缺点
优点
- 直接依托于操作系统,交互性最强,性能最好
相比于其它模式的交互,原生APP体验是最优的
- 功能最为强大,特别是在与系统交互中,几乎所有功能都能实现
得益于原生是直接依托于系统的,所以可以直接调用官方提供的api,功能最为全面(比如本地资源操作,通知,动画等)
缺点
- 开发成本高,无法跨平台,不同平台Android和iOS上都要各自独立开发
Android上基于Java开发,iOS上基于OC或Swift开发,相互之间独立,必须要有各自的开发人员
- 门槛较高,原生人员有一定的入门门槛,相比广大的前端人员而言,较少
原生的一个很大特点就是独立,所以不太容易入门,不像web前端一样那么广泛,而且Android,iOS都需要独立学习
- 更新缓慢,特别是发布应用商店后,需要等到审核周期
原生应用更新是一个很大的问题,Android中还能直接下载整包APK进行更新,但是iOS中,如果是发布AppStore,必须通过AppStore地址更新,而每次更新都需要审核,所以无法达到及时更新
- 维护成本高
同开发一样,项目上线后,维护起来也很为麻烦
Web App
即移动端的网站,将页面部署在服务器上,然后用户使用各大浏览器访问,不是独立APP,无法安装和发布
Web网站一般分两种,MPA(Multi-page Application)和SPA(Single-page Application)。而Web App一般泛指后面的SPA形式开发出的网站(因为可以模仿一些APP的特性),有如下优点和缺点
优点
- 开发成本低,可以跨平台,调试方便
web app一般只需要一个前端人员开发出一套代码,然后即可应用于各大主流浏览器(特殊情况可以代码进行下兼容),没有新的学习成本,而且可以直接在浏览器中调试
- 维护成本低
同上,如果代码合理,只需要一名前端就可以维护多个web app
- 更新最为快速
由于web app资源是直接部署在服务器端的,所以只需要替换服务器端的文件,用户访问是就已经更新了(当然需要解决一些缓存问题)
- 无需安装App,不会占用手机内存
通过浏览器即可访问,无需安装,用户就会比较愿意去用
缺点
- 性能低,用户体验差
由于是直接通过的浏览器访问,所以无法使用原生的API,操作体验不好
- 依赖于网络,页面访问速度慢,耗费流量
Web App每次访问都需要去服务端加载资源访问,所以必须依赖于网络,而且网速慢时访问速度很不理想,特别是在移动端,如果网站优化不好会无故消耗大量流量
- 功能受限,大量功能无法实现
只能使用Html5的一些特殊api,无法调用原生API,所以很多功能存在无法实现情况
- 临时性入口,用户留存率低
这既是它的优点,也是缺点,优点是无需安装,确定是用完后有时候很难再找到,或者说很难专门为某个web app留存一个入口,导致用户很难再次使用
Hybrid App
即混合开发,也就是半原生半Web的开发模式,有跨平台效果,当然了,实质最终发布的仍然是独立的原生APP(各种的平台有各种的SDK),有如下优点和缺点
优点
- 开发成本较低,可以跨平台,调试方便
Hybrid模式下,由原生提供统一的API给JS调用,实际的主要逻辑有Html和JS来完成,而由于最终是放在webview中显示的,所以只需要写一套代码即可,达到跨平台效果,另外也可以直接在浏览器中调试,很为方便
最重要的是只需要一个前端人员稍微学习下JS api的调用即可,无需两个独立的原生人员
一般Hybrid中的跨平台最少可以跨三个平台:Android App,iOS App,普通webkit浏览器
- 维护成本低,功能可复用
同上,如果代码合理,只需要一名前端就可以维护多个app,而且很多功能还可以互相复用
- 更新较为自由
虽然没有web app更新那么快速,但是Hybrid中也可以通过原生提供api,进行资源主动下载,达到只更新资源文件,不更新apk(ipa)的效果
- 针对新手友好,学习成本较低
这种开发模式下,只需要前端人员关注一些原生提供的API,具体的实现无需关心,没有新的学习内容,只需要前端人员即可开发
- 功能更加完善,性能和体验要比起web app好太多
因为可以调用原生api,所以很多功能只要原生提供出就可以实现,另外性能也比较接近原生了
- 部分性能要求的页面可用原生实现
这应该是Hybrid模式的最多一个好处了,因为这种模式是原生混合web,所以我们完全可以将交互强,性能要求高的页面用原生写,然后一些其它页面用JS写,嵌入webview中,达到最佳体验
缺点
- 相比原生,性能仍然有较大损耗
这种模式受限于webview的性能桎梏,相比原生而言有不少损耗,体验无法和原生相比
- 不适用于交互性较强的app
这种模式的主要应用是:一些新闻阅读类,信息展示类的app;但是不适用于一些交互较强或者性能要求较高的app(比如动画较多就不适合)
React Native App
Facebook发起的开源的一套新的APP开发方案,Facebook在当初深入研究Hybrid开发后,觉得这种模式有先天的缺陷,所以果断放弃,转而自行研究,后来推出了自己的“React Native”方案,不同于H5,也不同于原生,更像是用JS写出原生应用,有如下优点和缺点
其实很多大公司都已经转React Native开发了,已经很成熟了
优点
- 虽然说开发成本大于Hybrid模式,但是小于原生模式,大部分代码可复用
相比于原生模式,这种模式是统一用JS写代码,所以往往只需要一名成员投入学习,即可完成跨平台app的开发,而且后续代码封装的好,很多功能可复用
- 性能体验高于Hybrid,不逊色与原生
这种模式和Hybrid不一样,Hybrid中的view层实际上还是dom,但是这种模式的view层是虚拟dom,所以性能要高于Hybrid,距离原生差距不大
这种模式可以认为是用JS写原生,即页面用JS写,然后原生通过Bridge技术分析JS,将JS内容单独渲染成原生Android和iOS,所以也就是为什么性能不逊色原生
- 开发人员单一技术栈,一次学习,跨平台开发
这种模式是统一由JS编写,有着独特的语法,所以只需要学习一次,即可同时开发Android和iOS
- 社区繁荣,遇到问题容易解决
这应该是React Native的很大一个优势,不像Hybrid模式和原生模式一样各自为营,这种模式是Facebook统一发起的,所以有一个统一的社区,里面有大量资源和活跃的人员,对开发者很友好
缺点
- 虽然可以部分跨平台,但并不是Hybrid中的一次编写,两次运行那种,而是不同平台代码有所区别
这种模式实际上还是JS来写原生,所以Android和iOS中的原生代码会有所区别,如果需要跨平台,对开发人员有一定要求
当然了,如果发展了有一定时间,组件库够丰富了,那么其实影响也就不大了,甚至会比Hybrid更快
- 开发人员学习有一定成本
虽然社区已经比较成熟了,但是一个新的普通前端学习起来还是有一定学习成本的,无法像Hybrid模式一样平滑
分析
各大开发模式直观对比
以下是各大模式的直观对比分析
对比表格
Native App | Web App | Hybrid App | React Native App | |
---|---|---|---|---|
原生功能体验 | 优秀 | 差 | 良好 | 接近优秀 |
渲染性能 | 非常快 | 慢 | 接近快 | 快 |
是否支持设备底层访问 | 支持 | 不支持 | 支持 | 支持 |
网络要求 | 支持离线 | 依赖网络 | 支持离线(资源存本地情况) | 支持离线 |
更新复杂度 | 高(几乎总是通过应用商店更新) | 低(服务器端直接更新) | 较低(可以进行资源包更新) | 较低(可以进行资源包更新) |
编程语言 | Android(Java),iOS(OC/Swift) | js+html+css3 | js+html+css3 | 主要使用JS编写,语法规则JSX |
社区资源 | 丰富(Android,iOS单独学习) | 丰富(大量前端资源) | 有局限(不同的Hybrid相互独立) | 丰富(统一的活跃社区) |
上手难度 | 难(不同平台需要单独学习) | 简单(写一次,支持不同平台访问) | 简单(写一次,运行任何平台) | 中等(学习一次,写任何平台) |
开发周期 | 长 | 短 | 较短 | 中等 |
开发成本 | 昂贵 | 便宜 | 较为便宜 | 中等 |
跨平台 | 不跨平台 | 所有H5浏览器 | Android,iOS,h5浏览器 | Android,iOS |
APP发布 | App Store | Web服务器 | App Store | App Store |
如何选择开发模式
目前有多种开发模式,那么我们平时开发时如何选择用哪种模式呢?如下
选择纯Native App模式的情况
- 性能要求极高,体验要求极好,不追求开发效率
一般属于吹毛求疵的那种级别了,因为正常来说如果要求不是特别高,会有Hybrid
选择Web App模式的情况
- 不追求用户体验和性能,对离线访问没要求
正常来说,如果追求性能和体验,都不会选用web app
- 没有额外功能,只有一些信息展示
因为web有限制,很多功能都无法实现,所以有额外功能就只能弃用这种方案了
选择Hybrid App模式的情况
- 大部分情况下的App都推荐采用这种模式
这种模式可以用原生来实现要求高的界面,对于一些比较通用型,展示型的页面完全可以用web来实现,达到跨平台效果,提升效率
当然了,一般好一点的Hybrid方案,都会把资源放在本地的,可以减少网络流量消耗
选择React Native App模式的情况
- 追求性能,体验,同时追求开发效率,而且有一定的技术资本,舍得前期投入
React Native这种模式学习成本较高,所以需要前期投入不少时间才能达到较好水平,但是有了一定水准后,开发起来它的优势就体现出来了,性能不逊色原生,而且开发速度也很快
另类的app方案
除了以上的几种常见app开发模式,其实还有一些其它的类似方案
微网页
比如在进行微信网页开发时,可以调用一些微信的特殊api,这其实就是算是微信的Hybrid模式,实质上仍然是在浏览器中(只不过是腾讯的X5内核)
当然了,微信在这方面做了很多限制,比如权限认证等等,所以导致开发起来效果不是很完美。这里不再赘述其功能
微信小程序
微信小程序是微信新推出的一种新的app方案,2016年9月开始进行内测,2016年11月准备全面面向开发者
需要注意的是,这种模式是“反HTML5”的,相当于是微信提供的一套封闭开发模式,有自己的语法和IDE,有的类似于iOS开发的感觉。具体也不赘述,请参考引用来源中的文章
其它
当然除此外,还有一些其它的模式,比如“百度直达号”,"流应用"等等,这里不再赘述
Hybrid APP基础篇(二)->Native、Hybrid、React Native、Web App方案的分析比较的更多相关文章
- Hybrid APP基础篇(三)->Hybrid APP之Native和H5页面交互原理
本文已经不维护,新地址: http://www.cnblogs.com/dailc/p/8097598.html 说明 Hybrid模式原生和H5交互原理 目录 前言 参考来源 前置技术要求 楔子 A ...
- Hybrid APP基础篇(四)->JSBridge的原理
说明 JSBridge实现原理 目录 前言 参考来源 前置技术要求 楔子 原理概述 简介 url scheme介绍 实现流程 实现思路 第一步:设计出一个Native与JS交互的全局桥对象 第二步:J ...
- php基础篇-二维数组排序 array_multisort
原文:php基础篇-二维数组排序 array_multisort 对2维数组或者多维数组排序是常见的问题,在php中我们有个专门的多维数组排序函数,下面简单介绍下: array_multisort(a ...
- React Native & react-native-web-player & React Native for Web
React Native & react-native-web-player & React Native for Web https://github.com/dabbott/rea ...
- Hybrid APP基础篇(一)->什么是Hybrid App
最新更新 一个开源的快速混合开发框架:https://github.com/quickhybrid/quickhybrid Android.iOS.JS三端内容初步都已经完成,有完善的设计思路.教程以 ...
- react基础篇二
组件 & Props & 生命周期 组件可以将UI切分成一些独立的.可复用的部件,这样你就只需专注于构建每一个单独的部件. 组件从概念上看就像是函数,它可以接收任意的输入值(称之为“p ...
- Qt入门之基础篇 ( 二 ) :Qt项目建立、编译、运行和发布过程解析
转载请注明出处:CN_Simo. 题解: 本篇内容主讲Qt应用从创建到发布的整个过程,旨在帮助读者能够快速走进Qt的世界. 本来计划是讲解Qt源码静态编译,如此的话读者可能并不能清楚地知道为何要静态编 ...
- docker+k8s基础篇二
Docker+K8s基础篇(二) docker的资源控制 A:docker的资源限制 Kubernetes的基础篇 A:DevOps的介绍 B:Kubernetes的架构概述 C:Kubernetes ...
- JavaScript笔记基础篇(二)
基础篇主要是总结一些工作中遇到的技术问题是如何解决的,应为本人属于刚入行阶段技术并非大神如果笔记中有哪些错误,或者自己的一些想法希望大家多多交流互相学习. 1.ToFixed()函数 今天在做Birt ...
随机推荐
- BZOJ2226:LCMSum(欧拉函数)
Description Given n, calculate the sum LCM(1,n) + LCM(2,n) + .. + LCM(n,n), where LCM(i,n) denotes t ...
- HTTP 请求头中的 X-Forwarded-For,X-Real-IP
X-Forwarded-For 在使用nginx做反向代理时,我们为了记录整个的代理过程,我们往往会在配置文件中做如下配置: location / { 省略... proxy_set_header ...
- json 压缩中文不转码
$testJSON=array('name'=>'中文字符串','value'=>'test'); echo json_encode($testJSON, JSON_UNESCAPED_U ...
- Java应用中的编码问题(转载)
第三篇:JAVA字符编码系列三:Java应用中的编码问题这部分采用重用机制,引用一篇文章来完整本部分目标.来源: Eceel东西在线 问题研究--字符集编码 地址:http://china.ecee ...
- lucene查询语法简介
为什么要介绍lucene:我们在ELK中搜索相关日志的时候,搜索语言需要遵循Lucene才可以匹配到需要的信息 什么是Lucene:Lucene是一套用于全文检索和搜寻的开源程式库,由Apache软件 ...
- MetaMask/metamask-extension-provider
用来探测你的浏览器中有没有安装metamask插件 https://github.com/MetaMask/metamask-extension-provider MetaMask Extension ...
- android camera 摄像头预览画面变形
问题:最近在处理一下camera的问题,发现在竖屏时预览图像会变形,而横屏时正常.但有的手机则是横竖屏都会变形. 结果:解决了预览变形的问题,同时支持前后摄像头,预览无变形,拍照生成的jpg照片方向正 ...
- 使用sysbench 进行msyql oltp压力测试
安装参考: https://github.com/akopytov/sysbench#linux#参数说明 需要说明的选项: mysql-db=dbtest1a:测试使用的目标数据库,这个库名要事先创 ...
- D. Jzzhu and Cities
Jzzhu is the president of country A. There are n cities numbered from 1 to n in his country. City 1 ...
- 串口通信DMA中断
这是以前学32的时候写的,那时候学了32之后感觉32真是太强大了,比51强的没影.关于dma网上有许多的资料,亲们搜搜,这里只贴代码了,其实我也想详详细细地叙述一番,但是自己本身打字就慢,还有好多事情 ...