对于手机app来说，近几年有以下几种开发模式
| Native App | Web App | Cordova | Weex | React Native | |
|---|---|---|---|---|---|
| 优点 | 性能高 | 无需安装 | 界面复用性强 | 跨平台执行 | 跨平台执行 |
| 缺点 | 开发维护成本高 | 用户体验不好 | 性能差 | 开源较晚 | 学习曲线高 |
| 技术 | oc、swift、java | html、js | html、js | vue.js | react.js |
Native App
原生开发是系统自带的app开发方式，也是大部分人最熟悉app开发的技术，如android、ios、wp。是开发者采用最广泛的开发方式，优点十分显著。相比其他开发方式而言，原生开发可以访问设备中的所有功能，运行速度更快，性能更高，而且可以启用优秀的离线处理和存储能力等等，提供最佳的用户体验，最优质的用户界面，最华丽的交互。原生开发人员众多，开发环境成熟，有许多的开源库提供开发人员调用，可是方便实现各种设计效果。
原生开发的缺点在逐渐的开发、运营过程中显现出来。开发成本高，不同平台需要定制不同的app，也就是android定制apk，ios定制app，开发人员需要多平台多语言，人力成本、时间成本较多，通用性差；上线时间不稳定，需要审核，特别是苹果审核机制，审核时间长短不一，对内容还有控制，国内Android APP市场（百度手机助手，应用宝，360市场等等）也有类似的问题；版本控制能力差，版本发布到达率无法控制，多个版本更新发布，修复bug，无法保证及时送达到用户手中；获得新版本需要重新下载安装，虽然目前有增量升级方式逐渐改变，但是随之而来的其他问题如增量升级多版本控制也是个很头疼的问题。
优点
- 提供最佳的用户体验，最优质的用户界面，最华丽的交互效果
- 针对不同平台提供不同体验
- 可访问手机的所有功能
缺点
- 开发成本较高
- 范围限制多
- 未知的部署时间（应用商店审核时间）
- 内容限制
Web App
Web无需安装，对设备碎片化的适应能力优于App，它只需要通过HTML、CSS和JavaScript就可以在任意移动浏览器中执行。随着iPhone带来的WebKit浏览体验升级，使得专为iPhone等有WebKit浏览内核的移动设备开发的Web应用，也有了如App一般流畅的用户体验。
Web App即在浏览器直接可以访问的应用
优点
- 开发成本低
- 一套代码适配多种移动设备
- 跨平台和终端
- 迭代更容易
- 无需安装成本
缺点
- 浏览体验短期内还无法超越原生应用
- 不支持离线模式（断网无法访问）
- 消息推送不及时
- 调用系统能力弱
Cordova
Apache Cordova是一套设备API，允许移动应用的开发者使用JavaScript来访问本地设备的功能，比如摄像头、加速计。它可以与UI框架（如jQuery Mobile或Dojo Mobile或Sencha Touch）等相结合使用，这些UI框架可以使用HTML、CSS和JavaScript开发智能手机应用。
在使用Cordova API时，应用程序的构建可以无需本地代码（如Java或对象C等），使用的是Web技术。由于这些JavaScript API在多个设备平台上是一致的，而且是基于Web标准创建的，因此应用程序的移植很方便，基本不做什么改变。使用Cordova的应用使用平台SDK打包成应用程序，可以从每种设备的应用程序商店下载安装。
Cordova提供了一套统一的JavaScript库供调用，它支持iOS、Android、Blackberry、Windows Phone、Palm WebOS、Bada和Symbian。
- 开发自由度
首先 Cordova 构建的是一个运行于手机内置浏览器中的单页 Web 应用，因此理论上我们能够使用 jQuery，Angular 等等任何 Web 技术。
- 界面表现
Cordova 应用因为本质上是一个 Web 应用，因此某些地方会显得有些怪怪的。比如，列表滚动不像原生那么流畅，点击效果也缺少反馈。当然如果我们想让 Cordova 应用尽可能像原生应用的话，这些问题都是可以解决的，但也意味着我们需要付出额外的努力。
- 性能方面
Cordova 应用的性能很大程度上局限于运行它手机的 WebView 性能。比如，在 iOS 上，同一个 Web 应用，运行在默认 WebView 引擎上要明显慢于运行于 Safari 中。而 Android 也是在 4.0 之后 WebView 才换成了 Chrome 内核，因此，在老旧的 Android 机型上 Cordova 的表现会非常糟糕。进一步，由于 JavaScript 是单线程的，如果我们的Cordova应用同时做了很多事情，那可能就会遇到麻烦。
Weex
Weex能够完美兼顾性能与动态性，让移动开发者通过简捷的前端语法写出Native级别的性能体验，并支持iOS、安卓、YunOS及Web等多端部署。
对于移动开发者来说，Weex主要解决了频繁发版和多端研发两大痛点，同时解决了前端语言性能差和显示效果受限的问题。开发者可通过Weex官网申请内测。
开发者只需要在自己的APP中嵌入Weex的SDK，就可以通过撰写HTML/CSS/JavaScript来开发Native级别的Weex界面。Weex界面的生成码其实就是一段很小的JS，可以像发布网页一样轻松部署在服务端，然后在APP中请求执行。
目前Weex有三种集成方式：
- 全页模式
目前支持单页使用或整个app使用Weex开发（还不完善，需要开发router和生命周期管理）这是主推的模式，可以类比RN。 - Native Component模式
把Weex当作一个iOS/Android组件来使用，类比ImageView。这类需求遍布手淘主链路，如首页、主搜结果、交易组件化等，和业务同学沟 通下来这类Native页面主体已经很稳定，但是局部动态化需求旺盛导致频繁发版，解决这类问题也是Weex的重点。 - H5 Component模式
在H5种使用Weex，类比WVC。一些较复杂或特殊的H5页面短期内无法完全转为Weex全页模式（或RN），比如猫超、互动类页面、一些复杂频道页 等。针对这个痛点我发起过WVC项目，并在实际业务中验证了这样的想法：在现有的H5页面上做微调，引入Native解决长列表内存暴增、滚动不流畅、动 画/手势体验差等问题。WVC将会融入到Weex中，成为Weex的H5 Components模式。
这3种模式几乎涵盖了淘系业务上的动态化需求（针对Native）或体验提升需求（针对H5）。更有趣的是这3种模式的技术基础是一致的，这非常重要，意 味着：业务方可以使用Native或H5 Component模式 解决实际的业务痛点，同时平滑过渡到Weex全页模式。期待Weex成长壮大到AppFramework的那天。
优点
- 由于 Weex 采用了 Vue 作为上层框架，相较于 React 更加轻量，Vue 的官网宣传就是非常轻量，体积小巧，语法简单。
- Vue 的学习成本相较于 React 更加小，大部分 Native 开发者更容易上手。
- Weex 吸收了 RN 的精华，可以说 Weex 是站在巨人的肩膀上问世。
缺点
- Weex 相较于 RN 起步比较晚，社区没有 RN 活跃。
- 从问世的时间上来看，RN 具有更大的优势，Weex 的学习资料比较少。
- Weex 现在存在的 BUG 相较于 RN 还比较多，对于使用来说会有一些影响。
React Native
React Native 是Facebook发布的，可以让广大开发者使用JavaScript和React开发应用，提倡组件化开发，也就是说React Native提供了一个个封装好的组件让开发者来进行使用，甚至可以相关嵌套形成新的组件。
使用React Native开发者可以维护多种平台(Web,Android和IOS)的同一份业务逻辑核心代码来创建原生应用。
现阶段Web APP的的体验还是无法达到Native APP的体验，所以这边fackbook更加强调的是“learn once, write everywhere”，应用前端我们使用js和React来开发不同平台的UI，下层核心模块编写复用的业务逻辑代码，提供应用开发效率。
React Native的设计理念：既拥有Native的用户体验、又保留React的开发效率。
优点
- 可以大大节省开发成本,百分之90多界面可以通过RN开发,一份代码可以适配Android和IOS。
- RN有独特的UI实现框架,借助组件化开发是团队规模更容易进行调整,可以快速迭代项目。
- RN可以通过一些手段自动匹配不同屏幕大小的手机,再也不需要自己去计算视图的大小和位置。
- RN具备高效的UI调试。
缺点
- RN开发的程序内存消耗略大, 开发模式下开销大几十兆,发布后差异不大, 目前手机基本上都有2G以上的内存, 几十兆可以忽略不计了。
- 运行速度略慢， 不可否认，原生代码比RN运行速度略快, 显示一个界面多一两毫秒吧,正常的人根本感觉不到,如果你用不经过优化的原生代码反而不如RN。
- 安装包比原生代码安装包大,这点更可以忽略了, 现在手机什么都缺就不缺空间。
网友评论