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

我们公司即将开始为移动平台开发少量产品，因为我要求首席技术官研究可用不同工具的Pro和Cons，以实现最佳质量/成本效益解。移动开发 - 原生VS跨平台VS JavaScript

我们主要针对iOS和Android，主要面向Windows Mobile和BlackBerry。

考生：

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

本地 - 简单而费力地用其本地工具和语言各平台开发。
HTML5，CSS和JavaScript - 可能是在设备的浏览器（网站）上运行的Web服务，或者是围绕WebKit封装此类代码的应用程序。
卢移动 - 由谷歌制造所以它应该是好的 - 但基于Ruby（我们是不舒服），并确实有复杂和相当脆弱的开发环境。
的PhoneGap - 这似乎很容易，大多基于JavaScript - 它是开源的，但由Adobe最近收购 - （不是一个好兆头）
Appcelerator的 - 任何从Javascript到PHP和python，有一个很好的API访问范围，但我们听到了很多拒绝（苹果）的故事，以及在不同平台上使用复杂代码时的不兼容问题。
更像MoSync，Sencha，Appmobi和Corona（没有亲自测试过）。

参考几点：

我们不是在游戏开发计划，我们正计划开发的应用是在商业应用&信息工具的境界。
应用并不依赖于过度使用的设备API的（但确实需要一些小的基本接入）
该公司已经为iOS开发的，我们有一个小团队的原生iOS开发（Objective-的ç怪才）
我们想确保我们能继续发展我们的特色应用程序，而他们得到打破，由于新的操作系统或API
这将有利于确保前手了应用程序不会由于跨平台代码（主要是AppStore）而被拒绝
与任何公司一样，我们希望尽可能具有成本效益 - 另一方面，我们坚持高质量的产品和顶级的用户经验。

没有比StackOverflow更好的问这个问题的地方，我很感谢来自有此主题经验的开发者的任何意见。

来源

2012-01-14 Oliver Blint

你的问题具体是什么？ “任何评论”都不适用于SO的问题/回答格式。我发现你在这里是新来的，所以请阅读[常见问题]（http://stackoverflow.com/faq#dontask）：“开放式问题会降低我们网站的实用性，并推迟其他问题页。” – Caleb 2012-01-14 21:59:55

应用程序市场上有500多个应用程序，竞争非常激烈。拥有出色的UX和图形是最重要的。

跨平台工具与本地开发不相称。如果他们是，我们都会使用它们。但我们不是。有一个原因 - 你没有完全控制。而完全控制是必要的，有非常好看的应用程序。

如果您的应用程序是不是消费者应用程序，但一个企业应用程序，其使用是由一些内部部门决定的，那么你可能与马马虎虎的设计获得通过，因为这些应用程序的价值在于它的功能。但是，如果你对移动应用程序市场非常认真 - 那么唯一的办法就是去本土。你需要一个全职的UX小伙子和一个设计师（谁知道移动开发）。你会花费超过50％的时间在外观上。我现在参与的这个项目花费了80％以上的时间（图形，动画，用户体验，可用性测试）。

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

来源

2012-01-14 21:47:36

+1服务良好。 – Till 2012-01-14 22:11:32

好信息....谢谢你非常多 – Aamirkhan 2012-08-08 12:02:42

虽然我与@Peter Knego完全一致的时候，我要补充几个小点的团队寻找支持多种平台：

正如彼得指出，UX是巨大的，跨平台UX是最不常见的UX。很难将这些东西做成所需的一切，而无需在背后绑手。真正梦幻般的网络应用程序的判断能力来自关闭本地体验，而不是相反。
产品的许多部分不是UX。仔细考虑你可以到达那里的重用。例如，我经常建议拥有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应用一样。

如果你不关心什么是“某件事”，那么高度跨平台的方法是获得“某种东西”的一种便宜方法。他们是一个非常昂贵的方式来获得伟大的东西。

来源

2012-01-14 23:14:28

+1伟大的职位。我喜欢没有正确方式的评论。精益，把它放在人们的脑海中，然后迭代。 – 2012-01-14 23:51:02

我在AppMobi工作，我只是做一些评论。

你的应用程序不应该因为使用本地webview跨平台而被拒绝。我们还没有让Apple在任何AppMobi提交的应用程序上使用它。
Rhombile不是“由google制造”。事实上，谷歌收购它甚至不是摩托罗拉的一部分，这是他们的业务部门。他们正在推进HTML5/Javascript，但目前是Ruby。
Appcelerator开始支持webview，然后回溯。他们只是筹集了大量资金返回到webview suppport。

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

来源

2012-01-16 14:44:32

我想指出的是，如果facebook的应用出现问题，因为它在HTML 5上投入太多，几周后他们将应用变更为原生应用，速度提高了200％，评论更好，Mark扎克伯格承认，对HTML 5投注太多是个问题。简单地说，原生将永远更快+为显而易见的原因提供更多的控制。 – 2012-09-19 21:34:20

不，Facebook有问题，因为他们在实施他们的应用程序时做了一件糟糕的工作。http://news.ycombinator.com/item?id=4507879有一个非常好的讨论。 – 2012-09-20 14:45:11

这是两者的结合，确实不是所有的HTML 5，但仍然原生将始终比HTML 5更快，仅仅是因为Apple和Android都不会优化他们的移动浏览器来关闭违规（甚至是本地仍然会更快），他们不会那样做，因为他们希望人们使用他们的应用程序商店。更不用说使用objective-c比HTML5更具可持续性/可扩展性，并且IDE也更好，在objective-c和HTML 5中编码的速度也可以更快。事实上，单一平台概念永远落后。 – 2012-09-20 15:53:49

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

回答

相关问题