- 博客(204)
- 资源 (8)
- 收藏
- 关注
RSS订阅原创 Linux 性能实战系列 - 附录 Valgrind介绍
Valgrind是一个动态二进制分析框架，主要包含三个核心工具：Memcheck（内存错误检测）、Callgrind（CPU性能分析）和Massif（堆内存分析）。Memcheck用于检测内存泄漏、越界访问等问题；Callgrind通过统计指令数分析函数调用关系和热点；Massif则追踪堆内存使用变化。三者共享Valgrind的二进制翻译框架，但功能各异，运行开销在5-50倍不等。典型使用流程是先Memcheck查内存错误，再用Callgrind找性能瓶颈，最后Massif分析内存占用。注意Memcheck
2026-03-16 18:16:22
390
原创 Horizon QAT 量化训练指南 - fx_mode.py 工作流程分析文档
本文档分析了Horizon QAT量化训练工具中fx_mode.py的工作流程。主要分为三个阶段：1)参数解析阶段处理用户输入的命令行参数；2)模型准备阶段根据stage参数创建MobileNetV2模型并加载ImageNet预训练权重；3)训练执行阶段准备CIFAR-10数据集并进行30个epoch的训练循环。文档详细展示了各阶段的执行流程，包括核心模块调用关系、数据预处理步骤和训练评估循环。通过流程图和模块清单，清晰呈现了从模型初始化到完整训练的全过程，为理解和使用该量化训练工具提供了详细指导。
2026-03-12 16:39:24
572
原创 Horizon QAT 量化训练指南
本指南介绍基于Horizon OpenExplorer平台的量化感知训练(QAT)完整流程，包含从浮点模型到部署模型的转换过程。主要内容包括：浮点模型训练、QAT训练、HBIR中间表示导出和HBM模型编译四个关键步骤，以及各阶段输出的模型格式特点。特别对比了QAT与PTQ两种量化方法的差异，并详细解释了INT8量化原理、量化参数(scale/zero point)等核心概念。通过MobileNetV2在CIFAR-10上的实验表明，QAT方法能有效保持模型精度，最终HBM模型体积压缩70%，推理速度达11,
2026-03-12 09:02:16
493
原创 WSL + Docker GPU 环境排查：NVIDIA-SMI couldn‘t find libnvidia-ml.so 问题分析与解决
本文分析了WSL+Docker环境下出现NVIDIA-SMI couldn't find libnvidia-ml.so错误的原因和解决方案。关键发现是当Docker镜像已包含/usr/lib/wsl/lib目录时，NVIDIA runtime会跳过GPU库挂载，导致容器无法访问GPU。解决方法是通过-v /usr/lib/wsl/lib:/usr/lib/wsl/lib手动挂载WSL GPU库，并设置LD_LIBRARY_PATH环境变量。文章详细介绍了问题排查步骤，包括检查WSL GPU状态、Docke
2026-03-11 22:41:21
592
原创 Linux 性能实战 | 第 17 篇续 strace 高级技巧与生产环境实战
本文深入介绍了Linux调试工具strace的高级使用技巧和生产环境实战经验。通过真实案例展示了strace在排查程序卡死、多进程跟踪、系统调用耗时分析等方面的应用，包括：1) 通过futex调用定位死锁问题；2) 使用-f参数跟踪子进程；3) -T参数分析系统调用耗时；4) -c参数统计调用频率；5) 跟踪exec过程排查外部命令调用问题。文章还对比了strace与ltrace、perf等工具的区别，并给出生产环境使用建议，如控制性能开销、输出到文件等。最后总结strace作为Linux工程师"
2026-03-08 22:14:01
424
原创 Linux 性能实战 | 第 17 篇续 小白一文彻底掌握 strace（从入门到深入）
摘要：本文深入讲解Linux调试工具strace的使用方法和原理。strace通过跟踪系统调用，可以快速诊断程序问题，如CPU飙高、卡死、文件/网络异常等。文章通过真实案例展示strace排查配置文件错误、网络连接问题的过程，并解析其底层ptrace实现机制。虽然strace会影响性能(10-100倍)，但作为调试工具极为强大，能揭示程序与内核的所有交互。作者强调，熟练使用strace能显著提升排障效率，是Linux工程师必备技能。
2026-03-08 22:02:48
599
原创 Linux 性能实战 | 附录：深入理解 Valgrind 内存泄漏检测原理
Valgrind 内存泄漏检测的核心原理是基于可达性分析。当程序退出时，Valgrind 会扫描所有可能的指针来源（寄存器、线程栈、全局变量等），构建根指针集合，然后递归标记所有可达的堆内存块。未被标记的内存块被判定为"definitely lost"。检测过程包括：拦截malloc/free调用、维护分配记录表、执行根扫描和标记可达内存。Valgrind能区分四种泄漏类型：完全不可达（definitely lost）、间接丢失（indirectly lost）、可能丢失（possibl
2026-03-03 21:31:38
579
1
原创 Linux 性能实战 | 附录：内存泄漏定位体系对比：perf vs Valgrind vs Heap Profiler
本文对比了Linux系统中三种内存泄漏定位工具：perf、Valgrind和Heap Profiler。perf基于采样统计模型，能发现分配热点但无法确认泄漏；Valgrind通过生命周期追踪可精确判定未释放内存，但性能开销大；Heap Profiler则通过聚合分析存活内存来源，适合线上诊断。文章指出，完整的内存泄漏排查需要结合这三类工具：先用perf定位分配热点，再用Heap Profiler分析存活内存路径，最后用Valgrind验证泄漏。这种分层分析方法能有效构建系统化的内存问题定位体系。
2026-03-03 21:28:03
546
1
原创 Linux 性能实战 | 附录：深入理解 pmap：进程内存映射全解析
fill:#333;important;important;fill:none;color:#333;color:#333;important;fill:none;fill:#333;height:1em;pmap -XX 核心知识字段体系Size 虚拟大小勿直接用RSS 含共享会高估PSS 按比例分摊最准确Anonymous 匿名堆总量Pss_Dirty 脏页写入量内存类型识别Device=00:00 匿名映射Perm=rw-s 共享内存Perm=r-xp 代码段。
2026-03-02 17:52:06
1213
1
原创 Linux 性能实战 | 附录：为什么 Linux 要使用写入时复制（COW）
Linux采用写入时复制（COW）机制来优化内存管理，其核心设计原则是"先共享，按需复制"。动态库加载时，只读的代码段和常量段在进程间共享，而可写的数据段仅在进程实际修改时才复制。这种延迟分配策略大幅降低内存占用 - 例如加载100个进程时，COW机制相比立即复制可节省97%内存。COW体现了Linux的三大设计哲学：最大化共享、延迟成本和page fault驱动资源分配，使得fork操作快速、动态库共享高效，系统能够运行更多进程。通过pmap或smem命令可验证动态库内存主要显示为sh
2026-03-02 06:45:00
897
1
原创 Linux 性能实战 | 附录：动态链接库的内存是共享的吗？深入理解 .so 如何影响进程内存占用
动态链接库的内存共享机制解析 摘要：Linux系统中动态链接库(.so)的内存占用分为共享与私有两部分。代码段(.text)和只读数据段(.rodata)是共享的，所有进程共用同一物理内存；而数据段(.data)和未初始化变量段(.bss)则是每个进程私有的。这种机制通过写时复制(Copy-on-Write)实现，既保证了进程隔离性，又大幅节省了内存资源。实际内存分析时，应关注PSS(按比例分摊的共享内存)而非RSS，才能准确评估真实内存占用。典型场景下，100个进程共享2MB的libc.so，实际内存占用
2026-03-01 22:17:33
720
原创 Linux 性能实战 | 附录：动态链接库是如何影响多个进程内存占用的？
摘要： Linux系统中，多个进程的RSS（常驻内存）可能显示较大值，但实际物理内存占用远低于预期，核心原因是**shared page（共享页）**机制。动态链接库（.so）通过mmap映射到进程地址空间时，会被缓存在page cache中，多个进程共享同一物理内存页，而非各自复制。RSS统计所有映射页（含共享），而PSS（按进程数均摊）和USS（独占内存）更反映真实占用。例如100个nginx worker（RSS各50MB）可能仅占800MB物理内存，因共享libc等库。工程中应优先参考PSS/USS
2026-03-01 21:38:12
715
原创 Linux 性能实战 | 附录：为什么OOM killer参考的是RSS而不是USS或者PSS
Linux OOM killer机制基于RSS而非PSS进行决策，因为RSS直接反映进程实际占用的物理页数量，而内核内存管理的最小单位就是物理页。RSS统计成本低且准确反映可释放内存量，而PSS计算复杂且无法用于实际释放决策。当系统内存耗尽时，OOM killer选择RSS最大的进程终止以释放最多物理页，而非按比例分摊的PSS。共享内存虽计入RSS但实际释放需等待所有映射进程退出。实用建议：分析内存用PSS，预测OOM风险看RSS和oom_score。
2026-02-28 07:00:00
262
原创 Linux 性能实战 | 附录：VSS、RSS、PSS、USS的区别
本文解析了Linux系统中四种内存指标(VSS/RSS/PSS/USS)的区别与适用场景： PSS最准确，按比例分摊共享内存，反映真实进程内存占用 USS表示进程独占内存，决定进程终止时可释放的内存 RSS包含共享内存会重复计算，常用于OOM分析但不够精确 VSS包含虚拟内存不反映实际使用 工程建议：内存分析优先看PSS，判断释放效果看USS，OOM场景看RSS，避免参考VSS。通过示例演示了PSS如何正确计算共享内存，解决了RSS重复计算的问题。
2026-02-27 21:34:38
509
原创 Linux 性能实战 | 附录：进程CPU使用率的计算
本文详细讲解了计算进程CPU使用率的工程方法，核心公式为CPU% = Δ(utime + stime)/Δtotal_cpu_time × NCPU × 100%。utime和stime的单位是clock ticks（通常1 tick=10ms），通过两次采样差值计算CPU时间消耗。文章介绍了两种计算方法：直接使用进程统计信息或参考系统全局CPU时间，并提供了Python实现示例。重点分析了utime和stime的工程意义：utime高表示计算密集，stime高反映系统调用频繁。最后指出top工具的原理就是
2026-02-27 21:31:39
1109
原创 Linux 下高效管理 VS Code 进程：`kill` 与 `pkill` 的正确用法
Linux下高效管理VS Code进程指南 本文介绍了在Linux系统中管理VS Code进程的正确方法。针对VS Code卡死或残留进程问题，对比了kill和pkill命令的区别：kill针对特定PID，而pkill可按名称批量操作。解释了pgrep -i code输出大量PID的原因——VS Code的多进程架构和模糊匹配特性。提供了精准管理方案：用pgrep -x code查主进程，pkill -f "/usr/share/code/code"彻底关闭所有进程，并建议先SIGTER
2026-02-26 10:25:21
772
原创 从零开始：使用 Claude Code 打造字母消除游戏
本文记录了使用Claude Code AI工具开发字母消除游戏的全过程。首先介绍了Claude Code的功能特点，包括自然语言编程、代码生成调试等能力。详细说明了安装步骤（npm/pip安装）和配置OpenModel GLM大模型的方法。游戏开发部分展示了从需求描述到完整实现的流程：HTML/CSS/JS代码生成、字母掉落机制、键盘交互、分数系统、连击效果和粒子动画等功能的实现。文章还包含了调试优化过程（解决字母重叠、窗口适配等问题）和最终游戏效果展示（开始界面、游戏进行中、连击效果等截图）。整个项目约3
2026-02-24 22:00:56
1465
原创 Linux 性能实战 | 第 19 篇：ftrace 内核跟踪入门 [特殊字符]
📋 本章摘要 在第十八章中,我们使用 捕捉库函数的性能热点,定位到正则表达式库（ 占用 89%）、加密函数和 JSON 解析成为新的瓶颈。通过函数级别的性能分析,将帧率从 30 FPS 提升到 980 FPS。 但当问题进入**内核路径**（调度延迟、软中断拥塞、块 IO 队列、kworker 异常
2026-02-13 23:16:21
815
原创 Linux 性能实战 | 第 20 篇：trace-cmd 与 kernelshark 可视化分析 [特殊字符]
📋 本章摘要 在第十九章中,我们掌握了 ftrace 的核心用法,通过直接操作 接口完成了 kworker 高负载和软中断风暴的排查。但手工操作 ftrace 存在明显的痛点： - **操作繁琐**：需要手动 echo 到多个文件,容易出错 - **数据管理难**：trace 数据无法持久化保存和分
2026-02-13 23:11:57
807
原创 Linux 性能实战 | 第 18 篇：ltrace 与库函数性能分析
📋 本章摘要 在第十七章中，我们深入探讨了系统调用的性能开销——单次 100-300ns，但频繁调用会累积到整体性能的 50% 以上。通过 strace 诊断，我们发现一个感知算法每秒调用 845,000 次 gettimeofday，导致 load 8.5 但 CPU 使用率仅 15%。通过批量优
2026-02-12 22:49:17
812
原创 Linux 性能实战 | 第 17 篇：strace 系统调用分析与性能调优 [特殊字符]
📋 本章摘要 在第十六章中，我们深入探讨了文件系统层面的性能优化，发现文件系统会引入 12% 的性能开销，元数据操作比数据写入慢 500-1000 倍，fsync 每次耗时约 5ms。通过优化自动驾驶日志系统（目录分片、批量 fsync、切换到 XFS），我们将写入次数降低 99%，延迟降低 95%
2026-02-12 14:52:39
718
原创 Linux 性能实战 | 第 16 篇：文件系统性能优化与分析
📋 本章摘要 在第十五章中，我们深入探讨了磁盘 IO 的三大性能指标（IOPS、吞吐量、延迟），发现队列深度和 IO 块大小对性能的决定性影响。通过优化传感器数据录制系统，我们将 NVMe SSD 的写入带宽从 150MB/s 提升到 520MB/s。但磁盘 IO 只是存储栈的底层，在应用程序和磁盘
2026-02-11 23:46:42
551
原创 Linux 性能实战 | 第 15 篇 磁盘 IO 性能分析与瓶颈定位 [特殊字符]
🔗 从 Swap 到磁盘：存储性能的最后一环 在第十四章中，我们深入探讨了 Swap 机制——当物理内存不足时，内核将不活跃的匿名页 swap 到磁盘。我们诊断了一个自动驾驶系统的性能崩溃问题，发现每秒 2345KB 的 swap in 和 3456KB 的 swap out 导致 CPU iowa
2026-02-11 23:29:49
965
原创 Linux 性能实战 | 第 14 篇 Swap 使用分析与优化策略
本文深入探讨了Linux系统中Swap的设计原理、优化策略与监控方法。Swap不仅是内存不足时的应急方案，还具有释放不活跃内存页和支持休眠功能。通过分析swappiness参数(0-100)的真实含义，指出其控制内核回收内存时对匿名页和文件页的偏好程度，而非简单的内存使用阈值。文章提供了针对不同场景(如数据库服务器、自动驾驶平台等)的swappiness推荐值，并详细介绍了通过vmstat、sar等工具监控Swap活动的方法，包括关键指标(si/so、pswpin/s等)的解读与性能问题判断标准。最后强调S
2026-02-10 10:02:30
390
原创 Linux 性能实战 | 第 13 篇 虚拟内存与分页机制深度解析
本文深入解析Linux虚拟内存与分页机制，重点探讨了虚拟内存的三大设计目标：隔离性确保进程互不干扰，保护性防止非法访问，共享性提升内存利用率。通过多级页表实现虚拟地址到物理地址的高效转换，利用TLB缓存加速访问。当访问未加载的虚拟页时会触发Page Fault，内核按需分配物理页。文章还分析了共享库、Copy-on-Write等技术如何优化内存使用，并指出TLB失效可能导致的性能问题，为理解Linux内存管理提供了系统视角。
2026-02-10 06:00:00
931
原创 Linux 性能实战 | 第 12 篇 内核内存分配原理与 Slab 分析
本文深入解析Linux内核内存分配机制与Slab原理。内核态内存分配面临高频、固定大小、短生命周期等挑战，传统malloc方式效率低下。Slab分配器通过预分配对象池、批量申请和重复使用等优化手段，显著提升内核对象管理效率。文章对比了kmalloc、vmalloc和kzalloc三种分配接口的特性及适用场景，并详细介绍了GFP标志的使用规范。最后提供/proc/slabinfo和slabtop工具的使用方法，帮助开发者诊断内核内存问题。这些知识对优化自动驾驶等高性能系统至关重要，可有效解决内核内存泄漏和性能
2026-02-09 07:15:00
713
原创 Linux 性能实战 | 第 11 篇 性能计数器与 perf 工具入门
本文介绍了Linux性能优化中CPU性能计数器(PMU)和perf工具的使用方法。主要内容包括： 性能计数器原理：现代CPU内置硬件计数器，可低开销记录指令数、缓存命中/未命中等事件，实现精确性能测量。 perf工具三剑客： perf top：实时显示函数级CPU热点 perf stat：收集程序运行的性能统计指标 perf record：采样记录性能事件供离线分析 关键指标解读：如IPC(指令/周期)、缓存未命中率、分支预测失败率等，帮助定位性能瓶颈。 这些工具使性能优化从"猜测"变为
2026-02-09 06:45:00
2926
原创 Linux 性能实战 | 第 10 篇 CPU 缓存与内存访问延迟
本文探讨了CPU缓存与内存访问延迟对自动驾驶系统性能的影响。现代CPU与主存之间存在100-1000倍的速度差距，导致CPU常处于等待状态。为缓解这一问题，计算机采用多级CPU缓存(L1/L2/L3)和TLB机制。文章通过点云处理案例说明：当数据在L3缓存中时，处理速度可比主存访问快5倍；而随机访问大型特征地图可能导致速度下降10倍。此外还介绍了NUMA架构下本地/远程内存访问的性能差异，并提供了使用perf工具诊断缓存性能的方法。这些内存访问优化对自动驾驶系统实现实时处理至关重要。
2026-02-08 07:45:00
1646
原创 Linux 性能实战 | 第 9 篇 软中断、硬中断与 CPU 占用
本文分析了自动驾驶系统中软中断(si)和硬中断(hi)对CPU性能的影响。当传感器数据流量过大时，si占用率会显著上升，导致感知算法响应延迟。通过top、/proc/interrupts和/proc/softirqs等工具可诊断问题根源。优化方案包括调整传感器参数、CPU核心绑定、网卡中断合并、增大网络缓冲区等。实际优化后，si占用率降低70%，感知算法CPU可用率提升11倍，显著改善系统性能。理解中断机制对自动驾驶等实时系统至关重要。
2026-02-08 06:45:00
732
原创 Linux 性能实战 | 第 8 篇 上下文切换、内核线程与调度延迟
在本章中，我们学会如何量化和定位上下文切换带来的性能损耗。不仅掌握了 `vmstat` 和 `pidstat` 这两个强大的诊断工具，还认识了`kworker` 和 `ksoftirqd` 这两个重要的内核“打工人”
2026-02-07 22:08:24
708
原创 Linux 性能实战 | 第 7 篇 CPU 核心负载与调度器概念
本文深入探讨了CPU核心负载与调度器的工作原理。现代多核系统面临负载不均衡问题，Linux通过SMP架构、CFS调度器和负载均衡机制实现任务分配优化。CFS采用虚拟运行时间（vruntime）确保公平调度，而负载均衡则通过进程迁移避免核心过载。对于实时性要求高的任务，Linux提供SCHED_FIFO和SCHED_RR两种实时调度策略，优先级高于普通进程。文章最后提出CPU隔离与绑定的混合系统调优方案，通过预留核心和任务绑定，平衡实时任务与非实时任务的资源分配。这些机制共同构成了从系统级宏观视图到核心级微观
2026-02-07 22:04:40
784
原创 Linux 性能实战 | 第 6 篇 系统性能基线建立与异常识别
摘要：系统性能基线建立与异常识别 本文介绍了如何从被动性能问题处理转向主动系统健康管理，重点阐述了性能基线的重要性和建立方法。性能基线是系统正常运行状态下的性能指标集合，具有三大核心价值：快速发现异常、量化变更影响和科学容量规划。 文章推荐使用sar工具作为建立基线的核心解决方案，详细讲解了其安装配置、数据收集机制和实用查询技巧。通过多个实战案例展示了如何： 查看CPU历史负载 识别周期性性能问题 捕捉性能毛刺和长尾现象 构建7x24小时自动化性能档案 开发自定义监控脚本 最后提供了将基线数据与告警系统集成
2026-02-06 07:30:00
727
原创 Linux 性能实战 | 第 5 篇 内存指标的工程解读：free / available / buffer / cache
Linux 内存指标解析：从误报到实战 本文深入解析Linux内存指标，揭示free命令背后的真实含义。关键点： 指标误区：free内存低不等于内存紧张，buff/cache占用高通常是系统优化表现 核心指标：available才是判断内存健康的关键，它包含可回收缓存 缓存组成：通过/proc/meminfo可区分Buffers、Cached、Slab等不同类型缓存 性能影响：Dirty页过多会导致I/O突刺，Slab异常增长可能预示内核泄漏 实战案例。
2026-02-06 07:15:00
933
原创 Linux 性能实战 | 第 4 篇（续） “块设备 I/O”，什么是“非块设备 I/O”
本文分析了Linux系统中块设备I/O与非块设备I/O的关键区别。块设备I/O通过块层发起，会被内核明确识别并计入iowait统计；而非块I/O（如网络、锁等待等）虽然同样会阻塞进程并抬高系统负载，但由于不经过块层，CPU的空闲时间不会被统计为iowait。这解释了两种常见现象：当负载高且iowait高时，表明存在块设备I/O瓶颈；而负载高但iowait低时，则可能是网络、NFS或锁等非块I/O导致的阻塞。理解这一区别有助于准确诊断系统性能问题。
2026-02-05 07:45:00
1174
原创 Linux 性能实战 | 第 4 篇 进程状态与 D 状态深度分析
本文深入分析了Linux进程中的D状态（不可中断睡眠）及其系统影响。D状态是内核保护数据一致性的机制，发生在等待关键I/O资源时，进程无法被信号中断。其特征包括无法被kill、不消耗CPU但占用资源，并可能导致系统级问题如load飙升。文章澄清了D状态与load、iowait的关系，指出D状态必定抬高load但不一定增加iowait。通过NFS故障案例展示了D状态风暴的定位与处理方法，强调短期卸载和长期监控策略。同时简要提及Z状态（僵尸进程）的处理原则。最后指出进程状态比CPU指标更能反映系统健康状况。
2026-02-05 06:45:00
1394
原创 Linux 性能实战 | 第 3 篇（续） 如何理解同步 I/O 请求过多
/ 线程在这里阻塞在这次 write 对应的数据“安全完成”之前，线程不返回、不继续执行线程从R（Running）进入等待 I/O 完成再回到 RCPU 当前没有可运行任务，并且系统中存在至少一个线程在等待块设备 I/O（D 状态）所以出现wa有线程在等磁盘（D 状态）CPU 找不到别的 R 状态线程可以跑iowait偏高不一定意味着磁盘性能不足，也可能源于应用层使用了大量同步阻塞式 I/O，导致线程频繁进入 D 状态，从而使 CPU 在无可运行任务时被统计为 iowait。
2026-02-05 06:15:00
1301
原创 Linux 性能实战 | 第 3 篇 CPU 使用率的八种状态拆解
本文深入解析CPU使用率的八种状态（us/sy/ni/id/wa/hi/si/st），帮助精准定位性能瓶颈。通过工具如top、mpstat等获取这些指标，重点分析了iowait（wa）的本质是CPU空闲状态而非忙碌状态，并给出诊断iowait的三步法。文章结合实际案例，如自动驾驶数据录制模块的iowait优化方案，以及网络摄像头导致软中断（si）飙升的问题，说明如何通过状态拆解来对症下药。最后强调硬中断（hi）和软中断（si）对系统响应的影响，为性能优化提供细粒度观测能力。
2026-02-04 07:15:00
1289
原创 Linux 性能实战 | 第 2 篇 Load Average 的三个误区
本文剖析了Linux系统中Load Average的三个常见误区，指出Load并非等同于CPU使用率，而是综合反映可运行（R）和不可中断（D）状态的任务数。文章通过自动驾驶场景案例，说明高Load可能由设备阻塞（D状态）而非CPU繁忙导致。重点强调：1）Load包含R+D状态；2）1/5/15分钟数据反映历史趋势；3）需结合核心数分析。最后提供了排查方法，包括查看/proc/loadavg、统计R/D进程、分析CPU状态等，并针对不同场景给出优化建议。
2026-02-04 06:45:00
615
原创 Linux 性能实战 | 第 1 篇 先定一张“性能地图”：10 分钟判方向的 Linux 五维观察法
本文提出了一种10分钟快速定位Linux性能问题的五维观察法，适用于智能驾驶域控制器等场景。通过建立CPU、内存、磁盘、网络和进程五个维度的"性能地图"，系统性地分析资源使用、等待和竞争情况。文章提供了具体巡检清单和工具推荐，并以自动驾驶雨夜感知延迟案例说明该方法的应用价值。该方法强调先横向判断方向再纵向深入，避免盲目排查，形成可复用的工程化路径。核心思路是先用10分钟快速判断问题维度，再针对性深入分析，提升排查效率。
2026-02-04 06:00:00
1676
原创 Classic AUTOSAR深入浅出系列 - 【第二十三篇】从 ARXML 到代码：配置、生成与调试的完整闭环
ARXML ≠ 配置说明书ARXML = 系统的唯一真相源（Single Source of Truth）RTE API 形态Task / Runnable 的映射关系是否生成 Implicit / Explicit是否插入 Exclusive Area没有一个是“代码层临时决定的”。它们在 ARXML 里，已经被“提前判了刑”。看 ARXML 能脑补代码形态看 Bug 能反推出配置决策知道什么时候“该动配置”，什么时候“不该动代码”那你已经不在「API 使用者」这个层级了。
2026-02-03 06:00:00
243
【计算机视觉】基于蒙特卡洛预处理的GPU加速RANSAC模型：三维点云平面分割中的高效一致性集生成方法
2025-12-28
quaternion.pdf
2020-04-04
road environment modeling using robust perspective analysis
2020-04-11
MIMO技术浅谈.pdf
2020-04-04
转动参考系——位置、速度、加速度详细推导公式.ppt
2020-04-06
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人