一次编写，随处部署：何时原生化？

一次编写，随处部署 (WODE)已成为过去十年中许多开发框架的承诺，其目标是减轻编写多个本机应用程序的痛苦。 由于其高昂的启动成本、对开发团队的影响以及逆转的潜在不可行性，确定采取哪条路径是项目经理必须做出的最关键的决定之一。

Ionic 等混合解决方案利用 Web 技术跨平台呈现应用程序，但最终产品通常无法满足用户对原生外观和感觉的期望。

然而，即使是“原生”一词最近也被编译为原生代码的框架（例如，React Native、Xamarin 等）混淆了。

本文分解了各种移动开发路径的优缺点，并将它们与团队构成、成本和用户体验进行权衡，以使产品经理能够做出更明智的决定。

一次编写，到处部署

一次编写，随处部署的概念是指开发团队编写一次应用程序的能力——使用单个开发堆栈、将在其上部署应用程序的平台的抽象——但仍保持部署能力应用程序适用于所有需要的平台，例如 Android、iOS、Windows 等。理想情况下，这是在不牺牲可维护性、性能或用户体验 (UX) 的情况下完成的。

移动应用程序开发的替代方法和历史方法涉及简单的为每个平台编写单独的应用程序的简单过程，当然，这会带来其自身潜在的高时间和资源成本。

一般来说，选择发展路径时要考虑的因素包括：

• 项目年龄
• 开发团队的组成和规模
• 所需的分发平台
• 上市所需的时间表
• 如果必须，可用带宽更改到另一条路径

不幸的是，将这些因素中的每一个应用于每个可用的路径，以及涉足关于该主题的无数可用意见，可能会非常令人生畏。 此外，这个过程常常让项目经理不确定哪条路径最能满足应用程序的要求。

在高层次上，不同的移动开发路径可以分为两类：native 或 WODE，即，native 或其他一切。 简而言之，一个人要么编写本机应用程序，要么不编写。 WODE 类别进一步分为两组：

• 混合框架——那些利用 Web 技术在多个平台上呈现应用程序的框架。
• 非混合框架——那些使用原生 UI 组件（例如，按钮、文本字段，甚至布局管理器）而不是像混合框架那样在应用程序内部呈现 Web 视图的框架。

大多数 WODE 框架是混合的； 然而，为了改善混合框架的性能和用户体验限制，同时仍然提供 WODE 框架的好处，目前的趋势是朝着非混合框架发展。 由于这种趋势，React Native、Xamarin 和 Appcelerator 等框架越来越受欢迎。

这些路径中的每一种——原生、混合和非混合——都有不同的优势和劣势，因此，每一种都有最适合的不同用例。 在考虑团队构成、项目成本和用户体验等竞争优先级时，本文的其余部分将分解每种移动开发路径的优缺点。 除了一些专门的用例之外，编写原生应用程序可以以略高的成本最大限度地提高用户体验。

一般来说，“一分钱一分货”的格言适用，所以如果成本比客户体验更重要，那么原生可能不是正确的选择。 然而，一旦 UX 变得至关重要，原生应用程序成为明确的选择，因为为了改进 UX，基于 WODE 的应用程序会以时间或原生专业知识的形式产生相当大的成本，这违背了选择非原生应用程序的目的首先是发展路径。

此外，即使支付了这笔费用，与原生产品相比，基于 WODE 的最终产品也将始终提供较差的用户体验。 因此，对于大多数开发团队和大多数项目来说，native 几乎总是正确的选择。

本机应用程序

本机应用程序是用给定平台的核心语言编写的。 例如，Android 应用程序是用 Java 编写的，而 iOS 应用程序是用 Obj-C 或 Swift 编写的。 它们要求开发工程师了解语言以及特定于平台的细微差别，例如第三方包集成、布局管理、操作系统 (OS) 交互等。

优点

高度可定制。 由于每个应用程序都是使用本机组件编写的，因此定制的唯一限制是与底层框架的接口，有时甚至没有。 正如大多数本地开发工程师所证明的那样，尽管界面有限，但通常有一种方法可以完成给定的任务。

通过浏览给定平台的支持社区可以找到这个想法的简单证明。 尽管存在底层框架的限制，人们会发现许多关于如何完成一项可能“超出预定范围”的任务的示例。

这种看似简单的任务的具体 iOS 示例可能是在所有外部 UI 元素（例如选项卡栏、导航栏等）之上显示全屏覆盖。如图 1所示，这通常超出了当前呈现的普通 UI 层。 因此，为了获得全屏覆盖，必须将其添加到视图堆栈中选项卡栏上方的隐藏层。 这种定制通常只能在本机应用程序上进行。

最高性能。 正如预期的那样，本机应用程序设置了性能基准。 由于大多数其他框架类型添加了一个或多个中间层，因此它们本质上比原生应用程序运行得更慢。

最可维护。 操作系统不断变化。 时期。 当他们这样做时，取决​​于是否进行了重大更改，应用程序必须及时更新，以免失去升级到较新操作系统的用户群部分。 显然，从用户可以使用更改到更新应用程序之间的时间越短越好。 当没有需要更新的依赖项来支持这个新的操作系统时，这个时间就会被最小化，在处理原生应用程序时就是这种情况。

缺点

附加资源。 在为多个平台编写应用程序时，开发团队通常由每个受支持平台的一名或多名移动软件工程师组成。 当然，这本质上会增加开发团队的规模和成本。 它还要求工程师团队具有多种技能，而不是具有同质的技能基础。 这有可能在支持和协作方面分散团队。

开发周期较慢。 原生应用程序有可能具有较慢的开发周期，因为必须为每个所需平台编写单独的应用程序。 极端情况是团队中只有一名移动开发工程师，因为每个应用程序基本上都是按顺序编写的。

性能低下。 既有优点又有缺点的表现似乎很奇怪。 一方面，本机应用程序为开发人员提供了足够的空间来创建经过微调的高性能应用程序。 然而，另一方面，它们也给了开发者足够的绳索来吊死自己。 如果他们不知道自己在做什么，最后他们最多只能得到一个低于标准的应用程序。

注意：通常，这适用于所有框架路径（本机、混合和非混合）。 如果开发应用程序的工程师对他们正在尝试的事情没有足够的技能，那么最终的应用程序可能既不能满足设计要求，也不能被用户很好地接受。

混合应用

混合应用程序通常使用 HTML/CSS/LESS 来设计用户界面：MVC 设计模式中的“V”。 然后，“C”或控制器通常是用 JavaScript 编写的——理想情况下，使用 JavaScript MVC 框架，例如 AngularJS。 与仅使用 jQuery 相比，使用 AngularJS 之类的框架可以更好地分离类和职责。

这种类型的混合框架堆栈的一个示例是由 AngularJS 支持的 Ionic 视图层，它最终使用 PhoneGap 和 Cordova 在所需平台上转换并呈现​​在 Web 视图中。 显然，这种类型的 WODE 框架是以增加复杂性为代价的。

此外，JavaScript 的使用带来了其自身基于设计的限制和基于语言的问题。 本文的目的不是讨论任何一种语言的优缺点； 然而，作为一名项目经理，在自己的移动技术堆栈中使用 JavaScript 的选择不应该掉以轻心。 以下只是一些写得很好的文章示例，说明为什么应该尽可能避免使用 JavaScript：

• JavaScript 问题
  
• 为什么我不是 React Native 开发者

优点

最小的开发团队。 混合框架使小型开发团队（尤其是主要知识库是 Web 开发的团队）能够跨多个平台快速生成简单的应用程序。 这允许项目经理保持团队规模小，并消除团队学习多个平台的本地语言和框架的需要。

更快的开发周期。 除了较小的团队之外，混合框架在部署到多个平台时提供了更快的开发周期，因为只需要使用 Web 技术设计一个视图层。

缺点

可能很差的用户体验。 只需要编写一个视图层的缺点是只剩下一个视图层。 这可能会导致糟糕的用户体验，因为千篇一律的 UI 设计方法无法使应用程序的外观和感觉在所有平台上的用户都感到舒适和熟悉。 此外，由于混合应用程序本质上是嵌入在 UI 中的 webview，它可以给用户一种他们实际上是在查看网页而不是与原生应用程序交互的印象。 这种体验几乎总是对用户满意度产生负面影响，并最终影响留存率。

定制成本高。 通过为每个平台设计定制的 UI 来改进 UX 会产生复杂而独特的 UI 框架，这些框架的创建成本可能很高，并且随着时间的推移难以维护。 此外，为了创建有助于使应用程序脱颖而出的 UI 元素（例如，动画、自定义视图等），必须创建自定义桥接组件以将高级 UI 设计转化为低级框架的东西，如科尔多瓦，会明白的。 一般来说，定制和改进混合应用程序的用户体验越多，它就越会减少快速且廉价的设计周期所带来的好处。

性能较低。 由于混合应用程序在 web 视图中呈现应用程序的视图，因此在处理 OS 框架（例如，网络、蓝牙、设备上的联系人等）时，很可能会出现实现错误，从而导致性能大大降低。 还值得注意的是，即使由于一切都通过 web 视图显示，所以在性能方面非常小心，混合应用程序的最大性能将始终略低于其原生应用程序。

非平凡的插件管理。 还记得设计团队花了数周时间打磨这些自定义功能，然后开发团队创建了必要的桥接组件，以便 Cordova 可以使用它们吗？ 好吧，除非有一个支持 Cordova 插件来支持团队正在努力实现的目标，否则它们将无法工作。 这意味着两件事之一：要么团队自己创建它，要么需要找到合适的第三方插件来完成这项工作。 不幸的是，通常情况下，选项二不存在。 因此，它需要额外的开发时间来创建自定义插件，然后随着时间的推移构建支持工作以管理应用程序所需的不断增长的 Cordova 插件库。 当然，当 Cordova 更新时，这些插件很可能也需要更新。

操作系统支持滞后。 当操作系统更改核心功能时，前面提到的级联桥组件/Cordova 插件问题会进一步加剧。 一旦 Cordova、PhoneGap 和 Ionic 更新以支持这些更改，自定义插件和桥接组件可能也需要更新。 无论这项工作需要多少数量级，它都会导致应用程序不支持已更新到新操作系统的最终用户的额外时间。 当然，这是最坏的情况，Apple 或 Google 会做出破坏性的、非向后兼容的更改，但这种情况永远不会发生……对吧？ 通常，任何不受开发人员控制且必须首先更新的中间框架只会延迟该过程。 最后，依赖中间框架对于项目经理来说可能是一个令人头疼的计划，因为这些框架的时间是未知的。

非混合应用

非混合应用程序就像它们的混合应用程序一样开始生命 - 以非本机平台语言设计的 UI 层：React Native 使用由 JavaScript 或 Xamarin 支持的 HTML/CSS，由于其 .NET 根源而基于 C#。

然而，这就是相似性结束的地方。 非混合应用程序编译为原生代码并使用平台原生组件呈现应用程序，而不是通过 webview 呈现。 这导致了一个 WODE 框架，至少在表面上，它具有两全其美的优点。

如前所述，选择使用 JavaScript 不应该是一个轻率的决定，对于不想学习或对使用 JavaScript 没有兴趣的开发团队来说，这可能会破坏交易。

优点

比混合动力车性能更高。 正如人们所预料的那样，非混合应用程序本质上比混合应用程序具有更高的性能，因为它们能够使用本机 UI 组件（按钮、视图、布局管理器等）而不是依赖于嵌入式 Web 视图来呈现应用程序。 当然，开发人员仍然可以自由地编写性能出色或糟糕的应用程序。 与类似的混合应用程序相比，非混合应用程序的好处很简单，它们具有更高的性能基准。

最小的开发团队。 与混合框架类似，非混合框架使小型开发团队（尤其是主要知识库是 Web 开发的团队）能够跨多个平台快速生成简单的应用程序。 这允许项目经理保持他们的团队规模小，并阻止团队学习用于多个平台的本地语言和框架。

更快的开发周期。 除了较小的团队之外，非混合框架在部署到多个平台时提供了更快的开发周期，因为只需要设计一个视图层。

更快的迭代（反应） 。 React 框架提供了一个强大的功能，允许实时呈现对应用程序的更改：无需重新编译、重建等。因此，React 模拟器是一个非常强大的开发工具，可以显着减少每个实现的持续时间循环。

缺点

定制成本高。 就像它的混合应用程序一样，当非混合应用程序需要通过为每个平台设计自定义 UI 来改进 UX 时，它会导致创建复杂且独特的 UI 组件，这些组件的创建成本可能很高，并且随着时间的推移难以维护。 这也意味着编写定制的桥接组件来补充框架原生元素支持方面的差距。 与混合一样，这种成本降低了快速和廉价设计周期的好处，但与混合应用不同的是，桥组件是为每个所需平台以它们的母语编写的。 这意味着非混合应用程序不是主要由 Web 开发人员组成的团队的灵活替代方案，选择非混合路径的团队不仅必须学习框架的特定语言（例如 JSX 或 C#），而且也是每个平台的本地语言（Java、Obj-C 或 Swift）。

第三方依赖。 这种限制有两种不同的形式。 在 React Native 的情况下，它采用大量依赖项的形式，即大约 650 个。结果是，在任何特定时间，这些依赖项中的一个或多个已经过时的可能性很大。 这也意味着在操作系统级别发生较大更改的情况下，很可能需要更新大部分或所有这些依赖项。 潜在的可取之处在于 Facebook 使用 React，因此他们的角落里会有 300 磅的大猩猩。

在 Xamarin 的情况下，第三方依赖问题很简单，一开始就很难集成它们。 Xamarin 意识到了这个问题，并提供了一个名为 Sharpie 的实用工具。 该工具的目的是帮助进行一些集成，但不幸的是，Sharpie 经常尝试编译和链接不正确的资源，这迫使开发人员不得不承担手动修改低级编译参数的费时费力的任务才能成功完成整合。

操作系统支持滞后。 非混合应用程序受到与混合应用程序相同的问题的困扰。 任何不受开发人员控制且必须首先更新的中间框架只会延迟更新应用程序以支持尖端用户的过程。 此外，如前所述，依赖中间框架对于项目经理来说可能是一个令人头疼的计划，因为这些框架的时间安排是未知的。

长期支持（React Native） 。 这个问题是 React Native 特有的，并且与一个奇怪的事实有关，即迄今为止，Facebook 还没有承诺对其框架的长期支持计划。 可以说这是一个低风险，因为该公司为其移动应用程序使用自己的框架，但任何项目经理都值得停下来考虑一下为什么 Facebook 拒绝对此发表评论。

选择正确的方法

当成本不是主要考虑因素时，图 2表明，在根据应用程序的需求利用开发团队的构成时，编写本机应用程序几乎总是最佳选择。 当开发工程师的数量少于所需平台的数量时，它会变得更有趣。 在这种情况下，如果团队的发布计划非常紧张，那么使用 React 是正确的选择； 否则，去本地化仍然是最好的选择。

当团队主要是 Web 开发团队，并且需要定制的 UX 时，最好让一些团队成员更换帽子或添加一些团队成员，以使自己的应用程序原生化。 如果应用程序需要自定义元素（许多应用程序都需要），那么确实没有可行的、可维护的框架选项。

但是，如果不需要自定义 UX，那么根据发布时间表，使用 Ionic 或 React 可能会更好。 如果一个团队没有时间学习 JSX，那么 Ionic 是正确的选择。 否则，最好选择 React，因为它已经需要许多第三方依赖项，并且添加更多不会影响一个人的开发周期。

一旦项目成本成为主要关注点，通常情况下，现有团队的构成就不再那么重要了，因为第一步是安排合适的团队来执行项目计划以应对预计成本。 如图 3所示，与 WODE 对应的原生应用程序相比，原生应用程序的启动成本更高，但潜在的用户体验也更高。 此外，无论项目投入了多少资金和资源，WODE 应用程序的用户体验都会受到限制。

我希望本文能够阐明各种移动开发路径的优缺点，并有助于权衡团队构成与应用程序需求和项目成本。 它的信息不是要传达 WODE 框架低劣且不应该被寻求，而是即使有有效的用例不使用原生，人们也应该充分理解这样做的后果。