大前端应用对比
现今的前端应用实现方案已经不仅仅只有H5这种形式了，各端小程序、RN、Flutter等相继都在各自领域散发着不同的光芒。本文将各种方案做一个简单的整理，便于方案选型是使用，大概内容如下：
| 平台 | 优势 | 劣势 | 适用场景 | 难易程度 |
|---|---|---|---|---|
| H5 | 1.跨平台 2.开发成本低 3.维护迭代方便 4.推广成本低 |
1.联网要求高 2.性能不够理想 3.调用硬件困难 4.复杂交互性能低 |
1.需要跨平台能力 2.展示内容丰富 3.互动性没有特别高 4.性价比要求高 |
简单 |
| 微信小程序 | 1.即用即走 2.跨平台 3.使用微信提供原生能力 4.倚靠微信流量/微信生态赋能 |
1.留存问题 2.受控于微信 3.适用性：只能微信端使用 |
1.只在微信环境使用 2.使用系统硬件能力 3.使用微信赋能 |
中等 |
| 京东小程序 | 1.倚靠京东APP流量 2.京东APP赋能 |
1.只能在京东APP运行(京东系后续可能会支持) 2.兴起时间较短，不完全成熟 |
1.只在京东APP内使用 2.需要京东APP赋能的场景 |
中等 |
| ReactNative | 1.用户体验更好 2.布局简便 3.拓展性较强(调用原生) 4.原生能力支持(动画、收拾等) |
1.扩展性稍弱 2.开发体验不好 3.对开发人员要求较高 |
1.需要跨平台能力 2.需要性能较好的情况 |
中等偏难 |
| Flutter | 1.性能好 2.动画交互实现简单 3.开发体验较好 |
1.只有UI跨平台 2.开发思想需要转换 3.组件、社区不够完善 |
1.需要跨平台能力 2.追求高性能场景 3.有一定研究能力 |
困难 |
| 原生 | 1.性能超好 2.可以充分使用硬件能力 3.再次访问成本低、速度快 |
1.不跨端 2.维护复杂 3.首次访问成本高 |
1.开发时间充足 2.需要百分百硬件性能 3.需要充分调用硬件能力 |
难 |
用户体验
性能
开发难度
开发成本
社区
H5应用
H5应用的优势
1、跨平台。支持设备范围广，可以跨平台，编写的代码可以同时在Android、IOS、Windows上运行
2、开发成本低、周期短。移动互联网是一个快鱼吃慢鱼的时代，谁对用户的需求满足的更快，谁的试错成本更低，谁就拥有巨大的优势。互联网产品大多免费、且有网络效应，后入者抢夺用户的难度非常大。使用原生开发，从招聘、开发、上线各个环节的效率都慢一倍以上，而且参与的人越多，沟通效率往往拖慢不止一倍
3、维护迭代方便。用户可以直接使用最新版本（自动更新，不需用户手动更新）。很多人有这样的体会，一个原生应用上线Appstore，突然有一个大bug，只好连夜加班修复，然后静静等待2周或更长时间的Apple审核，这2个星期被用户的涂抹淹死，市场上一片差评，用户大量流失。等新应用被审核上线了，用户已经卸载了。但是，HTML5没有这些问题，你可以实时更新，有问题立即响应
4、推广成本低。HTML5应用导流非常容易，超级App(如微信朋友圈)、搜索引擎、应用市场、浏览器，到处都是HTML5的流量入口
H5应用的劣势
1、对联网要求高，离线基本不能做任何操作。而且H5如果图片等资源多，会拖累加载速度，耗费网速，用户体验不是很好。
2、H5应用在APP反应速度较慢，页面切换流畅性较差，用户体验感较差。H5运行需要调用更多的系统资源，造成H5的使用体验有一定影响
3、体验和性能上有很大的局限性，由于调用手机硬件（摄像头、麦克风等）困难，难以实现更多场景的需求。本身H5的技术还有着不完善，不完美的用户体验也很容易打击用户，造成留存不高，转化不高的情景。
4、多图处理和复杂交互动画性能不高，对硬件要求较高。复杂场景手机运行慢，手机内存饱和运行速度慢或者网速不给力，加载H5时候就会变慢
适用的场景
1、需要跨平台能力：既可以在APP中使用，也可以到其他浏览器(微信/浏览器)环境使用的场景
2、展示内容丰富：适合展示有大段文字（如新闻、攻略等），且格式比较丰富（如加粗，字体多样）的页面
3、适合用户互动性没有特别高，视觉效果比较好的场景。可以提高流量转化，加快获客的效率和速度
4、性价比要求较高的场景：H5制作成本低，传播成本低，维护成本低，总体上而言，性价比非常高
难易程度：简单
微信小程序
微信小程序优势
1、即用即走。——这个是从微信小程序上线就开始打的概念。即用即走使得小程序可以代替许多APP，或是做APP的整体嫁接，或是作为阉割版功能的承载体
2、倚靠微信流量。——相比APP，小程序一个突出的优点是完全嵌入了微信的聊天、公众号体系，完美进行微信体系内的流量引导。这一方面令小程序更加容易获客，另一方面也可以借助微信的成熟社交网络达到爆发式传播
3、连接线上线下。——连接线上线下场景也是微信小程序重要的一环，甚至最先开始为了推动线下习惯的养成，小程序在线上场景方面做了较强的限制。由于人们用微信扫描二维码的习惯培养得比较好，小程序相比APP更容易达成线上线下场景的连接与互动
4、使用微信原生提供的能力(需要用户授权)。微信提供了很多APP原生才有的能力，比如蓝牙/NFC等在小程序上使用便捷
5、微信赋能。包括微信为小程序提供的广告、直播流等API，相当于为传统的开发提供了一条高速路，使得开发这些能力有更简单的操作方式。还有微信体系能力的使用，包括登录、支付使用也是非常便捷
微信小程序的劣势
1、留存问题。——虽然有部分小程序已经杀出重围，但是普遍来讲，主打“即用即走”的小程序在用户留存上仍存在很大的提升空间。阿拉丁发布的小程序白皮书中显示，小程序的平均次日留存在13%左右，但是双周留存骤降到仅有1%。轻易拥有的也不在意失去，这大概是小程序目前的一个症结所在
2、受控于微信。——比起APP，尤其是安卓版的高自由度，小程序要面对很多来自微信的限制，从功能接口，甚至到类别内容，都要接受微信的管控，部分敏感内容还很容易遭受封禁威胁
3、适用性(原生)。–原生开发的微信小程序只能使用在微信客户端，无法在其他浏览器等环境运行
适用场景
1、只在微信环境使用，微信小程序无法在其他环境运行
2、需要调用系统硬件能力，如摄像头、蓝牙、NFC等
3、需要使用微信赋能能力，如微信支付、微信登录、微信广告支持等
难易程度：中等
京东小程序
京东小程序基本能力与微信小程序类似。赋能部分是京东APP对其进行赋能，可以便捷的使用京东体系能力、
京东小程序优势
1、依靠京东APP流量：京东APP内入口，提供京东流量之上的用户量
2、京东APP赋能：便捷的使用京东APP提供的能力，包括京东登录、京东支付、手机号授权、位置信息等
京东小程序劣势
1、只能在京东APP内运行
2、京东小程序兴起时间不长，具体用户体验还需要更多的时间来证明
适用场景
1、只需要在京东APP内部使用
2、需要京东APP赋能的能力：比如使用用户信息、唤起原生支付、调用扫码功能等
难易程度：中等
ReactNative
RN的优势
1、用户体验高于HTML，RN不用Webview，彻底摆脱了Webview让人不爽的交互和性能问题。虽然不能做到一处编码到处运行，但是基本上即使是两套代码，也是相同的jsx语法，使用js进行开发。用户体验，高于html，开发效率较高
2、全局采用flexbox布局。据说比native的自适应布局更加简单高效
3、有较强的扩展性。这是因为Native端提供的是基本控件，JS可以自由组合使用
4、可以直接使用Native原生的动画，例如iOS右滑返回等。用H5实现有很多问题
5、支持热更新。可以通过更新远端JS，直接更新app
RN的劣势
- 扩展性不如H5，H5开发的应用有更强的拓展性。H5沉淀许久，各种拓展能力都比较强，且RN的拓展性同样不用原生写的拓展能力强
- 从Native到Web，要做很多概念转换，势必造成双方都要妥协。比如web要用一套CSS的阉割版，Native通过css-layout拿到最终样式再转换成native原生的表达方式（比如iOS的Constraint\origin\Center等属性），再比如动画。另外，若Android和iOS都要做相同的封装，概念转换就更复杂了。
1、对开发人员要求较高。不是懂点web技术就行的，当官方封装的控件、api无法满足需求时 就必然需要懂一些native的东西去扩展，扩展性仍然远远不如web，也远远不如直接写Native code
3、发展还不成熟，目前很多ui组件只有ios的实现，android的需要自己实现。从Native到Web，要做很多概念转换，势必造成双方都要妥协。比如web要用一套CSS的阉割版，Native通过css-layout拿到最终样式再转换成native原生的表达方式（比如iOS的Constraint\origin\Center等属性），再比如动画。另外，若Android和iOS都要做相同的封装，概念转换就更复杂
RN的适用场景
难易程度：中等偏难
用过 React 会知道，React 的核心概念是「DOM Representation」，在开发者和 DOM 中间构建一个中间件，然后通过高效的算法来 diff 两次 Virtual DOM 渲染的差异，然后在最小范围内更新 DOM，在大部分情况下——注意是大部分不是所有——这种做法都是足够高效的，但是对于精细的需求、动画控制等——比如在移动设备上做一个跟随 touchmove 的元素，还要各种 transition 等等——场景 React 会显得力不从心，或者很笨拙。
但是抛开这些太过复杂的需求，React 是有能力满足大部分的业务场景的。再说 React Native，这几天不停看见媒体用「Web 开发要 XXX」一类的题目来发稿，真是吐槽无力。
React Native 根本都不算 Web 开发好不好——Webview 都没了还 Web 个 bird 啊…
React Native 继承了 React 在 JavaScript 的扩展语法 JSX 中直接以声明式的方式来描述 UI 结构的机制，并实现了一个 CSS 的子集，这把「DOM Representation」的概念外扩成了「UI Representation」，由于不是操作真实 UI，就可以放到非 UI 线程来进行 render——所有做客户端 UI 开发的都应该知道 UI 线程是永远的痛，无论你怎么 render，render 的多低效，这些 render 都不会直接影响 UI，而要借由 React Native 来将改变更新回 UI 线程。
由于目前没有任何示例代码，也看不到更细节的实现机制介绍，所以以下部分为猜测。如果 React Native 沿袭 React 的机制，就会同样是把两次 render 的 diff 结果算出来，然后把 diff 结果传递回主线程，在最小范围内更新 UI。
所以，核心是以下三点：
- 在非 UI 线程渲染 UI Representation
- 高效的 diff 算法保证 UI update 的高效
- 没错，由于中间件的机制，React 很有可能成为一个跨平台的统一 UI 解决方案，可以理解为 UI 开发的虚拟机？声明式 UI 开发，简单快捷，必然大有作为。精细控制无力，复杂应用场景无法很好满足，必然受限。最后再说一句…不是能写 JavaScript 就叫 Web 开发…
flutter
flutter的优势
1、优势就是性能好使用流畅，跨平台：Flutter对比weex和react native相比，性能的强大是有目共睹的。基于dom树渲染原生组件，很难与直接在原生视图上绘图比肩性能，Google作为一个轮子大厂，直接在两个平台上重写了各自的UIKit，对接到平台底层，减少UI层的多层转换，UI性能可以比肩原生，这个优势在滑动和播放动画时尤为明显。
2、优秀的动画设计：Flutter的动画简单到不可思议，动画对象会根据屏幕刷新率每秒产生很多个（一般是60个）浮点数，只需要将一个组件属性通过补间（Tween）关联到动画对象上，Flutter会确保在每一帧渲染正确的组件，从而形成连贯的动画。这种十分暴力的操作在Flutter上却看不到明显的卡顿，这也是Flutter的一个魔力所在。相比之下其他跨平台框架几乎不能设计动画……往往会遭遇非常严重的性能问题。
对于开发来说
1、路由设计优秀：Flutter的路由传值非常方便，push一个路由，会返回一个Future对象（也就是Promise对象），使用await或者.then就可以在目标路由pop，回到当前页面时收到返回值。这个反向传值的设计基本是甩了微信小程序一条街了。弹出dialog等一些操作也是使用的路由方法，几乎不用担心出现传值困难
单例模式：Flutter支持单例模式，单例模式的实现也非常简单。单例模式很好的解决了一些问题。相比之下，js的单例则并不是一个真正的单例，或者说不是一个简单的单例，这也是受限于js所运行的环境。单例模式并不总是合理的，容易被滥用。但是在App的初期开发中，往往一个容易实现的单例可以帮助我们快速完成一些逻辑的搭建。
2、UI跨平台稳定：Google直接在两个平台上在底层重写了UIKit，不依赖于Css等外部解释器，几乎不存在UI表达不理想，渲染不正常的情况，可以获得非常稳定的UI表达效果。Css换个浏览器就有不同的表现，基于Css的跨平台框架很难获得稳定的UI表现。
3、可选静态的语言，语言特性优秀：Dart是一个静态语言，这也是相对于js的一个优势。Dart可以被编译成js，但是看起来更像java。静态语言可以避免错误，获得更多的编辑器提示词，极大的增加可维护性。很多js库也已经用ts重写了，Vue3.0的底层也将全部使用ts编写，静态语言的优势不言而喻。
Flutter的劣势
1、假装跨平台，躲不开原生代码：这是最大的问题，跨平台框架说白了就是UI跨平台，最后还是在原生平台运行，本来两个平台就有天壤之别，一套代码就想吃掉iOS和Android在实际应用之中其实根本就不现实。Flutter具有与原生代码互相调用的能力固然非常科学，但是问题反而显得更加明显——我一个前端工程师上哪里去知道什么是UIViewController，什么是Activity呢？我要是双端都熟悉，学习Flutter就显得很没有必要。这是一个很矛盾的点，如果有原生开发者，那就没必要搞Flutter了
2、组合而不是继承的思路：Flutter提倡“组合”，而不是“继承”。在传统的前端开发以及面向对象开发的思想中，基本上都是使用继承的思路进行工作的
3、Widget的类型难以选择：Flutter中属性都是final的，例如你继承了了一个Container，你是不能在它的生命周期中修改他的属性的。你始终需要嵌套组合几种Widget，例如Row，Container，ListView等Widget。这种方法非常不符合直觉，初学时很难想明白如何构建一个完整的组件。
4、糟糕的UI控件API：虽然google尽可能的让我们通过构造函数定制化Widget，但是也难免有遗漏的
5、使用Dart语言开发，有一定的学习成本
6、周边社区不够丰富。flutter作为19年火起来的新贵，社区资源、组件都都在进一步扩展当中，相对H5/RN来说，拓展资源相差还比较大
适用的场景
1、需要跨平台能力：flutter平台一致性较强，一套代码可以运行在安卓/iOS两端，且还可以打包成H5运行在浏览器端
2、追求高性能场景：flutter的Skia框架绘制能力较强，性能相对于RN通过桥接方式调用原生组件有较大的提升
3、有一定的研究能力：因为现阶段的flutter应用并没有特别广泛，遇到问题时可能需要更多的精力来处理
难易程度：难
原生开发
原生开发的优势
1、性能超好：不用运行额外的渲染框架、引擎等。对手机性能要求更低，运行性能更加流畅
2、硬件完全使用能力：原生APP是一个系统性的应用程序，可以类比于电脑上的软件。原生app可以调用移动终端的硬件设备， 比如：麦克风、摄像头、短信、GPS、蓝牙、重力感应等。实现功能丰富
3、再次访问成本低：原生的应用程序独立安装，可以访问本地资源、缓存，所以原生开发的APP可以节约宽带成本
4、再次访问速度快：原生APP由“云服务器数据+APP应用客户端”两部分构成，APP应用所有的UI元素、数据内容、逻辑框架均安装在手机终端上。访问的时候，不需要重新下载加载应用页面框架，只需要加载数据即可。所以加载速度更快，页面响应更快
原生开发的劣势
1、无法跨端使用： 每一种移动操作系统都需要独立的开发项目，iphone版本、Ipad版本、安卓版本。每种平台都需要独立的开发语言。需要使用各自的软件开发包，开发工具以及各自的控件。开发成本高、开发速度慢、维护成本高。三个平台（IOS、安卓、windows）的规则、推广、运营都不相同。官方应用商店对APP上线审核流程比较复杂而且很慢，会严重影响APP的发布上线。
2、需要维护不同版本：由于不同操作系统版本API等更改，需要维护不同的APP版本
3、首次访问成本高：需要下载APP访问，首次访问成本较高
原生开发适用场景
1、开发时间充分
2、需要百分百硬件性能
3、需要充分调用硬件能力
难易程度: 难