这次有一个黑屏问题，但是这个问题主要原因是
"main" prio=5 tid=1 Native | group="main" sCount=1 dsCount=0 flags=1 obj=0x71d08518 self=0xb400007bdab5e7b0 | sysTid=1154 nice=0 cgrp=foreground sched=0/0 handle=0x7d6178d4f8 | state=S schedstat=( 6574416887 7326888929 18805 ) utm=440 stm=216 core=1 HZ=100 | stack=0x7fea186000-0x7fea188000 stackSize=8192KB | held mutexes= native: #00 pc 000000000009b0f4 /apex/com.android.runtime/lib64/bionic/libc.so (__ioctl+4) native: #01 pc 0000000000057de0 /apex/com.android.runtime/lib64/bionic/libc.so (ioctl+156) native: #02 pc 0000000000053a1c /system/lib64/libbinder.so (android::IPCThreadState::talkWithDriver(bool)+296) native: #03 pc 0000000000054a08 /system/lib64/libbinder.so (android::IPCThreadState::waitForResponse(android::Parcel*, int*)+60) native: #04 pc 0000000000054778 /system/lib64/libbinder.so (android::IPCThreadState::transact(int, unsigned int, android::Parcel const&, android::Parcel*, unsigned int)+184) native: #05 pc 000000000004d0f4 /system/lib64/libbinder.so (android::BpBinder::transact(unsigned int, android::Parcel const&, android::Parcel*, unsigned int)+120) native: #06 pc 0000000000123dcc /system/lib64/libandroid_runtime.so (android_os_BinderProxy_transact(_JNIEnv*, _jobject*, int, _jobject*, _jobject*, int)+152) at android.os.BinderProxy.transactNative(Native method) at android.os.BinderProxy.transact(BinderProxy.java:550) at com.desaysv.ivi.vdb.IVDBus$Stub$Proxy.get(IVDBus.java:170) at com.desaysv.ivi.vdb.client.bind.VDConnector.getOnce(VDConnector.java:339) at com.desaysv.ivi.vdb.client.bind.VDRouter.getOnce(VDRouter.java:210) at com.desaysv.ivi.vdb.client.VDBus.getOnce(VDBus.java:204) at com.android.systemui.e.i.f.d.b(MediaProxyImp.java:80) at com.android.systemui.e.i.f.d.e(MediaProxyImp.java:65) at com.android.systemui.e.i.f.d.a(MediaProxyImp.java:29) at com.android.systemui.e.i.f.d$1.onVDNotify(MediaProxyImp.java:43) at com.desaysv.ivi.vdb.client.bind.VDConnector.dispatchEvent(VDConnector.java:961) - locked <0x0398bab8> (a java.util.ArrayList) at com.desaysv.ivi.vdb.client.bind.VDConnector.access$200(VDConnector.java:48) at com.desaysv.ivi.vdb.client.bind.VDConnector$1.handleMessage(VDConnector.java:106) at android.os.Handler.dispatchMessage(Handler.java:106) at android.os.Looper.loop(Looper.java:223) at android.app.ActivityThread.main(ActivityThread.java:7705) at java.lang.reflect.Method.invoke(Native method) at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:592) at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1001) 01-22 16:52:45.904959 483 8155 E ActivityManager: Reason: Input dispatching timed out (8a87819 NavigationBar0 (server) is not responding. Waited 5118ms for MotionEvent(deviceId=3, source=0x00001002, displayId=0, action=DOWN, actionButton=0x00000000, flags=0x00000000, metaState=0x00000000, buttonState=0x00000000, classification=NONE, edgeFlags=0x00000000, xPrecision=1.0, yPrecision=1.0, xCursorPosition=nan, yCursorPosition=nan, pointers=[0: (722.0, 1640.0)]), policyFlags=0x62000000)日志分析：
SystemUI 主线程在处理 VDBus 的 onVDNotify 回调时，同步执行了 VDBus.getOnce()，导致主线程被阻塞超过输入分发超时时间，从而触发 ANR。
修复策略：
不在 onVDNotify 回调中发起同步 VDBus.getOnce()，Binder 调用，改为直接使用 notify 数据，避免主线程阻塞
但是于此同时，发现了空调CPU占用45%，客户觉得高了，针对此问题，我这边设立了专项进行分析
442D HvacPageView: isAutoHvacConfig:0行516506: 01-2216:49:56.20281724422442D HvacPageView: onProgressChanged: 7false 行516604: 01-2216:49:56.31451024422442D HvacPageView: executeUpdateBlowModeAnimation isSupHeatState:false,isSupCoolState:false;airConditionConfig:1 ionConfig:0;pm25Config:1 行516614: 01-2216:49:56.31558224422442D HvacPageView: executeUpdateBlowModeAnimation purry_type:3;fragranceOn:false;ionConfig:0 行516899: 01-2216:49:56.46580524422442D HvacPageView: onHvacCirculationModeStatus:2行516900: 01-2216:49:56.46591224422442D HvacPageView: updateCirculationModeStatus:2行516901: 01-2216:49:56.46610624422442D HvacPageView: isAutoHvacConfig:0行516907: 01-2216:49:56.46951824422442D HvacPageView: onHvacBlowSpeedAuto:1行516908: 01-2216:49:56.47269624422442D HvacPageView: onHvacBlowSpeedAuto invalidate 行517127: 01-2216:49:56.53126324422442D HvacPageView: onWindSpeedStatus:8行517128: 01-2216:49:56.53129224422442D HvacPageView: isAutoHvacConfig:0行517130: 01-2216:49:56.53179924422442D HvacPageView: onProgressChanged: 8false 行517131: 01-2216:49:56.53482824422442D HvacPageView: executeUpdateBlowModeAnimation handler 行517176: 01-2216:49:56.61551624422442D HvacPageView: mPvBlowModeFace:true;mPvBlowModeFoot:false;mPvBlowModeWindow:false 行517372: 01-2216:49:56.74083224422442D HvacPageView: onAutoStatus:0行517384: 01-2216:49:56.74225724422442D HvacPageView: updateBlowModeBg isSlideChange: var:0 行517389: 01-2216:49:56.74319424422442D HvacPageView: setBlowModeAnimationAndSelected: face=true, foot=false, window=false,powerState=true行517390: 01-2216:49:56.74327724422442D HvacPageView: isAutoHvacConfig:0行517394: 01-2216:49:56.74434524422442D HvacPageView: startBlowWindFacePag var:1 shouldload:false 行517395: 01-2216:49:56.74443024422442D HvacPageView: loadAndPlayFacePag currentFacePath:pag/blow_face_open_day.pag;filePath:pag/blow_face_open_day.pag 行517397: 01-2216:49:56.74483224422442D HvacPageView: startBlowWindFootPag var:0 shouldload:false 行517398: 01-2216:49:56.74489024422442D HvacPageView: loadAndPlayFootPag currentFootPath:pag/blow_foot_close_day.pag;filePath:pag/blow_foot_close_day.pag 行517403: 01-2216:49:56.74538724422442D HvacPageView: startBlowWindWindowPag var:0 shouldload:false 行517404: 01-2216:49:56.74542024422442D HvacPageView: loadAndPlayWindowPag currentWindowPath:pag/blow_window_close_day.pag;filePath:pag/blow_window_close_day.pag 行517405: 01-2216:49:56.74543824422442D HvacPageView: setBlowModeAnimationAndSelected run 行517479: 01-2216:49:56.85150824422442D HvacPageView: executeUpdateBlowModeAnimation isSupHeatState:false,isSupCoolState:false;airConditionConfig:1 ionConfig从附近时间点来看，在执行吹脚吹脸的吹风动效，同时也在收到mcu的风量变化的回调和加载小图标的动效，在涉及多个动效执行并且多个回调的场景情况下,CPU占用45%是正常的，之前其他项目出现CPU峰值70%甚至146%的情况
同时T1N项目来看T1N 的20260107数据，CPU前台1min是31.6%，峰值146%
和路试数据来看
2025年9月路试峰值48%（6 x 8核 = 48%）
当前45% CPU占用是正常现象，拉会系统同时一起分析此问题，反馈空调应用比较特殊，涉及动效场景多，不超过100%都不觉得高，因此最后澄清不是问题
