编写一次，到处部署（什么时候本地化（）） _部署

本文概述

本机应用
混合应用
选择正确的方法

在过去十年中, 一次编写, 无处不在部署(WODE)是许多开发框架的承诺, 其目标是减轻编写多个本机应用程序的痛苦。由于其高昂的启动成本, 对开发团队的影响以及潜在的不可行逆转性, 确定走哪条路是项目经理必须做出的最关键的决定之一。
诸如Ionic之类的混合解决方案利用Web技术来跨平台呈现应用程序, 但是最终产品常常达不到用户对本机外观的期望。
但是, 即使是” 本机” 一词, 最近也被编译成本机代码的框架(例如React Native, Xamarin等)弄混了。
本文介绍了各种移动开发路径的优缺点, 并权衡了它们与团队构成, 成本和用户体验之间的关系, 以期使产品经理能够做出更明智的决定。
编写一次, 随处部署
一次编写, 到处部署的概念是指开发团队具有使用单个开发堆栈, 将要部署应用程序的平台的摘要来编写应用程序一次并保持部署能力的能力。理想情况下, 在不牺牲可维护性, 性能或用户体验(UX)的情况下完成此应用程序。
移动应用程序开发的替代方法和历史性方法涉及直接为每个平台编写一个单独的应用程序的简单过程, 这当然会带来自身潜在的高昂时间和资源成本。
通常, 选择开发路径时要考虑的因素包括：

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

不幸的是, 将这些因素中的每一个应用于每条可用的路径, 以及涉猎关于该主题的众多可用意见, 可能会相当艰巨。此外, 此过程通常使项目经理不确定哪种路径最能满足应用程序的需求。
在较高的级别上, 可以将不同的移动开发路径分为两类：本机或WODE, 即本机或其他所有东西。简而言之, 要么编写本地应用程序, 要么不编写本地应用程序。 WODE类别进一步分为两类：

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

大多数WODE框架是混合的。但是, 为了同时提高混合框架的性能和UX限制, 同时仍提供WODE框架的优点, 当前的趋势是非混合。由于这种趋势, 诸如React Native, Xamarin和Appcelerator之类的框架越来越受欢迎。
这些路径(本机路径, 混合路径和非混合路径)都有不同的优点和缺点, 因此, 每种方法都有最适合的不同用例。当考虑竞争的优先级(例如团队组成, 项目成本和UX)时, 本文的其余部分将分解每种移动开发路径的利弊。除了一些特殊的用例外, 编写本机应用程序可以以稍高的成本最大化用户体验。
一般而言, “ 你得到所付的钱” 这句话是适用的, 因此, 如果成本比客户的体验更重要, 那么本地人可能不是正确的选择。但是, 一旦UX变得至关重要, 本机应用程序便成为了明智的选择, 因为为了改进UX, 基于WODE的应用程序会花费大量时间或本机专业知识, 这使选择非本机的目的失败了。发展之路放在首位。
此外, 即使付出了这笔费用, 基于WODE的最终产品与其本地同类产品相比也将始终提供劣质的UX。因此, 对于大多数开发团队和大多数项目而言, native几乎总是正确的选择。
本机应用本机应用程序以给定平台的核心语言编写。例如, Android应用程序是用Java编写的, 而iOS应用程序是用Obj-C或Swift编写的。他们要求开发工程师理解语言以及特定于平台的细微差别, 例如, 包括第三方程序包集成, 布局管理, 操作系统(OS)交互等。
优点
高度可定制的。由于每个应用程序都是使用本机组件编写的, 因此对自定义的唯一限制是与基础框架的接口, 有时甚至还没有。正如大多数本机开发工程师所证明的那样, 尽管界面有限, 但通常还是有一种方法可以完成给定的任务。
通过浏览给定平台的支持社区, 可以找到此想法的简单证明。尽管基础框架有局限性, 但人们将找到许多示例, 说明如何完成可能” 毫无保留” 的任务。
这种看似简单的任务的一个具体的iOS示例可能是在所有外部UI元素(例如, 选项卡栏, 导航栏等)上方显示全屏覆盖图。如图1所示, 这通常不属于该功能的范围。当前呈现的普通UI层。因此, 为了具有全屏覆盖, 必须将其添加到视图堆栈中选项卡栏上方的隐藏层。这种定制通常仅在本机应用程序上可行。

文章图片
图1：iOS TabBar分层示例。
最高的性能。正如预期的那样, 本机应用程序为性能设定了基准。由于大多数其他框架类型都添加了一个或多个中间层, 因此它们固有地比本地应用程序运行得慢。
最易于维护。操作系统不断变化。期。当他们这样做时, 取决??于是否进行了重大更改, 必须及时更新应用程序, 以免失去一部分用户群, 而这些用户群已升级到较新的操作系统。显然, 从更改可供用户使用到更新应用程序之间的时间越短, 效果越好。当没有依赖关系需要更新以支持此新OS时, 这种时间可以最小化, 在本机应用程序上工作时就是这种情况。
缺点
其他资源。在为多个平台编写应用程序时, 开发团队通常会为每个受支持的平台由一个或多个移动软件工程师组成。当然, 这必然会增加开发团队的规模和成本。这也要求工程师团队具有多种技能, 而不是具有统一的技能基础。这有可能使团队在支持和协作方面分散。
较慢的开发周期。仅仅因为必须为每个所需的平台编写一个单独的应用程序, 本机应用程序才可能具有较慢的开发周期。极端的情况是团队中只有一名移动开发工程师, 因为每个应用程序本质上都是串联编写的。
性能低下。既有优点又有缺点的表现似乎很奇怪。一方面, 本机应用程序为开发人员提供了足够的空间来创建经过微调的高性能应用程序。但是, 另一方面, 它们也会给显影剂足够的绳索以使其自身悬挂。如果他们不知道自己在做什么, 那么最终, 他们最终只能得到一个低于标准的应用程序。
注意：通常, 这适用于所有框架路径(本机, 混合和非混合)。如果开发应用程序的工程师没有足够的技能来进行尝试, 那么最终的应用程序很可能既不符合设计要求, 也不为用户所接受。
混合应用混合应用程序通常使用HTML / CSS / LESS编写, 以设计用户界面：MVC设计模式中的” V” 。然后, 通常以JavaScript编写” C” 或控制器-理想情况下, 使用AngularJS之类的JavaScript MVC框架编写。与仅使用jQuery通常相比, 使用AngularJS之类的框架可以更好地分离类和职责。
这种类型的混合框架堆栈的一个示例是由AngularJS支持的Ionic视图层, 最终使用PhoneGap和Cordova将其转换并呈现??在所需平台上的Web视图中。显然, 这种类型的WODE框架是以增加复杂性为代价的。
此外, JavaScript的使用带来了它自己的基于设计的局限性和基于语言的问题。本文的目的不是辩论任何一种语言的优缺点。但是, 作为项目经理, 在移动技术堆栈中使用JavaScript的选择不应轻易做出。以下是一些写得很好的文章的示例, 这些文章说明了尽可能避免使用JavaScript的原因：

JavaScript问题
为什么我不是React Native开发人员

优点
最小的开发团队。混合框架使一个小的开发团队, 尤其是其主要知识库为Web开发的团队, 可以跨多个平台快速生成简单的应用程序。这样一来, 项目经理可以使团队保持精简, 并且不需要团队学习多种平台的本地语言和框架。
更快的开发周期。除了规模较小的团队外, 混合框架在部署到多个平台时还提供了更快的开发周期, 因为仅需要使用Web技术设计单个视图层。
缺点
潜在的不良UX。只需编写一个视图层的缺点就是只剩下一个视图层。由于统一设计的UI设计方法无法使应用程序在所有平台上的用户都感到舒适和熟悉, 因此这可能会导致UX效果不佳。另外, 由于混合应用程序本质上是嵌入在UI中的Web视图, 因此它可以给用户以印象, 即他们实际上正在查看网页, 而不是与本机应用程序进行交互。这种体验几乎总是对用户满意度和最终保留率产生负面影响。
定制成本高。通过为每个平台设计定制的UI来改善UX会导致复杂而独特的UI框架, 这些框架的创建成本高昂, 并且难以长期维护。此外, 为了创建有助于使应用程序脱颖而出的UI元素(例如, 动画, 自定义视图等), 必须创建自定义的桥组件, 以将高级UI设计转换为较低级框架的东西。 , 例如Cordova, 将会理解。通常, 定制和改进混合应用程序的用户体验越多, 则越减少了快速便宜的设计周期的好处。
较低的性能。由于混合应用程序会在Web视图中呈现应用程序的视图, 因此在处理OS框架(例如, 网络, 蓝牙, 设备上的联系人等)时, 很可能会出现实现错误, 从而导致性能大幅下降。还要注意的是, 即使由于在网络视图上显示了所有内容, 所以即使在性能方面都非常注意, 混合应用程序的最大性能始终会比其本机同类应用程序稍差。
非凡的插件管理。还记得设计团队花了几周的时间对这些自定义功能进行抛光, 然后又花了几周的时间, 而开发团队又创建了必要的桥接组件, 以便Cordova可以使用它们？好吧, 除非团队支持要实现的Cordova插件, 否则它们将无法工作。这意味着两件事之一：要么团队自行创建它, 要么需要找到合适的第三方插件来完成任务。不幸的是, 第二种选择通常不存在。结果, 需要更多的开发时间来创建自定义插件, 随后需要花费一定的构建时间来管理应用程序所需的日益增长的Cordova插件库。当然, 在进行Cordova更新时, 很有可能也需要更新这些插件。
操作系统支持滞后。当操作系统更改核心功能时, 前面提到的级联桥组件/ Cordova插件问题会进一步恶化。一旦更新了Cordova, PhoneGap和Ionic以支持所做的更改, 则有可能也需要更新自定义插件和网桥组件。无论这项工作需要多大的数量级, 都将导致应用程序不支持更新了新操作系统的最终用户的额外时间。当然, 这是最坏的情况, 其中Apple或Google做出了重大的, 非向后兼容的更改, 但从未发生过……对吗？通常, 任何不受开发人员控制并且必须首先进行更新的中间框架只会延迟该过程。最后, 由于这些框架的时间安排未知, 因此依赖中间框架可能使项目经理难以计划。
非混合应用
非混合应用程序像混合应用程序一样开始工作-一种以非本机平台语言设计的UI层：React Native使用由JavaScript或Xamarin支持的HTML / CSS, 由于其.NET根基, 它基于C＃。
但是, 相似之处到此结束。非混合应用程序会编译为本地代码, 并使用平台本地组件而不是通过Webview进行呈现。这样就产生了一个WODE框架, 至少在表面上, 它具有两全其美的优势。
如前所述, 选择使用JavaScript并不是一个轻易做出的决定, 对于不希望学习JavaScript或对使用JavaScript不感兴趣的开发团队来说, 这可能是一个大难题。
优点
比混合动力更高的性能。就像人们可能期望的那样, 非混合功能固有地具有比混合应用程序更高的性能, 这是因为非混合功能可以使用本机UI组件(按钮, 视图, 布局管理器等)呈现应用程序, 而不必依赖于嵌入式Web视图。当然, 开发人员仍然可以自由编写性能非常出色的应用程序。非混合应用程序的好处是, 与类似的混合应用程序相比, 它们具有更高的性能基准。
最小的开发团队。与混合框架相似, 非混合使小型开发团队(尤其是其主要知识库是Web开发的团队)能够跨多个平台快速生成简单的应用程序。这使项目经理可以保持团队规模小, 并避免团队学习多种平台的本地语言和框架。
更快的开发周期。除了较小的团队之外, 非混合框架在部署到多个平台时还提供了更快的开发周期, 因为只需要设计一个视图层即可。
更快的迭代(反应)。 React框架提供了强大的功能, 可以实时呈现对应用程序所做的更改：无需重新编译, 重建等。因此, React模拟器是功能强大的开发工具, 可显着减少每次实现的时间周期。
缺点
定制成本高。与其混合对象非常相似, 当非混合应用程序需要通过为每个平台设计定制的UI来改进UX时, 会导致复杂而独特的UI组件, 这些组件的创建成本高昂, 并且难以长期维护。这还意味着编写自定义的桥组件以弥补框架本机元素支持中的空白。像混合动力车一样, 这种成本降低了快速且廉价的设计周期的好处, 但是与混合动力车应用程序不同的是, 桥组件以其本地语言为每个所需平台编写。这意味着, 非混合应用程序不是主要由Web开发人员组成的团队的灵活选择, 而是选择非混合路径的团队不仅必须学习框架的特定语言(例如JSX或C＃), 而且还必须学习也是每个平台(Java, Obj-C或Swift)的本地语言。
第三方依赖项。此限制采用两种不同的形式。对于React Native, 它采用多种依赖关系的形式, 即大约650个。结果是, 在任何特定时间, 这些依赖关系中的一个或多个已经过时的可能性很大。这也意味着, 如果发生较大的OS级更改, 则很有可能需要更新大多数或所有这些依赖项。潜在的节省之处是Facebook使用React, 因此一角将有300磅的大猩猩。
就Xamarin而言, 第三方依赖问题仅仅是因为首先将它们集成起来非常困难。 Xamarin知道此问题, 并提供了一个名为Sharpie的实用工具。该工具的目的是帮助某些集成, 但是不幸的是, Sharpie经常尝试编译和链接不正确的资源, 这迫使开发人员承担着繁琐的手动修改低级编译参数以成功完成的费时任务。整合。
操作系统支持滞后。非混合应用程序遇到与混合应用程序相同的问题。任何不受开发人员控制且必须首先进行更新的中间框架, 都只会延迟更新应用程序以支持尖端用户的过程。此外, 如前所述, 由于中间框架的时间安排未知, 因此依赖中间框架可能使项目经理难以计划。
长期支持(React Native)。这个问题是特定于React Native的, 并且与一个奇怪的事实有关, 即到目前为止, Facebook尚未致力于对其框架的长期支持计划。可以说, 这是一个低风险, 因为该公司在移动应用程序中使用了自己的框架, 但是对于任何项目经理来说, 考虑为什么Facebook拒绝对此主题发表评论, 都值得暂停一下。
选择正确的方法当成本不是主要考虑因素时, 图2显示, 在利用开发团队的组成和应用程序需求的情况下, 编写本机应用程序几乎总是最佳选择。当开发工程师的数量少于所需平台的数量时, 它会变得更加有趣。在这种情况下, 如果团队的发布时间表很紧, 那么使用React是正确的选择。否则, 本地化仍然是最好的选择。

文章图片
图2：选择移动开发路径时团队构成与应用程序需求的比较。
当团队主要是网络开发团队, 并且需要自定义UX时, 最好让一些团队成员改头换面或添加一些团队成员, 以使应用程序变得原生。如果应用程序需要自定义元素(许多应用程序确实需要这样做), 那么实际上并没有一个可行的, 可维护的框架选项。
但是, 如果不需要自定义UX, 则根据发布时间表, 最好使用Ionic或React。如果一个团队没有时间学习JSX, 那么Ionic是正确的选择。否则, 最好选择React, 因为它已经需要很多第三方依赖, 并且添加更多不会影响开发周期。

文章图片
图3：选择移动开发路径时的成本与用户体验。
通常, 一旦将项目成本作为首要考虑因素, 则现有团队组成就不再那么重要了, 因为第一步是将适当的团队放在适当的位置, 以按照预计的成本执行项目计划。如图3所示, 本机应用程序的启动成本比WODE同类应用程序高, 但潜在的用户体验也更高。而且, 无论将多少金钱和资源应用于该项目, WODE应用程序始终将受限于其UX。
【编写一次，到处部署（什么时候本地化（））】我希望本文能够阐明各种移动开发路径的利弊, 并有助于根据应用程序需求和项目成本来权衡团队构成。它的信息并不是要传达WODE框架的劣势, 也不应该寻求它, 而是即使存在有效的用例而不是原生的用法, 人们也应该充分理解这样做的后果。