Android 原生开发、H5、React-Native开发特点
本文转载自 Android 原生开发、H5、React-Native使用利弊和场景技术分享
由于工作原因，由Android原生开发转向React Native开发，ReactNative是从去年5月份开始至今，最近公司想要使用Android+H5开发，在这里，找了一篇文章，说一下Android 原生开发、H5、React-Native开发特点。
一、原生开发
原生开发是系统自带的app开发方式，也是大部分人最熟悉app开发的技术，如android、ios、wp。
原生开发依然是开发者采用最广泛的开发方式，优点十分显著。相比其他开发方式而言，原生开发可以访问设备中的所有功能，运行速度更快，性能更高，而且可以启用优秀的离线处理和存储能力等等，提供最佳的用户体验，最优质的用户界面，最华丽的交互。原生开发人员众多，开发环境成熟，有许多的开源库提供开发人员调用，可是方便实现各种设计效果。
原生开发的缺点在逐渐的开发、运营过程中显现出来。开发成本高，不同平台需要定制不同的app，也就是android定制apk，ios定制app，开发人员需要多平台多语言，人力成本、时间成本较多，通用性差；上线时间不稳定，需要审核，特别是苹果审核机制，审核时间长短不一，对内容还有控制，国内Android APP市场（百度手机助手，应用宝，360市场等等）也有类似的问题；版本控制能力差，版本发布到达率无法控制，多个版本更新发布，修复bug，无法保证及时送达到用户手中；获得新版本需要重新下载安装，虽然目前有增量升级方式逐渐改变，但是随之而来的其他问题如增量升级多版本控制也是个很头疼的问题；
总结：原生开发虽然有各种缺点，但是在目前所有的开发技术中原生是最成熟，有效，也是开发人数最多，开源库最广泛的。对APP要求各方面性能、响应要求高，人员充足，完整开发、测试流程，适合原生APP开发。
二、H5开发
H5开发是Html5开发的app，本质上运行在手机浏览器中的页面，一般使用app做一个壳套用浏览器运行H5的页面，由于H5的特性也有很多app使用半原生半H5的hybird app 开发模式。
H5有许多优点，特别针对原生开发的缺点。如： 直接在网页上调试和修改，几乎不用考虑用户机型和适配的问题，针对原生开发的平台碎片化、开发人力成本、时间成本高；版本升级优势，网页的升级与用户无关，用户无需下载更新安装，保证实时送达到用户手中；上线时间稳定、快速，不需要通过开发市场的审核，有收入分成的开发市场更是可以绕过收入分成。除此以外在视频媒体方面H5表现也十分优秀的。
H5的缺点有许多，当新技术出现时候许许多多的人都在吹嘘它的优点，到真正实用时才对它的缺点正视。H5加载大图片的时候性能会下降，大量用户访问同一个H5应用时性能会下降，响应速度比不上原生app，上网速度也不及原生app，H5不能自动处理动画上反复交互（网页游戏），需要借助css3、javascript。H5本质上是网页，无论是离线的还是在线的，它本质上是通过浏览器呈现到用户面前的网页，在手机上模拟得像app，网页的缺陷它无可避免。1.软、硬件的支撑问题，现在早已不是问题，这里讲出是由于2012年左右当时H5火起来时，我在FF公司看到宣讲H5时，当时许多的手机依然无法支持h5，几年过去了这个问题基本不存在了；2.性能问题，这才是H5最大的问题，原生开发对性能的支持远超H5，在用户体验上，H5的app绝对是占据下风的，app反应速度、流畅度等；3.功能问题，对某些硬件摄像头、陀螺仪、麦克风等硬件支持较差，频繁调用这些硬件，H5不容易扩展，调用速度也不如人意。
总结：纯H5 app适合小游戏、媒体、视频、营销产品、介绍等功能，大部分大型app属于原生、H5混合的hybird app。
H5话题的延伸。2010-2012年H5大火，有许多人认为可以替换原生开发，成为一种“write once,run anywhere”的开发模式，但是在许多公司的案例中就遭遇了失败，但是仅仅过去了3-4年，硬件设备的更新，软件的支持，H5又一次以不同的面目再一次火起来。这个过程十分让人唏嘘。HTML5已经出来很多年了，早在2010年，乔布斯在封杀Flash的言论中，就预言HTML5将取代Flash成为下一波技术浪潮。就算不关心技术的朋友，去翻翻手机也能感受到在pc端一直以来占据统治地位的Flash在手机端几乎不见踪影，这是从2010年以来苹果公司与Adobe公司的战争开始，苹果背后无数开发人员支持研发HTML5技术，让HTML5技术得以普及开来。2011年Adobe自己也放弃了Flash移动端的研发工作，HTML5已经被移动浏览器广泛支持，Flash已经落后于时代了。很多大公司都在推动HTML5的发展，但是也有滑铁卢，Facebook的扎克伯格是最惨痛的教训，他想要用HTML5的web app来打破ios和android的垄断，实用HTML5来代替原生App。在这件事上facebook失败了，具体表现在2013年前facebook在移动端的产品的市场表现非常一般，最后无奈宣布回归原生app的开发。Facebook在html5的试错大大打击了HTML5的实用性，但是HTML5自身的厚积薄发还是让这项技术没有没落。
手机硬件的提升和HTML5本身的完善，使得基于HTML5的应用表现更好，iPhone对HTML5的支持更加完善，Google也完成了移动端Chrome浏览器向Chromiumnie内核的切换，大幅提升对HTML支持。很多基于HTML5的应用都在试图替代原生app，但是由于技术限制，用户体验远远不如原生app，但是某些方面HTML5提供了比原生App更好的体验，但这种体验的基础不是单纯的替代原生App，而是做一些最适合HTML5的细分应用，比如小游戏、媒体和营销类的产品。这些细分的方向能够最大程度发挥HTML5跨平台、开发成本低、开发速度快的优点，在整体产品体验上远超过原生app。HTML5和原生app并不是对立的，反而原生app需要HTML5去解决一些核心的问题，让整个移动市场更有效率。很多公司在努力推动HTML5技术，但是让HTML5重新焕发生机的是微信，利用朋友圈的私密社交，以及HTML5自身的跨平台、低成本开发、速度快等特性，不少公司利用HTML5技术在朋友圈做了一次又一次的营销。微信本身没有在HTML5技术上有什么创造性的推动，而是在HTML5的应用场景上做出了自己的不同尝试，形成了附着微信这个超级app的HTML5应用场景。HTML5的优点跨平台、低成本开发、开发速度快等优点不是最终站稳市场的根源，最终成就它的还是它自身比原生app更加优秀的特质，比如小游戏、媒体、视频、营销产品等等。目前许多app都采用hybird app 开发（微信、支付宝等等），在h5适合的地方展示，在其他地方使用原生开发，以规避缺点，发扬优势。
三、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类似，跨平台、低成本开发、开发速度快、动态发布、一套类似代码维护三个平台。代码结构如下图：
程序结构上，有两个工程分别是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的原理如下图：
原理上看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感觉比较简单，比较JS大部分人都有基础，前端人员开发react-native理解原生部分的代码应该十分困难；相比原生海量的第三方控件和第三方包，react-native大部分道路还得靠自己摸索；不同端的代码风格和结构大体类似，但具体标签可能会不一样；目前得到经验是IOS版本比较稳定，android版本还不太成熟，android 版本2015年下半年发布，一直在0.*版本上更新，android1.0版本还没有发布；把把facebook的第三方包网络连接包okhttp和图片下载解析包fresco等一起封装进结果，造成包增加7、8M，但据了解这是可以修改的；只支持IOS7以上和android4.1以上机型，这应该不成问题，比较其他属于少数；听说qzone使用了react-native，但是crash率前10，react-native占8个，前5全是react-native，但是我一朋友项目使用过react-native，虽然有坑，但是不会有如此多crash;
总结：新技术，开发环境和代码编码方面都比较艰涩，有可能有很多坑，但是在界面简单，三端都要求，开发成本需要降低情况下可以使用react-native。
更多相关文章
- 安卓学习（初）第三章（3）（《第一行代码》）
- Android常用的基本控件
- [置顶] Android中以JAR形式封装控件或者类库
- 几个Android控件属性笔记
- 性能优化之Java(Android)代码优化
- 通过eclipse查看Android源代码（Java）
- Android显示时间和日期的控件的使用总结
- 【Android】注解框架（四）-- 一行代码注入微信支付