docs: ragdoll

Chapter1 - iOS/1.30.md

@@ -18,13 +18,14 @@
   Xcode 在 Debug 模式下定义了宏 DEBUG=1 ，所以我们可以在代码中把相关的测试代码写在预编译处理命令 **\#ifdef DEBUG... \#endif** 中间即可，如图所示
 
 ![DEBUG宏在头文件](https://github.com/FantasticLBP/knowledge-kit/raw/master/assets/WX20180626-144101@2x.png)
-  
+
 ![DEBUG宏在代码块](https://raw.githubusercontent.com/FantasticLBP/knowledge-kit/master/assets/WX20180626-144240@2x.png)
 
 * 测试用的 .a 和 .framework  
- 
+
     对于拖拽到工程中的 .a .framework 静态库，可以在 **target->Build Settings->Search Paths**这2个选项，分别设置 **Library Search Paths**和**Framework Search Paths**这2个选项。如果我们需要在测试的时候会用到，那么我们可以将 **Debug** 对应的值留下，删掉**Release** 对应的值。这样我们打包 Release 包的时候就不会包含不需要的包。  
     
+
 ![不需要的包删除即可](https://raw.githubusercontent.com/FantasticLBP/knowledge-kit/master/assets/WX20180626-144819@2x.png)
 
 * CocoPods 引入的库
@@ -81,3 +82,14 @@
 #pragma clang diagnostic pop
 
 
+10. Xcode Instruments 内存泄漏检测工具 Leaks 在内存检测后，无法看到具体的堆栈信息。
+
+    ![Leaks](./../assets/2020-11-25-InstrumentMemoryLeaks.jpg)
+
+    涂上右下方的 `Heaviest Stack Trace` 模块看不到对应的堆栈信息。一番定位问题后发现是工程项目在 debug 阶段，Build Setting 中的 **Debug Information Format** 选项的 debug 条目是没有 dSYM 文件的，我们要想看到堆栈信息，就必须选择 `DWARF with dSYM File` 选项。
+
+    ![](./../assets/2020-11-25-BuildSettingsDebugInformationFormat.png)
+
+    DWARF，即 ***Debug With Arbitrary Record Format*** ，是一个标准调试信息格式，即调试信息。这部分信息可以查看我的[这篇文章](./1.74.md)中讲 iOS 符号化的部分。
+
+11. 

Chapter1 - iOS/1.74.md

@@ -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 Leak，C/C++层问题都无法解决。
+> - 基于分配堆栈信息聚类的方案需要常驻运行，对内存、CPU 等资源存在较大消耗，无法针对有内存问题的用户进行监控，只能广撒网，用户体验影响较大。同时，通过某些比较通用的堆栈分配的内存无法定位出实际的内存使用场景，对于循环引用等常见泄漏也无法分析。
+
+核心原理是： 扫描进程中所有的 Dirty 内存，通过内存节点中保存的其他内存节点的地址值，建立起内存节点之间的引用关系的有向图。
+
+全部的讲解可以看[这里]((https://mp.weixin.qq.com/s/4-4M9E8NziAgshlwB7Sc6g))。对于 Memory Graph 的实现细节感兴趣的可以看这篇[文章](https://juejin.cn/post/6895583288451465230)
+
+ 
 
 ## 五、 App 网络监控