android - 为移动平台的易开发性和便携性而牺牲性能值得吗？

Question

所以我一直在为 iPhone 开发一个中型企业应用程序，我可能必须将其移植到 Android。我使用 native iOS SDK 编写应用程序，完全不关心可移植性。最初我对不得不用 Java 重新编写整个应用程序并维护两个代码库感到畏惧，所以我研究了一些跨平台选项。

我在两个跨平台应用程序和一个使用 native SDK 的应用程序中编写了一个简单的“hello world”，只是为了感受每个平台的性能和稳定性。这绝不是一个完全详尽的实验，只是快速而肮脏的测试。我惊讶地发现 PhoneGap 和 Appcelerator 的 Titanium 有一个非常明显的启动时间来显示“hello world”。此外，如果我关闭应用程序然后快速连续重新打开它(30-40 次快速迭代)，PhoneGap 和 Titanium 都会崩溃。另一端的 Native 应用程序从来没有出现过任何问题。

最初我认为我可以忍受较慢的启动时间，因为一个代码库可以控制所有启动时间。然后我遇到了以下潜在障碍:

1. 调试支持似乎有限。

   根据手机差距wiki建议您在桌面上调试 (1) (2) 使用远程 Web 检查器 (3) printf 调试 [你在开玩笑吗？] 或 (4) 使用 weinre

   Titanium 的调试稍微好一些，但仍然缺乏对设备调试的支持。有一个开放的request用于一年前的设备调试，因此将来可能会得到修复。

   对于只有少数开发人员的小型项目，调试可能不是问题，但随着项目变得越来越大，并且随着越来越多的开发人员使用相同的代码库，调试很快就会变得非常重要。

2. 您仍然需要为每个设备调整 UI。

   对于某些人来说，这可能是也可能不是问题，但我希望我们的应用程序看起来像 native 应用程序，并遵循每个平台的人机界面指南。所以我仍然会在 UI 层有重复的代码。

此时考虑到我必须为每台设备使用单独的 UI 代码，并且设备上的调试选项不像 native 应用程序那么丰富，我看不到跨平台开发框架能带来的节省.我认为最好的方法是用 C 重写我的模型，然后我可以在 Android(使用 NDK)和 iOS 之间共享该代码，每个设备都有自己的 native UI。

所以我的问题是，有人对跨平台移动框架有哪些经验？我对有限调试和重复 UI 代码的担心是没有根据的吗？请记住，我想要一个看起来像每个平台的 native 应用程序的应用程序。

对于那些使用过跨平台框架的人来说，这个项目有多大？你遇到了什么问题？您会再次使用该框架吗？

-肖恩

Answer 1

我经常使用 appcelerators titanium。我的总体感觉是IOS部分很好，但android仍然缺乏，特别是在错误消息方面，调试还不错，你所要做的就是添加一些打印输出，但问题是99%的android 上的错误类似于应用程序因 nullPointerException 崩溃而没有提示，因为它来自底层 java，至少可以说是棘手的。

但是我会说 UI 的东西不是问题，钛控制自动将应用程序缩放到不同的设备屏幕(当设置打开时 - 应该查看 1.7 中的这个)。因此，通常您遇到的唯一问题是特定于设备的问题，例如在 IOS 中有一个正确的导航按钮，没有 android 等效项，因此您必须为此编写一些特殊的代码，鉴于有 2 个不同的平台，这是可以理解的。

鉴于 IOS 已经完全开发，我不确定我会做什么，人们通常这样做是为了避免两个平台的学习曲线，并通过保持相同的代码库来节省时间，不确定你有多少好处会摆脱这个。 Appcelerator 很好，但控件存在错误，它会更慢并且需要时间来学习，但它确实有好处。

我个人不会使用 phonegap，因为我不喜欢它基本上是一个 webview 包装器的想法，而且我在桌面上遇到了足够多的基于浏览器的问题，足以让我终生受益。