HTML5，本机和混合移动应用程序方法的优缺点是什么？

我想开发一个移动应用程序。我最近在Telerik论坛上阅读了一篇文章，该文章比较了三种类型的移动应用程序，但我不知道应该选择哪种类型。这是一张描述不同移动设计选择的利弊的图像

为了在这些设计选择之间做出决定，我想更好地理解图中列出的每种体系结构选择的利弊。每种架构方法的优缺点是什么？

我是一位移动开发人员，他花了很多时间考虑此问题。

你为什么要问？

您最有可能希望通过以下方式降低应用开发成本：

• 使用现有的HTML5 / JavaScript开发技能
• 定位多个平台而无需从头开始编写多个应用
• 将来不必维护多个代码库

原因可能还包括：

• HTML5 / Javascript开发比本机平台开发“更容易”
• 避免支付开发人员计划注册费
• 避免应用商店内容限制（赌博等）
• 避免购买开发硬件（例如用于iPhone开发的Mac）

定义

让我们确切地确定所提到的三种方法的含义：

本机（Native）
一种通常安装在设备商店中的设备上的应用程序（尽管有时可以侧加载）。为了便于讨论，本机应用程序的UI通常不仅由全屏Web视图组成。

移动Web
实际上实际上可以是任何网页，但是在此讨论中，我们考虑一个单页面的Web应用程序，该应用程序试图模仿本机应用程序的外观。它不是本机应用程序，而是在设备的浏览器中运行。

混合
混合应用程序instanceof本机应用程序。

大多数人可能将混合应用程序理解为单页移动Web应用程序（再次很可能模仿本地应用程序的外观和感觉），但打包为可访问本地服务的本地应用程序（如Phonegap）。

但是，事实上，在Phonegap模型和完全本机之间存在一个频谱，我将在后面介绍。

行动网路

技术限制
让我们首先列出移动Web应用程序的一些技术限制，这些限制本身可能会破坏交易，具体取决于您在做什么：

• 仅HTML /画布UI
• 无法访问某些设备事件和服务（已被广泛记录）
• 无法在应用商店中列出（影响可发现性）
• 可以变为全屏并在iOS上具有主屏幕图标，但是对于大多数用户来说，这是一种不寻常且不熟悉的体验

如果您可以接受以上所有内容，请继续阅读有关单页本机样式Web应用程序的挑战的更多信息。但是，如果不参考FT应用程序，本节将不完整。

金融时报
的FT Web应用程序是这种风格的应用程序的一个著名的例子。 这是英国卫报的一个有趣的功能。

当然，这是一项非凡的工程壮举。请注意，目前它仅仍仅在iOS上可用-这告诉我，他们发现解决高级跨浏览器开发的挑战确实非常困难。

单页本机样式Web应用程序

本部分适用于移动Web和Phonegap风格的应用程序。

Web应用程序中的本机外观通常是通过诸如Sencha Touch之类的框架实现的，该框架提供了一组UI组件供您使用。

这样的框架非常适合非常简单的UI。但是它们缺乏灵活性。您将无法使用Sencha来实现任何本机应用程序设计，您需要使您的设计适应框架可以容纳的内容。

这些框架遭受的主要方式是试图模拟平台自己的UI复杂性。当您滚动到iPhone上列表的末尾时，会得到那种不错的弹跳效果吗？您的框架需要在Javascript中进行模拟。不可能完全重新创建它，它很容易放慢速度，并且您的用户将被卡在应用程序的“怪异谷”中，该应用程序看起来像本机，但显然不是，并且是非技术性的用户将无法确切地说出原因。

“ HTML5 / Java语言很简单”的神话

Web浏览器中的设备碎片非常普遍，当您超出最基本的HTML和CSS时，就会注意到事情并没有达到您的预期。您可能会发现自己花了更多的时间解决巧妙的UI问题，而不是自己本来就省去了两次。如果你打算本地，需要注意的是本机应用程序网页视图是不一样的设备浏览器，并有自己的碎片问题。

而且，随着您的应用程序功能变得更加复杂，您会发现，除了基本的jquery技能之外，您还需要更多的知识来保持Javascript的干净和可维护。

就是说，使用这种方法完全可以很快创建简单，功能强大的应用程序。但是当应用正在执行时，这是很明显的。

沿谱

因此，我们希望有一个比Phonegap风格的应用程序能够提供的更好的UX，而不必完全从头开始编写所有内容。我们能做什么？

共享非UI代码

有多种技术可用于在多个本机平台之间共享业务逻辑。谷歌已经推出了将Java转换为Objective-C的J2ObjC。经过仔细的代码分解，可以在Android和iOS上使用Java库。

诸如Calatrava和Kirin之类的库允许使用Javascript（以及因此可以编译为Javascript的任何东西）编写的代码库从本机代码中进行操作。免责声明：我为创建Kirin的Future Platforms工作；我们在iOS上使用GWT生成的Javascript在Java上成功使用了Java代码，并且Java代码也在Android上本地运行。

在适当的地方使用网络视图...

要模拟屏幕过渡和跳动效果，全屏Web视图有很多工作要做。但是本地应用程序chrome中的webview可能与本地应用程序没有区别。

有用于本机应用程序和Web视图进行通信的标准且记录良好的方法。

以这种方式完成操作后，列表和表可以特别好地工作，但是文本输入是本地处理最好的示例（用于完全控制键盘）。

综上所述

合适的方法取决于您的应用程序的复杂程度以及您对UI抛光的满意程度。

我的座右铭：尽可能使用webview，但请确保您的用户不会说。

首先检查此调查以了解发生了什么！

三种类型之间的比较： 了解您的移动应用程序开发选项

native和hyprid之间的比较：

HTML5与原生

HTML5 vs本机应用程序：选择哪个？

这真的很好： HTML5 v本机应用程序：您的移动策略的关键注意事项

评论：

• 您可以选择其中之一取决于您所拥有的（技能）和所能获得的（外观，感觉，性能，功能等）。
• 每个移动应用程序开发人员都应对他要开发的第一个版本和将来的版本的应用程序有清晰的愿景/要求！只是为了确保他会使用的选项在某些时候不会限制他。
• 没有什么比这三种方法有真实的经验，并且可以同时掌握最新知识，这将使您有意识并有能力做出正确的决定。

如果需要访问电话硬件，则应构建一个本机应用程序（在HTML5中，您可以访问设备的某些硬件组件，例如GPS）。

如果您对Web开发更满意，那么除非您需要制作本机应用程序，否则应该坚持这样做。

据您所知，我想您应该牢记所有不同的屏幕尺寸（包括垂直和水平方向）。您应该记住各种版本的OS（对于Android来说更多）。由于这些设备是移动设备，因此用户有可能会接听电话而不是电话，而且他们没有台式机或服务器的计算能力。

对我而言，编写任何消费者应用程序时，成功与否最重要的是用户对应用程序的接受程度和认知度。由于倾向于使用本机应用程序的四个原因，尽管与学习，培训和失去WORA（一旦在任何地方运行一次写入）相关的额外费用，仍然是：

1. 更快的应用启动
2. 滚动更流畅
3. 一致性更高的应用程序ui与其他操作系统和应用程序的关联更加一致
4. 更快的App UI响应

您最想要的是出色的用户体验，可帮助您的应用在激烈的市场中取得成功。当然也有例外，特别是缺乏技能，缺乏时间和预算。有时，应用程序只适合少数业务用户，他们可能不太在意这些事情。

出于类似原因，Facebook放弃了他们的应用程序策略，转而使用IOS和android的本机应用程序：

请阅读：

马克·扎克伯格（Mark Zuckerberg）：我们最大的错误是在HTML5上赌太多了 http://techcrunch.com/2012/09/11/mark-zuckerberg-our-biggest-mistake-with-mobile-was-betting-too-much-on- html5 /

为什么Facebook放弃了移动网络并通过其新的iOS应用程序放弃了原生功能 http://readwrite.com/2012/08/23/how-facebook-ditched-the-mobile-web-went-native-with-its-new- ios-app＃awesm =〜o9jDrRefxdgnpS

希望这可以帮助。

在下面的内容中，我目前对这种崩溃的立场是，从开始使用混合功能，探索您的应用程序，快速迭代客户反馈并稳定功能集的角度出发，这是很好的选择。然后，根据规范将应用程序重写为本机，以增强体验。

我将Mobile Web排除在外，因为它的目的完全不同。如果您想进入应用商店，则本机/混合是必经之路。如果要简化部署并愿意牺牲经验和技术能力，请使用Mobile Web。

Pro / Cons Native：

• 优点：符合设备的其他使用经验，没有任何异常谷问题。
• 优点：它主要提供流畅一致的UI体验，没有延迟，没有结结巴巴。
• 优点：技术上的限制很少，您可以充分利用该设备。
• 优点：本机工具可满足应用商店验证的要求。
• 优点：本机框架包括每个平台版本的调整，减少了微调时间。
• 缺点：可以持久使用，因此需要更多时间来构建。
• 缺点：需要很难找到的，昂贵的多语种开发人员。
• 缺点：需要熟悉每个设备平台的API（iOS / Android / etc）。
• 缺点：学习曲线陡峭。
• 缺点：每个平台使用不同的工具集。

Pro / Cons Hybrid：

• 专业版：单一代码库可针对多个设备平台。
• 专业：快速的开发周期，极大的布局灵活性，非常适合原型和MVP。
• 优点：舒适的学习曲线，大量文档，可帮助您的框架。
• 专业版：单一开发工具集。Chrome调试器工具非常出色。
• 专业版：一个针对多个设备平台的代码库。
• 专业版：提供大量开发人员，易于学习。
• 缺点：需要合适的UI框架才能使UI适用于每个不同的平台，以与设备体验保持一致。有诸如Kendo UI，Sencha Touch之类的解决方案。
• 缺点：需要非常了解内存和计算使用情况，一些CSS，javascript循环会严重降低应用程序的速度。设备上没有非常好的工具可用于调试。
• 缺点：还不成熟，情况可能会突然改变，但是工具却在不断完善。

作为自己的移动开发人员，最糟糕的事情是脱机访问。您只需要强迫用户在线即可在许多应用程序中使用，但不能在所有应用程序中使用。

另一个不好的方面是缓慢。解析远程数据所需的时间可能会花费大量时间。是的，您可以在加载期间预取数据，但是在所有其他情况下，您都无法避免速度过慢。

我发现这样的应用程序结束的应用程序比本地应用程序昂贵。我不再推荐给我的任何客户。

混合应用程序的最大问题是框架的碎片化：显然，其中的框架（Ionic，Xamarin，React Native等）比感兴趣的本机移动平台（通常只有两个，Android和iOS）更多。这些框架相互竞争，出现，衰落，因此即使您打算保留当前的团队一生，混合使用也无法避免您从一个平台跳到另一个平台。

Google和Apple正在尽最大努力为他们的平台提供和支持编辑器，调试器，测试框架，重构工具以及其他开发手段。因此，我会采用典型的措辞，“ 在保留合理的前提下，开发混合应用程序，使用自己喜欢的编辑器进行编辑并在浏览器中打开将更加容易 ”。Xamarin和React Native是开发平台，与Swift或Java / Android一样，虽然“ hello world”可能看起来更短，但最终应该花费相当的时间才能正确学习。

如果在任何情况下都需要本机组件（例如，必须集成现有的第三方库），您将最终得到三个框架，而不是两个：iOS，Android和顶部的混合框架，最终具有更复杂的架构。调试此类应用程序，在跨层调用之间切换，记录所有层，保持代码同步非常复杂，有时甚至是不可能的。

有人说“该应用在所有平台上看起来都完全一样 ”。真的好吗？Android应用必须看起来像Android应用，而iOS应用必须看起来像iOS应用。

新功能如何？可穿戴设备？Android平台现在提供的即时应用程序？在外部显示器上显示其他数据？混合应用程序现在支持许多本机功能，但是它们真的支持所有这些功能吗？随时都可以吗？

最后，本机应用程序不仅可以提高性能和用户体验，而且还可以提高安全性。混合框架添加了可能具有自己的错误（包括安全错误）的间接层。

综上所述，在可以选择的情况下，我肯定会选择两个本地应用程序，一个用于iOS，一个用于Android，或者只是设计网站的移动版本，而无需为任何平台进行应用程序开发。