你知道android的MessageQueue.IdleHandler吗?

作者:谷言,腾讯移动客户端开发工程师

商业转载请联系腾讯WeTest获得授权,非商业转载请注明出处。

原文链接:http://wetest.qq.com/lab/view/352.html

WeTest 导读

干货!干货!或许可以是一种处理问题的新思路哟!

前言

我们知道android是基于Looper消息循环的系统,我们通过Handler向Looper包含的MessageQueue投递Message, 不过我们常见的用法是这样吧?

一般我们比较少接触MessageQueue, 其实它内部的IdleHandler接口有很多有趣的用法,首先看看它的定义:

简而言之,就是在looper里面的message暂时处理完了,这个时候会回调这个接口,返回false,那么就会移除它,返回true就会在下次message处理完了的时候继续回调,让我们看看它有哪些有趣的用法吧~~

一、提供一个android没有的声明周期回调时机

如果有这种需求,想要在某个activity绘制完成去做一些事情,那这个时机是什么时候呢?有同学可能觉得onResume()是一个合适的机会,不是可是这个onResume() 真的是各种绘制都已经完成才回调的吗?No, too naive  ~~

你看谷老师说了,onStart是用户可见,onResume是用户可交互,谷老师可没说onResume是绘制完成吧~那么android那些耗时的measure, layout, draw是在什么时候执行的呢?它们跟onResume()又有何关系呢?让我们先来看看源码吧~

1. ActivityThread.java

我们知道app的进程其实是ActivityThread, 那么activity的生命周期自然是它来执行了,

performResumeActivity就是回调onResume了, 我们继续看wm.addView方法, 这个ViewManager是一个接口,其实现者是WindowManagerImpl

2.WindowManagerImpl.java

这个mGlobal是WindowManagerGlobal对象,我们继续

3.WindowManagerGlobal.java

这里我们new 出了ViewRootImpl对象, 我们知道这个对象就是android view的根对象了,负责view绘制的measure, layout, draw的巨长的方法 performTraversals就是这个类的,我们继续看setView方法

4.ViewRootImpl.java

这个函数调用了关键方法requestLayout(),  我们继续跟踪,顺便说下,后面一连串的BadTokenException就是我们常常遇到的dialog相关抛出的,也有些特殊场景也会出这个异常,可以到这里查看线索。

调用了scheduleTraversals, 从名字就能看出来了吧:

它往Choreographer里面post了一个runnable, 这个Choreographer是android负责帧率刷新相关的东西,我们暂时可以不关注它,可以理解为往主线程post一个消息是一样的,顺便说下这个Choreographer可以做帧率检测相关的东西,,可以用于卡顿检测什么的···

我们看这个runnable果然是去执行了那个巨长无比的函数performTraversals函数,  现在我们可以总结下流程了:

结论:所以如果我们想在界面绘制出来后做点什么,那么在onResume里面显然是不合适的,它先于measure等流程了, 有人可能会说在onResume里面post一个runnable可以吗?还是不行,因为那样就会变成这个样子

所以你的行为一样会在绘制之前执行,这个时候我们的主角IdleHandler就发挥作用了,我们前面说了,它是在looper里面message暂时执行完毕了就会回调,顾名思义嘛,Idle就是队列为空的意思,那么我们的onResume和measure, layout, draw都是一个个message的话,这个IdleHandler就提供了一个它们都执行完毕的回调了,大概就是这样

说了这么多,那么现在获取到这个时机有什么用呢? look!!

这个是我们地图的公交详情页面, 进入之后产品要求左边的页卡需要展示,可以看到左边的页卡是一个非常复杂的布局,那么进入之后的效果可以明显看到头部的展示信息是先显示空白再100毫秒左右之后才展示出来的,原因就是这个页卡的内容比较复杂,用数据向它填充的时候花了较长时间,代码如下:

可以看到这个detailView就是这个侧滑的页卡了,填充里面的数据花了90ms,如果这个时间是用在了界面view绘制之前的话,就会出现以上的效果了,view先是白的,再出现,这样就体验不好了,如果我们把它放到IdleHandler里面呢?代码如下:

效果是这样的:

看出不同了吗?顶部的页卡先展示出来了,这样体验是不是会更好一些呢。虽然只有短短90ms,不过我们做app也应该关注这种细节优化的,是吧~ 这个做法也提供了一种思路,android本身提供的activity框架和fragment框架并没有提供绘制完成的回调,如果我们自己实现一个框架,就可以使用这个IdleHandler来实现一个onRenderFinished这种回调了。

二、可以结合HandlerThread, 用于单线程消息通知器

我们先思考一个问题,如果有一个model数据管理模块,怎么设计?比如地图的收藏模块的model部分。就是下面这个图的小星星:

它原来的model设计大概是这个样子的:

由于这个model是单例的,而且是多线程可以访问的,所以它的增删改查都加上了锁,而且由于外部访问需要遍历有哪些收藏点,所以外部遍历列表也需要加锁,大概是这样的:

因为是多线程可访问的,如果遍历不加锁的话,其他线程删除了一个收藏,就会crash的,原来的这样设计有几个不好的地方:

1. 外部使用者需要关系锁的使用,增加了负担,不用还不安全

2. 如果在主线程加锁的话,可能另一个线程执行操作会阻塞主线程造成anr

总之,多线程代码就是容易出错,而且真的出错的时候查起来太费劲了,目前收藏夹模块就有N多bug,所以我想用单线程来解决这个问题,由于model层的访问需要数据库和网络等,所以需要异步线程,那么单线程队列+异步线程,首先想到的就是HandlerThread, 大概架构如下:

现在,我们把原来多线程的逻辑改到了单线程里面,各种收藏的model共用一个HandlerThread,这样我们增删改查都不用加锁了,出错几率大大减小,而且这种model的设计有点类似插件的意思,可以很方便的增加其他收藏。

Ok, 那么跟我们的主题IdleHandler有什么关系呢?思考这样一个问题,地图上的小星星需要实时更新,也就是model的任何变化都需要显示到地图上,那么收藏的小星星就应该作为model的观察者,以前的做法是向收藏model注册监听,在每一个增删改查操作后都对观察者回调,大概是这样:

这样有一个小小的问题,就是如果有一个操作生成10个快速连续的增删改查操作,那么我们的UI就会收到10次回调,而这种场景下我们其实只需要最后一次回调就够了,中间操作其实不用刷新UI的。

那么现在改成单线程模型,我们又该如何处理这个问题呢?当然我们也能在每个post到异步线程的runnable里面去回调观察者,但这样未免不够优雅,所以这个时候IdleHandler不就又可以发挥作用了吗?它是在消息暂时处理完的时候回调的呀,不是很符合我们的时机么,对吧?

就是这个样子了,这里为什么不用第一个场景下的Looper.myQueue().addIdleHandler()呢?注意这个地方Looper.myQueue()如果在主线程调用就会使用主线程looper了,所以我选择反射这个HandlerThread的looper来设置它,这个IdleHandler我们返回了true, 表示我们要长期监听消息队列,因为返回false,下次就没有回调了哦。

好了,结论是这个地方IdleHandler用作了一个消息的触发器,是不是挺有意思的呢?

三、 结语

如果你没有用过它,从今天开始试试吧,这篇文章只是我个人的一点小思路,说不定这个IdleHandler有很多其他的用法呢~~

腾讯WeTest提供上千台真实手机,随时随地进行测试,保障应用/手游品质。节省百万硬件费用,加速敏捷研发流程。

同时腾讯WeTest兼容性测试团队积累了10年的手游测试经验,旨在通过制定针对性的测试方案,精准选取目标机型,执行专业、完整的测试用例,来提前发现游戏版本的兼容性问题,针对性地做出修正和优化,来保障手游产品的质量。目前该团队已经支持所有腾讯在研和运营的手游项目。

欢迎进入:http://wetest.qq.com/product/cloudphone 体验安卓真机

欢迎进入:http://wetest.qq.com/product/expert-compatibility-testing 使用专家兼容测试服务。WeTest兼容性测试团队期待与您交流!You Create,We Test!

如果对使用当中有任何疑问,欢迎联系腾讯WeTest企业QQ:800024531

原创声明,本文系作者授权云+社区发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏黑白安全

Web安全测试学习手册-业务逻辑测试

1.2 验证码过于简易时效性过长,接口未做限制(一般为纯数字4-8位数,时效性长达30分钟以上可以对验证码进行枚举)。

702
来自专栏安恒信息

使用NB Exploit Kit攻击的APT样本分析

1、起因 近期,安恒工程师在某网络中部署的APT威胁分析设备中发现一条高危告警,该告警包含了较多可疑行为,包含在沙箱运行环境中进行增加自启动、创建网络套接字连接...

2824
来自专栏ytkah

微信公众平台数据接口正式对所有认证公众号开放

  经过10多天的微信公众平台数据接口内测,现在正式对所有认证公众号开放了。微信公众平台数据接口正式向所有已微信认证(通过资质认证即可)的服务号和订阅号开放。通...

3083
来自专栏FreeBuf

玩爆EDUP智能插座Part1

智能插座实现了远程开启/关闭连入的设备,的确是一款懒人神器!其实现原理就是通过WiFi模块实现对继电器的开启或者关闭。EDUP智能插座通过用户提供的凭证连接家庭...

17110
来自专栏阮一峰的网络日志

Java开源建站工具

美国程序员Jon Scott Stevens,公布了他的创业公司所使用的开发工具清单。 他的语言平台是Java,开发项目是一个网站(还未上线)。所用到的工具都是...

3448
来自专栏FreeBuf

穿透内网防线,USB自动渗透手法总结

USB(Universal Serial Bus)原意是指通用串行总线,是一个外部总线标准,用于规范电脑与外部设备的连接和通讯,这套标准在1994年底由英特尔、...

1717
来自专栏闰土大叔

vue菜鸟从业记:公司项目里如何进行前后端接口联调

最近我的朋友王小闰进入一家新的公司,正好公司项目采用的是前后端分离架构,技术栈是王小闰非常熟悉的vue全家桶,后端用的是Java语言。

951
来自专栏FreeBuf

安全科普:流量劫持能有多大危害?

作者 gethostbyname 上一篇文章,介绍了常见的流量劫持途径。然而无论用何种方式获得流量,只有加以利用才能发挥作用。 不同的劫持方式,获得的流量也有所...

2026
来自专栏程序猿DD

程序员你为什么这么累【续】:编码习惯之日志建议

——请先阅读这3篇文章: 程序员你为什么这么累? 我的编码习惯 - 接口定义 我的编码习惯 - Controller规范 开发中日志这个问题,每个公司都强调,...

3667
来自专栏数据之美

网站数据统计分析之二:前端日志采集是与非

在上一篇《网站数据统计分析之一:日志收集原理及其实现》中,咱们详细的介绍了整个日志采集的原理与流程。但是不是这样在真实的业务环境中就万事大吉了呢?事实往往并非如...

3277

扫码关注云+社区