本人负责的APP项目即将搭建团队启动开发了，现在纠结了，到底是原生还是h5？
领导们也在过问这个抉择，
考虑到APP项目的稳定性、扩展性和高性能的要求，其中的推送功能、离线功能、本地存储、数据交互较频繁且量较大的因素，技术选型的问题

原生开发模式

原生的缺点

• 开发成本高，不同平台需要定制不同的app，开发人员需要多平台多语言，人力成本、时间成本较多，通用性差；
• 上线时间不稳定，需要审核，特别是苹果审核机制，审核时间长短不一，对内容还有控制，国内Android APP市场也有类似的问题；
• 版本控制能力差，版本发布到达率无法控制，多个版本更新发布，修复bug，无法保证及时送达到用户手中；获得新版本需要重新下载安装，虽然目前有增量升级方式逐渐改变，但是随之而来的其他问题如增量升级多版本控制也是个很头疼的问题

原生的优点

原生开发依然是开发者采用最广泛的开发方式，优点十分显著。相比其他开发方式而言：

• 原生开发可以访问设备中的所有功能，运行速度更快，性能更高，而且可以启用优秀的离线处理和存储能力等等，提供最佳的用户体验，最优质的用户界面，最华丽的交互。
• 原生开发人员众多，开发环境成熟，有许多的开源库提供开发人员调用，可是方便实现各种设计效果。

H5开发模式

H5开发是Html5开发的app，本质上运行在手机浏览器中的页面，一般使用app做一个壳套用浏览器运行H5的页面，由于H5的特性也有很多app使用半原生半H5的hybird app 开发模式。

H5优点

H5有许多优点，特别针对原生开发的缺点。

• 直接在网页上调试和修改，几乎不用考虑用户机型和适配的问题，针对原生开发的平台碎片化、开发人力成本、时间成本高；
• 版本升级优势，网页的升级与用户无关，用户无需下载更新安装，保证实时送达到用户手中；
• 上线时间稳定、快速，不需要通过开发市场的审核，有收入分成的开发市场更是可以绕过收入分成。
• 除此以外在视频媒体方面H5表现也十分优秀的。

H5的缺点

H5的缺点有许多，当新技术出现时候许许多多的人都在吹嘘它的优点，到真正实用时才对它的缺点正视。

• H5加载大图片的时候性能会下降，大量用户访问同一个H5应用时性能会下降，响应速度比不上原生app，上网速度也不及原生app，H5不能自动处理动画上反复交互（网页游戏），需要借助css3、javascript。H5本质上是网页，无论是离线的还是在线的，它本质上是通过浏览器呈现到用户面前的网页，在手机上模拟得像app，网页的缺陷它无可避免。
• 最大的问题是性能问题，这才是H5，原生开发对性能的支持远超H5，在用户体验上，H5的app绝对是占据下风的，app反应速度、流畅度等
• 功能扩展与调用性能问题，对某些硬件摄像头、陀螺仪、麦克风等硬件支持较差，频繁调用这些硬件，H5不容易扩展，调用速度也不如人意。

原生 VS H5的总结

目前许多app都采用hybird app 开发（微信、支付宝等等），在h5适合的地方展示，在其他地方使用原生开发，以规避缺点，发扬优势。
纯H5 app适合小游戏、媒体、视频、营销产品、介绍等功能，大部分大型app属于原生、H5混合的hybird app。

react-native框架

介绍react-native之前，需要先提下react，react 是facebook在2013年开源的网站ui开发的js库，react-native是用react 进行原生app开发的框架，让广大开发者使用js和react开发应用，提倡组件化开发。react-native提供一个个封装好的组件让开发者使用，也可以相关嵌套形成新的组件。使用react-native可以维护多种平台（Web，Android和IOS）的同一份逻辑核心代码来创建原生app。从代码上看结构类似，细节有差别，facebook强调的是“learn once,write everywhere”，应用前端使用js和React来开发不同平台的ui，下层核心模块编写复用业务逻辑代码，提高应用的开发效率。

react-native的原理

react-native的优点和H5类似，跨平台、低成本开发、开发速度快、动态发布、一套类似代码维护三个平台。代码结构如下图：

image.png

• 程序结构上，有两个工程分别是ios 、android，编译后回在相应文件夹中生成apk和app，界面代码是选中的index.android.js和index.ios.js，右侧的JS代码在这两个JS文件中几乎一模一样。

• 它与web app很类似，但是绝对不是web app，查看开源代码，你不会发现webview的使用，也就是本质上react-native的app不是web app 或者hybird app，而是原生控件。那它是怎么实现的呢，react-native的原理如下图：

  
  
  image.png
  
  

  原理上看react-native在js端和java端互相有个映射关系，通过两端的配置表来实现，java端和js端持有同一张表，通信时靠这张表的各个条目的对应进行的。上面提到了facebook实现了组件让开发者调用，就是通过js的配置表调取原生控件，java调用js也是类似的情况。所以当我们使用复杂控件时，可以自己实现java代码，添加入配置表中，即可自定义心新的映射关系，让我们js调用自定义的复杂控件 , 当然web 、ios、androi需要实现不同的控件代码，只是js端的调用代码一样或者类似。

react-native的优点

• 不用webview,摆脱了webview的交互和性能问题；
• 有较强的扩展性，java端提供了基础控件，js可以自由组合使用也可以自定义组合控件；

react-native的缺点

• 组件不全，第三方组件也不全，遇到某些特殊功能，需要花大力气写；
• 性能方面也无法媲美原生，还是有一些损耗，特别是交换大数据时；
• IOS版本略好，androi发展较慢；ios和android代码并非通用，有可能需要维护两套代码或者在代码中做一些判断；
• 开发人员还是需要会原生开发，不然无法开发扩展的自定义组件；

react-native总结

react-native不是万能药，只是一种高效的解决方案，不要期望它解决所有的问题，要不要使用需要场景衡量；

• 客户端转开发react-native感觉比较简单，比较JS大部分人都有基础，前端人员开发react-native理解原生部分的代码应该十分困难；
• 相比原生海量的第三方控件和第三方包，react-native大部分道路还得靠自己摸索；
• 不同端的代码风格和结构大体类似，但具体标签可能会不一样；

• 版本发布频繁，一直是稳定1.0版本下面beta的0.xx的版本号，意味着稳定性是最大短板：目前得到经验是IOS版本比较稳定，android版本还不太成熟，android 版本2015年下半年发布，一直在0.*版本上更新，android1.0版本还没有发布；

  
  
  image.png
• 听说qzone使用了react-native，但是crash率前10，react-native占8个，前5全是react-native，但是我一朋友项目使用过react-native，虽然有坑，但是不会有如此多crash;
• 新技术，开发环境和代码编码方面都比较艰涩，有可能有很多坑，但是在界面简单，三端都要求，开发成本需要降低情况下可以使用react-native

最后个人总结：

• 安卓和苹果自家的原生开发是整个APP的底层框架，或者说是基座，
  但没有银弹，不要指望一种技术通吃所有的业务场景，最完美的解决方案是取长补短，结合具体的页面场景来混搭：

• 稳定性、扩展性、适配机型和运行性能的高要求，其中的推送功能、离线功能、本地存储、数据交互较频繁且量较大，乡下手机较低端或者领导高端机型的适配，建议大家就别绕过原生，毕竟是平台自家的原生开发才是亲生儿子，享有其他任何技术没有的优势。

• 存在较多变更因素，可以采用H5或者React，比如需求未明确，需求变更较频繁，比较鲜明的场景就是内容发布，天天更新，如果只是内容变更，而样式不变倒原生开发也是可以的；

• 具体技术场景相关业界标准的限制要求：自定义图层的在线地图，openlayers+GeoServer就是H5的地图开发标准，甚至是3D地图的Cesium解决方案，肯定是不适合安卓和苹果各自开发一套原生代码，但对于离线地图要求，还是要选择原生SDK的百度、高德地图；