Appcelerator vs Android SDK [英] Appcelerator vs Android SDK
问题描述
我一直在看 appcelerator，它看起来还不错！毫无疑问，appcelerator 的优势之一是它对多平台的支持.我有兴趣构建一个 android 应用程序，以后可能还会构建一个 iphone 应用程序.所以目前支持多平台并不重要.
I have been looking at appcelerator it seems pretty fine! Without a doubt, one of the advantages of appcelerator is its support for multi-platform. I am interested in building an android app and maybe a iphone app later on. So it is not crucial to support multiple platforms at the moment.
如果你不考虑支持多平台而只专注于安卓开发.appcelerator还有优势吗?它是否缺少Android sdk"的任何功能?
If you disregard supporting multiple platforms and just focus on android development. Is appcelerator still advantageous? Does it lack any features of "Android sdk"?
(当我说Andorid sdk"时，我的意思是使用 Eclipse 和原生 Android sdk 进行开发，如果有任何意义的话)
推荐答案
我们在启动 Android 项目时查看了 Appcelerator.我们知道接下来我们必须做一个 iOS 客户端，所以 Appcelerator 很有吸引力.
We looked at Appcelerator when starting our Android project. We knew we would have to do an iOS client next, so Appcelerator was enticing.
我们决定不走这条路，因为它不支持每台设备的所有本机功能.
We decided not to go that route because it doesn't support all the native features of each device.
例如，我们很早就决定我们的 Android 用户界面需要一个小部件.Appcelerator 不支持它，因为它特定于 Android.[这是几个月前的 - 你可能想再次检查].
For example, we decided early on that our user interface in Android would need a widget. No support for that in Appcelerator, as it's specific to Android. [This was a few months back -you may want to check again].
在用户界面上妥协对我们来说太过分了.我们决定使用 C/C++ 来处理应用逻辑，并使用 Android SDK 来处理用户界面.
Compromising on the user interface was too much for us. We decided to go with C/C++ for the app logic and use Android SDK for the user interface.
我们的应用现在有两个部分:C/C++ 尽可能多的大脑"和原生(Android/Cocoa Touch)用于 UI，以利用 UI 体验.
Our apps now have two pieces: C/C++ as much as possible to the "brains" and the native (Android/Cocoa Touch) for the UI to take advantage of the UI experience.
当然适用于可以集成 C/C++ 的平台.
Works of course for platforms that can integrate C/C++.
分手建议:首先设计你的用户界面，然后找到一个可以实现它的工具.用户对便携式设备中的 UI 有很高的期望.尽早妥协可能是您项目的关键因素.
The parting advice: design your user interface first, then find a tool that can implement it. Users have high expectations of the UI in portable devices. Compromising on it early on may be the KOD for your project.
每隔一段时间我就会看到有人对这个问题点赞.我想更新一下我们在过去两年中学到的东西:
Every so often I see an upvote for this question. I would like to update with what we learned in the past two years:
- 将 C/C++ 用于我们应用程序的公共部分已经获得了回报.它确实需要稍微复杂一些的构建过程，但如果共享的代码片段很复杂(如我们的例子)，则节省的成本是巨大的.
- 对于用户界面部分，我们开始研究混合应用(一些 HTML 中的 UI 元素).关于 HTML 界面仍然存在争论(Facebook 和 LinkedIn 是两个转向 UI 原生代码的)，但也有一些报告称，如果仔细选择它可以工作.Flipoard 对此进行了精彩的演讲；使用幻灯片这里.
- Using C/C++ for the common parts of our application has paid off. It does require a slightly more complicated build process, but the savings are gigantic if the piece of code being shared is complex (as in our case).
- For the user interface piece we are beginning to look into hybrid apps (some UI elements in HTML). There are still debates out there about HTML interfaces (Facebook and LinkedIn are two that move to native code for the UI), but also some reports that when chosen carefully it works. There is a great talk from Flipoard on that; with slides here.
2014 年 10 月更新
UPDATE Oct/2014
在 2014 年 3 月，Smashing Magazine 发表了一篇优秀文章，比较了原生 iOS、原生 Android、PhongeGap (Cordova) 和 Appcelerator Titanium.它们展示了在每个环境中开发一个简单的应用程序.
In March/2014 Smashing Magazine published an excellent article comparing native iOS, native Android, PhongeGap (Cordova) and Appcelerator Titanium. They show the development of a simple app in each environment.
这是本系列的最后一部分.在这部分的顶部有指向本系列前几部分的链接，在底部有方法的比较.最后还有读者的有趣评论.
This is the last part of the series. At the top of this part there are links to the previous parts of the series and at the bottom there is the comparison of the approaches. There are also interesting comments from readers at the end.
2015 年 5 月更新
UPDATE May/2015
仍然时不时地为这个问题点赞，所以我想分享自从我写下答案的第一部分以来我们做了什么.
Still get an upvote for this question every so often, so I would like to share what we have done since I wrote the first part of the answer.
我们现在正在开发一个也有网络客户端的项目.我们现在有 iOS 客户端、Android 客户端和 Web 客户端.
We are now working on a project that also has a web client. We have now the iOS client, the Android client, plus the web client.
JavaScript 是 Web 客户端的自然选择.
JavaScript is the natural choice for the web client.
由于我们希望在这些客户端之间共享尽可能多的代码(在业务逻辑层)，这意味着我们需要找到一种在 iOS 和 Android 中运行 JavaScript 代码的方法.
Since we want to share as much code (at the business logic layer) across these clients, it means we need to find a way to run the JavaScript code in iOS and Android.
这就是我们最终要做的.
And that's what we ended up doing.
这是我们如何处理它的摘要:
This is a summary of how we handle it:
- 对于所有客户端:所有数据结构均使用 Google 的 protobuf 定义.这允许为 iOS 和 Android 自动生成序列化/反序列化代码.
- iOS:在 JavaScriptCore 的帮助下运行 JavaScript 代码(一个很好的概述 这里).
- Android:在 Google V8 引擎的帮助下运行 JavaScript 代码.
- For all clients: all data structures are defined with Google's protobuf. This allows to automatically generate the serialization/deserialization code for iOS and Android.
- iOS: run the JavaScript code with the help of JavaScriptCore (a good overview here).
- Android: run the JavaScript code with the help of Google's V8 engine.
JavaScript 和 iOS/Android 层之间的桥梁可能是一个瓶颈，尤其是对象的序列化.我们必须优化一些事情并吸取一些教训才能避免麻烦.
The bridge between JavaScript and the iOS/Android layer can be a bottleneck, especially the serialization of the objects. We had to optimize a few things and learned a few lessons to stay out of trouble.
总的来说，体验是积极的.通过在所有客户之间共享代码，我们节省了大量时间.
Generally the experience has been positive. We saved significant amount of time by sharing the code across all clients.
如果我不得不开始另一个这样的项目(需要与网络和移动客户端共享代码)，我也会看看 Google 为收件箱做了什么.我们开始的时候还没有.看起来很有希望.
If I had to start another project like this one (that requires sharing code with web and mobile clients), I would also take a look at what Google did for inbox. It wasn't available when we started. Looks promising.
2015 年 8 月更新
UPDATE August/2015
世界一直在转动......
And the world keeps turning...
如果我不得不开始一个新的，我也会好好看看 React Native立即使用移动应用.
I would also take a good look at React Native if I had to start a new mobile app now.
它基于 JavaScript，可以更轻松地连接网络和移动开发.
It's based on JavaScript, bridging web and mobile development more easily.
Ray Wenderlich 的网站上有一个很棒的教程.
There is a great tutorial in Ray Wenderlich's site.
2016 年 2 月更新
UPDATE February 2016
我的跨平台开发候选名单有两个:
My shortlist for cross-platform development is down to two:
我一直更加关注 ionic 因为我们的网络应用程序使用 AngularJS，所以 ionic (Cordova + AngularJS).React Native 将迫使团队学习另一个框架(当然，如果你的网络应用使用 React).
I've been paying more attention to ionic because our web app uses AngularJS and so does ionic (Cordova + AngularJS). React Native will force the team to learn another framework (of course the argument is the opposite if your web app uses React).
尽管如此，我还是会认真考虑 React Native，甚至必须学习另一个框架，因为所报告的应用程序的性能和外观.来自 React Native 的网站:
Nevertheless, I'd seriously consider React Native, even having to learn another framework, because of the reported performance and look-and-feel of the app. From React Native's site:
使用 React Native，您可以使用标准平台组件，例如作为 iOS 上的 UITabBar 和 Android 上的 Drawer
With React Native, you can use the standard platform components such as UITabBar on iOS and Drawer on Android
如果您现在开始，我建议您至少花时间完成他们的教程，以便更好地了解每个框架.每个教程可以在一到两个小时内完成:
If you are starting now, I recommend you take the time to at a minimum complete their tutorials so you get a better feeling of each framework. Each tutorial can be complete in one to two hours:
对于更简单的方法:Smashing Magazine 刚刚出版(在我撰写此更新时)一篇好文章 展示了如何使用本机导航元素使应用程序感觉(嗯……)本机，同时使用 Web 视图呈现内容.这篇文章详细介绍了如何使 HTML/CSS 在移动设备中可用(不仅仅是推送您已有的 HTML/CSS).
For a simpler approach: Smashing Magazine just published (at the time I wrote this update) a good article showing how to use the native navigation elements to make the app feel (well...) native, while using web views to render the content. The article goes into the details of how to make the HTML/CSS usable in the mobile devices (it's not just pushing the HTML/CSS you already have).
这篇关于Appcelerator vs Android SDK的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
