亦余心之所善兮,虽九死其犹未悔。这篇文章主要讲述Android Handler 机制:Hander 机制深入探究问题梳理相关的知识,希望能为你提供帮助。
一、‘
非UI线程更新UI’
问题探究android开发的时候非UI线程不能更新UI,这个是大家都知道的开发常识。但是当问到为什么?可能我们就会有些含糊了。
本文我们就针对这个问题进行探讨并进行一定的思维发散,来加深我们对Android界面刷新机制的理解。
1. UI线程的工作机制
主线程的工作机制可以概况为 生产者 - 消费者 - 队列 模型。
2. 为什么UI线程不设计成线程安全的
总所周知,如果设计成线程安全的,那性能肯定是大打折扣的,而UI更新的要求有如下特性:
- UI是具有可变性的,甚至是高频可变。
- UI对响应时间很敏感,这就要求UI操作必须要高效。
- UI组件必须批量绘制来保证效率。
3. 非UI线程一定不能更新UI吗?
答:不一定。
说明:首先Android设计了Handler机制来更新UI是避免多个子线程更新UI导致的UI错乱的问题,但是又不能通过加锁机制设计成线程安全的,因为那样会导致性能下降的很厉害。但是在Android提供的SurfaceView、GLSurfaceView里面是都能在非UI线程更新UI的。
二、Handler发送消息的delay设置是否可靠?答案是:不可靠。
原因:当Handler所属的线程(UI线程)要处理的内容非常多,当Looper出现事件积压的时候会使得delay不可靠。如ANR的出现就是一个最极端的代表例子。
为了理解为何在事件挤压的时候,handler会出现delay的不可靠,这里我们就加入一些核心逻辑的分析,来帮助我们进行此问题的探究。
三、Handler机制下消息队列MessageQueue的优化一般情况下,可以考虑从以下几个方面进行优化
- 对消息队列中重复消息的过滤,用于控制一些操作的频率,既保证用户体验又保证性能(使用Handler Api)。
- 对消息队列中的互斥消息进行取消,用于类似开关之类的操作(使用Handler Api)。
- 消息池复用,减少创建Message实例的开销(Handler机制自带消息池)。
- IdleHandler的合理使用,利用空闲的时机进行一些业务逻辑的处理(视业务而定)。
- 输入超时:5秒(最常见)
- 服务超时:前台服务20s、后台服务200s。
- 广播队列超时:前台广播10秒、后台广播60秒。
- ContentProvider超时:10秒
这里我们使用Service举例,当Service超时的时候,发送的Message.what就是ActivityManagerService.SHOW_NOT_RESPONDING_UI_MSG。
ANR也算是Android系统提醒开发者程序编写有问题的一个机制。
2.Looper不会导致应用ANR的本质原因是什么?
当我们熟悉了Looper的工作机制,我们就会知道主线程执行的操作就是执行Loop.loop()不断的处理消息。Looper是进程上的一个概念,ANR是程序执行到某一个环节对开发者占用主线程耗时的一个监控机制,自然也就不存在Looper死循环导致ANR的问题。
3.Looper为什么不会导致CPU占用率高?(延伸)
这是因为使用了Linux底层的pipe管道机制和epoll机制,在主线程的MessageQueue没有消息时,便阻塞在loop的queue.next()中的nativePollOnce() 方法里,在没有消息时阻塞线程并进入休眠释放cpu资源,有消息时唤醒线线程,这样不会导致CPU占用率高。
【Android Handler 机制(Hander 机制深入探究问题梳理)】
推荐阅读
- NetCore+Dapper WebApi架构搭建(底层封装)
- Android Activity销毁
- Android Intent 隐式
- Appium自动化测试教程-自学网-monkey参数
- Appium自动化测试教程-自学网-Package与Activity
- Appium自动化测试教程-自学网-monkey事件
- Linux部署Django(报错 nohup: ignoring input and appending output to ‘nohup.out’)
- Ubuntu下安卓模拟器的选择
- 如何使用命令对Android系统进行截屏