在 2016 年学 Android 是一种什么样的体验？

最新推荐文章于 2021-05-12 17:27:41 发布

Hunter-狩猎者

最新推荐文章于 2021-05-12 17:27:41 发布

阅读量762

点赞数

转眼间 2016 年的电量已不足 20%，不禁感慨 How Time Flies！不知不觉 Android 移动开发已经走过了八年的光阴，在这八年的时间中，Android 开发从最初的简单调用系统 API，到各类框架的不断涌现，再到如今的成熟阶段，那么作为一个想在 2016 年开始学习 Android 或者重新开始学习 Android 的开发者来说，你将看到一幅什么样的光景呢？

首先你会发现最新的 Android 系统版本已经是 7.0，作为大版本肯定存在很多变化和改进，开发者需要持续跟进这些变化，例如 Android 7.0 删除了三个隐式广播，优化内存使用和优化电量消耗。再往前一个版本，Android 6.0 重新设计了权限系统，一系列的权限不再简单的在 AndroidManifest.xml 文件中声明就可以使用，而是要动态申请。再往前一个版本，Android 5.0 引入了 Material Design，从此 Android 有了自己特有的设计语言和规范。

从集成开发环境和构建工具上面看，一两年前还在苟延残喘的 eclipse＋ant 基本绝迹了，取而代之的是流行的 Android Studio ＋Gradle，截至本文发稿前，Android Studio 刚刚发布了 2.2.2 版本，对应的 Gradle 版本为 2.14.1 版本。谈到 Android 的构建，除了 Gradle，你也可以尝试 Facebook 的 Buck，虽然它的配置侵入性很强，但构建速度是比 Gradle 快很多的，当然，如果使用最新的 Android Studio＋Gradle，我们可以开启 Instant Run 模式，从而达到快速的重新构建。

著名的 Support Library 已经更新到 25.0.0，其中 support-v4 库从 24.2.0 版本开始就拆分成 5 个子库，开发者可以更灵活的引用它。

什么？你还在使用 ListView，GridView？是时候使用 RecyclerView 进行替换了，同时别忘了使用 Support Library 24.2.0 开始引入的 DiffUtil 来高效更新 RecyclerView。

从搭建应用的UI架构开始，我们不再考虑 MVC 模式，取而代之以 MVP 或者 MVVM 模式，Android 官方虽然对于 MVP 模式没有统一的标准，但还是提供了一系列使用例子供开发者作为实现参考。

至于 MVVM 模式，Android 官方提供了一个名为 DataBinding 函数库作为标准实现，相信后面会越来越多开发者在项目中引入。

如果你已经厌倦了使用 Java 来编写 Android 应用，没有关系，你可以尝试下 Kotlin，它可以比作 Android 世界的 Swift，目前已经发布了 1.0.4 版本，支持多种现代的编程特性，例如函数式编程。同时 100% 支持和 Java 的混合编程，具有 Java 编程基础的开发者很容易上手。

如果你也不喜欢 Kotlin，但熟悉 Javascript 语言，那么推荐你试用下今年非常火爆的 React Native，它不仅可以使用 Javascript 语言编写 Android 应用，而且可以编写 iOS 应用，而且代码复用高达 80% 左右，同时，新功能的上线不再需要往应用市场提交新的 APK 包，而是支持在线热更新。当然，React Native 写出来的界面是 Native 的体验，不是 H5 的体验。

提起 React Native，我们不得不提到它的竞争者 Weex，Weex 的基本原理和 React Native 一致，也是使用 Javascript 语言编写 Android 和 iOS 应用，不同的是，React Native 是基于 React 框架，Weex 是基于 Vue 框架。当然，目前看来，React Native 的势头是盖过 Weex 的。

前面我们提到过 Kotlin 支持函数式编程，我的意思当然不是说使用 Java 语言就不能支持函数式的开发，但是就目前 Android 支持的 Java 版本，要支持函数式编程我们需要引入一个知名的函数库 RxJava，这是一个函数响应式编程框架,采用观察者设计模式，最直观的，它能让你的代码避免回调地狱的出现，使得代码数据流向非常清晰，在 Android 中使用 RxJava，还需要引入 RxAndroid 作为桥接，当然，还存在 RxBus，RxBinding 等等扩展函数库。

说起这两年 Android 开发的变化，你会发现热修复框架的如春笋般涌现，你之前可能知道 Dexposed，AndFix，Nuwa 等，但最近几个月出现的新美大 Robust，微信的 Tinker，手机 QQ 的 QFix 等方案你是否了解和对比过？

我们知道热修复是用来在线修复严重性的 bug，那么 Android Native 代码如何实现功能模块的在线更新呢？这就需要涉及插件化框架的概念了。Android 平台的插件化框架也是存在多种方案，各有优劣。常见的携程的 DynamicAPK，360 的 DroidPlugin，iReader 的 ZeusPlugin 以及 Small 等。另外，插件化也是解决 64K 问题的一大利器。

另外一个和热修复容易混淆的概念是应用的增量更新，增量更新的意思是应用在自动更新时下载的 APK 不是全量的，而是一个差分包，下载完成合并后再进行安装，可以看到，热修复和增量更新最大的区别是应用更新后是否需要重新安装。

上面说到的热修复，插件化更新，增量更新，都依赖于应用启动后去服务端下载对应的更新包，那么如果应用启动时去读取本地缓存或者数据库等数据，由于文件损坏或者数据格式不正确，可能会导致应用启动必然闪退，因此，我们还需要引入启动保护机制来清除缓存数据从而保证应用可以正常启动。

对了，应用底层基础函数库也发生了很大变化，网络通信库 android-async-http 已不再是流行，OkHttp＋Retrofit 是主流的选择，图片加载和缓存框架 Android-Universal-Image-Loader 也已经落伍了，Glide，Fresco 等是更优的选择。其他流行的底层函数库还有依赖注入框架 Dagger2，事件总线框架 EventBus，数据库 ORM 框架 greenDAO，就连日志记录函数库也涌现了不少，其中以 Timber，Hugo，logger 最有代表性。

2017 年还将会有哪些新技术或者新的变化出现呢？让我们拭目以待吧！