移动开发跨平台技术

1. 为什么需要跨平台技术

随着移动互联网的快速发展，企业之间的竞争日益激烈。 如何快速实施好的想法并快速试错成为人们非常关心的问题。 提高研发效率，缩短研发周期，保证产品快速试错，快速迭代新功能，让新产品、新功能尽快触达iOS、iOS等多终端用户。

众所周知，

当需要开发支持多终端的应用时，每个终端都需要独立开发、测试直到上线，以及后续的维护工作。 工作量成倍增加，开发周期势必延长。

为了解决多终端独立开发的问题，跨平台技术应运而生。 各大互联网公司在这方面投入了大量的人力，因此各种跨平台的技术框架应运而生。

2、移动终端技术选型

作为移动端跨端技术解决方案，我们重点关注以下四个方面：

2.1 研发效率（一次，运行）

最大化代码复用，减少多端差异的适配工作量，降低开发成本，专注业务开发，达到“一次，运行”的最终目标。 效率提升是贯穿整个业务的生命周期线。 即使业务上线后，也能不断降低后续维护成本，加速新的迭代。 这是持续的效率增益。 当然，这里必须要说的是，任何新技术在开发和启动学习阶段都会有一些成本，但上手后的好处是长期的。

2.2 动态（突破频道更新频率，快速迭代新功能）

突破渠道更新频率，让新功能快速迭代。 这不仅是跨平台技术的要求，也是技术的必备条件。 也是评价跨端技术的重要考核点。

2.3 多端一致性

好的产品在多端UI设计上往往具有统一的整体风格。 因此，业务方在使用原生独立开发后，仍然需要花费大量额外的时间来修改UI，以保证多端一致性。 可见各个终端独立实现了开发方式。 带来的效率滞后不仅是iOS开发代码的工作量，还有UI两端一致对齐的工作量。

2.4 性能体验

总体来说，跨端技术方案具有上述多重优势，但其性能却比原生流畅度差。 牺牲部分经验来换取效率的提升也是合理的。 想象一下，一个跨平台的技术方案同时具备这四点。 那么原生技术可能就退出历史舞台了。 长期以来一直是跨平台技术的世界，因此往往是跨平台的。 技术性能成为核心指标。

3、跨平台技术划分

在对研发效率和体验的不断追求下，移动终端的跨平台技术框架层出不穷。 然而世间武功有很多，却始终不变。 根据其核心本质，大致可以分为以下三类：

3.1 网络技术

主要依赖先进技术，功能支持有限，性能体验较差，如、、、小程序。

3.1 原生渲染

将其作为编程语言，通过中间层转换为原生控件来渲染UI界面，例如Weex。

3.3 自渲染技术

自己实现一套渲染框架，可以通过调用skia等完成自渲染，无需依赖原生控件，比如，

4. 跨平台技术演进

跨平台技术一直是每一个雄心勃勃的开发者所追求的梦想，也是保守派的噩梦。 跨平台多终端一体化解决方案势必颠覆现有各终端原生独立开发模式。 下面列出了许多跨平台技术中最关键的技术解决方案的演进阶段。

从上图可以看出，技术演进过程大致分为以下三个阶段：

4.1 使用技术绘图界面的混合开发技术

采用技术绘图接口的混合开发技术，通过JS将系统的部分能力暴露给JS调用。 其缺点是性能差、功能有限、可扩展性差，不适合诸如.

4.2 鉴于界面性能等问题，绘图回归原生渲染，原生控件仅通过JS调用。

鉴于界面性能等问题，绘图回归原生渲染，原生控件仅通过JS调用。 相比技术性能，体验更好。 这是目前大多数跨平台框架的设计思想，比如Weex。 另外，最近小程序也开始流行。 集成的第一和第二阶段仍然使用它们作为渲染容器。 通过限制Web技术栈的子集、标准化组件的使用、逐步引入原生控件来表示渲染，来提高性能。

4.3

.NET 以及适用于 、iOS、tvOS、 、 和 的应用程序。

优势：

不足的：

4.3 提出一种拥有自己的渲染引擎的解决方案，最大限度地减少不同平台之间的差异，同时提供与原生相当的高性能体验。

虽然通过桥接技术使用原生控件解决了功能有限的问题，提升了性能体验，但相比原生体验差距还是比较大，而且处理平台差异非常费力。 因此，提出了内置渲染引擎的解决方案，以尽量减少不同平台之间的差异，同时又能媲美原生的高性能体验。 因此，受到了业界的高度关注。

5. 详细介绍跨平台解决方案的技术细节 5.1 基于H5的跨平台解决方案

基于浏览器的Web技术具有跨平台、动态更新、可扩展性强等优点。 随着移动设备性能的提高，网页的性能逐渐变得可以接受。 越来越多的嵌入式Web页面出现在客户端中，很多应用程序也会将一些功能模块改为Web实现。

缺点

因此，移动端的H5主要用在一些交互不太复杂的场景。 总体来说，即使帧率不如原生，但也基本满足要求。 从我个人的经验来看，目前H5最大的问题就是启动白屏时间。

优势

随着技术的进步以及各种优化方案的出现，启动白屏时间可以得到相当程度的优化，但响应流畅度问题依然存在，不适合重度交互场景。

5.2 与Weex

基于H5跨平台方案，经过近乎疯狂的性能优化，看起来性能确实不错。 但对于一些交互和动画复杂的场景（如左右滑动、手势），性能仍然无法满足要求。

2015年开源，被废弃，作为调用转换为调用的桥梁。 换句话说，最终会使用系统的原生渲染流程生成相应的自定义原生控件。

但世上哪有完美的计划呢？ 为了达到接近原生开发的性能和交互体验，/Weex 方案必须在跨平台和动态性上做出牺牲。

它与 Weex 向上连接前端生态系统，向下连接原生渲染。 这似乎是一个完美的解决方案。 然而前端和客户端、客户端和iOS之间的差异并不是那么容易抹平的。 强行整合会遇到各种陷阱。

既然Weex牺牲了跨平台，那么它的性能和交互是否可以直接与开发挂钩？ 真遗憾。 我认为他们目前的表现主要有两个瓶颈。

虽然性能相比 H5 方案有了很大提升，但 Weex 和 Weex 也不得不面对启动时间慢、帧率比原生低的性能问题。 是一个比较温和的解决方案，当然也会有自己的应用场景。 比如一些二级页面（比如淘宝的分店）有比较重要的业务，但是交互并不是特别复杂，希望保持一定的动态能力。

5.3 小程序

每个应用程序都有成为超级应用程序的梦想。 各大厂商都推出了自己的小程序框架：微信、创客、支付宝、今日头条、百度、淘宝、Play。 小程序的战场已成为“七国战争”。

然而，小程序并不是跨平台的开发解决方案。 大家更看重的是它的渠道优势，考虑如何通过微信、支付宝等全民App获得更多的流量和用户。

6. 跨平台开发场景 6.1 部分业务

某个业务或者页面的跨平台共享，有时候我们也希望能够实现跨应用。 例如，在“全民问答”时，可以看到该功能可以在今日头条系列的各个应用程序中运行。 对于一个公司来说共享同一个跨平台解决方案具有重要意义，业务可以在不同的应用中进行尝试。

6.2 核心功能。

C++是最可行的跨平台解决方案小程序属于平台未开发，大公司正在将越来越多的核心模块迁移到底层，例如网络库、数据报告、加解密、音频和视频等。

6.3 跨平台开发对比

H5的跨平台解决方案只要开发成本不太高，就可以开发出性能和功能都不错的应用。 然而，如果想要做到极致的优化，很容易发现开发者能够控制的东西非常少，性能和功能都依赖于浏览器的支持。

这时候如果我们想更进一步，我们不仅需要了解浏览器的内部机制，可能还需要具备定制和修改浏览器内核的能力。 这就是阿里巴巴、腾讯、今日头条、百度必须组建核心团队的原因。

相反，原生开发一开始需要较高的开发成本，但一旦开始产生产出，开发者就能取得更大的进步。

Weex 计划创建一个兼顾跨平台、开发成本和性能的综合解决方案。

七、总结

现在似乎有一种观点是“没人要开发”，大家都想转前端开发。 事实真的如此吗？ 事实上，无论我们使用哪种跨平台解决方案，它们最终都会在该平台上运行。 死机、内存、卡顿、功耗等问题仍然存在，而且可能会变得更加复杂。 而且从H5极致体验优化的例子来看，很多优化都需要深入研究平台特性和底层系统机制。 我们学到的底层的、系统相关的知识还是很重要的。

对于开发者来说，唯一不变的就是学习能力。 一旦掌握了学习能力和学习精神，你就能应对这些趋势变化。 无论未来移动开发如何变化，即使有一天AI真的可以自动编写代码，有适应能力的人也根本不会害怕。

参考链接