跨端开发：移动互联时代的挑战与解决方案

自从乔帮主发布iPhone以来，世界被推入智能手机时代，随之而来的是移动互联网潮流。移动应用开发一时风靡一时，逐渐超越传统桌面、传统前端，成为主流。接下来就是重复开发的问题了。同样的业务需要在Android上实现一次，在iOS上实现一次，通常在Mobile Web（移动H5）上实现一次。从此，跨端发展就成了移动互联网。这是这个时代必须克服的难题。

header前端开发简史

工程师的使命是让不可能成为可能，让可能变得简单，让简单变得优雅。如果同一套代码可以在不同的终端上运行那就太好了。毕竟终端的业务逻辑是一样的，只是不同的编程语言、不同的框架、不同的平台、不同的团队开发一次。如果能够“一次开发，多终端运行”，将大大节省人力、物力、财力，开发效率也会大大提高。业界一直在探索如何跨移动终端开发，即只用一套代码，开发一次，就可以运行在Android、iOS和移动Web上。

史前时代：混合应用程序

第一个出现的框架是混合应用程序（PhoneGap 和 Cordova）。 Android和iOS都对WebView有很好的支持。因此，移动前端（即网页）用于开发应用程序和大部分业务逻辑。两者都在网页上。 Android和iOS都使用WebView来显示网页。对于网页中JavaScript无法实现的东西，可以通过JavaScript Bridge来调用与平台强相关的东西，来调用平台实现的API，称为JsBridge。

这个架构非常简单。对于 Android 和 iOS，只需使用 WebView 并实现一些本机 API。其余的都是标准的移动前端。得益于平台对 HTML 5 的支持以及 jQuery Mobile 等优秀前端库的加持，Hybrid app 无论是开发体验还是使用体验都还不错。最重要的是跨平台性很强，性价比很高。对于UI部分较多且交互不复杂的面向显示的页面，这是一种非常经济有效的实现方式。

这可以称为史前时代。

黑暗时代：各种不成熟的尝试

混合App方式虽然可行，但不同终端上的体验差距很明显。对于性能较好的中高端设备，由于设备整体性能较好，Hybrid app体验尚可。虽然和原生UI相比还有差距，但也在可以接受的范围之内。但对于中低端设备来说，WebView不仅性能差，而且兼容性也很差，体验比原生UI严重差。另外，如果UI交互变得复杂，或者体验和实时操作要求比较高（比如文档编辑等），Hybrid方式就会与Native方式相差甚远。工程师们开始尝试新的解决方案。

例如，使用json格式来定义UI。定义好格式之后，每一端都会拿到一堆json数据来解析，然后生成UI。这实际上不是一个框架。事实上，它使用json来描述一个页面。解析和构建 UI 仍然由两端完成。最多是一种UI描述格式。但它很难通用，只能描述UI的静态结构，不能具有动态行为。该解决方案已被许多主要制造商采用。它非常适合本地且不复杂的 UI。业务逻辑是固定的，但页面上的UI布局风格可能随时发生变化。但用它来编写整个应用程序是不现实的。

在此期间，Google也做出了尝试，拿出了一个名为j2objc的工具，可以将Java代码翻译成Objective-C代码。转换后的Objective-C代码无需修改即可直接编译运行。显然，这个工具不适合UI，因为UI与平台强相关，需要大量平台依赖的SDK。这不仅仅是“翻译”代码。这个工具适合非UI部分的业务逻辑代码，效果非常好。转换后的代码可以直接编译运行。据说Google本身也在使用它。当时Google Inbox等GMS产品都采用了j2objc，实现了70%的代码共享。

这是大前端的黑暗时代。尽管大家都在努力，但仍然没有一个理想、完整的解决方案。

黎明的曙光：划时代的ReactNative

Hybrid 方式最大的问题是 WebView 是性能和体验的瓶颈。 WebView之所以是瓶颈，是因为它是一个完整的浏览器，它必须完全支持JavaScript、HTML和CSS。但随着HTML5和Web前端技术的发展，有很多库可能只能用JavaScript来实现。 JavaScript 是独立的，又与 Node.js 结合在一起（严格来说是 JS）。它也可以用作前端，但无需HTML和CSS的拖累。就要遵循这个思路（当时叫Facebook，现在叫Meta）推出了ReactNative，一个跨移动平台的开发框架。它基于Facebook的React框架，并针对移动端进行了扩展。其主要实现方式是使用React来编写页面。这是一个基于JavaScript语言的声明式UI框架。它添加了一个虚拟DOM层来屏蔽频繁的DOM变化，然后将虚拟DOM转换为渲染树。最后，Node打开了大门，利用Native API实现了渲染树，从而实现了原生UI。

ReactNative 可以跨三个终端实现。用React编写页面后，无需修改即可在Web、Android和iOS上运行。一经发布，就引起了巨大反响，满大街的人都拍着大腿说：“哎呀，你还可以这么玩！”

ReactNative是划时代的，因为它决定了跨端框架的基本结构：声明式UI、虚拟DOM和渲染树，使用原生API实现渲染树（映射到Native组件，或者使用原生图形API实现渲染）树） 。后续的跨端框架基本都遵循这种做法。

群星闪耀的那一刻

时光荏苒，移动互联网风潮已经过去十几年了，技术层出不穷，新的框架不断涌现。如今，跨端领域百花齐放，群星璀璨，各大框架经过几年的沉淀和发展，已经相对成熟。除了ReactNative之外，还有NativeScript、Flutter和CMP。 NativeScript实际上与ReactNative类似。唯一的区别是它允许使用 JavaScript 家族语言（例如 TypeScript 和 CoffeeScript）并且不限制开发框架。您可以使用 Vue.js 或 Angular.js 来编写 UI。

当然，业界最广泛流行和使用的还是Flutter和ReactNative。 CMP作为一颗新星，也越来越受到人们的关注。

流行框架对比

这里对最流行的ReactNative和Flutter以及Rising Star CMP进行简单的比较，以方便用户做出更好的选择。

框架开发者开发语言UI开发库支持的终端

反应原生

元

JavaScript

反应

安卓、iOS、网络

扑

谷歌

镖

安卓、iOS、桌面、网络

化学机械抛光

捷脑公司

科特林

Jetpack 组合

安卓、iOS、桌面、网络

ReactNative和Flutter都比较成熟稳定，用户较多，社区活跃。 ReactNative更适合移动端，而Flutter可以跨越更多终端和CMP。另外，Flutter和CMP等框架最大的区别在于，它使用Skia库构建渲染引擎，可以直接将渲染树渲染成平台支持的下层canvas，并直接访问图形API本机层而不是映射。作为原生组件，它的渲染效率更加高效，性能也更好。您可以将它们视为浏览器。

技术栈也不同。 ReactNative基于Node和JavaScript，属于前端技术栈，与前端结合更加紧密；而CMP基于Kotlin和JVM，与Android结合更加紧密，属于Java派；而Flutter则是自成一派。

选择是痛苦的

说实话，Flutter是目前最成熟、最完整的跨端框架，但学习成本可能会稍高一些。对于大多数学生来说，Dart 是一种小众编程语言。 ReactNative最大的问题是React过于前端化，写一堆HTML风格的标签对于客户端同学来说是相当不爽的。

应该说Flutter已经非常成功了。它已经达到了它应有的高度，实现了它的价值。换句话说，它的未来并不是特别明确。由于它已经非常成熟，有传言称谷歌内部也废除了 Flutter。研发资源。 ReactNative 也是如此。这么多年了，版本还没到1.0。

图 1. Flutter 与 CMP

CMP刚刚出现，使用起来非常方便简单。它的安装和配置是所有框架中最简单的（只需要安装一个Android Studio插件，剩下的就是编译插件和依赖，不像Flutter和ReactNative需要在开发机器上安装其他东西），前景广阔，非常值得投资。而 Flutter 对于 Google 来说只是杯水车薪。这是一件非常不起眼的事情。毕竟，谷歌的业务很大。像谷歌和Meta这样的巨头现在都对人工智能感到疯狂，而其他小企业却没有受到重视。但CMP不同。 JetBrains 本身专注于开发工具。这是他们的主业，他们一定会做好的。将CMP与其IDE深度集成，将非常方便开发者使用。事实上，JetBrains 已经开始研究它。其最新的IDE Fleet（通用IDE）将与CMP深度绑定，非常值得期待。

经过综合考虑，给出的建议是，如果是一个全新的项目，尤其是在 MVP 阶段，不要犹豫使用 Flutter。而如果是现有项目，想要跨端，就选择CMP，对现有项目最友好。除非你是资源前端和React粉丝，否则不要考虑ReactNative。

框架只能解决部分问题

最后想说的是，对于跨端开发，框架只能解决一小部分问题。

跨端开发最难的部分是合理的架构和团队协作。架构层与层之间需要做好隔离，尤其是与平台强相关的API更应该做好隔离，以最大化代码的共享。如果到处都是粗粒度的平台相关实现，复杂度就会急剧上升。它最终成为一个多方面的拼盘，而不是一个跨方面的项目。人员的协作应该以功能为单位来划分，而不是以终端维度来划分。我们要彻底消除终端思维，从UI、功能、业务逻辑的角度思考问题，从而实现更好的协作。总之，跨终端对团队的要求更高，否则只会产生更多问题。

人的问题总是比技术问题更复杂。举个最简单的例子，过去，每个终端都是独立工作的。如果Android端的同学犯了一个错误，Android端最多就无法使用，最多可能是3.25。真正跨完之后，如果再犯一个错误，所有的结局都会失败。至少可能3.25开始。这里的差别是相当大的。如果没有强大的大boss来推的话，是很难推的。移动。

研发生都喜欢努力。仅仅完成业务是枯燥的，不可能取得成果的。他们都想尽办法产出一些“技术产出”（俗称造轮子）。记得ReactNative刚出来的时候，大家都非常热情的想把它引入到各自的业务中，但最终的结果是没有人会真正专注于在自己的业务中使用它，但是他们都不厌其烦地拿出了一套他们自己的。跨端框架并推广给其他团队。年终报告时，PPT非常漂亮：“老板，你看，我们不仅完成了业务，还开发了一个跨端框架，比ReactNative更好，已经在我们的业务中使用，并推广到了其他球队。” 。相反，如果你真的使用跨终端，你怎么举报呢？ “老大，你看，我们利用了别人的跨端技术，成功实现了跨端，以前三端15个人做的事，现在只需要8个人了！”老板听后非常兴奋。 3月25日，终于找到了人选，缩减开支的计划终于敲定了！

不管怎样，总的来说，跨端开发更适合业务不复杂、UI 交互重的中小型应用，或者 UI 相对较小、非 UI 逻辑比例较大的应用（最典型的就是浏览器）。充分利用它。一个比较简单的标准是，如果每端研发人员超过10人，可能不适合跨平台开发。

参考

原创并不容易。 “打赏”、“点赞”、“观看”、“收藏”、“分享”一定有一个！