移动开发 - 原生 VS 跨平台 VS JavaScript [关闭]

Posted 2023-03-12

【中文标题】移动开发 - 原生 VS 跨平台 VS JavaScript [关闭]

【英文标题】：Mobile development - Native VS Cross Platform VS JavaScript [closed]

【发布时间】：2012-01-14 20:53:07

【问题描述】：

我们公司将很快开始为移动平台开发一些产品，因为 CTO 我被要求检查可用的不同工具的优缺点，以实现最佳质量/成本效益的解决方案。

我们将主要瞄准 ios 和 android，其次是 Windows-Mobile 和 BlackBerry。

候选人：

在进行了一些背景调查后，我发现了以下可能的候选人：

原生 - 使用原生工具和语言为每个平台进行简单但费力的开发。

HTML5、CSS 和 JavaScript - 可以是在设备浏览器（网站）上运行的 Web 服务，也可以是在 WebKit 周围封装此类代码的应用程序。

李>

Rho 移动版 - 由 Google 制造，所以它应该很好 - 但是基于 Ruby（我们不习惯），并且确实有一个复杂且相当脆弱的开发环境。

PhoneGap - 看起来很简单，主要基于 javascript - 它是开源的，但最近被 adobe 收购 - （不是一个好兆头）

Appcelerator - 从 Javascript 到 php 再到 python 的任何东西，都有很好的 API 访问范围，但我们听到了许多拒绝（被苹果公司）的故事，以及在跨平台使用复杂代码时出现不兼容的情况不同的平台。

更像是 MoSync、Sencha、Appmobi 和 Corona（没有亲身测试过）。

一些参考点：

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

应用程序不依赖于过度使用设备 API（但确实需要一些小的基本访问权限）

公司已经为 iOS 开发，我们有一个由原生 iOS 开发人员（Objective-C 极客）组成的小型团队

我们希望确保我们可以继续在该功能中开发我们的应用程序，而不会因为新的操作系统或 API 而损坏

事先确保应用程序不会因跨平台代码（主要是 AppStore）而被拒绝是有益的

与任何一家公司一样，我们希望尽可能提高成本效益 - 另一方面，我们坚持高质量的产品和一流的用户体验。

没有比 *** 更好的地方来问这个问题了，我会感谢任何有此主题经验的开发人员提供的 cmet。

【问题讨论】：

您的问题具体是什么？ “任何 cmets”并不真正适用于 SO 的问题/答案格式。我知道您是新来的，所以请阅读FAQ：“喋喋不休的开放式问题会降低我们网站的实用性，并将其他问题推到首页。”

【参考方案1】：

应用市场上有超过 50 万个应用，竞争非常激烈。拥有出色的用户体验和图形至关重要。

跨平台工具无法与原生开发相提并论。如果它们是，我们都会使用它们。但我们不是。有一个原因 - 你没有完全控制权。要拥有漂亮的应用程序，完全控制是必要的。

如果您的应用程序不是消费者应用程序，而是企业应用程序，其用途是由某个内部部门规定的，那么您可能可以通过马马虎虎的设计，因为这样的应用程序的价值在它的功能中。

但是，如果您认真对待移动应用市场，那么唯一的方法就是采用原生方式。你需要一个 UX 人员和一个设计师（谁知道移动开发）全职团队。您将花费超过 50% 的时间在外观上。我现在参与的项目将 80% 以上的时间用于外观（图形、动画、用户体验、可用性测试）。

建议：花合理的时间（= 天）使用您的竞争对手应用。还花时间在每个市场上排名前 50 的应用程序上。你会感觉到酒吧有多高。然后检查使用跨平台工具制作的应用（您可以在他们的网站上找到链接）并进行比较。

【参考方案2】：

虽然我完全同意@Peter Knego，但我想为希望支持多个平台的团队补充几点：

正如 Peter 所说，UX 是巨大的，跨平台的 UX 是最小公分母的 UX。要让这些东西成为它需要的一切，而不把你的手绑在背后，这已经够难的了。真正出色的网络应用的评判标准是它们接近原生体验的能力，而不是相反。

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

这并不是一个笼统的建议，即用 C++ 编写核心。如果你有一个广泛的、现有的 C++ 核心，我已经made suggestions before 关于如何重用它。但我通常不建议将它用于新代码。在大多数情况下，最好使用平台的最佳操作系统级功能。

设计在所有平台上都能正常工作的网络协议非常容易，应该继续努力。在几乎所有情况下，您最好的选择是 REST 和 JSON。保持简单，尤其是对于讨厌 SOAP 和解析复杂 XML 之类的 iPhone。

一些复杂的布局问题在 html+CSS 中比使用原生控件更容易。如果您有复杂的多列表（尤其是您需要 colspan 和 rowspan 的东西），则尤其如此。即使在根本不考虑可移植性的情况下，我也很幸运地将单个 UIWebView 片段嵌入到其他本机应用程序中。这里可以有一些值得重用的地方。请记住，您不想浪费大量精力和性能来尝试使您的 HTML 浏览器中立。在 iPhone 上，可以在任何地方使用 WebKit 扩展来让您的应用更适合用户。

不过，其中最重要的经验之一是，没有一种“正确”的方法可以制作适用于所有平台的应用。 iPhone 应用程序应该像 iPhone 应用程序一样运行。 Android 应用应该像 Android 应用一样运行。

如果您并不真正关心“某物”是什么，那么高度跨平台的方法是获得“某物”的一种廉价方式。它们是一种非常昂贵的获得好东西的方式。

【讨论】：

+1 很棒的帖子。我喜欢关于没有正确方法的评论。精益求精，把它放在人们的手中，然后迭代。

【参考方案3】：

我在 AppMobi 工作，我只会做一些 cmets。

您的应用程序不应该因为使用本机 webview 跨平台而被拒绝。我们还没有让 Apple 在任何 AppMobi 提交的应用程序上使用它。

Rhombile 不是“谷歌制造”。事实上，谷歌收购的甚至不是摩托罗拉的一部分，而是他们的业务部门。他们正在推动 HTML5/Javascript，但目前是 Ruby。

Appcelerator 开始支持 web 视图，然后回溯。他们刚刚筹集了大量资金来支持 webview。

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

【讨论】：

我想指出 Facebook 有很多问题，如果他们的 facebook 应用程序出现问题，因为它在 HTML 5 上下注太多，几周后他们突然改变为原生，他们的应用程序速度提高了 200%，而且评论要好得多，马克扎克伯格承认在 HTML 5 上投入过多是问题所在。简而言之，原生总是更快 + 提供更多控制，原因显而易见。

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

它是两者的结合，确实它不全是 HTML 5，但仍然原生总是比 HTML 5 快，因为 Apple 和 Android 都不会优化他们的移动浏览器关闭漏洞（即使这样原生仍然会更快），他们不会这样做，因为他们希望人们使用他们的应用商店。更不用说使用 Objective-c 比 HTML5 更易于维护/可扩展，而且 IDE 也好很多，它也可以说在 Objective-c 中比 HTML 5 更快。事实是，单平台理念永远落后。

我忘了添加 iOS API 很棒，HTML 5 API 很差。

我支持通过 js 进行本地开发，但是 facebook 的 html 5 应用程序是一场灾难（意味着它非常慢）的真正原因是他们的实现而不是 HTML5。 sencha.com/blog/the-making-of-fastbook-an-html5-love-story