Using a Thread Pool in Android

Android上使用线程池

In my last post Using HanderThread in Android, I showed how to offload short blocking tasks to a worker thread. While HandlerThread is good for tasks running in a sequential manner, there are cases where background tasks do not have dependencies on each other. To get these tasks done as quickly as possible, you might want to exploit the powerful multi-core processor on the mobile device and run the tasks concurrently on more than one worker thread.

A thread pool is a good fit for this scenario. Thread pool is a single FIFO task queue with a group of worker threads. The producers (E.g. the UI thread) sends tasks to the task queue. Whenever any worker threads in the thread pool become available, they remove the tasks from the front of the queue and start running them.

Comparing with starting a random number of individual worker threads, using a thread pool prevent the overhead of killing and recreating threads every time a worker thread is needed. It also gives you fine control over the number of threads and their lifecycle. E.g. ThreadPoolExecutor allows you to specify how many core threads, how many max threads the pool should create and the keep alive time for the idle threads.

Android supports Java’s Executor framework which offers the following classes for using a thread pool.

  • Executor: an interface which has a execute method. It is designed to decouple task submission from running.
  • Callable: An Interface similar to runnable but allow a result to be returned.
  • Future: Like a promise in JavaScript. It represents the result for an asynchronous task.
  • ExecutorService: an interface which extends Executor interface. It is used to manage threads in the threads pool.
  • ThreadPoolExecutor: a class that implements ExecutorService which gives fine control on the thread pool (Eg, core pool size, max pool size, keep alive time, etc.)
  • ScheduledThreadPoolExecutor: a class that extends ThreadPoolExecutor. It can schedule tasks after a given delay or periodically.
  • Executors: a class that offers factory and utility methods for the aforementioned classes.
  • ExecutorCompletionService: a class that arranges submitted task to be placed on a queue for accessing results.

Basic Thread Pool

The simplest way of creating a thread pool is to use one of the factory methods from Executors class.

newFixedThreadPool creates a thread pool with a a fixed number of thread in the pool specified by the user. The user can call setCorePoolSized(int) later to resize the thread pool.

newCachedThreadPool creates a new thread when there is a task in the queue. When there is no tasks in the queue for 60 seconds, the idle threads will be terminated.

newSingleThreadExecutor creates a thread pool with only one thread.

To add a task to the thread pool, call one of the following methods.

The second method returns a future object. It can be used to retrieve the result from the callable by calling future.get() or cancel the task by calling future.cancel(boolean mayInterruptIfRunning).

Advanced Thread Pool

If you want to have finer control over the thread pool, ThreadPoolExecutor class can be used. In the following example, I first find the available processors of the phone. The thread pool is configured to have core size as the NUMBER_OF_CORES, the maximum core size as the NUMBER_OF_CORES x 2, idle threads’ keep-alive time as 1 second, task queue as a LinkedBlockingQueue object and a custom thread factory.

Cancel Tasks

To stop the tasks in the task queue from execution, we just need to clear the task queue. To allow the running threads to be stopped, store all future objects in a list and call cancel on every object which is not done.

Handle Activity Lifecycle

One thing the thread pool framework does not handle is the Android activity lifecycle. If you want your thread pool to survive the activity lifecycle and reconnect to your activity after it is re-created (E.g. after an orientation change), it needs to be created and maintained outside the activity.

In my example, I made a static singleton class called CustomThreadPoolManager. It has a private constructor. It creates an instance of itself and return that single instance in the static getInstance method. It also holds a weak reference to the Activity. The reference is later used to communicate with the UI thread (see the next section).

In the Activity, get the thread pool singleton instance by calling the getInstance static method. Set the activity to the CustomThreadPoolManager. As CustomThreadPoolManager keeps the reference to the Activity as a weak reference, you don’t need to worry about leaking the Activity.

Communicate with UI Thread

When each task finishes, you may need to send some data back to the UI thread. A safe way of doing this is to send a message to the handler of the UI thread. First, extend Handler class and define what the UI thread should do when a message is received.

In the CustomThreadPoolManager, use the Activity’s weak reference to send the message to the UI thread.

In the CustomCallable, as it has reference to the CustomThreadPoolManager, it can send the message by calling CustomThreadPoolManager’s sendMessageToUiThread method.

Source Code

The full source code for the example used in this post is available on Github.

也可本站下载一份 代码拷贝

参考链接


Using a Thread Pool in Android

Activity singleInstance/singleTop启动模式的理解

Android有四种启动模式,分别是standard,singleTop,singleTask,singleInstance。下面分别简单的介绍下这四种启动模式的作用。

standard

Android 默认的一种启动模式。不需要为activity设置launchMode。这种启动模式简单的来说就是当你startActivity的时候,他就创建一个。

singleTop

这种模式模式从字面意思就能看得出来,就是当前的activity处于栈顶的时候,当你startActivity当前的activity的时候,它不会创建新的activity,而是会复用之前的activity。举个例子,startActivity了一个ActivityA,ActivityA又startActivity了ActivityB,当在ActivityB再次startActivity一个ActivityB的时候,它不会创建一个新的ActivityB,而是复用之前的ActivityB。
这里需要注意的是,只有当前的activity处于栈顶的时候才管用。举个例子:startActivity了一个ActivityA,ActivityA又startActivity了ActivityB,ActivityB又startActivity了ActivityA,那么ActivityA还是会重新创建,而不是复用之前的ActivityA。

singleTask

单一任务。意思就是说当前的activity只有一个实例,无论在任何地方startActivity出来这个activity,它都只存在一个实例。并且,它会将在他之上的所有activity都销毁。通常这个activity都是用来作为MainActivity。因为主页只需要存在一个,然后回到主页的时候可以将所有的activity都销毁起到退出应用的作用。举个例子,startActivity了一个ActivityA,ActivityA的启动模式为singleTask,那么在ActivityA里startActivity了一个ActivityB,在ActivityB里startActivity了一个ActivityC。此时在当前的任务栈中的顺序是,ActivityA->ActivityB->ActivityC。然后在ActivityC里重新startActivity了一个ActivityA,此时ActivityA会将存在于它之上的所有activity都销毁。所以此时任务栈中就只剩下ActivityA了。

singleInstance

这个模式才是重点,也是比较容易入坑的一种启动模式。字面上理解为单一实例。它具备所有singleTask的特点,唯一不同的是,它是存在于另一个任务栈中。上面的三种模式都存在于同一个任务栈中,而这种模式则是存在于另一个任务栈中。

注意事项

以往的理解中,只要在AndroidManifest.xml中声明singleTop或者singleInstance,那么在使用startActivity或者startActivityForResult的时候,自动就会保证singleInstance的情况下只有一个对象,singleTop的情况下不会两个相同的Activity叠加在一起。

但是现实是让人崩溃的。

使用如下的代码:

在两次触发startSingleTopActivity/startSingleInstanceActivity的时候,出现了两个叠加的Activity,如下:

可以看到出现两个单独的实例 Hist #2/Hist #1,而不是预期的忽略第二次调用。

在两次触发startSingleTopWithFlagsActivity/startSingleInstanceWithFlagsActivity的时候,只会出现了一个Activity,如下:

两者的区别就是

这句代码。

还是学艺不精啊。

完整例子代码,点击此处下载 MyApplication

参考链接


Java Calendar 获取上下午

参考链接


Java Calendar 获取上下午

华为手机配置显示返回键

使用华为Honor V8习惯了Android屏幕最下方的三个操作按键(返回/Home/列表),三个按键所在的位置被称之为"导航栏"。

最近换了华为Honor 30,想要点返回键时,却发现手机屏幕上没有返回键。手势操作非常不方便,经常误操作。而且有些界面适配的很不好,界面上没有设置回退功能。当缺少系统层面的返回按键的时候,只能强制退出应用。

其实这个返回键是在导航键里,需要设置才会显示。下面几个步骤就教你如何设置返回键:

继续阅读华为手机配置显示返回键

Gradle: 一个诡异的问题(ERROR: Failed to parse XML AndroidManifest.xml ParseError at [row,col]:[5,5] Message: expected start or end tag)

今天同事说他下了一个老版本的Android Studio项目死活编不过,我心想不就是一个项目么,编不过要么就是代码有问题,要么就是依赖库不完整这能有什么问题,于是自己在自己电脑试了下,结果自己也中招了:

继续阅读Gradle: 一个诡异的问题(ERROR: Failed to parse XML AndroidManifest.xml ParseError at [row,col]:[5,5] Message: expected start or end tag)

Android 5.x新特性之elevation(阴影),tinting(着色)以及clipping(剪裁)

研究了Google I/O 2014 发布 Material Design设计,人性化的风格,丰富的色彩,使人机交互更完美。中文学习地址http://wiki.jikexueyuan.com/project/material-design/(这个好像是极客学院翻译的),当然如果你的引文OK的话,也可以去看官方英文文档http://www.google.com/design/spec/material-design/

1. 阴影以及高度--elevation

继续阅读Android 5.x新特性之elevation(阴影),tinting(着色)以及clipping(剪裁)

Android获取SD卡路径及SDCard内存的方法

Android获取SD卡路径及SDCard内存的方法。

代码如下:

然后:在后面加上斜杠,在加上文件名

如下:

代码如下:

参考链接


Android获取SD卡路径及SDCard内存的方法

Android 获取View在屏幕中的位置

Android里面提供了一些方法可以获取View在屏幕中的位置。

getLocationOnScreen,计算该视图在全局坐标系中的x,y值,获取在当前屏幕内的绝对坐标(该值从屏幕顶端算起,包括了通知栏高度)。

getLocationInWindow,计算该视图在它所在的widnow的坐标x,y值。

getLeft, getTop, getBottom, getRight, 这一组是获取相对在它父亲布局里的坐标。

注意:如果在Activity的OnCreate()事件输出那些参数,是全为0,要等UI控件都加载完了才能获取到这些数据。

getDimension()、getDimensionPixelSize()和getDimensionPixelOffset()的区别

今天写代码的时候,需要从资源文件中读取一个长度值,用来设置控件的宽高,误以为getDimension()返回的就是资源里定义的dp值,后来发现不是我理解的那样。下面介绍一下getDimension()、getDimensionPixelSize()和getDimensionPixelOffset()的区别;

先看我在资源中的定义:

<dimen name="guide_first_cover_image_width">171dp</dimen>

然后打印出它们的值看看

QLog.i(TAG,String.format("getDimension: %f",mContext.getResources().getDimension(R.dimen.guide_first_cover_image_width)) );

QLog.i(TAG,String.format("getDimensionPixelSize: %d",mContext.getResources().getDimensionPixelSize(R.dimen.guide_first_cover_image_width)));

QLog.i(TAG,String.format("getDimensionPixelOffset:%d",mContext.getResources().getDimensionPixelOffset(R.dimen.guide_first_cover_image_width)));

结果如下:

getDimension: 256.500000

getDimensionPixelSize: 257

getDimensionPixelOffset:256

我的模拟器是480*800的,屏幕密度是1.5,从打印结果就可以推知,getDimension()、getDimensionPixelSize()和getDimenPixelOffset()的结果值都是将资源文件中定义的dip值乘以屏幕密度,即171*1.5=256.5,只是getDimension()返回的是float,其余两个返回的是int, 其中getDimensionPixelSize()返回的是实际数值的四舍五入,而getDimensionPixelOffset返回的是实际数值去掉后面的小数点; 再跟踪代码查看这三个函数的具体实现,可以了解得更具体。总然而之,这三个函数返回的都是dip值乘以屏幕密度,如果你在资源文件中定义的长度单位不是dip,而是px的话,程序会直接抛出异常。

参考链接


getDimension()、getDimensionPixelSize()和getDimensionPixelOffset()的区别

Android Scroller实现View弹性滑动完全解析

说起View的滑动效果,实现的方法有多种,例如使用动画,或者通过改变View的布局参数,其实除了这两种外,在AndroidView已经为我们提供了scrollTo()scrollBy()方法来实现滑动效果,这两个方法也是我们接下来要重点讨论的...

但是呢,这两个方法实现的滑动效果都是瞬时完成的,并不能带来良好的体验哦,所以此时就需要我们的重量级嘉宾Scroller登场了,通过Scroller可以实现View在一定时间间隔内的弹性滑动,以带来更好的视觉体验,这么说可能有点抽象,举个例子,当我们使用ViewPager时,手指滑动一段距离松开后ViewPager会自动的滑动一段距离后停止,这个效果就是通过Scroller实现的,这样说应该能更好的理解Scroller的用途了。

本着从理论到实践的原则,我们来一步步的揭秘Scroller...

1. 你应该知道的scrollTo()和scrollBy()

首先看一下这两个方法的源码:

两个方法第一个参数x表示相对于当前位置横向移动的距离,正值向左移动,负值向右移动。第二个参数y表示相对于当前位置纵向移动的距离,正值向上移动,负值向下移动,单位都是像素。
不同的是,scrollTo()方法让View相对于初始的位置滚动某段距离,scrollBy()方法则是让View相对于当前的位置滚动某段距离。同时可以发现scrollBy()是通过scrollTo()方法实现的。

上边我们说过,两个方法第一个参数x表示相对于当前位置横向移动的距离,正值向左移动,负值向右移动。这是为什么呢???看下scrollTo()方法中的mScrollX = x;一行,我们传入的x值被赋值给了mScrollX ,mScroller又是什么东东呢?其实View有一个getScrollX(),继续走进源码的世界:

可以看到通过getScrollX()方法可以返回mScrollX,也就是View在 水平方向移动的距离,其实关于mScrollX的值有个变化规律:mScrollX等于View左边缘和View内容左边缘的水平方向x坐标的差值,同样的道理mScrollY 等于View上边缘和View内容上边缘的垂直方向y坐标的差值

通过scrollTo()或scrollBy()实现View的移动,只是View的内容的移动,View本身的位置并不会发生改变。此时的View可以理解为一个ViewGroup,而内容可以理解成ViewGroup中的子View,假设View的坐标原点为(0, 0),如果View内容从左向右移动,则View的内容左边缘x值将大于0,而View的左边缘x值始终为0,所以View左边缘和View内容左边缘的水平方向x坐标的差值小于0,也就是mScrollX的值小于0,这也就解释了为什么当scrollTo()或scrollBy()的x参数为负值,看起来View是向右移动的,这样也就可以理解x参数为正值的情况了,同理纵向上的y参数值也是一个道理。

说了这么多scroll相关的方法,也该聊聊我们的Scroller了...

2. Scroller弹性滑动原理

首先看一下Scroller的典型用法:

目测startScroll()方法和View的滑动有关,继续看源码:

原来startScroll()方法只是进行相关参数的初始化,其中startX、startY代表滑动的起点,dx、dy代表需要滑动的距离,duration代表整个滑动需要的时间。骗子...这里并没有View滑动的相关逻辑。那么View如何通过Scroller实现弹性滑动呢?其实是通过startScroll()下面的invalidate();方法,略抽象,可能我们更多的知道invalidate()方法能够使得View重绘,其实奥秘就在这里,通过使View重绘,会间接的执行computeScroll()方法,继续看源码:

原来是一个空方法,所以需要我们自行实现,so sad...
而在computeScroll()中,我们首先通过computeScrollOffset()方法判断滑动是否结束,这个方法如何工作呢?继续看源码:

看第一个if条件,如果滑动动画已经finish,则返回fasle,继续看第二个if条件,如果执行滑动动画已经花费的时间小于整个滑动动画需要的时间,则计算出mCurrXmCurrY的值,也就是当前View内容左边缘的x、y坐标的值,同时返回true,所以,如果滑动的动画未结束则返回true否则返回false。当返回true时,则调用scrollTo(mScroller.getCurrX(), mScroller.getCurrY())进行View的滑动,其中参数mScroller.getCurrX()、mScroller.getCurrY()得到的就是上边的mCurrX和mCurrY,scrollTo之后继续执行invalidate()方法,此时又会导致View重绘,又一次执行computeScroll()方法...,这样的反复执行,直到computeScrollOffset()方法返回flase,即完成View的滑动。

通过上边的分析可以看出,仅仅通过Scroller,并不能实现View的滑动效果,同时需要配合View的invalidate()、computeScroll()、scrollTo()方法才可以完成。

说了这么多的理论,也该实践一下了...

继续阅读Android Scroller实现View弹性滑动完全解析