半年前在公司的技术分享搬到简书来。
前言
移动互联网时代到来之后，移动App成为新的主流，而浏览器的地位则逐渐降低。但是移动app开发成本高，不能够动态部署成为行业痛点。移动端统一是未来趋势，大前端不仅会成为移动开发与 Web 前端的发展趋势，也将会是未来的显示设备终端的开发技术趋势。
只是现在方向不明显，没有出现能够统一前端与移动端的技术，市场上解决方案鱼龙混杂，需要花时间去尝试，仔细甄别。
App跨平台技术对比
reactNative
react native 用了 react 的设计模式，但UI渲染、动画效果、网络请求等均由原生端实现。开发者编写的js代码，通过 react native 的中间层转化为原生控件和操作，总结起来其实就是利用 JS 来调用 Native 端的组件，从而实现相应的功能。
特点：JS语言、react语法、支持热更新、原生UI。
缺点：iOS/安卓部分功能代码不能复用，调用原生控件容易被操作系统卡脖子，性能比原生稍差。
flutter
Flutter 是 Google推出并开源的移动应用开发框架，主打跨平台、高保真、高性能。开发者可以通过 Dart语言开发 App，一套代码同时运行在 iOS 和 Android平台。 Flutter提供了丰富的组件、接口，开发者可以很快地为 Flutter添加 native扩展。同时 Flutter还使用 Native引擎渲染视图，这无疑能为用户提供良好的体验。
特点：自己实现底层图形绘制框架不依赖于原生、Dart语言。
缺点：18年才发布，踩坑的人较少；Dart语言需要重新学习；
Taro-多端开发框架。
使用 Taro，我们可以只书写一套代码，再通过 Taro 的编译工具，将源代码分别编译出可以在不同端（微信小程序、H5、App 端等）运行的代码。同时 Taro 还提供开箱即用的语法检测和自动补全等功能，有效地提升了开发体验和开发效率。拥有React 完全一致的 API 和组件化系统。
特点：JS语言、类react语法，写一套代码生成H5、小程序、reactNative代码。
缺点：生成各端代码，各端人员还要去做好兼容措施；目前踩坑人较少。对小程序兼容较好，H5部分兼容，reactNative兼容性较差基本不能用。
大公司技术方案
faceBook：
开源并使用reactNative,用来开发性能交互要求不高的模块与页面。
Google：
内部使用flutter来统一安卓iOS两端的开发，推进flutter支持网页端。
阿里:
阿里开源week框架（类似于reactNative），运用于项目中。持续关注reactNative，开源了reactNative组件库。阿里咸鱼团队 Flutter和Native混合开发技术。
美团:
组件化来实现多个app复用模块问题，开源了ReactNative的基础组件库beeshell，beeshell中的组件已经在美团外卖移动端应用蜜蜂App中广泛应用。
中大型团队:
使用原生+reactNative+H5技术方案，组件化解耦，RN和Native和H5之间通过指定统一的协议来实现互相调用，路由跳转功能。比如：WMRouter、MGJRouter框架。
技术使用场景
H5：
适用于纯展示页面，用户交互少页面，对更新有要求的活动页。
reactNative:
调用硬件较少的功能模块，性能要求不太高的功能，不涉及到平台差异的功能。
原生:
使用原生功能场景(定位、数据库、视频音频处理)和需要集成第三方功能场景(支付、地图、IM、统计等等)，以及复杂的长列表功能。对APP要求各方面性能、响应要求高的功能。涉及到硬件的问题，比如摄像头、陀螺仪、麦克风等硬件。
路由问题：
制定url协议来实现各个模块解耦与调用以及路由跳转。安卓使用:WMRouter, iOS使用：MGJRouter。
后端服务架构：一云多端
问题：服务端设计的API接口，面向通用服务，还是面向UI？各个端对数据的显示要求不同，给一个公共的API还是分别给不同的API？比如，时间显示，PC端可能要求“2018-6-11”的格式，而APP端可能要求“2018/6/11”的格式，接口怎么给？
再比如，相同功能的一个接口，PC Web端需要20个字段，已经做好了。现在APP端因为屏幕小，只要10个字段就够了，是复用老的API，让APP忍受垃圾信息，还是为APP额外新增一个接口？
解决：
1.考虑在前端和后端之间插入一个中间层，作为前后端之间的桥梁，增加灵活性。对于这个中间层的称呼，一种是“网关层或者接入层”，这个可能会和后台现有的网关和接入层造成混淆。另一种叫法叫做BFF(Backend for Frontends，为前端而存在的后端)针对“一云多端”，可以在BFF层做适配。可以考虑MVVM的模式，从服务器来的数据当做Model，在BFF中针对各种端，提供不同的ViewModel。如果数据变了，只要修改Model就可以了。如果要增加一种端，只要增加一个ViewModel就可以了。在这里集中修改，就可以解放各个终端的格式转化工作。服务端设计的API接口，面向通用服务，不需要面向UI。各种端的UI差异，由BFF层负责适配。这样的话，可以让后端更加专注于业务逻辑和数据服务，不需要操心各种端的差异。
2.使用GraphQL查询语言，由客户端自己掌控想要的数据。
趋势
继微信小程序出来后又出来了头条小程序、支付宝小程序、百度智能小程序等，未来还会有很多。同时，手机厂商大概是看到了小程序对其应用商店的威胁，小米、华为、OPPO、vivo 等九大国内手机厂商联手成立了“快应用联盟”，基于 react-native 技术栈，整体也很不错，尤其是天猫调用菜鸟裹裹的快应用，安卓下有非常好的体验。相较而言，微信是基于 Webview 的，而快应用使用的是原生渲染方案，比webview具有更大优势。5G时代很快就到了，在网速、内存和 CPU 更高的情况下，5G 每秒最高下载速度高达 1.4G，秒下秒用的快应用会得到很大的发展。
计划
1.统一原生与H5交互规范，解决前端调用原生方法不统一的问题。
2.iOS/安卓集成reactNative做混合开发。移动端改造目前项目框架做好能够集成reactNative的准备，方便reactNative能随时切入进来。
3.选择合适的功能需求进行业务尝试。
难点与风险
1.跨平台技术未来发展方向不明确，受操作系统影响大。
2.让移动端与前端掌握对应技术，学习时间成本大。
3.团队人员变动，未来招聘不容易招到合适的人，招聘成本增加。
