胡凯

Android Jetpack - 使用WorkManager处理简单的后台任务

| Comments

时间来到2018年的当下,当我们讨论后台处理任务的时候,一般可能涉及的行为类型有下面一些类型,例如:

  • 发送程序运行日志
  • 上传图片和视频
  • 同步数据
  • 处理数据

这些行为都需要在后台进行操作,在Android平台上,我们可以利用如下的这些可选方式来实现后台任务:

google_io_2018_android_jetpack_workmanager_01

那么到底我们如何做出合理的选择呢?过去的几年,Android系统随着版本的更新针对电量优化这一块做出了不同程度的限制优化,例如在Android M上的Doze Mode,Android N上的Limit Implicit Broadcast,Android O上的Background Service Limitations以及最新的Android P上面的App Standby Buckets。为了确保后台任务对电量的消耗影响足够小,对待后台任务的处理要更加的慎重小心。

0)Types of Background Work

通常来说,我们可以把所有的后台任务按照任务紧迫性(是马上需要执行的任务/还是可以缓期执行的任务)和任务重要性(是确保一定要被执行的任务/还是最好能够执行的任务)进行四象限的划分。通常来说对于非确保一定要执行的任务,无论时间是否紧迫,我们都可以使用ThreadPool来完成这个任务。对于那些比较重要的又时间紧迫的任务,我们一般会使用Foreground Service来完成这个操作。比较有有意思的是最后一个象限:那些希望确保可以被执行但是又可以接受延期执行的任务。这些任务可以使用JobScheduler/JobDispatcher/AlarmManager/BroadcastReceivers来完成。WorkManager也刚好是用来解决这一类的问题的。

google_io_2018_android_jetpack_workmanager_02

Android相机开发 - 1)基础概览篇

| Comments

在Android平台上面实现自定义相机,根据业务的复杂度,涉及到的知识范畴大致如下,开篇优先描述下基础概览的部分:

android_dev_custom_camera_basic.jpeg

0)开始之前

在应用中开启Android设备的相机功能之前,应该考虑如下几个问题:

  • 必须的相机硬件 - 当然不能把一个包含相机功能的应用安装到一个连相机硬件都没有的设备上。因此,应该在mainfest文件中声明需要使用到相机。
  • 快速获取图片还是自定义相机 - 应用将如何使用相机?是想实现一个快速的抓拍功能还是录制一小段视频剪辑?还是说想提供一种全新的相机使用方式?如果是快速的获取一张抓拍图片或者是一小段视频剪辑,建议查看下面的3)使用已经存在的相机应用。如果是为了开发一个自定义的相机功能的应用,查看下面的4)创建自定义相机应用
  • 存储位置 - 生成的图片与视频是只对自己的应用可见还是其它相册Gallery类的应用也可以访问?即使自己的应用被卸载后也不能被其他应用访问吗?建议查看5)保存媒体文件

1)简要概述

Android framework通过提供Camera API来支持拍照与录制视频的功能。下面是相关的类:

Android性能优化典范 - 第6季

| Comments

android_perf_patterns_season_common

这里是Android性能优化典范第6季的课程学习笔记,从被@知会到有连载更新,这篇学习笔记就一直被惦记着,现在学习记录分享一下,请多多指教包涵!这次一共才6个小段落,涉及的内容主要有:程序启动时间性能优化的三个方面:优化activity的创建过程,优化application对象的启动过程,正确使用启动显屏达到优化程序启动性能的目的。另外还介绍了减少安装包大小的checklist以及如何使用VectorDrawable来减少安装包的大小。

1)App Launch time 101

提高程序的启动速度意义重大,很显然,启动时间越短,用户才越有耐心等待打开这个APP进行使用,反之启动时间越长,用户则越有可能来不及等到APP打开就已经切换到其他APP了。程序启动过程中的那些复杂错误的操作很可能导致严重的性能问题。Android系统会根据用户的操作行为调整程序的显示策略,用来提高程序的显示性能。例如,一旦用户点击桌面图标,Android系统会立即显示一个启动窗口,这个窗口会一直保持显示直到画面中的元素成功加载并绘制完第一帧。这种行为常见于程序的冷启动,或者程序的热启动场景(程序从后台被唤起或者从其他APP界面切换回来)。那么关键的问题是,用户很可能会因为从启动窗口到显示画面的过程耗时过长而感到厌烦,从而导致用户没有来得及等程序启动完毕就切换到其他APP了。更严重的是,如果启动时间过长,可能导致程序出现ANR。我们应该避免出现这两种糟糕的情况。

从技术角度来说,当用户点击桌面图标开始,系统会立即为这个APP创建独立的专属进程,然后显示启动窗口,直到APP在自己的进程里面完成了程序的创建以及主线程完成了Activity的初始化显示操作,再然后系统进程就会把启动窗口替换成APP的显示窗口。

android_perf_6_launch_time_start_process