跨平台移动

随着众多移动平台的兴起，每个平台都有不同的 UI，许多人都在关注跨平台工具包。这些工具包允许您编写一次移动应用程序，然后将其部署到各种移动设备。这些工具包值得使用吗？

跨平台工具包很有吸引力。市场上有许多移动设备，为每个设备编写应用程序需要大量工作。如果我们能够编写一次，随处运行，那就容易多了。

当然，我们以前也遇到过这种情况，比如桌面应用程序。多年来，人们尝试过很多方法来创建用于桌面的跨平台环境。Java 可能是最著名的，但它既不是最好的，也不是第一个（问问 Smalltalk 用户关于 VisualWorks 的情况）。但您可能会注意到，跨平台应用程序总体上并不成功。 [1][2]

第一个问题是处理不同平台上 UI 控件之间的差异。您有两种主要策略：您可以使用每个平台上的原生组件，也可以使用更原始的图形来模拟组件，实际上是创建您自己的 UI 系统。在 Java 世界中，这就是 Swing（模拟）和 SWT（原生控件）之间的区别。

两种方法都有问题。如果您使用原生控件，您必须处理不同平台上类似控件在工作方式上的细微差异，这使得很难找到一个好的抽象。此外，您必须决定如何处理仅在某些平台上可用的功能 - 您是否最终会得到平台的最低公分母？

因此，模拟变得很有吸引力，无论是作为一种完整的方法，还是弥补某些平台上无法获得的控件。模拟有一些困难：首先，很难让模拟的 UI 响应速度足够快 - 对于 UI 控件来说，这是一个大问题。其次，很难让它们完全像原生控件一样运行。很容易陷入 恐怖谷，在那里，事物在很大程度上像原生控件一样工作，但有一些细微的差异，足以让用户感到困惑。对于 UI 控件，您必须非常细致地才能让行为“恰到好处”。

获得好的 UI 控件几乎是不可能的，但这并不是最大的问题 - 更重要的是整体用户体验。不同的平台有不同的使用方式，这会改变整个体验设计。如果您使用的是基于 Unix 的系统，良好的体验设计将充分利用鼠标中键，因为这是 Unix UI 的方式。但在 Mac 上尝试这样做会很困难，因为 Mac 认为即使是两个按钮也太多。

移动设备在这方面负担更大，因为它们在整体用户交互方式上存在更大的差异。最近，一位客户要求我们为他们开发的 iPhone 应用程序制作一个 Android 版本。我们最初的实验表明，我们必须从头开始重新思考体验设计，才能获得一个像样的 Android 应用程序。iPhone 应用程序的测试用例为 Android 应用程序的功能提供了一个非常有价值的清单，但整个应用程序的感觉必须有所不同。

因此，出于这些原因，我认为跨平台移动工具包是一个死胡同。它们很难真正模拟原生体验。如果值得构建一个原生应用程序，那么就值得将其构建得当，包括针对该平台的个性化体验设计。 [3]

那么，对于那些想要支持大量移动平台，但又不想为每个平台都处理原生应用程序成本的人来说，该怎么办呢？幸运的是，我们确实有一个可以在任何有价值的移动设备上运行的单一平台 - 网络。如今，由精通技术的人编写的 Web 应用程序可以非常实用且功能强大。这里最大的问题是离线使用。如果您能够始终在线，那么这将不是问题，但如果您需要离线，则需要探索 各种本地存储选项。

当您进行 Web 应用程序开发时，不要试图让它看起来和感觉像一个原生应用程序 - 让它看起来像一个移动 Web 应用程序。它仍然像模拟应用程序一样可用，但会避免让用户陷入恐怖谷。这反映了桌面领域发生的事情，那些想要支持多个桌面平台的人发现网络是一个有效的部署平台。它在这里取得成功的关键是，人们期望 Web 应用程序像 Web 应用程序一样运行，因此他们不期望它们像原生应用程序一样 - 避免了不同平台上不同用户期望带来的问题。

总结

• 不要使用跨平台工具包
• 为了最大程度地覆盖用户：构建一个看起来像 Web 应用程序的 Web 应用程序
• 为了吸引特定平台的用户：为该平台构建一个原生应用程序，并根据该平台的交互风格进行体验设计

后续

来自电子邮件和其他评论的一些想法和反应

一位通信员谈到他的公司如何创建原生应用程序，这些应用程序是围绕 Web 应用程序的薄包装器。这提供了启动和访问常用链接的便利，同时将大部分行为保留在跨平台 Web 中。

Gunnar Peterson 认为 安全模型的差异 也阻碍了跨平台工具包的发展。