之前有写过一篇粗略分析的文章:
http://blog.csdn.net/fyfcauc/article/details/43307253
不过还是不够,这次再专门细读一下:Choreographer主要被外部使用的函数是postCallback(…), 就是在Choreographer中schedule一个Task,这个Task何时运行,则是是由Choreographer来自行安排,满足作Sync的需求。
postCallback(…) -> postCallbackDelayed(…) ->postCallbackDelayedInternal(…, long delayMillis), postCallbackDelayedInternal的具体步骤:
- 首先获取mLock来同步操作mCallbackQueues这个Queue, 获取当前的时间存为now(SystemClock.uptimeMillis(), 再根据输入的delayMillis获得一个到期时间dueTime), 然后将dueTime以及输入的Task加入到mCallbackQueues[输入的callbackType]对应的Queue中.
- 如果发现dueTime <= now,那么会直接scheduleFrameLocked(now)。
- 否则, 会生成一个MSG_DO_SCHEDULE_CALLBACK类型的,runnable为输入的Task的Message,并且该msg的arg1是输入的callbackType.
- 将Messgae设置为异步的(setAsynchronous(true)).
- 然后将这个Message post到Choreographer的handler中(这个handler基于的线程是传入的Looper基于的线程,在这里就是UI线程).
Choreographer不能直接构造(private ctor),而是使用getInstance()获得当前线程的TLS, 其构造时传入的looper也是调用getInstance()所在线程的looper, 因此在ViewRootImpl中使用的mChoreographer基于的looper就是ViewRootImpl构造时所在的线程,这里就是UI线程. 因此Choreographer的主体操作(doFrame这种重构UI的操作)就是在主线程的handler被post已经执行的.
mHandler的类型是自定义的FrameHandler:
- 其对MSG_DO_SCHEDULE_CALLBACK的处理是doScheduleCallback(msg.arg1):
- doScheduleCallback(…)操作也会获取mLock, 然后检查当前是否已经scheduke过一个FrameTask了(mFrameScheduled), 如果还没有sc
- 其对MSG_DO_SCHEDULE_CALLBACK的处理是doScheduleCallback(msg.arg1):
Android Choreographer 源码笔记
最新推荐文章于 2024-07-14 11:09:46 发布
本文详细分析了Android Choreographer的源码,探讨了如何使用Choreographer调度任务,重点在于postCallback流程,包括时间处理、Message的发送与接收,以及在主线程中的执行。同时,介绍了Choreographer如何通过VSYNC信号实现同步,确保UI更新的流畅性,并分析了可能的丢帧和卡顿情况。
摘要由CSDN通过智能技术生成