【问题标题】:FIghting the 'native vs html5' mobile app battle [closed]打“原生 vs html5”移动应用之战[关闭]
【发布时间】:2012-07-13 18:12:35
【问题描述】:

我是一名 iOS(本地)开发人员,自 App Store 推出以来一直如此。从那时起,我也学习了一些 Windows-Phone 和 Android。我已经注意到在原生之上构建 HTML5 网络应用程序的必然趋势,而且它的增长速度似乎比我预期的要快。这让我作为一个原生开发者感到沮丧,因为大多数时候有很多关于原生的争论,而只有少数支持 HTML5(即它是跨平台的!),但后面的那些争论似乎更胜于前者现在还有更多,有时是由于无效的原因。

我不相信移动应用程序的“未来”在于 HTML5 和 PhoneGap 等工具,这些工具可以跨平台进行大规模分发。与原生应用程序相比,网络应用程序的体验总是低于标准的,除此之外,很多关于它的神话往往都在流传。例如,“客户不会为多平台的原生开发付费;太贵了!”这是一个神话,如果许多客户真正了解他们所获得的应用程序质量的差异,他们就会为此付出代价。行业领导者一次又一次地证明了这一点,他们在大多数情况下并没有为客户构建网络应用程序。我什至知道当一位 CEO 拿到他们外包的一个应用程序时发生了一场近乎诉讼,这是一个 PhoneGap/HTML5 应用程序。他(理所当然地)对承诺“一个应用程序”的公司感到愤怒,并想知道为什么它不像他的其他应用程序那样感觉或响应,从而导致一团糟。

其他神话包括走 HTML5 路线可以节省大量代码和时间,但事实并非如此。涉及跨设备/平台的测试,更不用说使应用程序在这些平台上运行所涉及的 CSS 和 javascript 的数量,通常会导致代码混乱,并花费大量时间调试相关问题。一个典型的原生开发者可以在几个小时内在几个平台上弹出简单的基于列表的导航/详细视图,而构建 HTML5 以“模仿”并伪造相同的确切功能和外观/感觉很可能需要大约相同的时间.此外,走PhoneGap/HTML5 路线将始终确保您将落后而不是处于平台和技术的前沿,这一事实又如何呢?

我最大的挫败感是,现在似乎有些开发公司有时甚至向客户推荐 PhoneGap/HTML5 方法,因为它具有跨平台的魅力等,甚至没有向客户真正解释(他们有时可能毫无头绪) 关于性能和外观/感觉差异的实际含义。

我绝对想跟上时代的步伐,为最坏的情况做准备,这就是为什么我要扩展学习这些工具的原因,但我只是好奇你们(本地开发人员)是如何处理这种工具的的东西?我一个人在想这个吗?关于如何以理性的方式向人们解释如何做出这个决策过程的任何建议?

在收到有关此问题的回复之前,请注意,我完全理解有时使用网络应用程序路线是正确的方式,并且我完全理解有些客户根本不会为原生支付费用,所以这很好。我也理解预测表明 HTML5 应用程序的百分比将随着时间的推移而继续上升。但是,我只是不同意“所有应用程序都应该是 HTML5,我们只是使用本机组件”的日益增长的心态。需求出现了(即相机等)。”我个人的观点是应该反过来:“所有应用程序都应该是原生的,除非特定的 UI 和功能在 HTML5 中更容易/更快地完成”。公司可以找到能够快速编写代码并可以访问代码库的本地开发人员,以使本地开发与通过网络应用程序进行开发一样快,甚至快得多。

想法?如果这是此类事情的错误论坛,我提前道歉,但我渴望得到意见和建议。谢谢! -文森特

【问题讨论】:

  • 这是一个非常重要的问题,我建议其他人相应地支持这个问题
  • 看起来更像是一个宣传片而不是一个问题。
  • 我很抱歉,我并不是有意将其视为宣传片;我只是面临一种情况,我的职业生涯受到趋势的影响,而这种趋势发生的基础在很多情况下都是错误的。这是一种严重的挫败感,我想联系一下,看看我在这方面是否孤单,和/或是否有人对向开发商店或客户解释它的最佳方式提出建议,以便做出明智的决定。
  • 您需要认真考虑您的假设。将这样的行业趋势视为威胁会伤害你。您最好熟悉所涉及的技术,这样您就可以为您的客户提供满足他们需求的最佳解决方案,并以公正的方式向他们提供两种方式的利弊建议。您的偏见在您所写的内容中很明显,并且适用于您的客户。如果你不能更灵活,你将被注销为“iOS 人”。
  • 朱利安,你对客观性提出了很好的看法。我阅读问题的方式有点不同。我认为作者是在说选择 HTML5 的基本假设通常是不正确的,事实上,基于对成本和跨平台支持的看法存在一种 HTML5 偏见,这通常是不正确的。因此,帮助客户的一部分是能够确定他们何时更好地使用其中一个。

标签: android iphone ios html


【解决方案1】:

这是使用 Native 与 HTML5 的简单案例。从技术上讲,没有什么可以阻止基于浏览器的解决方案变得与基于本机的解决方案一样强大,但它永远不会发生,原因如下: 供应商参与进来:Apple、Google 和 Microsoft 没有动力去实现这一点。想想看。如果他们将其完全标准化,那么他们的平台将几乎没有优势。让我们以消息传递为例。您能否拥有通过 HTML5 提供的最佳 Apple 或 Android 消息服务?当然可以,但是为什么平台供应商会走这条路呢?为什么他们会贬低 iOS SDK 或 Android SDK?所以这真的就像只在移动领域上演的浏览器大战。当浏览器大战开始时,每个人都认为超级浏览器会出现,但它从未出现过,出于同样的原因,这次也不会出现。所以真的它不仅仅是一个技术问题,如它所描述的,开放与封闭。事实上,供应商不会以公开的方式提供他们最新最好的产品。这是大多数跨平台解决方案落后于供应商版本的原因之一。

另一个例子是对 WebGL 的支持。对 WebGL 的支持花费了比预期更长的时间。一旦有比 WebGl 更好的东西,它将首先以原生方式提供,然后 WebGL 最终将在所有浏览器中得到完全支持,在每个主流设备上。但是支持总是落后于原生的。关键是基于浏览器的总是会落后一步,因为这就是供应商喜欢它的方式。

另外请注意,许多应用程序客户认为使用 HTML5 实际上更符合 Web/Internet 的要求,而实际上本机应用程序使用 HTTP 就像 HTML5 应用程序一样。这是一种常见的误解,因为大多数原生应用程序都像 HTML5 应用程序一样通过 HTTP 使用服务访问。唯一的区别是您是在 javascript 与本机方式中处理请求和响应。

安全性是另一个需要考虑的重要问题,有多少安全应用正在使用 HTML5?我敢打赌,大多数进行安全交易的应用都是原生的,而且有充分的理由。

如果人们可以提供最近在 Android 或 iOS 中发布的功能示例,以及 PhoneGap 提供的这些功能的支持级别以及 PhoneGAP 在支持这些 sdk 功能方面的路线图,将会很有用。换句话说,当 SDK 的新版本出现时,PhoneGAP 并没有同步,Titanium 也没有。然而,PhoneGap 在我看来是原生解决方案的主要竞争者,因此它与原生解决方案的比较将是最有意义的。我认为将本机与跨平台的专有 SDK 进行比较是浪费时间。这永远不会吸引到PhoneGAP或Native的竞争。

但是,对于那些对 PhoneGap 感到兴奋的人来说,请注意。内置插件可能存在于您需要的所有平台上,但如果您需要为 PhoneGap 编写自己的插件怎么办? (您将在 PhoneGAP 中了解 GAP 背后的真实故事)要么是因为您想做与现有插件完全不同的事情,要么是因为您想自定义现有插件。这不是一次写入无处不在的部署方案。您需要为每个想要该功能的平台编写一个自定义插件。换句话说,你又回到了原生状态。因此,您最好花时间仔细评估插件(在您将运行 HTML5 应用程序的所有平台上),并确保它们现在和将来都是您需要的。另一方面,没有 PhoneGAP 的 HTML5 相当不稳定,而且有限,你很快就会发现自己重写了 PhoneGAP。

另外一点是,一个应用程序实际上可以通过多种方式进行交互,其中只有一种是使用 HTTP。它还经常需要以最佳方式与设备上的操作系统和资源进行交互。更不用说真正不关心使用什么底层技术但基于与大量原生应用交互而抱有很高期望的用户。

当您运行 HTML5 应用程序时,您实际上是在另一个应用程序(即浏览器)中运行您的应用程序。浏览器应用程序仅在平台供应商允许的范围内强大。如果历史可以作为指导,它会发展,并且会添加更多功能,但永远不会优化,永远不会与所有其他供应商同步,并且出于技术和商业原因,永远不会与底层操作系统和 SDK 同步。

用户想要最好的体验,应该注意的是,虽然拥有 Android 的人很多,拥有 iPhone 和 iPad 的人也很多,但同时拥有两者的人相对较少。换句话说,Android 用户可能不太关心您的应用程序的 iOS 版本,而 iOS 用户可能不太关心您的 Android 应用程序。但用户真正关心应用程序如何在他们选择的平台上运行。他们不想要在两个平台上运行一半的东西,因为他们从来没有在两个平台上看到它。用户几乎总是一次在一个平台上体验应用程序。

就原生解决方案与 HTML5 的定位而言,我认为这让决策者认识到,不仅原生开发者喜欢原生解决方案,平台供应商也喜欢原生解决方案,这意味着更好、更高质量的应用与操作系统改进同步。 反过来,这意味着快乐的应用用户拥有更好的移动体验。

【讨论】:

  • 读起来像锡纸帽子手册。
  • 直到你开始思考!
  • 这就是您意识到出于性能和安全原因,在浏览器之外运行东西可能不是最好的主意的地方......
  • 另外值得注意的是,虽然很多用户拥有 Android 设备,但很少有人购买过应用程序。因此,如果您已经是一位经验丰富的 iOS 开发人员,那么仅仅为了迎合 Android 而选择跨平台解决方案可能不是一个好主意。只需谷歌搜索“android vs ios app sales”,您就会发现大量论坛帖子,人们在其中销售 1000 份 ios 副本和 1 份 android 副本(但随后开始从 android 客户端获取网络请求......盗版! !!)
  • 您已经提到了很多关于平台供应商限制浏览器功能的问题,那么网络浏览器是如何接管原生 PC 应用程序的呢?
【解决方案2】:

我想我能以某种方式理解你。我开发原生 Android 应用有一段时间了,我们公司就跨平台开发进行了很多讨论。

根据我的经验,如果您想构建一些严肃的应用程序,许多移动跨平台解决方案(如 Phonegap、Appcelerator 或 Adob​​e Air)都会失败。也许这些解决方案在未来会变得更好。

目前我推荐以下开发移动应用程序:

  • 非常简单的应用程序(只是几个视图),没什么特别的:去 Phonegap。简单的应用程序可以与 phonegap 配合使用,并且您拥有“跨平台”解决方案。
  • 稍微复杂一点的东西(大量的服务器通信、同步等):选择 Native。在这种情况下,原生应用程序的 API/性能/调试工具通常比“跨平台参数”更有优势。

移动网站有点不同。在许多情况下,已经有一个“正常”的网站只需要针对移动设备进行清理和优化。在这种情况下,您可以使用现有的代码/接口,从而节省大量时间。

【讨论】:

  • 我同意一些简单的应用程序。但是,如果应用程序需要某些高质量的图形,它作为原生应用程序可能仍然更好。但只要确保客户意识到,如果他们的应用程序增长,他们可能需要重写为原生应用程序。
  • 对于移动网站,重新利用现有网站并不总是可行的。甚至网站使用的服务通常也不适合拉入移动设备。
  • @CodeDroid 通常是正确的——但这不是移动浏览器的错。写得不好/不灵活的网站总是会卡在原地
  • “所有稍微复杂一点的东西(大量的服务器通信、同步等):选择 Native。” -- 或者你可以让它成为一个有自己的 API 的 Rails 应用程序,对吗?这不是让你的代码更简单更漂亮吗?
【解决方案3】:

这类似于“未来哪一种编程语言会胜出?”的问题,或者 (sotto voce) vi vs emacs。制作应用程序的方法不止一种。 Native 有它的优势,HTML5 也有它的优势,这取决于问题和开发者的技能。我建议您熟悉这两种工作流程,这样您将来更有资格提出建议,并在可行的情况下接受他人的意见。

【讨论】:

  • 正如我的帖子中所述,我对这两种工作流程都很熟悉,而且我对允许创建应用程序的 VIABLE 平台持完全开放的态度。我的观点是,原生开发似乎“失败”的原因并不是可行的原因,我想就如何解决问题获得意见。我不是在问未来哪种语言会胜出;坦率地说,我不在乎,因为我对两者都很熟悉。不是说你是这些人中的一员,但对其他回复仅供参考 - 我对 HTML5/PhoneGap 狂热者不感兴趣,他们因为它有利于原生而降低了这篇文章的评分。
  • Yusuf,你为什么不分享你对何时使用 HTML5 而不是原生的看法。
  • 当你有一个简单的应用程序需要移植到许多平台并且不需要很多资源或很多时间,它使用 HTTP,那么 HTML5 是最简单的。一旦其中一些条件不满足,就该考虑原生了。
【解决方案4】:

几个重要的其他问题。会有一种很棒的元编程方式吗?就像 Titanium 或 Java 背后的最初想法一样。此外,还有一些可以更好地在本地实现的东西,例如地图。此外,cpu、内存的增加使得一些支持原生的论点变得不那么相关了。

【讨论】:

  • 好吧,我认为这里的重点是,即使您想要一种通用的方式来制作应用程序,javascript 似乎也是一条次优路径。 javascript 是 HTML5 和 CSS3 中的关键语言
  • 再一次,即使可以开发跨平台方法,您还要从哪里获得供应商的支持以完全支持跨平台方法?
猜你喜欢
  • 2011-06-08
  • 1970-01-01
  • 2023-03-24
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2016-10-19
  • 1970-01-01
相关资源
最近更新 更多