Android 开发的昨天、今天和明天

收到过位将要毕业的同学的来信，问 Android 开发是否有「前途」。我个人从前端转到移动相关的工作也有些时日，虽然期间有点心得但回复类似的问题不免会有「误人子弟」的担忧。

刚好在 Android Weekly 上见到了这篇文章，阐述的部分观点竟然和我不谋而合，因此草译下权当有相关问题的同学作为参考。同时，国内的 Android 环境可以用「奇葩」来形容，因此文章后面我会加入些自己的个人观点。

混沌之初

很难相信，如此的一个系统竟然会有 80% 的市场占有量！在我个人看来，Android 能够做到如此成功在早期并不是它足够的优秀，而是同期的竞争对手做得比它更好。

为什么？我亲爱的读者，在那个时候到处都是问题好吗：

糟糕的开发工具（甚至包括 IDE）

你尝试过用铁锹修车吗？或者，开着你爷爷曾经使用过的有着 40 年历史的 Yugo 载着姑娘去兜风？在那个时代 Android 开发有且只有一个「相对」官方的开发工具：Eclipse 。

请您相信我，Eclipse 有各种的问题甚至能让你在十分钟之内发疯！Eclipse 的 ADT 插件简直就是 「Bug 与 Crash 齐飞，重启和关闭共一色」 。尤其在相对复杂的项目开发上，那酸爽简直不敢相信！

很大的程度上，光就是 Eclipse 这个开发工具就吓到了很多入门开发者，让他们投入其他开发阵营的怀抱（对，例如 XCode）。

碎片化

Android 的碎片化严重得可以用张麻子脸上的痘痘来形容，我们先来说说软件方面的。Gingerbread (2.3.7) 是相对比较老的系统版本了，对比同期的 iOS 4.x 系列，目前还有百分之 15-20 个点（可能具体地区的占有率稍有不同）。

您或许已经知道，Android 4.0(Ice Cream Sandwich) 是一个巨大革新的版本，新的 UI、新的 API、新的屏幕分辨率，这一切看起来非常的美好。但，缓慢的用户迁移过程让我们不得不面对这些优秀新系统特性的同时，同时还需要兼容那老旧的系统。于是为了兼容新老的两套系统，项目开发中多了非常多的兼容代码，这会使得应用到处是 Bug 和奔溃。

（这段译者自己添加，吐槽我最擅长了。）除了软件方面，硬件的碎片化的问题更加的严重。你甚至不了解你的应用会在什么样的硬件上运行，你需要获取用户的位置信息，对不起设备可能没有 GPS 甚至没有基站定位；你需要打开摄像头扫描二维码，对不起设备可能没有摄像头、即便有摄像头但运行内存不够，崩溃！这个时候用户是嫌弃自己的硬件呢，还是说您的应用有问题…

硬件方面最头疼的还是屏幕分辨率的问题，Android 开发过程中在资源（resource）目录下有各种的目录（drawable-xxhdpi、drawable-xhdpi、drawable-mhdpi、etc…），你需要针对不同的分辨率调整自己的资源文件，对相信我这块有时候会比编码的时间还长！

缓慢的模拟器

当你完成一个应用以后，首先要测试在各个不同 Android 版本以及屏幕分辨率下的运行情况，所以我们购置了不下二十台 Android 设备用于测试。

听起来似乎有点夸张？好吧，感谢上帝我们还有 Android 模拟器！

然后，你兴冲冲的跑去建立 Android 模拟器并尝试让它跑起来，你会发现半小时后你会哭！先不说它那缓慢的运行速度，就连调试过程中你甚至会开始思考你的人生。

从此以后你再也没有勇气打开运行过它，它只是成为你机子文件系统中一块占用地方的文件而已。

UI

「设计 Android 应用是多么得无趣！」如果你对比过同期的 iOS 应用，那么 Android 的应用竟然会如此得暗淡无色。对比 iOS 那流畅的动画、交互以及细节，你会觉得 Android 应用一切都是「静止」的！

当你打算给 Android 添加点生气的时候，你会发现还是那些老旧的系统（例如 Gingerbread）囚禁了你的创意和思想、乃至期望。

全新

我们将时间推倒 2013 年，这些糟糕的事情总算有了一些改变。

那个时候问题已经足够糟糕到连 Google 自己都看不下去的程度，即便 Android 4.0 发布至今对于上面的问题稍微有些缓解，但还不足够达到能够彻底解决问题的程度。

直到 Android 5.0(Lollipop) 的发布。

所有人都在思考 - Google、设备提供商、开发者。所有人都会自问这样的问题，就是「当我们有了个相对稳定的系统、上千万的应用以及对应的用户。那么我们应当如何让 Android 这个巨无霸化繁为简？如何将开发的过程变得优雅、吸引更多的人加入这个行列？」

Android 5.0(Lollipop) 有着巨大得改变，那些非常多的特性出于篇幅的考虑我只能列出我个人认为重要的几个点：

Android Studio

Android Studio 在 1.0 版本以后就变得非常的稳定。我无法从只言片语来描述这个应用能够给我们带来的巨大的变革。如果您愿意了解详细信息，可以参看原先我写的两篇文章（这里和这里）。

Android 开发的昨天、今天和明天

这个 IDE 是如此的优秀，以至于 Eclipse ADT 插件已经停止了官方的维护，因此严重推荐原先如果开发 Android 的同学迁移到这个 IDE 上。

人生苦短、及时行乐。

Gradle

Gradle 是个全自动化的构建工具，在 Android Studio 已经全面替代了 Apache Ant 作为主要的构建系统。

这个全新的系统将会给构建 Android 应用带来全新的体验（听着耳熟？）。当您设置好构建配置脚本以后，所有剩下的事情都将不用你操心。

译者注：Gradle 在大陆使用建议还是需要挂代理，Sigh…

Lollipop

Google 说过 Lollipop 是有史以来变革最大的系统版本（每次它都这样说），我希望他们是对的。

同时，也希望目前的主流机型能够升级到这个版本（译者：个人觉得原文作者有些乐观）。

Lollipop 之外 - Material Design

理所当然，作为 Lollipop 提出的重点之一，自然会有很多的笔墨来阐述 Material Design 这个新的设计理念。我个人非常同意 Material Design 的其中之一的理念，那就是「所有的东西都是重要的(everything is important)」。

Android 开发的昨天、今天和明天

例如动画，长期以来我们的观点是动画只是效果的一部分，而 Material Design 主张动画也是有含义的，就好比文章分段的间隔符。

我们重新设计、重新开发符合 Material Design 的应用，最终的目的在于应用并不仅仅是生活的一部分，而是能像水和空气一样够让它融入到生活中的每处，让它无处不在。

这就为了以后即便在不同的平台下不同的应用看起来风格和体验也是统一的。

Lollipop 之内 - ART

对于 Material Design 提供的外在设计元素，我们开发人员最关注的还是其内在的改变。一个新的运行时（runtime system）称之为 ART 的就内在其中。

其实 ART 并不是新鲜事物，首次出现应该在 Android 4.4（Kitkat）中。我们之所以重新介绍它是因为在 Lollipop 中 ART 已经全面替代了 Dalvik 成为系统默认的运行时（runtime system）。

ART 有很多优秀的特性，处于篇幅考虑我只说明其中两点：

使用前置编译 AOT (ahead-of-time) 。这意味着 ART 模式下，代码被直接编译为机器指令，程序运行时直接执行机器指令。这能带来更快的执行速度以及更小的 CPU 损耗以及更长的电池时间，当然另一面就是安装时间可能会变长。
支持更多的方法数量（multidex support）。Dalvik 的每个 dex 字节文件只支持 65,356 个方法。这使得我们单个应用无法支持超过这个数量的方法数量。虽然这个数量看起来非常的庞大，但如果我们将例如 Google Play、以及其他的库加入到项目中，那么剩余我们能够使用的方法数量将会大大的减少，甚至不够用。ART 中将重新整理字节码文件分割到不同的 dex 文件中，同时再整合到单个 APK 安装文件中，从而避免了这个问题。

译注，针对这块下面有评论，可以参考

Note that ART still has the same 65k method limit. Multidex support applies to Dalvik as well. As an addition to the improvements you mentioned, I would add the unit testing support they just released with version 1.1.0 of AS. Hopefully it's a fresh start for better testing of Android apps out of the box. It also works great with Robolectric.

到处都是 Android

现在我们已经可以开始针对智能手表、电视、甚至汽车编写应用。想象下我们坐下来煮上一杯热咖啡，环顾四周将来可能至少有四五个设备运行着 Android 系统：电视、笔记本、平板、相机、乃至厨房电器。

Android 开始逐渐占领所有具有微处理器的设备，犹如水和空气一般得存在。

逐渐高品质的智能手机

Android 的核心平台还是其智能手机这块，但长期以来一直所受的困扰就是运行其系统的智能手机品质差次不齐。老的 Anroid 设备运行起来对比其同时代的 iPhone 设备显得非常的卡顿 - iOS 却依然流畅得多。这「得益于」那些国产厂商提供的众多低端机型。（译者注：原文 This was especially true for cheaper devices produced by a multitude of Chinese manufacturers. 华强北再次被黑）。

值得庆幸的是随着硬件设备的摩尔定律，目前的 Android 智能手机设备提供商正在逐渐的改变这一现状。很可能在不远的将来，我们能够得到一台性能足够强大但同时性能不差的 Android 智能手机。

例如我个人非常喜欢 Motorola 提供的智能手机（虽然它目前已经是 Lenovo 的子公司），他们出品的 Moto X、Moto G、Moto E 等型号的手机都有着不俗的性价比。

Android 开发的昨天、今天和明天

同时有个叫 Ara 的项目能够提供类似 PC 的模块化硬件解决和组装方案，在未来相信 Android 智能手机硬件平台这块能够得到非常乐观的发展。

下一步？

远离 Java

当解决完系统和开发工具层面的问题以后，我们继续将 Android 相关的问题聚集到其他地方。

恕我直言，我认为针对 Android 最核心的问题将会是 Java，尤其是 Java6 或者 Java7。Java 是门非常的好的语言，但有时候我们可以考虑跳出这个圈子去思考 - 我们或许针对 Android 开发需要门更新的语言。

作为对比的 Apple ，他们的 Swift 提供了更新以及更现代的特性。这使得它能够支持 iOS 开发人员更便捷的开发应用。明显，Java 在这方面比现代的语言臃肿些。

是时候我们需要更新鲜点的内容了，目前其实已经有了针对 Java 的替代方案，例如我原先关注的 Groovy 。它从语法方面和 Java 很接近（实际上它之于 Java），同时我们针对此开发已经有了些原型。当然，还有别忘记了它是 Gradle 的主要实现语言 - 所以为什么不直接用于 Android 开发呢？

同时，Scala （使用数增长迅速）以及 Kotlin （这里有篇文章或许能让你热血澎湃）也是非常好的考虑对象。

更好的数据管理

还有个必须指出的问题，就是数据管理 API（database management API）。如果你有对比，例如 iOS（严格上说应该是 Core Data），他们提供了众多非常好的抽象方法（method）、图形化的数据管理、对象、数据观察者（database change listeners）等。对比 Android 提供的 API，这简直就像是只土鳖 - 我们仍然在写 SQL 语句并同时期望得到正确的结果。

调试 SQL 语句是件非常不容易的事情，首先需要面对的问题就是我们没有个直观的图形化界面去跟踪这些事务。虽然目前已经有些很优秀的 ORM 类库供我们使用（例如 GreenDAO 、 ActiveAndroid 、或者 SugarORM ），但实际上他们仍然各自有各自的问题。

我还是期待能够像 iOS 一样操作数据库，例如有个数据观察者（database change listeners）等类似工具帮忙。目前能够找到的就类似 DBFlow 等第三方的类库，至少目前而言他们能减少和减轻我很多工作量。