noham/knowledge-kit
1
0
Fork 0
mirror of https://github.com/NohamR/knowledge-kit.git synced 2026-05-25 04:17:17 +00:00
Code Issues Packages Projects Releases Wiki Activity

update: content update

Browse Source
This commit is contained in:
Unix_Kernel
2024-11-13 14:47:32 +08:00
parent dae10db9d4
commit aca020701b
14 changed files with 285 additions and 78 deletions
Download Patch File Download Diff File Expand all files Collapse all files

10
Chapter1 - iOS/1.74.md
View File

@@ -28,7 +28,7 @@ _displayLink = [CADisplayLink displayLinkWithTarget:self selector:@selector(p_di
![显示器和 CPU、GPU 关系](https://raw.githubusercontent.com/FantasticLBP/knowledge-kit/master/assets/2020-02-02-screen_display_gpu.png)
通常，屏幕上一张画面的显示是由 CPU、GPU 和显示器是按照上图的方式协同工作的。CPU 根据工程师写的代码计算好需要现实的内容（比如视图创建、布局计算、图片解码、文本绘制等），然后把计算结果提交到 GPU，GPU 负责图层合成、纹理渲染，随后 GPU 将渲染结果提交到帧缓冲区。随后视频控制器会按照 VSync 信号逐行读取帧缓冲区的数据，经过数模转换传递给显示器显示。
通常，屏幕上一张画面的显示是由 CPU、GPU 和显示器是按照上图的方式协同工作的。CPU 根据工程师写的代码计算好需要显实的内容（比如视图创建、布局计算、图片解码、文本绘制等），然后把计算结果提交到 GPU，GPU 负责图层合成、纹理渲染，随后 GPU 将渲染结果提交到帧缓冲区。随后视频控制器会按照 VSync 信号逐行读取帧缓冲区的数据，经过数模转换传递给显示器显示。
在帧缓冲区只有一个的情况下，帧缓冲区的读取和刷新都存在效率问题，为了解决效率问题，显示系统会引入 2 个缓冲区，即双缓冲机制。在这种情况下，GPU 会预先渲染好一帧放入帧缓冲区，让视频控制器来读取，当下一帧渲染好后，GPU 直接把视频控制器的指针指向第二个缓冲区。提升了效率。
@@ -44,7 +44,7 @@ _displayLink = [CADisplayLink displayLinkWithTarget:self selector:@selector(p_di
设想一个显示器显示第一帧图像和第二帧图像的过程。首先在双缓冲区的情况下，GPU 首先渲染好一帧图像存入到帧缓冲区，然后让视频控制器的指针直接直接这个缓冲区，显示第一帧图像。第一帧图像的内容显示完成后，视频控制器发送 V-Sync 信号，GPU 收到 V-Sync 信号后渲染第二帧图像并将视频控制器的指针指向第二个帧缓冲区。
**看上去第二帧图像是在等第一帧显示后的视频控制器发送 V-Sync 信号。是吗？真是这样的吗？ 😭 想啥呢，当然不是。 🐷 不然双缓冲区就没有存在的意义了**
**看上去第二帧图像是在等第一帧显示后的视频控制器发送 V-Sync 信号。是吗？真是这样的吗？ 当然不是，不然双缓冲区就没有存在的意义了**
揭秘。请看下图
@@ -2131,7 +2131,7 @@ OC 语言：指针指向的内存对象已经被释放或回收了，但是指
#### 什么是僵尸对象？
僵尸对象就是指一个 OC 对象释放后所占用的内存还没被复写（重新分配给其他对象）前被称为僵尸对象。此时僵尸对象内存很不稳定，内存随时可能被系统分配给其他对象所使用。所以此时僵尸对象不应该访问和使用（调用对象的方法等）
僵尸对象就是指一个 OC 对象释放后所占用的内存还没被覆写（重新分配给其他对象）前被称为僵尸对象。此时僵尸对象内存很不稳定，内存随时可能被系统分配给其他对象所使用。所以此时僵尸对象不应该访问和使用（调用对象的方法等）
#### 为什么 OC 野指针 Crash 很多？
@@ -7930,6 +7930,8 @@ runZoned<Future<Null>>(() async {
![](https://raw.githubusercontent.com/FantasticLBP/knowledge-kit/master/assets/2022-0204-SubThreadUIXcode1@2x.png)
本来常见的开发都会规避这些写法，没机会看到子线程操作 UI 的问题，但是 Weex 的业务代码，检测出存在子线程操作 UI 的问题，所以还是有必要增加这个能力的。
其实我们可以给 Xcode 打个 `Runtime Issue Breakpoint` ，type 选择 `Main Thread Checker`， 在发生子线程操作 UI 的时候就会被系统检测到并触发断点，同时可以看到堆栈情况
![](https://raw.githubusercontent.com/FantasticLBP/knowledge-kit/master/assets/2022-0204-SubThreadUISymbolBreakpoints@2x.png)
@@ -7956,7 +7958,7 @@ runZoned<Future<Null>>(() async {
对 [dlopen](https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man3/dlopen.3.html)、[dlsym](https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man3/dlsym.3.html) 陌生的小伙伴可以直接看 Apple 官方文档，这里不做展开。
具体可以参考这个 [saDemo](https://github.com/FantasticLBP/MainThreadChecker)
具体可以参考这个 [Demo](https://github.com/FantasticLBP/MainThreadChecker)
## 十一、页面渲染时长统计