分析下面这张图分析600190帧卡时，主线程大部分时间一直运行在cpu3上，查看cpu3，主线程(navi.cn.oi.audi)在多处时间点运行的任务时间较长，导致了帧绘制被阻塞
主线程执行时长过长：在00:00:15.863733405开始运行，持续了3ms 669us 920ns，并在多个时间点都存在高于理想值的运行时间，例如：
00:00:15.870970380持续了3ms 482us 347ns。
00:00:15.875775456持续了5ms 604us 689ns。
00:00:15.885852316持续了10ms 218us 813ns。这些任务持续时间占用了大量的 CPU 资源，阻碍了主线程按时提交渲染任务。
其他线程对主线程的干扰：某些非关键线程（如logd、adbd等）在CPU3上争抢资源，例如：
00:00:15.870913354logd线程运行了57us 26ns。
00:00:15.870286330开始的system_server和logd线程占用了部分时间，造成了资源争抢。
RenderThread 效率低下
RenderThread的运行存在一些碎片化任务，时间分布较为分散，未能及时协助完成帧的渲染。例如：
00:00:15.903572722开始运行，持续480us 290ns。
后续多个任务运行时间较短，例如52us 458ns、79us 518ns等，显示出可能存在同步或优先级调度问题。
存在资源竞争：
在cpu1，cpu2，cpu3上，Binder、adbd、FastMixer和其他系统线程与主进程navi.cn.oi.audi存在资源竞争，特别是：
CPU3上的资源分配较为密集，且高优先级的任务（如navi.cn.oi.audi）并未能始终占据主导地位。
CPU1、CPU2上的logd和Map-Logical-0线程虽为低耗时任务，但数量较多，进一步影响了调度效率。
通过上面的分析：
600190帧卡顿的原因主要包括主线程的执行时间过长，RenderThread 的效率较低、以及多线程间的资源争用导致的调度延迟。
需要优化主线程的任务
renderThread 要避免重复绘制
