这次有一个黑屏问题，但是这个问题主要原因是
"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%，客户觉得高了，针对此问题，我这边设立了专项进行分析
bash
442 D HvacPageView: isAutoHvacConfig: 0
行 516506: 01-22 16:49:56.202817 2442 2442 D HvacPageView: onProgressChanged: 7false
行 516604: 01-22 16:49:56.314510 2442 2442 D HvacPageView: executeUpdateBlowModeAnimation isSupHeatState:false,isSupCoolState:false;airConditionConfig:1 ionConfig:0 ;pm25Config:1
行 516614: 01-22 16:49:56.315582 2442 2442 D HvacPageView: executeUpdateBlowModeAnimation purry_type:3 ;fragranceOn:false ;ionConfig:0
行 516899: 01-22 16:49:56.465805 2442 2442 D HvacPageView: onHvacCirculationModeStatus : 2
行 516900: 01-22 16:49:56.465912 2442 2442 D HvacPageView: updateCirculationModeStatus: 2
行 516901: 01-22 16:49:56.466106 2442 2442 D HvacPageView: isAutoHvacConfig: 0
行 516907: 01-22 16:49:56.469518 2442 2442 D HvacPageView: onHvacBlowSpeedAuto: 1
行 516908: 01-22 16:49:56.472696 2442 2442 D HvacPageView: onHvacBlowSpeedAuto invalidate
行 517127: 01-22 16:49:56.531263 2442 2442 D HvacPageView: onWindSpeedStatus: 8
行 517128: 01-22 16:49:56.531292 2442 2442 D HvacPageView: isAutoHvacConfig: 0
行 517130: 01-22 16:49:56.531799 2442 2442 D HvacPageView: onProgressChanged: 8false
行 517131: 01-22 16:49:56.534828 2442 2442 D HvacPageView: executeUpdateBlowModeAnimation handler
行 517176: 01-22 16:49:56.615516 2442 2442 D HvacPageView: mPvBlowModeFace:true ;mPvBlowModeFoot:false ;mPvBlowModeWindow:false
行 517372: 01-22 16:49:56.740832 2442 2442 D HvacPageView: onAutoStatus: 0
行 517384: 01-22 16:49:56.742257 2442 2442 D HvacPageView: updateBlowModeBg isSlideChange: var:0
行 517389: 01-22 16:49:56.743194 2442 2442 D HvacPageView: setBlowModeAnimationAndSelected: face = true, foot = false, window = false,powerState = true
行 517390: 01-22 16:49:56.743277 2442 2442 D HvacPageView: isAutoHvacConfig: 0
行 517394: 01-22 16:49:56.744345 2442 2442 D HvacPageView: startBlowWindFacePag var:1 shouldload:false
行 517395: 01-22 16:49:56.744430 2442 2442 D HvacPageView: loadAndPlayFacePag currentFacePath:pag/blow_face_open_day.pag ;filePath:pag/blow_face_open_day.pag
行 517397: 01-22 16:49:56.744832 2442 2442 D HvacPageView: startBlowWindFootPag var:0 shouldload:false
行 517398: 01-22 16:49:56.744890 2442 2442 D HvacPageView: loadAndPlayFootPag currentFootPath:pag/blow_foot_close_day.pag ;filePath:pag/blow_foot_close_day.pag
行 517403: 01-22 16:49:56.745387 2442 2442 D HvacPageView: startBlowWindWindowPag var:0 shouldload:false
行 517404: 01-22 16:49:56.745420 2442 2442 D HvacPageView: loadAndPlayWindowPag currentWindowPath:pag/blow_window_close_day.pag ;filePath:pag/blow_window_close_day.pag
行 517405: 01-22 16:49:56.745438 2442 2442 D HvacPageView: setBlowModeAnimationAndSelected run
行 517479: 01-22 16:49:56.851508 2442 2442 D 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%都不觉得高，因此最后澄清不是问题
