1. 为什么需要跨平台技术
伴随着移动互联网的高速发展，公司间竞争越来越激烈，如何将好想法快速落地、快速试错，成为备受关注的问题。提升研发效率、缩短研发周期，保障产品快速试错并能快速迭代新功能，让新产品新功能以最快的速度同时抵达 Android、iOS 等多端用户。
众所周知，
- Android 应用采用 Java 或 Kotlin 编写
- iOS 应用采用 Objective-C 或 Swift 编写
- Web 端采用 HTML/CSS/JavaScript 编写
当需要开发支持多端的应用，每一端都需要独立研发、测试，一直到上线，以及后续的维护工作，工作量成倍增涨，势必延长研发周期。
为了解决多端独立开发的问题，跨平台技术便应运而生，各大互联网公司为此都投入大量人力，于是出现了各种跨平台技术框架
2. 移动端技术选型
作为移动端的跨端技术方案，所关注无外乎以下这4个方面：
- 研发效率
- 动态性
- 多端一致性
- 性能体验
2.1 研发效率 (write once，run everywhere)
最大化代码复用，减少多端差异的适配工作量，降低开发成本，专注业务开发，实现“write once，run everywhere”的终极目标。效率提升是贯穿整个业务的生命周期线，即便业务上线后，可持续降低后续的维护成本，加快新feature的迭代速度，这是一个持续的效率收益。当然，这里不得不说，任何一门新技术在开发启动学习阶段会有一些成本，但上手后的收益是长期的。
2.2 动态化 (突破渠道的更新频率，可快速迭代新功能)
突破渠道的更新频率，可快速迭代新功能，这一点不仅是跨平台技术的诉求，也是Native技术必备的杀手锏，这也是评估跨端技术的一个重要考核点。
2.3 多端一致性
好产品在多端UI设计上，往往是整体风格统一，所以业务方采用原生各自独立开发完成后，还需额外花不少时间来修改UI以保证多端一致性；可见，各端独立实现开发方式，带来的效率滞后，不仅仅是Android和iOS各开发一份代码的工作量，还有双端UI的一致性对齐的工作。
2.4 性能体验
一般地，跨端技术方案拥有以上多重优势，但在性能方面比原生流畅更差些。牺牲部分体验换来效率提升，这一点也是情理之中，试想一下，跨平台技术方案同时兼得这4点，那么原生技术恐怕已退出历史舞台，早已是跨平台技术的天下，所以往往跨平台技术的性能优劣便成为核心指标。
3. 跨平台技术划分
对研发效率和体验的不断追逐，移动端的跨平台技术方框架层出不穷，然则天下武功众多，万变不离其宗，从其核心本质来划分，可大致分为以下三大类：
3.1 Web技术
主要依赖于 WebView的技术，功能支持受限，性能体验很差，比如PhoneGap、Cordova、小程序。
3.1 原生渲染
使用 JavaScript 作为编程语言，通过中间层转化为原生控件来渲染UI界面，比如 React Native、Weex。
3.3 自渲染技术
自行实现一套渲染框架，可通过调用skia等方式完成自渲染，而不依赖于原生控件，比如 Flutter、Unity
4. 跨平台技术演进
跨平台技术，一直以来是每一个有追求的开发者所追逐的梦想，同时也是守旧者的噩梦，跨平台的多端一体化方案势必颠覆现有的原生各端独立开发模式，接下来列举众多的跨平台技术中最为关键的几个技术方案的演进阶段。
上图可以看出，技术演进过程大致分以下三个阶段：
4.1 采用WebView技术绘制界面的Hybrid混合开发技术
采用 WebView 技术绘制界面的 Hybrid 混合开发技术，通过 JS Bridge 将系统部分能力暴露给 JS 调用，其缺点是性能较差，功能受限，扩展性差，不适合交互复杂的场景，比如 Cordova。
4.2 针对WebView界面性能等问题，于是绘制交还原生渲染，仅仅通过JS调用原生控件
针对 WebView 界面性能等问题，于是绘制交还原生渲染，仅仅通过 JS 调用原生控件，相比 WebView 技术性能体验更好，这是目前绝大部分跨平台框架的设计思路，比如 React Native、Weex。另外，最近小程序也比较火，第一和第二阶段的融合，依然采用 WebView作为渲染容器，通过限制 Web 技术栈的子集，规范化组件使用，并逐步引入原生控件代表 WebView 渲染，以提升性能。
4.3 Xamarin
Xamarin extends the .NET developer platform with tools and libraries specifically for building apps for Android, iOS, tvOS, watchOS, macOS, and Windows.
优点：
- 更适合 .neter 开发
- building apps for Android, iOS, tvOS, watchOS, macOS, and Windows
不足：
- IDE 是 VS，使用起来不如 AS 之类的开发工具顺畅，用多了你就懂了
- 需要你对 Android/iOS 都有一定了解的，UI 不一致你需要写 Custom Renderers， 系统功能不一致你需要写 DependencyService 之类的东西，flutter 也有类似的东西但是没这个麻烦
- 优秀的第三方库相对较少，虽然官方也提供了 Bindings Library 去引用原生第三方库，但是非常容易踩雷，当你引用的时候可能会发现缺少一些库里的方法，你还得去 Customizing Bindings, 这需要你对 java 有一定的掌握的，对新人不是很友好
- 使用的是原生控件渲染，这意味着 iOS、Android 、UWP 平台 UI 不是很一致，对 UI有要求的需要写很多 Custom Renderers, 淡然有很多优秀的第三方库替你完成了这些，提供许多漂亮的 UI 组件，但是需要付费… 不能像国内很多 app 开发一样白嫖了
- 对国内开发者而言，社区严重不活跃，我熟悉的 Xamarin 开发大多是一些工厂里的，他们有自己成熟的 .net 库，需要将想法快速落地、而且不愿付出太多成本，对 app 性能也没有很高要求，这时候用 Xamarin 还是一个不错的选择的
- 碰到开发中的一些 bug 难以解决，Xamarin 有自己的官方社区，有专人提供 技术 support, 但是很多问题需要你有耐心
4.3 提出自带渲染引擎的解决方案，尽可能减少不同平台间的差异性, 同时媲美原生的高性能体验
虽然通过桥接技术使用原生控件解决了功能受限问题，提升性能体验，但相比原生体验差距还是比较大，以及处理平台差异性非常耗费人力。于是Flutter提出自带渲染引擎的解决方案，尽可能减少不同平台间的差异性, 同时媲美原生的高性能体验，因此业界对 Flutter有着极高的关注度。
5. 细说跨平台方案技术细节
5.1 基于 WebView 的 H5 跨平台方案
以浏览器为载体的 Web 技术就具备跨平台、动态更新、扩展性强等优点。随着移动设备性能的增强，Web 页面的性能也逐渐变得可以接受。客户端中出现越来越多的内嵌 Web 页面，很多应用也会把一些功能模块改为 Web 实现。
缺点
- 启动白屏时间。
WebView是一个非常重量级的控件，无论是是WebView的初始化，还是整个渲染流程（Native 时间 + 网络时间 + 渲染时间）都非常耗时。这导致界面启动的时候会出现一段白屏时间，体验非常糟糕。 - 响应流畅度。由于单线程、历史包袱等原因，页面的渲染和
JavaScript的执行效率都不如原生。在一些重交互或者动画复杂的场景，H5 的性能还无法满足诉求。
所以在移动端 H5 主要应用在一些交互不太复杂的场景，一般来说即使帧率不如原生，但也基本符合要求。从我个人的感受来看，H5 当前最大的问题在于启动的白屏时间。
优点
随着技术的进步和各种优化方案的出现，启动白屏时间可以得到相当程度的优化，但是 响应流畅度 的问题还是存在的，不适合重交互的场景
5.2 React Native 和 Weex
基于 WebView 的 H5 跨平台方案，经过近乎疯狂的性能优化，看起来性能真的不错了。但是对于一些交互和动画复杂的场景（例如左右滑屏、手势），性能还是无法满足要求。
Facebook 在 2015 年开源了 React Native，它抛弃了 WebView，利用 JavaScriptCore 来做桥接，将 JavaScript 调用转为 Native 调用。也就是说，React Native 最终会生成对应的自定义原生控件，走的是系统原生的渲染流程。
但是世上哪有十全十美的方案？React Native/Weex方案为了能达到接近原生开发的性能和交互体验，必然要在跨平台和动态性上面做出了牺牲。
React Native 和 Weex 向上对接了前端生态，向下对接了原生渲染，看起来是非常完美的方案。但是前端和客户端，客户端中的 Android 和 iOS，它们的差异并不那么容易抹平，强行融合就会遇到各种各样的坑。
既然 React Native 和 Weex 在跨平台上面做了牺牲，那它的性能和交互是不是能直接对齐 Native 开发呢？非常遗憾， 目前它们的性能我觉得主要还有两个瓶颈。
- JS 的执行时间。
React Native和Weex, 虽然它每年都在进步，但是JS是解释性的动态语言，它的执行效率相比AOT编译后的Java，性能依然会在几倍以上的差距距。 - 跨语言的通信成本。既然要对接前端和原生两个生态，就无法避免 JS -> C++ -> Java/Objective-C 之间频繁的通信和转换，所以这里面会涉及各种序列化，对性能的影响比较大。
- 平台一致性较差
虽然相比 H5 方案在性能方面有了很大的提升，但是 React Native 和 Weex 也要面对启动时间慢、帧率不如原生的性能问题。它属于一种比较中庸的方案，当然也会有自己的应用场景。例如一些二级页面（例如淘宝的分会场），它们的业务也比较重要，但是交互不会特别复杂，同时希望保持一定的动态化能力。
5.3 小程序
每一个应用都有成为超级 App 的梦想，各个大厂纷纷推出自己的小程序框架：微信、厂商、支付宝、今日头条、百度、淘宝、Google Play，小程序这个战场已然是“七国大乱战”。
但是小程序并不属于一种跨平台开发方案，大家更看重的是它的渠道优势，考虑如何通过微信、支付宝这些全民 App 获得更多的流量和用户。
6. 跨平台开发的场景
6.1 部分业务
某个业务或者页面的跨平台共享，有的时候我们还希望可以做到跨应用。例如“全民答题”的时候，可以看到这个功能可以运行在头条系的各个应用中。一个公司共用同一套跨平台方案有非常重大的意义，业务可以在不同的应用中尝试。
6.2 核心功能。
C++ 才是生命力最顽强的跨平台方案，大公司也将越来越多的核心模块往底层迁移，例如网络库、数据上报、加解密、音视频等。
6.3 跨平台开发对比
H5 的跨平台方案只要投入不太高的开发成本，就能开发出性能、功能还不错的应用。但是如果想做到极致优化，很容易发现开发者可控的东西实在比较少，性能和功能都依赖浏览器的支持。
这个时候如果想走得更远，我们不仅需要了解浏览器的内部机制，可能还需要具备定制、修改浏览器内核的能力，这也是阿里、腾讯、头条和百度都要组建内核团队的原因。
原生开发则相反，刚开始要投入很高的开发成本，但是一旦开始有产出之后，开发者能够有更大的发
挥空间，而 React Native 和 Weex 方案更是希望打造兼顾跨平台、开发成本以及性能的全方位解决方案。
7. 总结
现在好像有个观点说“Android 开发没人要”，大家都想转去做大前端开发，是不是真的是这样呢？事实上，无论我们使用哪一种跨平台方案，它们最终都要运行在 Android 平台上。崩溃、内存、卡顿、耗电这些问题依然存在，而且可能会更加复杂。而且从 H5 极致体验优化的例子来看，很多优化是需要深入研究平台特性和系统底层机制，我们学到的底层和系统相关的知识依然很重要。
对开发者来说，唯一不变的就是学习能力。掌握了学习能力和钻研的精神，就能够应对这些趋势变化。无论移动开发未来如何变化，哪怕有一天 AI 真的能够自动写代码，具备应变能力的人也丝毫不会惧怕的。
2186
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
