移动开发 - 原生 VS 跨平台 VS JavaScript

Question

我们公司即将开始为移动平台开发几款产品，作为CTO，我被要求研究不同的工具的优缺点，以实现最佳的质量/成本效益解决方案。

我们主要针对iOS和Android，次要是Windows-Mobile和BlackBerry。

候选人:

在进行一些背景研究后，我找到了以下可能的候选人:

• 本地开发-简单但费力，为每个平台使用其本机工具和语言进行开发。

• HTML5、CSS和JavaScript - 可以是在设备浏览器上运行的Web服务(网站)，或者是封装该代码的应用程序围绕WebKit。

• Rho mobile -由Google制作，因此应该很好 - 然而基于Ruby(我们不太熟悉)并且拥有复杂而脆弱的dev环境。

• PhoneGap - 它似乎很容易，大多数基于Javascript - 它是开源的，但最近被Adobe收购 - (不是一个好兆头)

• Appcelerator -从Javascript到PHP再到Python，有一个不错的API访问范围，但我们听到了很多关于被Apple拒绝和在使用复杂代码跨不同平台时的不兼容性的故事。

• 还有MoSync、Sencha、Appmobi和Corona等更多(没有亲自测试过)。

一些参考点:

• 我们不打算开发游戏，我们计划开发的应用程序属于商业应用程序和信息工具领域。

• 这些应用程序不依赖于过度使用设备API(但确实需要一些基本访问权限)

• 公司已经为iOS开发了应用程序，并且我们有一个小型的本地iOS开发人员团队(Objective-C极客)

• 我们希望能够确保在未来继续开发我们的应用程序，而不会因新的操作系统或API而出现问题。

在提交申请前确保应用程序不会因跨平台代码（主要是AppStore）而被拒绝将是有益的。

和任何公司一样，我们希望成本尽可能低 - 另一方面，我们坚持高质量的产品和顶级用户体验。

没有比在StackOverflow上提问更好的地方了，我非常感谢有经验的开发人员对这个问题的任何评论。

- Oliver Blint

---

你的问题具体是什么？"有任何评论"并不适用于SO的问题/答案格式。我看到你是新来的，所以请阅读FAQ："交谈式、没有明确答案的问题会降低我们网站的实用性并将其他问题推出首页。" - Caleb

Answer 1

应用市场上有500,000多款应用程序，竞争激烈。拥有优秀的用户体验和图形设计至关重要。

跨平台工具与本地开发不相匹配。如果它们可以，我们都将使用它们。但事实并非如此-您无法完全控制。而完全控制对于拥有外观出色的应用程序至关重要。

如果您的应用程序不是面向消费者的应用程序，而是企业级应用程序，其使用由某个内部部门规定，那么您可能会接受一般的设计，因为此类应用程序的价值在于其功能性。

但是，如果您对移动应用市场认真，那么唯一的方法就是使用本机应用。您需要一个全职的用户体验专家和设计师（了解移动开发）。您将花费50％以上的时间来处理外观。我现在参与的项目正在花费80％以上的时间进行外观设计（图形、动画、用户体验、可用性测试）。

建议：花费合理的时间（=几天）使用竞争对手的应用程序。同时花时间了解每个市场前50个应用程序。您将感受到标准有多高。然后检查使用跨平台工具制作的应用程序（您可以在其网站上找到链接）并进行比较。

- Peter Knego

---

随着谷歌将其Google Pay应用从本地平台转向跨平台开发，我的问题是，他们是否仍然有iOS和Android团队与跨平台开发团队（Flutter团队）并行工作？他们是否已经将所有应用迁移到了Flutter平台？ - undefined

Answer 2

虽然我完全同意@Peter Knego的观点，但对于想要支持多个平台的团队，我会添加一些细节：

如Peter所说，UX是非常重要的，跨平台的UX则是最低公共分母的UX。即使没有束缚，让这些东西变得完美已经很难了。真正出色的Web应用程序被评判的标准是它们接近本地体验的能力，而不是反过来。

产品中有许多部分与UX无关。值得仔细考虑您可以在那里获得哪种类型的重用。例如，我经常建议那些在Android上已经运行SQL数据库的团队不要尝试在iPhone上使用Core Data。没有理由重新发明您的对象和数据模型。

这不是一个写C ++核心的全面建议。如果您拥有广泛的、现有的C++核心，我之前曾提出过如何重用它的建议。但是我通常不推荐新代码使用它。在大多数情况下，最好使用平台的最佳OS级功能。

设计在所有平台上都能良好工作的网络协议相当容易，应该追求。在几乎所有情况下，您的最佳选择是REST和JSON。保持简单，特别是对于像SOAP和解析复杂XML这样的iPhone讨厌的东西。

一些复杂的布局问题在HTML+CSS中比使用本机控件更容易解决。如果您有复杂的多列表格（特别是您需要使用colspan和rowspan的内容），这一点尤其正确。我在其他本地应用程序中嵌入了单个UIWebView片段，即使根本不考虑可移植性也能取得相当不错的效果。在这里可以进行一些有价值的重用。只要记住，您不希望浪费大量精力和性能来使您的HTML浏览器中立。在iPhone上，使用WebKit扩展可以让您的应用程序更好地服务于用户。

在这个过程中最重要的一点是，没有一种适用于所有平台的制作应用程序的“正确”方法。iPhone 应用程序应该像 iPhone 应用程序一样运行。Android 应用程序应该像 Android 应用程序一样运行。

高度跨平台的方法是一种廉价的方式，如果您不关心“某物”的具体内容，那么这是一个好的选择。但是，如果您想要获得出色的结果，那么这种方法是非常昂贵的。

- Rob Napier

---

+1 很棒的帖子。我喜欢关于没有正确方法的评论。保持精益，把它放在人们面前，然后迭代。 - Peter Knego

@Rob 由于Google已经从原生平台转向跨平台开发其Google Pay应用，我的问题是，他们是否仍然有iOS和Android团队与跨平台开发团队（Flutter团队）并行工作？他们是否已经将所有应用迁移到了Flutter平台？ - undefined

我不是谷歌的员工，我不知道他们是如何组织他们的团队的。 - undefined

Answer 3

我在AppMobi工作，以下是我的一些评论。

1. 您的应用程序不应因使用本地Web视图而被拒绝跨平台。我们还没有看到苹果在任何提交给AppMobi的应用中使用过它。

2. Rhombile并非“由Google制造”。实际上，它甚至不是Google收购的摩托罗拉的一部分，而是他们的业务部门。他们正在推动HTML5 / Javascript，但目前使用Ruby。

3. Appcelerator最初支持Web视图，然后又改变了主意。他们刚刚筹集了大量资金，以重新支持Web视图。

至于有人说“不”跨平台应用程序。 Facebook和其他一些大公司正在向基于HTML5的移动应用程序转移。

- user258082

---

我想指出，Facebook的Facebook应用程序出现了许多问题，因为它过于依赖HTML 5技术。几周前，他们突然改用本地技术，结果应用程序速度提高了200%，评价也更好了。马克·扎克伯格承认，太过依赖HTML 5是问题所在。简单来说，由于明显的原因，本地技术始终会更快并提供更多控制。 - Oscar Gomez

不，Facebook遇到问题是因为他们在实现应用程序方面做得非常糟糕。在http://news.ycombinator.com/item?id=4507879上有一个非常好的讨论。 - user258082

这是两者的结合，确实并不全是HTML 5，但本地应用程序始终比HTML 5更快，这很简单，因为无论是苹果还是安卓，都不会优化他们的移动浏览器来弥补差距（即使那样本地应用仍然会更快），他们不会这样做，因为他们希望人们使用他们的应用商店。更不用说使用Objective-C比HTML5更易于维护/扩展，而且IDE也好得多，可以争议地认为在Objective-C中编码比HTML 5更快。事实上，单一平台的概念将永远落后。 - Oscar Gomez

我忘记说iOS API非常好，而HTML 5 API相对较差。 - Oscar Gomez

我更倾向于本地开发而非 JS，然而 Facebook 的 HTML5 应用之所以失败（即表现非常缓慢），实际原因并非在 HTML5 上。http://www.sencha.com/blog/the-making-of-fastbook-an-html5-love-story - Mike6679