前人栽树,后台乘凉,本文参考了以下来源
前置技术要求
阅读本文前，建议先阅读以下文章
目前的主流应用程序有四大类型:Native App、Hybrid App、React Native App、Web App。本文分别对这几种方案做一些分析对比
几种APP开发模式
当前的APP开发模式注意有以下四大类型:
Native App
即传统的原生APP开发模式,Android基于Java语言,底层调用Google的 API;iOS基于OC或者Swift语言,底层调用App官方提供的API。体验最后。
即移动端的网站,将页面部署在服务器上,然后用户使用各大浏览器访问。一般泛指 SPA(Single Page Application)模式开发出的网站。体验最差。
Hybrid App
即混合开发,由Native通过JSBridge等方法提供统一的API,然后用Html5+JS来写实际的逻辑,调用API,这种模式下,由于Android,iOS的API一般有一致性,而且最终的页面也是在webview中显示,所有有跨平台效果
React Native App
Facebook发起的开源的一套新的APP开发方案,使用JS+部分原生语法来实现功能。初次学习成本较高,但是在入门后,经过良好的封装也能够实现大部分的跨平台。而且体验很好。
Native App
即原生开发模式,开发出来的是原生程序,不同平台上,Android和iOS的开发方法不同,开发出来的是一个独立的APP,能发布应用商店,有如下优点和缺点
直接依托于操作系统,交互性最强,性能最好
相比于其它模式的交互,原生APP体验是最优的
功能最为强大,特别是在与系统交互中,几乎所有功能都能实现
得益于原生是直接依托于系统的,所以可以直接调用官方提供的api,功能最为全面(比如本地资源操作,通知,动画等)
开发成本高,无法跨平台,不同平台Android和iOS上都要各自独立开发
Android上基于Java开发,iOS上基于OC或Swift开发,相互之间独立,必须要有各自的开发人员
门槛较高,原生人员有一定的入门门槛,相比广大的前端人员而言,较少
原生的一个很大特点就是独立,所以不太容易入门,不像web前端一样那么广泛,而且Android,iOS都需要独立学习
更新缓慢,特别是发布应用商店后,需要等到审核周期
原生应用更新是一个很大的问题,Android中还能直接下载整包APK进行更新,但是iOS中,如果是发布AppStore,必须通过AppStore地址更新,而每次更新都需要审核,所以无法达到及时更新
维护成本高
同开发一样,项目上线后,维护起来也很为麻烦
即移动端的网站,将页面部署在服务器上,然后用户使用各大浏览器访问,不是独立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(比如动画较多就不适合)
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 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
如何选择开发模式
目前有多种开发模式,那么我们平时开发时如何选择用哪种模式呢？如下
选择纯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开发的感觉。具体也不赘述,请参考引用来源中的文章
当然除此外,还有一些其它的模式,比如&百度直达号&,"流应用"等等,这里不再赘述
阅读(...) 评论()ReactNative 开发实践 - 简书
ReactNative 开发实践
这是一个在StuQ做分享时的讲稿。当然还有很大的改进空间，但我这会却没有什么劲头继续改进，既然这样就不如索性先发出来，先把它从脑袋清出来，把其它我更想做的事情做了，回头再看哪天想改了再回来改。
当然，大家有觉得不对的地方，随便批，我会当做问题之一，以后努力改进：）
分享环节：
大家好，我是深圳平安科技的利炳根。网名：清醒疯子。主要研究iOS和ReactNative。今天和大家分享的是我在ReactNative上的一些开发实践经验。请大家多多指教。
在ReactNative上的研究，我还是做得比较粗浅，有不对的地方，大家随便批，我多向大家学习。
今天的内容分为四个部分。分别的ReactNative的开发环境搭建、JS/Bundle的管理、混编以及数据流的处理。
ReactNative的开发环境搭建比较简单。只需要把node、watchman、flow通过brew安装完，通过npm把ReactNative命令行安装到全局，就可以用init命令创建ReactNative项目。
其中，node是node.js。它有非常好用的包管理工具npm。也可以拿来写后台。我自己经常拿来在本地快速写一些简单的后台辅助调试代码。
watchman是Facebook的开源项目，主要用来监视文件，记录文件的改动。React通过watchman来实现代码发生变化时完成相关的重建功能。
flow也是Facebook的开源项目，用来做JavaScript的静态类型检查。用来发现JS程序里的类型错误，提高编码效率和代码质量。包括前期错误检测、代码智能提示等。
安装ReactNative命令行的时候要注意加上-g这个参数，把RN命令行安装到全局，才方便我们在任何目录通过命令行创建ReactNative项目。
ReactNative项目创建的时候，会自动把一些需要用的库加到项目工程里，自动做好基本的依赖管理，并且自动生成最简Demo代码。创建完之后就可以运行一个最简单的Demo，方便大家体验ReactNative的编程。
目前，ReactNative还没有特别好用的开发工具。开发效率会稍微打点折扣。但利用现有的开发工具还是足够完成基本的开发任务的。
Nuclide是Facebook的开源项目，是与Ract配套的IDE。目前还在不断地完善当中。已经能实现基本的代码提示和静态类型检查。Nuclide目前还不是独立的IDE，需要作为Atom的包进行安装。
Atom和WebStorm都可以做到React的部分代码提示。对ReactNative的支持就相对差一些。主要还是针对JavaScript的支持而已。
ReactNative的JSX只是JavaScript的封装。一些在JavaScript上的打包工具，ReactNative也能用。比如Browserify和Webpack。
Browserify使用比较简单。指明入口点和出口点就可以打包。而Webpack则一般要写一个配置文件webpack.config.js指明打包细节。当然，Webpack的功能相对就更强大一些。
Nuclide的开源项目代码提交还是比较活跃的，对这方面有兴趣的朋友不妨关注一下，参与其中和大神一起做一个IDE也不失为一种相当不错的娱乐项目。
虽然ReactNative最终会渲染成Native的View，但它只能通过浏览器调试。基本上就是用Chrome来做。
Chrome上有一个插件React Developer Tools，不过要翻墙才能装。
通过Chrome的consle可以打印变量。如果对这块不熟悉的话，可以先通过调用一个网络请求，打印返回的数据，并根据数据调整显示，来熟悉一下Chrome的调试过程。
在JavaScript代码中插入就可以作为调试过程中的断点。
在iOS平台上，ReactNative组件通过RCTRootView这个类接入到Native的视图层次里头。
RCTRootView初始化只需要提供两个参数，一个是JS包的路径，一个是模块的名称。
ReactNative的应用组件，最后渲染出来都是一个View的子类，都可以通过addSubView加到Native的视图层次上面。
ReactNative可以实现动态编码。只需要在远端修改JS文件并保存，Native端无需重新编译，只需要Reload刷新一下，就可以更新APP视图和功能。
在设置RCTRootView的JS包地址时，设置为远端的JS文件资源网址，在引用时把文件后缀改为.bundle，即可以调用远端的ReactNative bundle命令，把对应的JS文件打包为可用的JS包文件，在Native端实现视图的渲染。
bundle命令有两个常用的参数。platform参数指定打包到iOS平台还是Android平台。dev参数指定是否开启开发选项以提供更多的调试信息。
调用远端JS文件打包的方式有一个缺点，打包过程导致视图初次加载比较慢，影响用户体验。可以过加载离线包的方式解决这个问题。
在设置RCTRootView的JS包地址时，设置为Native端沙盒内的jsbundle文件地址，ReactNative就可以从Native端加载渲染视图，速度有明显提升。
通过bundle命令，可以把JS文件打包成jsbundle包。bundle命令有三个常用参数。platform参数指定平台，entry-file参数指定入口文件，bundle-output参数指定出口文件。
通过加载Native端离线包jsbundle文件，在提升加载速度的同时也让ReactNative失去了远端更新的能力。这样得不偿失。我们可以通过静默下载jsbundle文件替换Native端jsbundle文件的方式解决这个问题。
通过远端jsbundle文件资源网址，启动一个下载文件请求。在收到请求返回的时候设定文件路径。在收到返回数据时写文件。
写文件时，要注意先让写入点移动到文件末尾，再进行文件写入，避免覆盖之前接收到的数据。
10.pic.jpg
ReactNative因为技术发展不久，还有部分Native端的功能并没有完全实现。在项目开发过程中有可能需要在ReactNative项目里加入Native端的功能代码辅助。
ReactNative有一套机制实现。在Native端的类里引用RCTBridgeModule，并遵循RCTBridgeModule协议。通过宏RCT_EXPORT_MODULE向JS暴露Native端的类，通过宏RCT_EXPORT_METHOD暴露Native端的方法，通过RCTResponseSenderBlock实现JS端的回调。
11.pic.jpg
JS端的处理和Native端同样简单。在JS文件的开始引用NativeModules组件。通过NativeModules引用Native端指定类。由Native端指定的类就可以直接调用指定的方法并指定回调的实现。
12.pic.jpg
Native项目添加ReactNative模块稍微复杂一点。首先需要进行一些工程配置。把ReactNative需要的静态库加到工程里。在Build Settings里设置Other Linker Flags 和Header Search Paths。最后还要在Info.plist里设置App Transport Security Settings -& Allow Arbitrary Loads。
13.pic.jpg
在Native的类中引用RCTBridge和RCTEventDispatcher。通过bridge的eventDispatcher向JS端派发事件。派发事件的接口有5个，分别对应5个不同的事件类型。
这里要注意，不要在Native端的viewDidLoad方法里向JS发送事件消息，因为这个时候ReactNative组件还没有挂载出来，接收不到消息。
14.pic.jpg
JS端在文件一开始引用NativeAppEventEmitter组件。通过NativeAppEventEmitter组件的addListener方法监听Native端派发的事件消息。组件卸载时，通过NativeAppEventEmitter组件的removeAllListeners方法移除监听。
15.pic.jpg
ReactNative的数据流处理，目前业内有4种方案。原生的ReactJS通过Props - States - Components的机制处理数据流。
缺点很多。扩展性差，增加新功能时，需要在每一个用到的组件里复制一遍代码。
可读性、可维护性差，代码量大，难以调试、测试。
可移值性差，代码耦合度高，视图、数据不分层。
违背单一数据层原则，在视图层直接进行数据操作。
16.pic.jpg
Facebook官方推荐的Flux，通过Actions - Dispatcher-Stores - Component的机制处理数据流。
代码冗长，Dispatcher和Store有很多重复烦琐的人工检查、定义。
多个Store中处理同一个Action，将产生大量的waitFor方法处理Store的先后逻辑。
多个Store间共享一个State，State有可能被分散到多个Store中，State的变化将变得不可控。
多个Store互相依赖，还有可能产生依赖循环。
17.pic.jpg
Redux通过Actions -Store - Components的机制处理数据流。
Redux针对Flux做了不少优化。通过内部拓展actions的行为，移除了单例的dispatcher。stores可以监听actions的行为，无需进行冗杂的switch判断。
stores可以相互监听，可以进行进一步的数据聚合操作。waitFor方法被连续和平行的数据流所替代。
Redux也有自身的一些弊端。由于整个应用的数据都集中在1个Store里，数据和处理逻辑的复杂度将不可避免地变高。
因为语法相似，从ReactJS、Flux迁移到Redux成本较低，建议旧项目迁移采用Redux。
18.pic.jpg
Baobab通过Actions -Baobab Tree - Components的机制处理数据流。
Baobab的优点十分明显。应用所有状态都存在一棵数据树里。可以非常简单地实现数据域的切换。应用状态树的存在使得数据流管理变得非常简单，代码量少。
通过Baobab库创建状态树，数据以键值对的方式存储。
Baobab通过select方法直接切换数据节点，还可以通过cursors创建数据游标组，访问数据。
Baobab通过set方法修改数据。
如果项目新建，没有旧代码维护的包袱，个人建议采用Baobab来处理数据流，一定会更省事省力。
我的分享到此结束，非常感谢大家今天来参加，希望上面分享的内容能对大家有所帮助。如果大家对ReactNative或者其它问题想跟我交流，欢迎到我的支付宝经费群来。
19.pic.jpg
问答环节：
1.能说说选择相较PhoneGap,ionic等些其他平台,为什么选择React么?PhoneGap是比较早期的技术，一直以来，在性能上或者功能的覆盖上，大家都不够满意。尤其是性能。RN因为最终是渲染成Native的View ，体验上就好很多。同时呢，因为RN是Facebook在推，从Github上的Star，大家也可以看出业界还是对Facebook有很大的期待和信心的。
2.请问rn中的组件出现相互嵌套的问题可以怎么解决？即 a require b， b 也require a。当调用a时，就会b=null了。可以用es6的模块解决吗？这就是涉及到数据流的处理。如果用原生的ReactJS去处理，是会非常麻烦的。Facebook希望Flux能解决这个问题，但实际下来，大家觉得满足不了需求。然后业界就有了Redux和Baobab两种方案。Baobab是最新的方案，解决方式也最优雅，大家有兴趣可以重点研究一下。
3.既然是在Mac下，为什么不用safari调试，当前safari调试窗口也是很棒的在我自己这边主要是习惯问题。一直以来用的都是Chrome。因为很早之前调试API啊各种东西都是用Chrome搞。既然Chrome能搞定就懒得换了。
4.Native与js调用时，与hybrid方式的app有什么不同。RN的双向通信还是做得比较好的，上面的分享也有讲到，实现起来非常简单。我在这上面多花了一点时间，也只是因为把发消息的代码放到了AppDelegate上，结果死活收不到。Hybrid，常见也是用Bridge。这块的麻烦是，需要HTML5的同事配合。
5.再请教一个问题。组建多层嵌套时，组建间该如何通信？特别是最底层跟顶层的通信，除了props之外，还有啥好办法吗这个其实就是第四部分数据流的处理问题。Baobab可以把数据统一到一个地方，而且数据域切换非常方便，可以看看。
6.提问：React Native对安卓的支持情况，是否能兼容如此碎片化的安卓目前，我们还没有去处理具体的适配。这块因为主要是Android的同事在研究，我也不大清楚。不过，既然很多大厂都有用RN，应该不会有太大问题。
8.没有ios经验，只有reactjs经验的，怎么上手xcode下react native开发配置呢，或者android下的Native下的工作量是非常少的。基本上只要随便找几篇入门的文章看看，问题就不大了。遇到搞不定的问题多上stackoverflow搜搜。或者找我交流也可以：）
9.rn在开发团队中的分工如何，如界面，js，ios程序员如何合作目前我们是1个iOS和1个Android，然后就是后端了。其实重点的开发量反而是JS上的。一旦把平台需要配合的东西摸清，剩下的主要工作量就是写JS了。两个平台的多数组件都是可以共用的，也就是很多代码只要写一份就可以了。
11.rn适合渲染view还是处理各种逻辑呢，有不如原生的地方吗目前为止，我还是学习RN就算是View上也做得没有Native漂亮。如果逻辑比较复杂，是不是适合全部用RN来做，还有待考察。RN目前主要的针对点还是迭代比较快的相对轻一点的业务。反正熟悉之后，混编是非常简单的事情，大不了拿Native做一个复杂业务的API：）
问题回答完毕：）
招聘：深圳平安科技移动开发架构师团队，iOS/Android/Java/HTML5/测试/运营都招。15薪，过节费丰厚，内部福利众多，欢迎大家自投或推荐。简历直接微信发给我就可以了，尽量用PDF文件。