这是一个专门讨论 idea 的地方。
每个人的时间，资源是有限的，有的时候你或许能够想到很多 idea，但是由于现实的限制，却并不是所有的 idea 都能够成为现实。
那这个时候，不妨可以把那些 idea 分享出来，启发别人。
每个人的时间，资源是有限的，有的时候你或许能够想到很多 idea，但是由于现实的限制，却并不是所有的 idea 都能够成为现实。
那这个时候，不妨可以把那些 idea 分享出来，启发别人。
这是一个创建于 57 天前的主题，其中的信息可能已经有所发展或是发生改变。
目前准备做一个把 log 匹配到代码上的工具，大概是这个样子：
目的是帮忙定位 log ，理解系统运行时发生了什么。
当然我知道大家手动也能搜索到，或者有些大牛扫一眼 log 就知道怎么回事。
但有时候问题牵涉到的模块很多，或者没研究过具体代码。
或者突然丢来一个问题和 log ，借助工具能很快理解代码流转，比一点一点抠架构要快一些。
有人感兴趣吗？
目的是帮忙定位 log ，理解系统运行时发生了什么。
当然我知道大家手动也能搜索到，或者有些大牛扫一眼 log 就知道怎么回事。
但有时候问题牵涉到的模块很多，或者没研究过具体代码。
或者突然丢来一个问题和 log ，借助工具能很快理解代码流转，比一点一点抠架构要快一些。
有人感兴趣吗？
 |
1
julyclyde 57 天前
sourcemap 是不是就是做这个的？
|
 |
2
davin 57 天前
类似于 Sentry Java SDK 的东西么？
|
 |
3
liuchao719 OP @julyclyde 不太一样，sourcemap 是让人看到代码真正的出错行数，这个工具是想把一很多行 log 对应的代码同时展示出来，方便跟着 log 理解代码是怎么走的。
|
|
4
liuchao719 OP @davin Sentry 应该是侧重解决错误，定位错误。 我的想法其实是更偏向于“理解系统运行时发生了什么”，就不管有没有错误，也可以通过 log 快速串联起代码执行路径，感觉更像是一个运行时代码路径追踪工具。
|
|
5
liuchao719 OP 可能我和大家做的方向不太一样，我现在在搞鸿蒙系统开发，从 bsp 到 hal 再到 framework ，只要某个功能出了问题，就得跟全链路。
比如显示不正常，可能得从框架的图层状态，跟到渲染，合成，再到驱动，dts 。 再比如上层 app ANR 了，得从 app 跟到 framework service ，看看究竟系统出了什么问题。 做这个工具的初衷，是快速在眼花缭乱的 log 中，梳理出真正的代码执行流……而不是从每个模块的 readme 开始看起，这样太慢了…… |
 |
6
startisan 56 天前
这个东西做出来是很有用的，以前我也有过类似的想法，在 IDEA 导入 log 文件或者直连服务器定位到日志文件，然后可以根据线程号或者请求唯一 ID ，筛选日志来匹配代码，进一步的话可以根据 log 文件来模拟 IDEA 的 debug 。
不过我也只是想过，没啥实现思路。😂 |
|
7
liuchao719 OP @startisan 不谋而合！其实 log 本身就是精准的运行时，难点还是怎么根据用户意图筛选 log ，以及从 log 和代码中确定真正的执行流。实现基本就是人怎么根据 log 搜代码，程序就怎么搜。
|
 |
8
fulln 56 天前
单纯根据日志里面的堆栈信息定位，可以解决 99 的问题。 至于剩下的 1 ，要解决的话缺少的是需要一个带参数的日志回放系统，因为大部分难定位的问题都是循环套循环，同步转异步。这种情况下很难排查到底是什么情况下中断的异常。
|
|
9
liuchao719 OP @fulln 赞同，要排查这种问题确实很难，log 一般都不会为了调试打印全部参数，而且也不会随处打印，不像断点一样，能精确知道栈和内存。但是从最近用 AI Coding 的经验看，AI 貌似很会加 log ，数量多，而且关键参数信息也比较全。所以感觉日志回放可能是未来调试的大趋势。
|
 |
10
coder001 51 天前
C♯ 基础库 CompilerServices 里面的 CallerFilePath CallerLineNumber CallerMemberName 参数特性
简直是 C 的 __FILE__ 和 __LINE__ 宏，把这些 log 起来就可以准确记录源代码位置 （这里不是 java 板块，我说 C♯ 应该不算离题吧？ |
|
11
liuchao719 OP @coder001 哈哈哈当然不算，开头的图只是 gpt 生成的，其实我是搞 C 的。
C 能打出 file ，line 和 func name 我是知道的，不过你这个真神，居然能打印 caller 。属实涨见识了 其实我还想过编译器插桩，或者搞个 hook 统一打印所有函数的调用记录和参数。不过现阶段看起来没有必要，开销太大，而且有点麻烦，还得搞各种特殊版本。所以现阶段思路还是清洗 log ，RAG 代码然后分析出执行流。 |
Select Language