分析WM Shell中线程相关的官方帮助文档

背景这几年WM Shell部分也在不断更新而且基本上互联网AI等对于WM Shell的知识几乎是空白的啥也搜不到马哥这边对于WM Shell出了自己去代码调研以外也会经常去寻找一些官方的文档资料进行学习下面就是关于WM Shell相关的官方文档路径。frameworks/base/libs/WindowManager/Shell/src/com/android/wm/shell/docs今天分享一下我们比较陌生的的WM Shell的线程知识针对这块我们一起看着官方文档学习哈有啥要讨论分享的知识可以vip群中讨论发言哈。ThreadingBoundariesThread boundary | WM Shell | SystemUI | | FeatureController - FeatureInterface --|-- WMShell - SysUI | (^post to shell thread) | (^post to main thread) ... | | | OtherControllers |ThreadsWe currently have multiple threads in use in the Shell library depending on the configuration bythe product.SysUI main thread (standard main thread)ShellMainThread(only used if the resourceconfig_enableShellMainThreadis set true(ie. phones))This falls back to the SysUI main thread otherwiseNote:This thread runs withTHREAD_PRIORITY_DISPLAYpriority since so many windowing-criticalcomponents depend on itThis is also the UI thread for almost all UI created by the ShellThe Shell main thread Handler (and the Executor that wraps it) is async, somessages/runnables used via this Handler are handled immediately if there is no syncmessages prior to it in the queue.ShellBackgroundThread(for longer running tasks where we don’t want to block the shell mainthread)This is always another thread even if config_enableShellMainThread is not set trueNote:This thread runs withTHREAD_PRIORITY_BACKGROUNDpriority but can be requested to be boostedtoTHREAD_PRIORITY_FOREGROUNDShellAnimationThread(currently only used for Transitions and Splitscreen, but potentially allanimations could be offloaded here)ShellSplashScreenThread(only for use with splashscreens)Dagger setupThe threading-related components are provided by the WMShellConcurrencyModule,for example, the Executors and Handlers for the various threads that are used. You can requestan executor of the necessary type by using the appropriate annotation for each of the threads (ie.ShellMainThread Executor) when injecting into your Shell component.To get the SysUI main thread, you can use theMainannotation.Best practicesComponentsDon’t do initialization in the Shell component constructorsIf the host SysUI is not careful, it may construct the WMComponent dependencies on the mainthread, and this reduces the likelihood that components will intiailize on the wrong threadin such casesBe careful of using CountDownLatch and other blocking synchronization mechanisms in Shell codeIf the Shell main thread is not a separate thread, this will cause a deadlockCallbacks, Observers, Listeners to any non-shell component should post onto main Shell threadThis includes Binder calls, SysUI calls, BroadcastReceivers, etc. Basically any API thattakes a runnable should either be registered with the right Executor/Handler or posted tothe main Shell thread manuallySince everything in the Shell runs on the main Shell thread, you donotneed to explicitlysynchronizeyour code (unless you are trying to prevent reentrantcy, but that can also bedone in other ways)Handlers/ExecutorsYou generallyneverneed to create Handlers explicitly, instead injectShellMainThread ShellExecutorinsteadThis is a common pattern to defer logic in UI code, but the Handler created wraps the Looperthat is currently running, which can be wrong (see above for initialization vs construction)That said, sometimes Handlers are necessary because Framework API only takes Handlers or youwant to dedupe multiple messagesIn such cases injectShellMainThread Handleror use view.getHandler() which should be OKassuming that the view root was initialized on the main Shell threadNeveruse Looper.getMainLooper()It’s likely going to be wrong, you can injectMain ShellExecutorto get the SysUI main threadTestingYou can use aTestShellExecutorto control the processing of messages原文地址https://mp.weixin.qq.com/s/MhLa812mRCxuryL5WF7YfQ更多fw实战开发干货请关注“千里马学框架”