最近在公司里面遇到一个尴尬的事情，一开始手机是用 Native 开发的，进度赶不上产品的需求，有人反馈用 H5 可以大大加快速度，老板有点意思，但是又有人反馈用 H5 坑多，这下团队不知道如何是好，怎么选择了。
为了解决这个问题，我结合一下自己的开发经验，尝试说明一下大前端如何进行技术选型。欢迎看官给我更多建议，大家一起讨论。
名词解释
| 名词 | 说明 |
|---|---|
| 大前端 | 手机，web，pc 等客户端都包括在内 |
| Native 开发 | 只用平台原生的开发语言，开发框架来做应用 |
| 混合开发 | 用 js+h5 开发应用的技术，可以通过某种手段调用系统能力 |
| 其他 Native 开发 | 不是平台原生的开发方式，但是可以生成 Native 代码，或者调用 native 接口的技术（想不到更好的名字，抱歉，暂时叫其他native开发） |
| 开发效率 | 是指某一技术方案，开发的速度 |
| 运行效率 | 是指最终产品的体验，运行速度 |
| 需要人员 | 是指需要的人力资源的多少，人员所需的知识的范围 |
手机端
现在移动端的使用人数大于桌面端，所以先讨论一下移动端，列举一下我知道的现有的技术方案，只讨论 android 和 iOS 系统
| 技术方案 | 代表方案 | 开发效率 | 运行效率 | 需要人员 |
|---|---|---|---|---|
| Native开发 | Android，iOS原生框架 | 高 | 高 | 两套人马，需要 Android，iOS 的知识 |
| 混合开发 | Cordova，AppCan | 极高，最新的语言和框架，one code base | 低 | 一套人马，需要web知识 |
| 其他Native | RN，WEEX，Xamarin | 很高 | 比较高 | 一套人马，需要相关技术框架知识（比如web），有一位专家解决和原生平台相关的问题 |
注意点：
- 混合开发不是只开发一个 h5 webapp 就好了，h5 是需要调用本地接口的，所以需要部署在本地，如果把 h5 放在远程，就只能显示一些静态资源，如果远程调用本地接口，则是非常危险的事情。
- 其他 Native 方案不一定是 Javascript 写的，比如 Xamarin 就是用 C#，所以挑选自己团队喜欢的方案很重要，需要有个人能罩得住，有一些和原生平台相关的问题，需要技术专家去解决。
- 其他 Native 方案实际上是牛逼团队提出的方案，他们有原生平台非常精通的人，也有其他领域精通的人（比如 Xamarin 就需要 C# 精通，Mono 虚拟机有所了解和原生也懂的人。RN 需要对 React，JS，原生系统都很了解），所以人家能提出牛逼方案，如果你的团队没有能罩得住的人，则会在不断挖坑填坑。
- 业务非常着急的小团队，还是比较适合技术栈不复杂，有很多成熟方案技术路线，所以原生开发比较合适，也好招人。
- 业务非常着急，但是有钱，可以招牛人或者已经有几位牛人的团队，适合用“其他 Native 方案”。
- 小白比较多的团队，也适合使用原生开发。
- 特别小的创业团队，验证商业逻辑的，可以使用混合开发，因为性能不是最重要的。
- 如果使用了原生的开发方式，其实也还可以混合其他开发方式，当团队发展壮大的时候，可以适当的切换。
- 上面并没有开发游戏的方案，因为我还没做过游戏，游戏和 APP 开发的原理也差别很多，游戏里面比较火的引擎，https://unity3d.com/cn，也是用 C#，JS 作为主要开发语言
- 很多人会疑问为啥 Native 开发的效率也是高，那是因为开发效率是只开发的速度，Native 一般都有比较成熟的框架，所以当然不会慢，只是需要两套人马，成本高。
- Google 推出了一个框架 Flutter，据说是提供了一个引擎，所以你发布的App的时候要带上这个引擎，咸鱼有尝试用，还不是很成熟。
总结一下，对公司来说，没有最好的方案，只有最适合自己的方案。混合开发可以做到
one code base，write once，run anywhere，其他native方案可以做到learn once, write anywhere，native开发方案最成熟，技术栈简单，坑少
PC端
虽然现在互联网产品 PC 端的产品比较少，不过我最近还是遇到过一些需求，需要在 Linux，Mac，和 Windows 上跑。相比较与手机，PC 的能力强大很多，所以在 PC 上，混合开发的模式比较流行。
我只在 windows 上使用过传统的 native 开发方式，所以只能比较一下windows上传统的开发方案和混合开发方案的优缺点。
| 技术方案 | 代表方案 | 开发效率 | 运行效率 | 需要人员 |
|---|---|---|---|---|
| Native | MFC | 听过这个名词的，都是老人，开发效率不做评价 | 高 | 需要 CPP 和windows 的大牛才能 handle 此 framework，是微软大又笨的代表 |
| Native | WTL | 去掉 MFC 框架，使用 windows API 的一个轻量框架，CPP 开发 | 高 | CPP 大牛，windows 大牛 |
| Native | win-form | .net 平台，效率高 | 高 | C#，.Net，windows 平台知识 |
| Native | wpf | .net 平台，效率高，代替winform | 高 | C#，.Net，windows平台知识 |
上面的技术都不能跨平台，当然C#有一个跨平台的虚拟机mono，mono 上以前有一个公司 Xamarin，可以做 Mac 上的开发，现已被微软收购。
这些技术已经都不是我的菜，现在比较一下跨平台方案
| 技术方案 | 代表方案 | 开发效率 | 运行效率 | 需要人员 |
|---|---|---|---|---|
| Native | QT | 有 QML，JS 接口，高 | 高 | CPP 大牛，各个系统平台大牛 |
| 混合开发 | electron | web技术开发，高 | 尚可，复杂动画不行 | web 大牛，需要一些平台知识 |
很明显，如果不是做游戏，electron 是一个很好的方案了，我们常用的开发工具vs code，就是用electron开发的。
总结一下，跨PC平台的开发，electron可以做到
one code base，write once，run anywhere
“其他 Native 开发”和 Web 开发的关系
其他 Native 开发现在比较火的 ReactNative 和 Weex（不知道火不火，据说手淘在用），都使用了一些 web 端的框架和知识，所以有必要说明一些他们和web开发的关系。
下图以React Native举例说明
React Native 和 React 开发 web 使用的是同样的框架，不同点一个生成 DOM 在浏览器中渲染，一个是最后还是调用 native 接口。这样我们学习了 React 的知识以后，就可以在不同的平台下使用，做到学习一次，可以在各个平台上写代码，做到了人力资源的复用。
既然 React Native 是需要调用平台原生的接口，那么他和混合开发模式有什么区别呢，我们看下图，下图向我们说明，每一个 UI 元素，对应的都是 Natvie 的控件，所以 UI 渲染也是 Native 的，只是我们用 JS 去写而已。其实 Xamarin 也是类似原理。
作为对比，我们看一下混合开发的架构，在下图的混合开发架构中，我们看到渲染界面是用 HTML 开发的，所以最影响用户体验的 UI，我们交给了 WebView，所以他的表现目前来说是没有 Native UI 好的。
electron 架构
在 PC 上混合开发的模式和手机比较像，electron 更近一步的是使用了浏览器的多进程架构，所以你开发的应用等于是一个浏览器加上网页。手机里面没有使用的原因是因为不是所有的 APP 都需要这种复杂的架构，只需要调用 native 接口就好。
electron 牛逼的地方在于，主进程有 Node 环境， 但是渲染进程也有 Node 环境，只是被阉割放在容器里面了。大部分 electron 使用 H5 渲染界面，但是菜单等和系统相关的 UI，是在 Main Process 里面使用 native ui 完成的。
React Native 是否能做到不写平台相关的代码
这个问题，我特别咨询了一位前同事，他用react native写过几个项目，他给我的答案是大部分可以做到，他采用的方案是尽量使用两个平台都支持的控件。
- 50%使用 ant design moblie，
- 30%使用其他跨平台开源控件
- 20%自己开发跨平台开源控件
- 一些和原生相关的问题，一些坑，由自己解决，其他都可以招 web 开发工程师。
- 采用这套方案后，还可以兼容微信小程序。
- 他的产品主要是银行产品，工具属性比较重。
- 可以一套人马打天下，测试的时候，也可以减少人力，因为逻辑代码也是一套。
其他方案
当然，还有一些更小众的方案，比如用 C# 开发，Xamarin 可以了解以下。C++ 开发可以了解以下 QT，也可以使用 C++ 开发逻辑，这样也能跨平台，这样的团队可能不多了。
总结
我们可以看到，使用“混合开发方案”和“其他 Native 开发方案”可以复用代码，确实整体效率高了，但是这些技术方案由于增加了技术栈，可能会导致一些坑，影响开发，所以，选择每个方案前，一定要清楚技术上能不能把握住。
由于时间关系，很多东西只是草草网上找个图，所以没有深入探讨，等以后深入到代码，再总结总结。
