一、 目前主流的开发模式

• 引言内容

1、原生开发（Native）

2、混合开发（Hybrid）

3、WebAPP(HTML5）

4、React Native

5、Weex（阿里巴巴开发的，目前淘宝在使用）

6、Flutter等

二、方案描述

1. 原生开发

• 简要

Native app开发即是我们所称的原生app开发，它的开发特点是开发者通过编写代码将每个页面、功能、效果、逻辑、步骤全部搭建起来，一层层，一段段形成完整的app。此类app的数据都保存在本地，app能及时调取，所以相应速度及流畅性有保障。

• 优点
  速度更快、性能更高、整体用户体验最好;
  * 可线下使用;
  * 原生app可以支持大量图形和动画; 并且容易发现(在app Store里面)和重新发现(应用图标会一直在主页上);
  * app质量及安全性还不错。
  * 缺点
  * 1、开发及维护成本不低; 由于安卓、iOS两个系统用不同都开发语言，所以需要两个团队的人员进行开发和维护，成本较高。
  * 2、获得新版本时需重新下载应用更新。
  * 具体分析
  * 代码重用率
  * Android和iOS是两套代码，不可复用。
  * 第三方SDK支持情况
  * 选择范围广，基本都持续更新。
  * 兼容性
  * 开发兼容性非常好，不需要担心兼容性问题。
  * 性能
  * 可实现性能最大化。
  * 学习成本；
  * 原生开发的学习成本高，需要深入了解不同平台的特性，Android和iOS需要使用不同的编程语言开发。
  * 市场人力储备
  * 市场人力储备非常充足。
  * 社区活跃度；
  * 对应的社区多，涉及面广，活跃度高。
  * 框架市场占比
  * 框架对最新操作系统的支持情况（框架最新支持的迭代速度）
  * 开发框架基本都是持续更新的，即使某些框架不满足需求，也可以及时的找到替代，不会影响开发工作

2. 混合开发

• 简要

其实Hybrid app(混合模式移动应用)是指介于web-app、native-app这两者之间的app，兼具“Native app良好用户交互体验的优势”和“Web app跨平台开发的优势”。

• 优点
  混合开发可以快速兼容多个系统，开发周期快，更新发布快
  * 跨平台开发，核心代码只需编写一次就可以部署到多个平台，节省开发时间和成本
  * 后期运用维护成本低，只需要一个团队就可以维护app的更新迭代；
  * 原生和web的融合，是新的技术趋势，尤其对经常需要更新的app，如淘宝、大众点评等app，将h5技术应用到原生app里，已经是大的趋势。

• 缺点
  相对原生来说，性能稍慢。但混合开发已经是未来的发展趋势。
  * 加载缓慢/网络要求高：混合APP数据需要全部从服务器调取，每个页面都需要重新下载，因此打开速度慢，网络占用高，缓冲时间长，容易让用户反感；

*具体分析
*代码重用率
Android和iOS是两套代码，原生代码编写的部分不能复用，H5代码编写的部分可重用。
* 第三方SDK支持情况
* 选择范围广，基本都持续更新。
* 兼容性
* 兼容性非常好，基本和原生差不多，H5代码编写的兼容性有少部分代码需要单独处理。
* 性能
* H5编写的代码加载缓慢，对网络要求高。
* 学习成本
* 开发的学习成本高，需要深入了解不同平台的特性，Android和iOS需要使用不同的编程语言开发。
* 市场人力储备
* 市场人力储备非常充足。
* 社区活跃度
* 对应的社区多，涉及面广，活跃度高。
* 框架市场占比
* 框架对最新操作系统的支持情况（框架最新支持的迭代速度）
* 开发框架基本都是持续更新的，即使某些框架不满足需求，也可以及时的找到替代，不会影响开发工作。

3. WebAPP(HTML5）

• 简要

HTML5应用开发，是利用Web技术进行的App开发。Web技术本身需要浏览器的支持才能进行展示和用户交互，因此主要用到的技术是HTML5、JavaScript、CSS等。

• 优点
  支持设备范围广，可以跨平台，编写的代码可以同时在Android、IOS、Windows上运行；
  * 开发成本相对较低；
  * 无内容限制；
  * 用户可以直接使用最新版本（自动更新，不需用户手动更新）。
• 缺点
  由于Web技术本身的限制，H5移动应用不能直接访问设备硬件和离线存储，所以在体验和性能上有很大的局限性；
  * H5页面过多，容易被应用市场拒绝上架；
  * APP反应速度慢，页面切换流畅性较差；
  * 图片和动画支持性不高；
  * 用户体验感较差；
  * 具体分析
  * 代码重用率
  * Android和ios可以使用同一份代码。
  * 第三方SDK支持情况
  * 兼容性
  * H5兼容性好。
  * 性能
  * H5编写的代码加载缓慢，对网络要求高。
  * 学习成本
  * 开发的学习成本高，需要深入了解不同平台的特性。
  * 要求开发者不仅需要会前端开发，还需要懂Android和iOS原生开发。
  * 市场人力储备
  * 目前前端开发市场人力储备很充足，但是针对webApp的开发者还不是很清楚。
  * 社区活跃度
  * 框架市场占比
  * 框架对最新操作系统的支持情况（框架最新支持的迭代速度）

4. React Native

• 优点：
  调用方便，ipa安装好之后，就不需要频繁编译了，只需要reload一下，把js代码从云服务器下载下来就可以呈现改变代码后的效果。而且RN支持hotReload，在调试界面的时候非常方便，修改代码之后保存，界面就自动跟着变化，这一点在调试的时候实在很爽，不过有时候有点慢，需要reload。chrome在线调试也挺不错，可以打断点，看日志。虽然没有xcode或者Android Studio那么浑然一体，但是作为脚本语言的调试工具，也是很厉害了；

  这对于前端程序员来说，降低了不少学习成本，也大大减少了代码量。但是对于iOS或者安卓开发者来说，刚开始接触的时候，得接受一些思想上的转变；

  这可能也是大多数公司选择使用RN的主要原因。频繁的app升级会让用户很烦，而且苹果的审核真是很麻烦。现在很多大型app都使用了RN，毕竟繁多的业务迭代，每次都通过APP审核，也算是噩梦啊。

  有着Facebook的支撑，相信会发展的很好。

• 缺点：
  Facebook对React Native的长期承诺缺乏清晰度。对于那些完全依赖React Native的APP而言，这样的灰色区域是值得关注的真正原因。专利权也略有不清。对于那些在线条之间进行检查和阅读的用户，似乎使用React Native的许可证可以在用户针对任何类型的专利侵权起诉或启动针对Facebook的任何法律诉讼时立即终止；
  * 虽然js语法很灵活，但毕竟是脚本语言，调试起来还是不方便，不好查错。我们用的表现较好的vscode编辑器，就这都感觉各种跳转很不方便，动不动就得全局搜索，可能是xcode用习惯了吧。脚本语言的编写也会慢慢习惯吧；
  * 官网上的文档，就只是简单介绍用法和各个控件的属性，对细节的描述很少。当你遇到难解决的问题或者踩到坑了，上面基本找不到答案；
  * 很多控件都是iOS专属，或者安卓专属。还有同一些控件，在不同平台上表现差异很大；
  * React Native的USP在于其生产力和可移植性; 但所有企业的担忧都是关于其专利许可，安全和长期未来计划。
  * 对复杂UI不太友好。React Native的渲染机制是基于前端框架的考虑，复杂的UI渲染是需要依赖多个view叠加。比如我们渲染一个复杂的ListView，每一个小的控件，都是一个native的view，然后相互组合叠加，再加上滑动刷新等，渲染效果不太友好。
  * 对开发人员要求较高，当官方封装的控件、API无法满足需求时就必然需要懂一些native的东西去扩展。
  * 具体分析
  * 代码重用率
  * Android和ios可以使用同一份代码，针对于不同平台的UI部分代码需要单独适配，代码重用率大概在70%左右。
  * 第三方SDK支持情况
  * 因为本身就算是三方框架，具体还不是很清楚，需要实战以后才知晓。
  * 兼容性
  * 因为框架本身就是跨平台，而且项目结构也是Android和iOS分别运行对应代码，所有兼容性非常好。
  * 性能
  * 整体性能仍不如原生，但是内存和cpu的使用率和原生差别不是很大。
  * 学习成本
  * 学习成本高；（需要熟悉原生）；
  * 涉及底层的功能需要Android和Ios双端单独开发，JS调用；
  * 试错成本高，有些问题较少解决方案，易耽误开发进度。
  * 市场人力储备
  * 拉钩、智联、前程的APP上招聘机会都没有超过20个，具体情况还不是很清楚。
  * 社区活跃度
  * 目前React Native社区活跃度很高，GitHub上star在8w多。
  * 框架市场占比
  * 框架对最新操作系统的支持情况（框架最新支持的迭代速度）
  * 因为关于原生部分代码可以单独编写，使用js调用，所以基本和原生同步。

5. Weex

• 优点：
  在Native端，两者的最大的区别可能就是在对JSBundle是否分包。React Native官方只允许将React Native基础JS库和业务JS一起打成一个JS bundle，没有提供分包的功能，所以如果想节约流量就必须制作分包打包工具。而Weex默认打的JS bundle只包含业务JS代码，体积小很多，基础JS库包含在Weex SDK中，这一点Weex与Facebook的React Native和微软的Cordova相比，Weex更加轻量，体积小巧。

  由于 Weex 采用了 Vue 作为上层框架，相较于 React 更加轻量，Vue 的官网宣传就是非常轻量，体积小巧，语法简单。

• 缺点：
  学习资料少，从问世的时间上来看，Weex 的学习资料比较少。而RN使用的开发者比较多, 社区活跃，围绕react产生了许多开发框架。这一点，个人认为是weex最大的缺点，甚至是weex能不能很好发展下去的关键因素，虽然react-native和weex大部分普通界面的开发都可以用js的方式来开发， 但很多移动端的功能，必须是原生开发，然后对接到js端。 比如，地图控件， 设备信息， 二维码扫描，摄像头的调用，视频播放，本地图片选择，动画绘制，日历组件，通讯录信息获取，国内的一些服务，qq登录，支付宝，极光推送，等等等等。 这些常用组件, 以及一些框架，react-native因为社区活跃，已经有不少优秀的轮子在github上。 weex起步较晚，且国外开发者可能并不怎么看好，这方面的资源相对较少。 虽然weex搞了个插件市场，但上面的资源太少，且看不出能火爆起来的趋势。

  社区活跃度不够，Weex 相较于 RN 起步比较晚，Weex目前社区主要由阿里人员在维护, 相较于已经成熟的RN社区目前还有很多不足。用的人相对RN少很多，目前没有形成一个良好的生态。作为开发者，如果碰到一个问题，搜索不到，抛出去也没人很好的解答，自己摸索的成本就会很高了。 可能解决一个问题的成本就已经远远大于节省下来的一点学习成本。

  Weex 现在存在的 BUG 相较于 RN 还比较多，对于使用来说会有一些影响。

6. Flutter

• 优点
  Flutter的优点非常明显，如果你选择一个跨平台框架，与众多基于html的 跨平台框架相比，Flutter绝对是体验最好，性能与构建思路几乎最接近原生开发的框架。

• 性能强大，流畅
  Flutter对比weex和react native相比，性能的强大是有目共睹的。基于dom树渲染原生组件，很难与直接在原生视图上绘图比肩性能，Google作为一个轮子大厂，直接在两个平台上重写了各自的UIKit，对接到平台底层，减少UI层的多层转换，UI性能可以比肩原生，这个优势在滑动和播****放动画时尤为明显。

• 路由设计优秀
  Flutter的路由传值非常方便，push一个路由，会返回一个Future对象（也就是Promise对象），使用await或者.then就可以在目标路由pop，回到当前页面时收到返回值。这个反向传值的设计基本是甩了微信小程序一条街了。弹出dialog等一些操作也是使用的路由方法，几乎不用担心出现传值困难

• 单例模式
  Flutter支持单例模式，单例模式的实现也非常简单。单例模式很好的解决了一些问题。相比之下，js的单例则并不是一个真正的单例，或者说不是一个简单的单例，这也是受限于js所运行的环境。单例模式并不总是合理的，容易被滥用。但是在App的初期开发中，往往一个容易实现的单例可以帮助我们快速完成一些逻辑的搭建。

• 优秀的动画设计
  Flutter的动画简单到不可思议，动画对象会根据屏幕刷新率每秒产生很多个（一般是60个）浮点数，只需要将一个组件属性通过补间（Tween）关联到动画对象上，Flutter会确保在每一帧渲染正确的组件，从而形成连贯的动画。这种十分暴力的操作在Flutter上却看不到明显的卡顿，这也是Flutter的一个魔力所在。相比之下其他跨平台框架几乎不能设计动画……往往会遭遇非常严重的性能问题。

• UI跨平台稳定
  Google直接在两个平台上在底层重写了UIKit，不依赖于Css等外部解释器，几乎不存在UI表达不理想，渲染不正常的情况，可以获得非常稳定的UI表达效果。Css换个浏览器就有不同的表现，基于Css的跨平台框架很难获得稳定的UI表现。

• 可选静态的语言，语言特性优秀
  Dart是一个静态语言，这也是相对于js的一个优势。Dart可以被编译成js，但是看起来更像java。静态语言可以避免错误，获得更多的编辑器提示词，极大的增加可维护性。很多js库也已经用ts重写了，Vue3.0的底层也将全部使用ts编写，静态语言的优势不言而喻。

• 编译模式Jit/Aot
  不同于传统的开发框架，flutter天生支持两种编译模式(Jit/Aot),使得开发页面的效率大大提高，不用再修改代码后再编译一次然后运行，

• 代码量大大减少
  相对与原生语言java/kotlin /oc/swift 而言，flutter使用自研Dart语言开发界面和功能，代码量可以减少50%以上。

• 缺点

• 假装跨平台，躲不开原生代码
  这是最大的问题，跨平台框架说白了就是UI跨平台，最后还是在原生平台运行，本来两个平台就有天壤之别，一套代码就想吃掉iOS和Android在实际应用之中其实根本就不现实。Flutter具有与原生代码互相调用的能力固然非常科学，但是问题反而显得更加明显——我一个前端工程师上哪里去知道什么是UIViewController，什么是Activity呢？我要是双端都熟悉，学习Flutter就显得很没有必要。这是一个很矛盾的点，特别是在团队里，只有几个前端突然想学Flutter，是绝对做不来大项目的，如果有原生开发者，那就没必要搞Flutter了。

• 组合而不是继承的思路
  Flutter提倡“组合”，而不是“继承”。在iOS开发中，我们经常会继承UIView，重写UIView的某个生命周期函数，再添加一些方法和属性，来完成一个自定义的View。但是在Flutter中这些都是不可能的——属性都是final的，例如你继承了了一个Container，你是不能在它的生命周期中修改他的属性的。你始终需要嵌套组合几种Widget，例如Row，Container，ListView等Widget。这种方法非常不符合直觉，初学时很难想明白如何构建一个完整的组件。

• 市场占有
  虽然目前flutter的占有率暂时不如RN，但是随着阿里，腾讯，携程等大厂纷纷接入flutter,相信在不远等未来，flutter很容易超过市面上所有等跨平台框架

• 使用Dart语言，还属于小众语言
  Flutter详细说明链接：https://book.flutterchina.club/chapter1/mobile_development_intro.html

• 具体分析

• 代码重用率
  Android和iOS一套代码，但跟系统相关的一些复杂功能，需要特殊适配和调试，flutter需要掌握比较多的原生开发知识，另外虽然说起来是一套代码，但实际不管RN还是flutter提供的安卓和iOS都是两套，在具体写的时候可能UI还是要写两套。

• 第三方SDK支持情况
  目前flutter的开源社区基本上一些常用功能的SDK都有，满足基本要求，但不丰富

• 兼容性
  兼容性尚可。

• 性能
  性能很接近原生开发。

• 学习成本
  原生开发也需要较高的能力，iOS的也要学习安卓，安卓的也要学习iOS。

Dart语言是新语言，学习成本也较高。

• 市场人力储备
  市场人力储备不足，目前也就一些前沿公司小规模尝试，市面上很难招到有flutter实际开发经验的开发人员。
• 社区活跃度
  因为flutter出的也不久，所以社区很活跃，在google的大力推进下，框架很多问题都基本得到解决。
• 框架市场占比
  没找到相关资料，从各种资料描述预估30%左右，且国外比国内的占比高些框架对最新操作系统的支持情况（框架最新支持的迭代速度）
• 支持较快

三、 总结

* React Native、Flutter主要的坑就在于需要**非常了解原生的环境**，其实跨平台的框架都是如此，想要通过跨平台的API就拿下双端的开发任务，对认真学习的原生开发者来说也是不公平的。
* 不管Weex、RN还是Flutter，都无法做到完全的一套代码维护两端产品，之后基本上还是iOS，安卓，和对应框架三套代码同时维护。Flutter更符合趋势一些。
* weex目前bug比RN还多，社区也不如RN和Flutter，所以暂时不做讨。
* 相比之下RN和Flutter差不多，RN优势在于市场活跃度高于Flutter，但是致命问题受到Facebook对应协议的约束。
* Flutter在2017年投放市场，虽然到现在才3年，但是有Google公司做后盾，相信发展会越来越好。