Compose Multiplatform桌面端原生内存泄漏排查求助

1. 把ParagraphBuilder节点映射到Kotlin源码定位根源 #

• 保留/获取Skiko调试符号：ParagraphBuilder属于Compose桌面依赖的Skiko库，确保项目编译时保留调试符号，或下载对应版本的Skiko调试包，这样分析堆快照时能直接关联到Skiko源码实现，进而追踪到业务代码的调用点。
• 堆快照+线程栈联动分析：先获取进程ID，执行jmap -dump:format=b,file=heap.hprof <pid>导出堆快照，再用jstack <pid>导出当前线程栈。在IntelliJ等IDE中打开堆快照，搜索ParagraphBuilder实例，查看其引用链，结合线程栈里的文本渲染相关调用，就能定位到触发它创建的Kotlin代码。
• 开启Compose渲染追踪：添加启动参数-Dcompose.debug.render.trace=true，日志会输出文本渲染的详细调用栈，直接找到业务代码中调用Text、AnnotatedString等API的地方。
• 反编译Skiko字节码：如果没有调试符号，用IDE的反编译功能查看Skiko中ParagraphBuilder的调用逻辑，对应到自己代码里的文本渲染逻辑，比如是否频繁创建富文本对象。

2. 需要警惕的第三方库或Compose API #

• Compose文本相关API：频繁动态更新Text内容（尤其是富文本）、重复创建AnnotatedString对象，或使用remember时未正确缓存文本状态，导致ParagraphBuilder反复创建。
• Voyager页面导航：如果页面销毁时，文本相关状态未被正确回收，容易累积大量ParagraphBuilder实例。
• Skiko版本问题：部分旧版本Skiko在段落缓存逻辑上存在原生内存泄漏，建议升级到最新稳定版的Compose Multiplatform尝试解决。
• 协程触发的频繁更新：在协程里高频触发文本渲染更新，却未做好上下文管理，可能导致对象堆积。
• SQLDelight结果转换：频繁将数据库查询结果转为文本内容且未复用对象，间接会导致ParagraphBuilder创建过多。

3. 其他排查原生内存泄漏的有效方法 #

• 开启Skia内存日志：添加启动参数-Dskia.debug.memory=true，Skia会输出原生内存分配的详细日志，可直接追踪文本渲染相关的内存分配情况。
• 系统级工具分析：
  • Linux：用perf record -g <pid>追踪原生内存分配，再用perf report查看调用栈；或valgrind --leak-check=full（注意会大幅降低进程速度，适合小场景测试）。
  • macOS：用Instruments的「Memory Graph」工具，查看原生对象的引用链，找到未释放的内存块。
  • Windows：用Process Explorer查看进程内存细分，或WinDbg加载进程分析原生堆。
• 逐步隔离代码：先注释掉部分功能（比如暂时禁用导航、关闭动态文本更新），观察内存变化，定位到出问题的模块。
• 切换Compose版本：尝试降级或升级Compose Multiplatform，验证是否为版本特定的bug。
• 检查JNI调用：添加-Xcheck:jni启动参数，开启JNI调用检查，排查是否存在JNI对象引用未正确释放的情况。

内容的提问来源于stack exchange，提问作者khebrati