主线程休眠时ProgressBar仍旋转是否属于正常现象？

嘿，这个问题问得特别好，我刚接触Android开发的时候也有过一模一样的疑惑！先给你吃个定心丸：这种情况完全正常，你对UI线程的核心认知没错，只是Android的UI渲染机制藏了点小细节~

• 无限旋转ProgressBar的动画特殊性
  我们常用的那种不停转圈的ProgressBar（也就是设置了android:indeterminate="true"的样式），它的动画并不是靠主线程逐帧计算、绘制的。Android系统为这类通用循环动画做了专门优化：它的旋转逻辑是由系统渲染管线（SurfaceFlinger + 硬件加速模块）直接处理的，对应的Drawable是系统预定义的动画资源，这些动画的驱动不需要依赖主线程的消息队列——只要View的硬件层没有被销毁，系统会自动在后台完成动画的渲染工作。

• 主线程sleep不阻塞独立的渲染线程
  从Android 4.3（API 18）开始，UI渲染就由专门的**RenderThread（渲染线程）**负责了，这个线程是独立于主线程存在的。主线程的核心工作是处理用户输入、更新View的布局和属性，而实际的绘制命令会被打包提交给RenderThread，由它和系统的SurfaceFlinger服务配合完成屏幕刷新。当你调用Thread.sleep(10000)让主线程休眠时，只是阻塞了主线程的消息处理流程，但RenderThread还在正常运行，所以ProgressBar的旋转动画不会中断。

• 什么时候ProgressBar才会停？
  只有当你在主线程执行耗时的UI计算操作（比如复杂的多层布局测量、大量自定义View的绘制逻辑），导致主线程完全被占用，连向RenderThread提交绘制命令的机会都没有时，ProgressBar的动画才会卡顿甚至停止。单纯的Thread.sleep()只是让主线程暂停，并没有占用渲染相关的资源，所以动画能正常跑。

举个直观的对比例子：如果你在主线程写一个死循环while(true){}，这时候主线程彻底被卡死，连基本的消息都处理不了，ProgressBar的旋转会立刻停止——这才是真正意义上的UI线程阻塞场景。

内容的提问来源于stack exchange，提问作者fhucho