部分性能要求的页面可用原生实现。这应该是Hybrid模式的最多一个好处了,因为这种模式是原生混合web,所以我们完全可以将交互强,性能要求高的页面用原生写,然后一些其它页面用JS写,嵌入webview中,达到最佳体验
相比原生,性能仍然有较大损耗。这种模式受限于webview的性能桎梏,相比原生而言有不少损耗,体验无法和原生相比
不适用于交互性较强的app。这种模式的主要应用是:一些新闻阅读类,信息展示类的app;但是不适用于一些交互较强或者性能要求较高的app(比如动画较多就不适合)
React Native App
Facebook发起的开源的一套新的APP开发方案,使用JS+部分原生语法来实现功能。初次学习成本较高,但是在入门后,经过良好的封装也能够实现大部分的跨平台。而且体验很好。
虽然说开发成本大于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 AppWeb AppHybrid AppReact 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模式的情况