为什么SDK 30及以上版本后台线程调用lockCanvas仍会阻塞UI线程？

你观察到的行为是Android 11（API 30）对SurfaceView渲染机制的官方调整，不属于系统bug，你得出的「lockCanvas和unlockCanvasAndPost的执行区间现在会阻塞UI线程」的结论是完全正确的。

具体变更细节 #

• API 30之前的SurfaceView的Surface是完全独立于应用主View渲染层级的，持有单独的渲染缓冲区，lockCanvas()仅会锁定这个独立缓冲区的锁，和主线程的View渲染流程没有资源竞争，所以你在lockCanvas()之后执行sleep，仅会阻塞后台工作线程，不会影响UI线程的交互和渲染。
• 从API 30开始，Google为了优化SurfaceView的画面同步效果、降低不同步导致的画面撕裂问题，引入了SurfaceView帧同步对齐机制：SurfaceView的渲染帧会和应用主View树的vsync信号做对齐同步，调用lockCanvas()时，系统会同时锁定主UI渲染线程的缓冲区队列，直到你调用unlockCanvasAndPost()提交当前帧之后，才会释放这个全局锁。因此你在lock和unlock之间插入sleep，等于长时间持有UI线程的渲染锁，自然会导致主线程阻塞、滑动掉帧。

为什么移动sleep位置可以解决问题 #

当你把sleep移动到unlockCanvasAndPost()之后执行时，画布锁和全局渲染锁已经被释放还给系统，sleep仅会阻塞你运行协程的后台工作线程，完全不会干扰UI线程的渲染和交互流程，因此页面滑动就恢复了流畅。

最佳实践建议 #

• 无论运行在哪个API版本，都不要在lockCanvas()和unlockCanvasAndPost()的区间内执行任何耗时操作，包括sleep、复杂计算、IO读写等，API 30只是让这种错误写法的负面影响暴露得更明显而已
• 如果需要控制SurfaceView的绘制帧率，不要使用Thread.sleep，更推荐使用协程的delay方法，或者配合Choreographer监听系统vsync信号做帧对齐，精度更高也更节省系统资源
• 对SurfaceHolder的操作建议严格遵循SurfaceHolder.Callback的生命周期管控，避免多线程操作引发的画布冲突问题

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