如果你正在构建移动产品，你可能正在考虑 React Native、Flutter 或某种 HTML 版本。也许你甚至正在考虑完全原生应用。如果是这样，你应该了解 Compose Multiplatform。Compose 提供全平台效率，可以满足你的原生需求，同时降低风险。
现代移动开发
现代智能手机时代始于 2007 年的 iOS，紧接着在 2008 年推出了 Android。在前几年，如果你关心你应用的质量，你会构建原生应用。没有人对构建同一个应用两次感到兴奋，但跨平台风险太大。
使用原生应用开发是明智的选择。
今天，大多数新应用都是使用类似 React Native 或 Flutter 等技术构建的。不过，当应用本身是产品时并非如此，但当移动性对您的业务需求至关重要时，情况就不同了。虽然各种跨平台工具都有其妥协之处，但最终结果通常足够好。
Compose 多平台是一个相对较新的选择，它提供了提高质量和降低移动产品开发风险的显著优势。它可能现在还没有出现在你的雷达上，但很快就会。以下是原因。
什么是 Compose Multiplatform
Compose Multiplatform 技术让您能够利用跨平台技术的优势，同时避免了其关键风险，并允许您将这些应用打造得尽可能原生。
您能构建跨平台应用吗？是的。您能构建原生应用吗？是的。您还可以拥有两者之间的东西。这是一种根本不同的技术。
跨平台效率
使用 Compose 和 KMP，您可以使用单一代码库构建 Android 和 iOS 应用。换句话说，它是一个跨平台应用。
跨平台工具的质量和成熟度对效率有重大影响。React Native 和 Flutter 是成熟的工具。Compose Multiplatform 相对较新。然而，Compose 本身并不新。它是 Android 的主要 UI 技术。Compose 本身及其背后的工具都是由谷歌的 Android 团队构建的。他们投入了多年的大量资源，以确保 Compose 成为移动开发的绝佳平台。
没有使用任何外国、第三方平台，这与所有其他跨平台选项不同。这是一个关键点需要理解。
Compose 作为 Android 原生的一部分，意味着 Android 开发者无需完全重新学习如何构建应用程序。这对现有团队和寻找有能力的开发者来说是一个优势。
如同原生应用的体验
如果您能构建一个无需原生开发复杂性的原生应用，您就会这么做。每个人都更喜欢一个好的原生应用。我。您的用户。您。我们都是移动用户，一个好的原生应用只是更好的体验。
原生开发，然而，有许多复杂性。成本、团队隔离、功能一致性偏差等。对于大多数应用来说，跨平台和原生之间的质量差异微乎其微，但开发差异却很大。
对于大多数应用来说，原生开发的成本并不值得。
Compose 多平台提供了一种新的选择。它可以像您需要的那么原生。
首先，Compose 和 Kotlin 是 Android 的主要框架。使用 Compose 和 KMP 构建的应用在 Android 上是原生的。它没有任何跨平台的特点。
在 iOS 上，Compose UI 表现良好，但本身并不具有那种“原生外观”。与其他跨平台选项一样，您可以使用主题在 iOS 上近似原生体验。
但是 Compose Multiplatform 有所不同。它可以做到其他选项做不到的事情。
如前所述，Compose 和 KMP 直接与原生平台协同工作。这意味着您可以使用 Compose 将完全原生的 iOS UI 与之融合，同时使用相同的支持代码。
这意味着，你可以拥有一个跨平台的 iOS 应用、一个完全本地的 iOS 应用，或者介于两者之间的混合 UI。
产品所有者和用户的反馈表明，您应该在 iOS 上构建原生应用。您需要重写应用吗？绝对不需要！
在大多数应用中，用户几乎将所有时间都花在几个核心屏幕上。应用中不太常见的区域可能很少或从未被大多数用户使用。设置、信息对话框、次要功能等。您只需用原生实现重新设计 iOS 上的主要屏幕，而无需替换其下方的支持代码。
如果分析表明您的用户在核心屏幕上花费了大约 90%的时间，考虑到您的 Android 用户已经拥有一个完全本地的应用，这意味着您的综合用户体验几乎完全是本地的。几乎拥有一个单一代码库。
并且，您可以逐步进行。
低风险
跨平台框架始终存在一个关键风险：
- 您需要在开始之前决定如何构建您的应用，是跨平台还是原生
- 你不知道你是否做出了“正确”的决定，直到“结束”（即使那时，你也不一定真的知道）
“结束”可能出现在开发周期的后期，或者更糟糕的是，收到用户的不良反馈。
“这是正确的决定吗？”
无论您的应用是跨平台还是原生，这可能会是一个困扰您的问题。
如果你的应用是跨平台的，你可能想知道如果使用原生开发，接收度是否会更好。跨平台应用的结果永远不是完美的。它真的在整体上更好吗？
对于跨平台，我们称之为风险悬崖。你在山脚下做出了决定。你已经一路攀登到了山顶。在这个时候，如果你所在的地方不是你想要的地方，你将没有太多好的选择。前方只有一条大悬崖
为什么是悬崖？因为一个本应原生开发的跨平台应用的修复需要重写，两个应用都要重写。这个决定通常是在花费时间尝试调整跨平台构建以使其足够好之后做出的。额外的成本。
风险悬崖曾是几年前的一个真正问题。跨平台应用真的并不出色。跨平台工具的质量已经大幅提高。仍然存在同样的悬崖，但你不太可能需要处理它。
Compose 多平台没有那个悬崖。
此外，跨平台开发并不完美高效。它并不是“一价两得”。您不会得到两个原生应用的质量，而且构建跨平台应用肯定比原生构建任何一个应用都要费劲。
跨平台效率的神话
跨平台从未是，现在也不是“一价两用”的应用。
两个应用
这个问题应该是显而易见的。你不会得到两个原生应用。你得到的是两个足够好的应用。如果这两个应用确实足够好，这其实并不是一个问题。然而，跨平台支持者经常暗示基本的 2 比 1 等式。实际现实与这一点相去甚远。
一个价格
非平凡应用总是需要更高效的功能和集成，当它们以原生方式构建时。跨平台工具试图使 Android 和 iOS 的具体细节一致化，但它们只能做到如此。最终，一个应用是在真实设备上运行的。
一些原生平台集成确实有所不同。不仅限于 API，还包括它们实现时的流程和限制。没有任何跨平台工具（即使是 KMP）可以完全避免这一点。这个因素总会使“1”变成大于“1”的东西。特定的跨平台工具以及它们与原生平台直接交互的程度，会影响“1”变得多大多。因为 Compose 和 KMP 都是为了直接与原生平台交互而设计的，所以它们可以最小化这种影响。
用户界面是另一个问题。出于性能考虑，一些复杂的用户界面在跨平台实现上可能会遇到困难。这因框架而异。然而，一些用户界面组件有可用的本地实现。尝试用跨平台用户界面重写它们根本不是一种选择。
例如，地图。这些是复杂且性能关键组件，具有本地实现。显然，从头开始编写跨平台的地图用户界面是一个糟糕的想法。您需要将本地地图实现集成到跨平台工具中。
所有现代跨平台工具都提供了一些机制来集成原生 UI。然而，这些机制的开销和难度在跨平台工具之间差异很大。再次强调，由于 Compose 和 KMP 都是为了直接与原生平台集成而设计的，因此没有其他跨平台工具可能在这一点上做得更好。这既从开发者的努力角度，也从集成的运行时性能角度来看。
其他跨平台框架不仅隐藏了本地平台，它们在技术层面上仍然与之分离。从技术角度来说，调用本地平台是一种 RPC（远程过程调用）。尽管调用目标在意义上并不是“远程”，因为它们生活在同一个进程沙盒中，但调用需要在不兼容的运行时之间进行。数据需要序列化，并且通常通过消息传递进行调用。
在更通俗的术语中，大多数跨平台框架与其他框架的兼容性不佳。它们自成体系。在那个体系之外进行通信是一个严格的过程，涉及额外的开销。
Compose 和 KMP 直接在原生应用运行时操作。在 Android 的情况下，Compose 和 Kotlin 是您用于构建完全原生应用的工具。对于 iOS，Kotlin 被呈现给 Swift，就像它是更多的 Objective-C 或 Swift（顺便说一句，请使用 SKIE）。原生调用不是 RPC 调用。
使用 Compose 多平台
跨平台应用不是“2”个原生应用，其构建成本也超过“1”。使用 Compose，Android 应用实际上是原生的。在 iOS 上，您希望应用有多原生是灵活的。您可以投入更多努力，更接近原生，也可以不那么做。由于 KMP 和 Compose 与原生运行时的集成方式，虽然您不能达到“1”，但可以尽可能接近“1”。
如果你开发了两个原生应用，这些额外的工作真的值得吗？现在你有了两个不同的应用，需要两种不同类型的开发者。随着应用的发展，应用需要保持同步。
Compose 多平台并不完全消除这个问题。它只是减轻了这个问题的重要性。你可以用跨平台 UI 来构建应用。如果你认为它应该有一些原生 UI，你可以在需要的地方精确地替换它。
该交换可以在任何时间点发生。在开发过程中，团队可以集成原生组件。如果最终产品感觉不太对劲，您可以使用原生 iOS UI 重新设计其关键部分。
Compose 多平台的优势并不仅仅是这项技术在制作跨平台应用方面本质上优于所有其他选项。真正的区别在于，您不必被迫做出风险较高的前期决策。
