在 Android 诞生的第十个年头, Android 手机应用的开发应该变得更加快捷. Google 也一直在聆听开发者的心声, 尽力的提高开发者在开发 Android 应用的效率. 在去年, 我们听到开发者说, Android 开发的生命周期管理很困难, 所以我们推出了 lifecycle 组件. 我们还听到, 当你对后台任务进行处理的时候, API 给你了 5-6 种不同的解决方法, 那么哪一种才是你最该使用的呢? 为了解决这些问题, Android JetPack 诞生了.
我们希望 JetPack 不仅能够提供各种功能的 API, 同时, 也希望给各位开发者在开发移动应用的时候可以有一个可以依照的蓝图.
Android JetPack 是什么以及其组成部分
什么是 Android JetPack?Android JetPack 是一套组件, 工具和架构指南, 我们将现有的 support library 和架构组件联系起来. 一会儿你们就将看到, 这些架构和组件, 都是你们非常熟悉和正在使用的.
Android JetPack 由四个部分组成, 分别是架构, 界面, 基础和行为, 每个部分的具体组成部分请查看下图
去年我们推出的架构组件, 在开发者心中获得一致好评, 架构组件的优点是, 你可以通过使用一个或者几个架构组件, 来解决你在开发过程中遇到的问题. 在去年的基础上, 今天我们又推出的新的架构组件, 分别是: WorkManager,Navigation,Paging.Paging 已经达到稳定版本, WorkManager 和 Navigation 还处在阿尔法的阶段.
JetPack 的第二部分是行为, 行为种的大部分组件包含了大家都非常熟悉的组件, 例如 Download Manager 可以进行大数据的下载, Media&Playback 和 Permissions 可以帮助大家在音视频的处理和获取权限, Notifications 是对推送的处理. 这些组件有一个通用的特点: 他们都是向后兼容的.
行为中, 我们还加入了一个新的组件: Slices.Slices 提供给应用的一个新的数据遍历的方式, 现在 Slices 已经在 Google Assistant 和 Google Search 中有所体现了.
JetPack 的下一个部分是界面, 其中包括 Fragment,Layout,Palette,Animation&Transitions, http://Auto.TV & Wear,Emoji 等部分. 我们希望界面部分不但能够让界面更加好看, 同时也希望能够给用户带来好的用户体验.
JetPack 的最后一个部分是基础, 就像他的名字的一样, 它是大家在应用开发过程中必不可少的一部分. 我们推出了 Kotlin Extensions(KTX), 通过利用 Kotlin 语言自身的特性, 例如: 扩展函数, 属性等, KTX 可以帮助大家更好的写出简洁的 Kotlin 代码. AppCompat 是大家都很熟悉的向后兼容库, 之前 v4 和 v7 在大家的开发过程中带来了不小的麻烦, 所以我们对它进行了封装, 推出了 androidx, 大家可以通过使用 Android Studio3.2 来使用 androidx
架构组件
去年, 我们推出了一套架构指南, 并且有一套组件来完成这个架构指南, 通过使用架构组件, 可以使你的应用变得更加模块化和易于测试和维护. 架构组件的宗旨是: 让 Android 开发更简单.
在去年的 GDD 上 , 我们想大家介绍来 4 个稳定版本的架构组件他们分别是: Lifecycles,LifeData,Room 以及 ViewModel. 就像下图中展示的, 界面组件负责显示 UI 界面, ViewModel 负责处理 UI 数据, 你可以使用 LiveData 来更新数据进而更新 UI 界面. Respository 是一个唯一的数据层结构, 你可以使用 Room 来进行数据持久化.
在这一基础上, 我们还推出来 Paging, 它可以帮你在 recyclerview 中更好的夹在分页数据. Paging 库已经达到的稳定版本.
接下来, 我们来看一下处理阿尔法阶段的两个库, Navigation. 当用户在使用你的应用时, 就像下图中的一样, 是你为用户设计来一个个的目的地. 并且引导用户在这些目的地中浏览. 我们为导航列出来这几个必须遵循的原则:
需要有一个共同的其实目的地
导航的状态需要一个栈来代表的 (后进先出)
系统和应用的向上和返回按钮因该为用户提供统一的体验
很好的支持 DeepLink
让我们来看一下 Deep Link 的例子 (如上图), 在这个应用程序当中, 从首页到类别到内容, 一步一步的到了这样的一个页面, 当然, 你的用户也可能通过一个 url 直接来到这个界面. 当你做为一个开发者, 为了给用户提供这样的一个一致可预测的体验, 你需要怎么做呢?, 你需要对回退栈做统一. 开发者在解决这个问题的时候, 要么是自己把导航库的逻辑自己完成了, 要么是自己写了很多代码去实现这个功能, 但是代码不易于维护. 并且是容易出错的.
Navigation 就是为了解决这样的问题出现的. Navigation 成功的解决了以下问题:
处理 Fragment Transactions
处理'向上'和'返回'
支持 Deep Link
提供动画, 跳转效果
Navigation 在 Android Studio 中提供了一个可视化的导航编辑界面, 这个可视化的界面是一个 xml 文件, 下图是一个 xml 文件的例子.
我们说, Acitivty 将会作为 Navigation 的一个切入点, 让 Fragment 成为内容的载体. Activity 只是负责一个全部的导航, 二中间的部分我们是交给一个 NavHost 托管的.
具体是实现导航跳转是使用 NavController 实现的, 为了获取 NavController 我们为大家提供了下面三个方法
如果你要通过一个按钮来跳转一个界面, 我们为大家提供来一个方便的方法 createNavigateOnClickListener, 如果你不想用这个方法, 我们还提供来另外一种方法来实现, 参照下图
关于 Navigation 的跳转动画, 你可以参考下图:
在导航的时候, 我们经常需要传递参数, 但传递参数我们经常需要考虑的一个问题是: 我们无法确保类型的安全. 所以 Navigation 提供来一个插件 Safe Args.
一个常见的 DeepLink 类型, 通常是一个通知, Shortcuts,Widget,Action 或者 Slices, 我们为这些 DeepLink 提供了一个方法叫做 NavDeepLinkBuilder. 关于 NavDeepLinkBuilder 的使用方法, 可以参考下图:
另外一些 DeepLink, 例如: URL 或者自定义的 Scheme URIs, 我们需要在 Navigation 图中加入 < deepLink > 标签
由于时间关系, 我们无法一一介绍 Navigation 的所有方法, 所以, 我们建议开发者在会后可以亲自体验一下 Navigation
WorkManager
在 Android 开发过程中的另外一部分对于用户来说是非常重要的, 但是也是我们看不见摸不着的, 那就是后台运行.
从最开始, 我们为大家提供了 Background Services,AlarmManager, 到 API 21 之后, 我们为大家提供了 Jobs, 对于使用 Google Play 服务的应用, 我们又提供了 Firebase Job Dispatcher 和 GcmNetWorkManager. 上图中显示了应用市场中各个 Android 系统的版本分布. 你为了覆盖市场上的这些机型, 你可能需要写一段很长的 if 和 else 代码来判断设备的情况, 来选择合理的 API.
说到来后台运行, 就不得不提设备电量的问题. 在使用 Background Services 的时候, 应用经常在后台自行运行, 从而造成设备电量快速消耗. 为了解决这个问题, Android 系统在最近的几个版本中陆续推出来减少设备电量消耗的功能, 详细情况请参考下图:
目前, 关于后台运行的 API, 我们选出以下下几个:
那么在上图中的几个 API 当中, 我们应该首选哪一个呢? 答案是 WorkManager.
WorkManager 是一个 API, 它简单到只需要一个 dowork() 这样的操作, 就可以很好的控制后台程序的运行. 同时, 它支持向后兼容. 无论你在应用中是否使用 Google Play 服务, 你都可以使用过 WorkManager.
举个例子, 例如我们要上传一张照片, 下图中是我在上传照片中使用的 WorkManager API
针对上传图片这个操作, 我们来看一看怎么写:
在这个任务里, 我们 override 的一个 doWork 方法, doWork 方法会在后台运行哦, 任务上传成功与否, 我们在 doWork 方法里返回.
在创建好一个任务之后, 我们还需要创建一个任务请求:
如果我们在上传图片的过程中没有网络怎么办? 这就需要我们在创建任务的时候添加一个约束条件:
怎样确定照片是否上传成功? 在这里我们可以使用 LiveData 来观察任务状态:
刚放给大家介绍来一个新的类叫 WorkStatus, 它又两个方法, 一个是 getId, 一个是 getState
如果我们想在上传照片之前先压缩, WorkManager 也提供来几个这样的方法, 你可以顺序的执行或者同步执行这样的几个任务.
首先, 我们先创建一个压缩任务, 在压缩任务之后再创建一个上传任务, 然后使用 beginWith 和 then 把刚才的两个任务依次加群进去, 就可以完成这个任务了.
如果说我想上传多张图片该怎么做呢? WorkManager 也为大家提供了一个方法来做这件事情, 大家可以依次调用 enqueue 这个方法, 把多个任务请求依次加入到这个方法中就可以了.
当我们需要选择一张图片来进行上传的时候, 需要输入一个 URI, 我们在进行这个任务的时候, 需要一个输入值, 在 WorkManager 中, 提供来一个 Data 用作这个输入值, 关于这个 Data 的相关介绍, 请看下图:
首先, 我们给我们的需要上传图片的 URL 一个做一个 bundle, 然后把它传入到我们的任务请求当中:
然后获取之前存入的参数, 进而获得需要压缩图片的图片地址, 然后把压缩图片的地址存起来:
我们把这两个任务串起来, 就是一个这样的 WorkManager 任务链:
怎样取消上传? 取消上传, 你可以使用 cancelWorkById, 但是我们不建议你使用 id 作为任务取消时的标签.
我们建议大家使用 Tags 来对你的任务进行标记:
然后, 我们使用 getStatusByTag 来获得 Tag 的任务或者取消任务.
在后台任务中, 还又一个非常重要的功能, 就是同步, 同步又一个特点, 就是我们不希望在同一个时间有多个同步任务.
为了实现这个的效果, 我们为大家提供了 UniqueWork 这个方法:
具体实现的原理如下:
目前 WorkManager 也处于阿尔法阶段, 欢迎大家在会后使用 WorkManager.
这里有一些关于 Androd JetPack,Navigation 和 WorkManager 的一些资源, 欢迎大家在会后进行访问.
谢谢大家!
我去推特粉一下这个小姐姐.
来源: https://juejin.im/post/5baa047c6fb9a05d330abf06