基干移动开发现状探析React Native.doc

基干移动开发现状探析React Native 　　摘要：由于移动互联网的热潮，很多从事传统行业的新人涌入移动互联网，这导致移动互联网移动开发者稀缺，开发产品以及创业的成本大大增加。 由于移动平台IOS与Android开发的特性，导致开发速度慢，问题多。Android的开放性导致各平台众多，开发者苦不堪言，而基于Html5的解决方案又有自己的性能问题，一直未能解决开发效率。该文通过分析当前移动开发遇到的问题，对React Native 进行研究，从一个新的角度去解决这些问题 关键词：移动互联网；混和开发；React Native 中图分类号：TP311 文献标识码：A 文章编号：1009-3044（2016）32-0076-02 1 研发开发现状 随着移动互联网的高速发展，移动开发越来越热门，目前市场上实现做一个移动端产品，客户端主要考虑两个平台，一个是Android平台，一个IOS平台，Android平台是Google开源的系统，IOS是苹果公司封闭的一套系统，由于这两者的语言以及平台的不同，开发一个应用，需要使用不同的语言，由不同的人员共同完成相同功能系统，而每个系统的更新，都很麻烦，都需要开发者重新上传，然后审核，用户才能更新，IOS的审核至少需要一周，所以对于产品运营，无疑会加大时间投入。这就如以前做桌面程序，开发者每开发一个应用程序都需要将应用开发程序上传到互联网上，提供给用户一个下载地址，用户需要自己下载安装，之后的更新需要用户自行更新，而不像现在互联网上的网站，只需输入一个网址就可以实现远程更新 移动开发，特别是Android开发至今缺乏最佳实践，很多类和接口有多种实现方式，开发者都按自己熟悉或喜欢的模式来进行开发，导致想要读懂他人的代码很费劲，后续维护起来问题较大。由于Android的开源性，每个厂商都可以定制自己的Android系统，定义不同的分辨率，这对Android开发人员来说，要开发同一个产品必须要满足不同的Android版本以及众多的分辨率，开发效率必然大打折扣 2 目前解决方案 由于原生开发会遇到不同的问题，所以现在普遍的解决方案是采用Html5方案，即用Html5、Css、Javascript来实现客户端的展示与后台数据交互。再通过WebView控件在每个平台上分别打包，由于各个资源都是放在云端，所以可以做到一次开发，处处使用。这种方案很多，包括比较出名的PhoneGap与APPCAN。这种方式真正做到了开发一次，多次运行的目的，其采用了标准的W3C标准，能直接让Web APP直接运行，而采用的语言也是主流的Html5，Javascript，CSS3，这使得以前做前端的工程师也能开发出Android，IOS的应用 这种方案采用平台各自内置的WebView组件，具有以下两个特点： 1）WebView组件实质是移动设备内置的浏览器，正是由于这中特性，使Web能被打包成客户端，可方便调用Html5，CSS3 2）PhoneGap，APPCan等方案针对不同平台的WebView做了扩展与封装，使WebView 这个组件变成可访问设备本地API的强大浏览器，开发人员在这些框架下可通过Javascript访问本地设备API 但此方案也存在不足，一是性能不足，正常操作速度虽能满足，但是频繁操作则会导致响应变慢；二是稳定性以及占用资源方面存在着较大问题，这是由于WebView组件不能很好的释放内存，导致内存占用上升，甚至会引起应用的crash 3 React Native 出现的根本原因 在过去，移动开发中的Web与Native之争基本以Native的胜利而告终，因为Web UI的性能无法与原生相提并论。即使目前手机性能有了巨大提升，但在UI交互等方面Web UI还是远远不如原生UI：Native 的原生控件有更好的体验；Native有更好的手势识别； Native有更合适的线程模型，例如图像解码、文本渲染仍无法多线程渲染，这影响了Web的流畅性 这些正是直接导致React Native出现的根本原因，这也是为什么现在我们手?C上的应用还是基于Native的居多，目前主流应用基本上没有一款是用Web来实现的，虽然这是未来的趋势，但是现在而言，硬件以及软件技术还达不到这一要求 React Native 起源于Facebook的内部项目由于其设计思想极其独特，属于革命性创新，性能出众，代码逻辑却非常简单，所以被越来越多的人开发关注和使用 4 React Native 简介 React Native 并不能真正的解决同一份代码，不同平台运行，由于Native平台上的用户体验不同，所以不提供“write once， run anywhere”