标签：
现如今，拥有着 80% 的市场份额的 Android 是最主流的手机操作系统。它运行在无数的智能手机、平板以及其他各种各样的设备上。仅凭这一点，我们是否可以认为 Android 编程是简单而轻松的呢？
几年前，Miley Cyrus 还在唱着乡村音乐，Justin Bieber 还梳着他那著名的“Bieber”发型，Malcolm 还在 AC/DC 乐队，而同时 Android 开发还相当复杂。Android 开发者对于Android 系统开发最简单的应用都有一大堆问题。
为什么？嗯，亲爱的读者，问题出在各种地方：
漏洞层出的IDE：你有没有试过用一把铲子去修理你的汽车？或者你开着你爷爷的40年前的 Yugo 汽车去把妹？在Android世界中，对于 Android 开发，我们有一个官方 IDE——Eclipse，它有一大堆问题，在10分钟之内保证让你抓狂。Eclipse ADT 插件对于更多的复杂工程来说也是充满漏洞、缓慢而不友好的。我们对此非常恶心，祈祷能发生奇迹来改善这一切。
系统分裂：Gingerbread (2.3.7)在 Android 系统版本中占据着相当大的市场份额（至少15-20%）。正如你已知道的，Android 正通过4.0版本（Ice Cream Sandwich）经历着复杂的翻修过程。系统有了新的用户界面元素、新的设备硬件API、新的屏幕密度等等，这就导致了我们必须小心地优化和编写我们的应用来使得在新版本Android和旧版本 Android 都能运行良好。所有的这一切都极大地影响了我们的开发进程和导致了更多的 bug 和 crash，以至于延长了开发时间。
缓慢的仿真器：我们需要在不同的 Android 系统版本和屏幕尺寸测试我们的应用，所以我们必须买至少20种 Android 设备。听起来是不是很疯狂？好吧，我们能使用仿真器来解决。但是你曾有没有试过用默认的 Android 仿真器？它的缓慢让人痛不欲生，当你的应用正在被部署到你的仿真器的时候，你会让你自己去数办公楼前面停的车的数量来打发时间。
用户界面(UI)：Android 应用无聊死了。如果你亵渎看一眼 iOS 应用，你会看到这些应用充满了生活气息而且色彩缤纷。所有的事物都是活生生的，动作转换，从左到右、从右到左……而我们的应用是死的，如果我们想要提高我们的用户体验，老旧的Gingerbread 会很快抹杀我们的希望和憧憬。
但是这些都是2013的事了。
所有者一起都在去年发生了改变，改变发生的如此之快，以至于你很容易地失去对它们的追随脚步，然后问自己“这都是什么时候发生的？”更重要的是整个 Android 生态系统提高了很多——我们有了新的硬件（智能手表），新的软件（Gradle，Android Studio），新的系统（Android 5.0 Lollipop）。
每个人都对此有着贡献——Google、设备制造商、开发者。每个人都有相同的目标。问他们相同的这个问题：“OK。现在我们有稳定的系统，十亿计的应用和十亿计的用户——我们怎么才能进一步简化和提高 Android？我们怎么才能使得开发进程更好？”这就是 open access和 open source 原则展现的他们的潜力——每个人都可以做出改变、产生提高、创造新的事物的所在。
很难列出全部的变化，但我做了一个列表来列出其中（在我看来）最重要的变化：
我们最喜欢的Andorid 开发的 IDE 终于变成了稳定的1.0版本了。我不会谈论太多关于 AS 为什么对于开发进程来说是最好的相关细节，因为我们已经有两篇登出的博客覆盖了这一主题。我会说 Eclipse ADT 插件已经不被官方赞成使用，我也强烈建议你把所有的应用迁移到 Android Studio。向 Google 致敬！
Gradle 是工程自动化工具，它已经替代 Apche Ant 成为 Android 应用主要的构建系统。它在 Android 开发者中非常流行。因为我们通过它几乎可以自动化所有事情——从将我们的应用区分成不同风格、正确配置签名等等
因此，他变成了一系列的“管理”工具，我们用来定义和维持我们的工程设置。Gradle 也是测试自动化库和自动构建服务器大量增长的主要原因。测试自动化库和自动构建服务器又给 Android 系统带来了持续集成（CI）开发过程。但是不是一切都是那么令人乐观——Gradle也在执行速度上饱受批评。在复杂工程上面 Gradle 也真的很慢，但我们希望这个问题会在接下来的版本和发行中解决。
Google 说 Lollipop 是自人类诞生以来 Android 系统最大的提升，Google 说的没错。 Android 的每个部分都有相应的修改和提升，但是我们也尚未见到开发者对这些改变有怎样的反应。虽然将旧设备升级到 Lollipop 还有很多问题，但是我们期望这会在接下来的版本中解决。
对于这个叫作 Material Design 的金光闪闪的新 Android UI 有很多要写。这是最近几年Android 系统最重要创新点之一，它完全改变了我们应用的观感。我最喜欢 Material Design 的是它彻底改变了用户体验原则——一切都重要。即使是细小的细节也不能被忽略。我们必须对每个用户交互、点击、触摸等做出响应。因为，这正如 Google 所说的，这些动作都是有意义的。我们必须使用黑体、拥抱新的生动的色彩、每一步使用动画、大字体，简单地说，我们要给我们的应用以生命。Material Design 同样也完全符合 Android 生态系统，适应各种不同的屏幕尺寸。这也就是为什么我们的应用是相似的，但是在不同的平台有着不一样的外观。
每个人都在谈论设计、UI、UI 元素、动画、色彩······,但是我们是开发者，我们感兴趣的是外表之下的东西。而且，哇！！！这引擎真是美极了：ART，新的运行系统。为了记录，ART 并不是什么新东西—它被介绍为 Kitkat 上次要的运行系统。通过引入 Lollipop，它完全代替了 Dalvik，成为主系统。由于很多原因 ART 是伟大的，但我只提及其中两点：
一、它使用 AOT（ahead-of-time）编译，这意味着它把中间语言（Dalvik字节码）编译成系统二进制码。这就导致我们应用更短的执行时间、更少的 CPU 占用、更少的电池消耗。在另一方面，安装过程也就更长。
二、他提供 multidex 支持。Dalvik dex 文件有个重大缺陷—它们只能包含65，356种方法。我们必须组织好我们的 Android 应用以使方法不要超过这个限制。尽管这个数字可能看上去很大，但是如果你把 Google Play 服务（几乎每个应用都需要）算在内，再加上一些外部函数库，你就能轻易超过这个限制。ART 以一种突破了字节码以众多 dex 文件打包到一个单独的 APK 的方式组织你的应用。
我们开始给智能手表、电视、汽车开发应用，为什么要在此打住呢？如果你坐在你的房间，喝着了一杯热咖啡，花一两分钟看看你的周围。在接下去的这几年你也许会看到至少五样运行着 Android 系统的设备—电视、笔记本、平板、相机、自行车、厨房电器、恒温器、汽车等等。Android 开始作为一种试验，它被证明能够运行在任何一个拥有小型微处理器的事物上面。
智能手机还是Android 系统的核心设备。长期以来，智能手机的整体质量有问题。老旧的Android 设备比老旧的 iPhone 更丑更慢——iOS 通常感觉更流畅。对于那些被众多中国制造商们生产的廉价设备来说，这种感受尤其如此。
幸运地是，Android 智能手机的质量和速度稳步提升，所以今天我们有过多适合每个人的预算和需要的新设备。如果你想拥有一台手机，它有着很高的相机分辨率、优秀的设计、强大的处理器和电量，这不是个问题——我们都有。
我个人最喜欢的品牌是摩托罗拉，它的手机—Moto X、Moto G和Moto E 都有着优美的线条，同时也的确有着很好的性价比。而在同时，Google 的一个团队正力于模块化手机的开发。Project Ara 目标在于彻底动摇 Android 世界，如果一切进行顺利，它有可能会来到人们面前。
我们已经解决了 IDE 和系统版本的大多数问题，我们就可以关注 Android 其他方面的问题。
恕我直言，在 Android 开发最核心的问题中最重要的问题是 Java。对不起，Java Harmony，基于 Java 7 或 Java6，但它不是 Java。不要让我放错——我坚信Java是一门好的编程语言，但是我也认为我们是时候打破常规了。我们需要开始寻找另外一门编程语言来代替 Java 成为 Android 开发的基本语言。
看看我们最重要的竞争者—Apple。他们已经介绍了一门全新的语言，叫做 Swift，它结合了数个其他语言（如 Python、Ruby 或 C#）的最优特征。我们已经比 iOS 开发者开发同一应用需要更多的时间，而这会使我们更慢。
这就是为什么我们需要新事物的加入了。我们已经有了关于哪个语言能够代替Java的一些想法。我认为是 Groovy。它的语法与 Java 非常相似（实际上，它是基于 Java 的），我们也有一些工作原型了。同时，也不要忘了它是 Gradle 的主语言——所以，为什么不把它用于Android 开发呢？或者也许是 Scala（它可以很快获得新用户），又或者是 Kotlin（Jake Wharton 最近写了一篇很好的关于用于 Android 的 Kotlin 的概论）？
我要支出另一个问题—数据库管理 API。如果你再一次亵渎 Andoird，看一眼我们的竞争对手—iOS（核心数据，将更加精确）—你会看到他们确实有着优秀的方法和创建数据库对象的GUI 和 CRUD 方法，数据库变化监听器。但是如果你回头看下默认的 Android API ——我们还没有远离写那些极大地影响我们开发进程的 SQL 命令。
调试 SQL 错误不是一件容易的事—它非常消耗时间，我们也没有查看数据库数据的GUI。尽管也有一些不错的 ORM 库（如 GreenDAO、ActiveAndroid 或 SugarORM），但是它们都有自己的问题。我从没有对它们完全满意—他们要不是使用很复杂，要不就是丢失一些东西（如数据库改变监听器）。我注意到了 Realm for Android 和 DBFlow，我希望他们会解决我所有的问题并且减少执行时间。
Android 在过去的几年发生了巨大的改变。它已经从一个简单的智能手机系统进化为一个支持各种设备的强大系统。时间会告诉我们 Android 将会变成怎样。谁知道哪天我们会不会甚至可以用它来给核聚变反应堆编程，或者给”终结者“编程。PS. 显然终结者更有趣。
这是本人课余时间的翻译，错误很多，还请耐心指出，谢谢！
原文链接：https://www.infinum.co/the-capsized-eight/articles/the-past-present-and-future-of-android-development
标签：
原文地址：http://www.cnblogs.com/findwg/p/4491453.html
