docs: ragdoll

This commit is contained in:
liubinpeng
2020-11-29 20:39:43 +08:00
parent a783e556c2
commit 1c33797c86
8 changed files with 144 additions and 7 deletions

View File

@@ -399,7 +399,7 @@ while (self.isCancelled == NO) {
在计算机科学中,调用堆栈是一种栈类型的数据结构,用于存储有关计算机程序的线程信息。这种栈也叫做执行堆栈、程序堆栈、控制堆栈、运行时堆栈、机器堆栈等。调用堆栈用于跟踪每个活动的子例程在完成执行后应该返回控制的点。
维基百科搜索到 “Call Stack” 的一张图和例子,如下
![调用栈](https://raw.githubusercontent.com/FantasticLBP/knowledge-kit/master/assets/2020-02-08-StackFrame.png)
![函数调用栈](https://raw.githubusercontent.com/FantasticLBP/knowledge-kit/master/assets/2020-02-08-StackFrame.png)
上图表示为一个栈。分为若干个栈帧Frame每个栈帧对应一个函数调用。下面蓝色部分表示 `DrawSquare` 函数,它在执行的过程中调用了 `DrawLine` 函数,用绿色部分表示。
可以看到栈帧由三部分组成:函数参数、返回地址、局部变量。比如在 DrawSquare 内部调用了 DrawLine 函数:第一先把 DrawLine 函数需要的参数入栈;第二把返回地址(控制信息。举例:函数 A 内调用函数 B调用函数B 的下一行代码的地址就是返回地址)入栈;第三函数内部的局部变量也在该栈中存储。
@@ -1944,7 +1944,23 @@ ASLR: `slide` 函数虚拟地址加载到进程内存的随机偏移量,每
### 7. 现状及其改进
在使用了一波业界优秀的的内存监控工具后发现了一些问题,比如 `MLeaksFinder`、`OOMDetector`、`FBRetainCycleDetector`等都有一些问题。比如 `MLeaksFinder` 因为单纯通过 VC 的 push、pop 等检测内存泄露的情况,会存在误报的情况。`FBRetainCycleDetector` 则因为对象深度优先遍历,会有一些性能问题,影响 App 性能。`OOMDetector` 因为没有合适的触发时机。
思路有2种
- `MLeaksFinder` + `FBRetainCycleDetector` 结合提高准确性
- 借鉴头条的实现方案:基于内存快照技术的线上方案,我们称之为——线上 Memory Graph。引用如下
> - 基于 Objective-C 对象引用关系找循环引用的方案适用范围比较小只能处理部分循环引用问题而内存问题通常是复杂的类似于内存堆积Root LeakC/C++层问题都无法解决。
> - 基于分配堆栈信息聚类的方案需要常驻运行对内存、CPU 等资源存在较大消耗,无法针对有内存问题的用户进行监控,只能广撒网,用户体验影响较大。同时,通过某些比较通用的堆栈分配的内存无法定位出实际的内存使用场景,对于循环引用等常见泄漏也无法分析。
核心原理是: 扫描进程中所有的 Dirty 内存,通过内存节点中保存的其他内存节点的地址值,建立起内存节点之间的引用关系的有向图。
全部的讲解可以看[这里]((https://mp.weixin.qq.com/s/4-4M9E8NziAgshlwB7Sc6g))。对于 Memory Graph 的实现细节感兴趣的可以看这篇[文章](https://juejin.cn/post/6895583288451465230)
## 五、 App 网络监控