-
-
-
-## Clang
-
-[Clang](http://clang.llvm.org/) 是 LLVM 的一个子项目，基于 LLVM 架构的 c/c++/Objective-C 语言的编译器前端
-
-GCC 是 c/c++ 等的编译器
-
-Clang 相较于 GCC，具备下面优点：
-
-- 编译速度快：在某些平台上，Clang的编译速度显著的快过GCC(Debug模式下编译OC速度比GGC快3倍)
-
-- 占用内存小：Clang 生成的 AST 所占用的内存是 GCC 的五分之一左右
-
-- 模块化设计：Clang 采用基于库的模块化设计，易于 IDE 集成及其他用途的重用
-
-- 诊断信息可读性强：在编译过程中，Clang 创建并保留了大量详细的元数据 (metadata)，有利于调试和错误报告
-
-- 设计清晰简单，容易理解，易于扩展增强
-
-
-
-
-
-## 各个编译阶段
-
-Demo
-
-```c++
-#import 
-
-
-
-可以看到经历了：**输入、预处理、编译、LLVM Backend、汇编、链接、绑定架构**7个阶段。
-
-
-
-### 预处理
-
-查看 preprocessor （预处理）的结果：`clang -E main.m`。预处理主要做的事情就是头文件导入（ include、import）、宏定义替换等。展示如下：
-
-
-
-
-
-### 词法分析
-
-词法分析阶段，主要生成 Token。使用指令 `clang -fmodules -E -Xclang -dump-tokens main.m` 查看具体做了什么
-
-
-
-
-
-### 语法分析
-
-语法分析阶段，生成语法树（AST，Abstract Syntax Tree）。使用指令 `clang -fmodules -fsyntax-only -Xclang -ast-dump main.m` 查看
-
-
-
-对 main.m 的代码进行改造
-
-```
-#import 
-
-其中：
-
-- `FunctionDecl` 节点下存在2个 `ParamVarDecl` 和1个 `CompoundStmt` 也就是2个参数和1个函数体
-- 函数体 `CompoundStmt` 内部存在一个变量声明 `VarDecl`
-- `-`是一个操作符。
-- 红色框框内的是第一层树形结构。操作符 `-` 有2个参数。首先是最下面的字面量 `IntegerLiteral` 4。另一个就是蓝色框内的运算结果
-- 蓝色框内操作符 `+` 也有2个 `DeclRefExpr`
-
-也就是先运算蓝色框内的值，然后用结果和红色框内的进行相减。所以这是很标准的树形结构。
-
-
-
-
-
-### LLVM IR
-
-IR 作为中间语言具有语言无关的特性，下面是 IR 中与语言无关的类型信息：
-
-- 语言共有的基础类型（void、bool、signed 等）
-- 复杂类型，pointer、array、structure、function
-- 弱类型的支持，用 cast 来实现一种类型到另一种任意类型的转换
-- 支持地址运算，getelmentptr 指令用于获取结构体子元素，比如 a.b 或 [a b]
-
-LLVM IR 有3种表示格式：
-
-- text：便于阅读的文本格式，类似于汇编语言，推展名为 `.ll`。使用指令 `clang -S -emit-llvm main.m` 进行转换
-
- 
-
- 学过 arm64 汇编的话看这段 IR 很眼熟，汇编里 `load` 相关的指令都是从内存中装载数据，比如 `ldr`、`ldur` 、`ldp`。`store` 相关的指令是往内存中写入数据，比如 `str`、 `stur`、 `stp`
-
- 一些读 IR 的 tips：
-
- - 注释以分号 `;` 开头
- - 全局变量以 `@` 开头
- - 局部变量以 `%` 开头
- - `alloca` 在当前函数栈帧中分配内存，为当前执行的函数分配内存，当该函数执行完毕时自动释放内存
- - `i32`，表示整数占几位，例如 i32 就代表 32 bit，4个字节的意思
- - `align` 内存对齐。比如单个 int 占4字节，为了对齐，只占1字节的 char 要对齐，就需要占用 4 字节
- - `store` ，写入数据
- - `load` ，读取数据
- - `icmp`，2个整数值比较，返回布尔值
- - `br`，选择分支，根据条件跳转到对应的 label
- - `label`，代码标签
-
- 更多的可以参考[官方文档](https://llvm.org/docs/LangRef.html)
-
-- memory 格式：内存格式
-
-- bitcode：二进制格式，拓展名为 `.bc`.使用指令 `clang -c -emit-llvm main.m` 进行转换。
-
-
-
-## 调试 LLVM
-选择 Edit Scheme.
-
-
-
-
-
-
-最后就可以加断点进行 Debug 了。但为了让调试更有意义，类似 `nm -a /Users/unix_kernel/Library/Developer/Xcode/DerivedData/LDExploreDemo-ehvvtxafpkdkubgrswvvsudzhqbb/Build/Products/Debug-iphonesimulator/LDExploreDemo.app/LDExploreDemo` 一样可以查看到更有意义的信息，可以在 Edit Scheme 面板中 `Run -> Arguments -> Arguments Passed On Launch` section 中的 **+** 点击，添加一些参数，如下图：
-
-
-
-最后允许测试。注意：LLVM 项目较大，可以选择顶部 "Product -> Perform Action -> Run Without Building".
-
-
-## 用途
-
-LLVM 的一些插件，比如 libclang、libTooling，可以查看官方文档：https://clang.llvm.org/docs/Tooling.html，可以做一些**语法树解**
-
-**析、语言转换**等工作。
-
-应用场景分为3大类：
-
-- Clang 插件开发，可以参考官方文档：
-
- - https://clang.llvm.org/docs/ClangPlugins.html
-
- - https://clang.llvm.org/docs/RAVFrontendAction.html
-
- - https://clang.llvm.org/docs/ExternalClangExamples.html
-
- 应用场景是：代码检查（命名规范、代码规范）等。
-
-- Pass 开发，可以参考官方文档：
-
- - https://llvm.org/docs/WritingAnLLVMPass.html
-
- 应用场景是：代码优化、代码混淆、精准测试等
-
-- [libclang](https://clang.llvm.org/doxygen/group__CINDEX.html)、[Clang plugins](https://clang.llvm.org/docs/ClangPlugins.html)、[libTooling](https://clang.llvm.org/docs/LibTooling.html) 做语法树分析，实现语言转换 OC 转 Swift、JS 等其它语言；字符串加密；开发新的语言，例如 Swift 语言。可以参考博客：
-
- - https://kaleidoscope-llvm-tutorial-zh-cn.readthedocs.io/zh-cn/latest/
- - https://llvm-tutorial-cn.readthedocs.io/en/latest/index.html
-
-
-
- 其中：
-
- libclang 供了一个相对较小的 API，它将用于解析源代码的工具暴露给抽象语法树（AST），加载已经解析的 AST，遍历 AST，将物理源位置与 AST 内的元素相关联。
-
- libclang 是一个稳定的高级 C 语言接口，隔离了编译器底层的复杂设计，拥有更强的 Clang 版本兼容性，以及更好的多语言支持能力，对于大多数分析 AST 的场景来说，libclang 是一个很好入手的选择。
-
- ##### 优点
-
- 1. 可以使用 C++ 之外的语言与 Clang 交互。
- 2. 稳定的交互接口和向后兼容。
- 3. 强大的高级抽象，比如用光标迭代 AST，并且不用学习 Clang AST 的所有细节。
-
- ##### 缺点:不能完全控制 Clang AST。
-
-
-
- Clang Plugin 允许你在编译过程中对 AST 执行其他操作。Clang Plugin 是动态库，由编译器在运行时加载，并且它们很容易集成到构建环境中。
-
-
-
- LibTooling 是一个独立的库，它允许使用者很方便地搭建属于你自己的编译器前端工具，它的优点与缺点一样明显，它基于 C++ 接口，读起来晦涩难懂，但是提供给使用者远比 libclang 强大全面的 AST 解析和控制能力，同时由于它与 Clang 的内核过于接近导致它的版本兼容能力比 libclang 差得多，Clang 的变动很容易影响到 LibTooling。libTooling 还提供了完整的参数解析方案，可以很方便的构建一个独立的命令行工具。这是 libclang 所不具备的能力。一般来说，如果你只需要语法分析或者做代码补全这类功能，libclang 将是你避免掉坑的最佳的选择。
-
-
-
-### 编写 Xcode 插件
-
-比如检查类名的合法性，Xcode 默认认为类名带有下划线或者小写开头的类名是合法的。但是这个不符合团队代码规范，使用 LLVM 就可以编写 Xcode 插件，来检查类名的合法性。
-
-判断类名是否合法，这肯定是编译前端做的事情。搞清楚这点，就好办了
-
-接下来就一步步实现该功能。
-
-
-
-#### 下载
-
-创建文件夹 `llvm_explore` ，shell 进入到文件夹执行指令 `git clone https://github.com/llvm/llvm-project.git`
-
-
-
-#### 编译
-
-用 brew 安装 cmake 和 ninja：`brew install cmake` 、`brew install ninja`
-
-Tips：ninja 如果安装失败，可以直接从 [github]( https://github.com/ninja-build/ninja/releases) 获取 release 版放入`/usr/local/bin`中
-
-
-
-编译方式有2种：
-
-- ninja 编译
-
- 在 LLVM 源码同层目录下创建一个 `llvm_build` 目录，最终会在 `llvm_build` 目录下生成 `build.ninja`
-
- ```shell
- cd llvm_build
- cmake -G Ninja ../llvm -DCMAKE_INSTALL_PREFIX=LLVM的安装路径
- ```
-
- 然后执行编译指令，使用 `ninja`
-
- 再执行安装指令，使用 `ninja install`
-
-- Xcode 编译
-
- 在 LLVM 源码同层目录下创建一个 `llvm_xcode_build` 目录
-
- ```shell
- mkdir llvm_xcode_build
- cd llvm_xcode_build
- cmake -S ../../llvm-project/llvm -B ./ -G Xcode -DLLVM_ENABLE_PROJECTS="clang"
- ```
-
-
-因为要编写 Clang 插件，是 c++ 代码，所以需要借助 IDE 的能力，我们选用 Xcode 进行编译。如下图所示，代表编译成功
-
-
-
-
-
-
-
-#### LLVM 角色说明
-
-- LLVM Core：包含一个现在的源代码/目标设备无关的优化器，一集一个针对很多主流(甚至于一些非主流)的 CPU 的汇编代码生成支持。
-- Clang：一个 C/C++/Objective-C 编译器，致力于提供令人惊讶的快速编译，极其有用的错误和警告信息，提供一个可用于构建很棒的源代码级别的工具
-- dragonegg： gcc 插件，可将 GCC 的优化和代码生成器替换为 LLVM 的相应工具。
-- LLDB：基于 LLVM 提供的库和 Clang 构建的优秀的本地调试器。
-- libc++、libc++ ABI：符合标准的，高性能的 C++ 标准库实现，以及对 C++11 的完整支持
-- compiler-rt：针对 __fixunsdfdi 和其他目标机器上没有一个核心 IR(intermediate representation) 对应的短原生指令序列时，提供高度调优过的底层代码生成支持
-- OpenMP：Clang 中对多平台并行编程的 runtime 支持
-- vmkit：基于 LLVM 的 Java 和 .NET 虚拟机
-- polly： 支持高级别的循环和数据本地化优化支持的 LLVM 框架。
-- libclc： OpenCL 标准库的实现
-- klee：基于L LVM 编译基础设施的符号化虚拟机
-- SAFECode：内存安全的 C/C++ 编译器
-- lld： clang/llvm 内置的链接器
-
-
-
-#### 添加插件目录
-
-进入目录 `/Users/unix_kernel/Desktop/LLVM_Explore/llvm-project/clang/tools`：
-
-- 先创建一个插件文件夹 `code-style-validate-plugin`
-
- 
-
-- 编辑 `CMakeLists.txt` 文件，在最后添加 `add_clang_subdirectory(code-style-validate-plugin)`
-
- 
-
-
-
-#### 配置插件
-
-在上一步创建的 `code-style-validate-plugin` 文件夹下：
-
-- 创建插件代码文件 `CodeStyleValidatePlugin.cpp`
-
-- 创建 `CMakeLists.txt` ，添加配置代码，其中 `FANPlugin` 是插件名，CodeStyleValidatePlugin 是插件源码文件名
-
- ```shell
- add_llvm_library(CodeStyleValidatePlugin MODULE BUILDTREE_ONLY
- CodeStyleValidatePlugin.cpp
- )
- ```
-
-
-由于新做了配置，并且要开发 `CodeStyleValidatePlugin.cpp` ，所以重新生成 `cmake -S .https://raw.githubusercontent.com/FantasticLBP/knowledge-kit/master/llvm-project/llvm -B ./ -G Xcode -DLLVM_ENABLE_PROJECTS="clang"`
-
-
-
-#### 编写插件代码
-
-Xcode 打开项目，选择自动创建 Schemes
-
-
-
-
-
-选择 Target 为 `CodeStyleValidatePlugin`，源代码所在文件夹为 `Sources/Loadable modules`，然后选中 CodeStyleValidatePlugin.cpp` 文件进行编写逻辑
-
-
-
-
-
-初步编写后 Command + B 进行编译，在 Products 下可以看到编译产物：`CodeStyleValidatePlugin.dylib` 动态库。
-
-
-
-
-
-#### 编译 clang/clang++
-
-此步骤前需要做一步编译 Clang 的动作。Xcode 打开 LLVM 项目，选中 `ALL_BUILD` target，进行编译，此过程耗时较长（1h+）
-
-此步骤的目的是：在 testLLVM 项目中，加载 `CodeStyleValidatePlugin.dylib` 插件可以成功。因为默认的 Xcode 使用的 clang/clang++ 编译器和编译 `CodeStyleValidatePlugin.dylib` 动态库不是一个版本。不做修改的话，Xcode 加载 `CodeStyleValidatePlugin.dylib` 会报错。所以需要先编译出同一个 LLVM 版本的 clang/clang++。
-
-
-
-
-
-#### Xcode 加载插件
-
-新建一个名字叫做 ` TestLLVM` 的 Xcode 项目。要在 Xcode 中加载指定的动态库，需要修改 Build Settings 配置，操作路径为：`Build Settings -> Other C Flags`。
-
-添加：
-
-- `-Xclang`
-- `-load`
-- `-Xclang`
-- 动态库路径
-- `-Xclang`
-- `-add-plugin`
-- `-Xclang`
-- 插件名称
-
-
-
-
-
-#### 设置编译器
-
-在新创建的 TestLLVM Xcode 项目中加载创建的 `CodeStyleValidatePlugin.dylib` 会报错。原因是：由于 Clang 插件需要使用对应的版本去加载，如果版本不一致则会导致编译错误。如下所示：
-
-
-
-
-
-解决方案是在 Build Setiings 中增加2项用户自定义的设置：
-
-- `CC`：对应的是自己编译的 clang 的绝对路径
-
-- `CXX`：对应的是自己编译的 clang++ 绝对路径
-
-如下所示：
-
-
-
-
-
-继续编译还是会报错，报错如下：
-
-
-
-解决方案为：在 `Build Settings` 栏目中搜索 `index`，将 `Enable Index-Wihle-Building Functionality` 的 ` Default` 改为 `NO`。
-
-
-
-
-
-#### 编译插件，验证正确性
-
-编译项目后，会在编译日志看到 `FANPlugin` 插件的打印信息，说明前面的配置没有问题，接下去就是继续编写 `FANPlugin.cpp` 的逻辑代码，继续验证。
-
-Tips： 由于重新修改了插件的源码，所以每次 Build 构建完 FANPlugin 之后，在 `TestLLVM` Xcode 项目中，最好每次都执行一下 Clean 操作。
-
-编译成功，可以看到在日志中输出了我们编写的日志信息。
-
-
-
-
-
-#### Clang 插件编写说明
-
-- `AnalysisConsumer`：`AnalysisConsumer` 是 clang AST 中做实事儿的接口，根据具体情况 `ASTFrontendAction` 可能对应一个或多个 `AnalysisConsumer`
-- `RecursiveASTVisitor` & `StmtVisitor`：`RecursiveASTVisitor `是顶层的遍历 clang AST 的工具，虽然也能处理 `stmt` 级别的处理，但是终归没有 `StmtVisitor` 用的顺手
-- `PluginASTAction`：clang 插件的关键组件之一。通过 PluginASTAction，可以在编译过程中运行额外的用户定义操作。这个类允许创建 AST 消费者对象，并处理插件命令行参数，以便根据需要执行特定操作。您可以通过实现 `ParseArgs` 方法来处理插件的命令行选项，以及通过覆盖 `getActionType` 方法来确定插件的执行时机，例如在主要操作之前或之后执行。这样的灵活性使得开发人员能够根据需求定制 clang 插件的行为
-- `ASTConsumer` ：用于处理抽象语法树（AST）的重要组件。ASTConsumer 负责遍历和处理由 clang 前端生成的 AST 节点，执行特定的操作或分析。通过实现 ASTConsumer，开发人员可以访问和处理 AST 中的各种节点，例如函数、变量声明、表达式等，以便进行静态分析、代码转换或其他编译器任务
-- `MatchFinder`：提供类似 DSL 的方式用于匹配 AST 节点，用于做进一步的检验，获取节点来做判断或者进一步的处理。
-- `MatchFinder::MatchCallback`：用于在 MatchFinder 中处理匹配结果的回调函数。当 MatchFinder 在抽象语法树（AST）中找到与匹配器描述的模式相匹配的节点时，会调用注册的 MatchCallback 来处理这些匹配结果。MatchCallback 通常包含一些虚拟方法，如 `run()`、`onStartOfTranslationUnit()`、`onEndOfTranslationUnit()` 等，开发人员可以根据需要重写这些方法来实现自定义的处理逻辑。例如，在 `run()` 方法中处理每个匹配结果，在 `onStartOfTranslationUnit()` 方法中处理每个翻译单元的开始，在 `onEndOfTranslationUnit()` 方法中处理每个翻译单元的结束。
-
-
-
-#### 继续完善代码
-
-类名不符合规范的情况。
-
-```objective-c
-#import 
-
-核心思路为：我们要分析类名不符合规范的情况，要精确报错，首先要识别到类名，利用 AST 的能力可以办到（类名在 AST 的 `ObjCInterfaceDecl` 节点上）。然后获取到类名的行号信息，精确报错。
-
-步骤为：
-
-- 注册插件，需要指定 Action 是什么。这里我们指定自定义的继承自 `PluginASTAction` 的 `PluginASTAction`
-- Action 内部会调用 `CreateASTConsumer` 方法，所以需要创建一个继承自 `ASTConsumer` 的 consumer，即 ·`FANCounsumer`
-- Consumer 在 Xcode 解析完 AST 后会调用 `HandleTranslationUnit` 方法，`HandleTranslationUnit` 方法的参数是一个类行为 `ASTContext` 的对象，携带了 AST 的全部信息
-- 然后创建一个 `MatchFinder ` 对象。在构造器里指定 Macther 找什么 `matcher.addMatcher(objcInterfaceDecl().bind("ObjCInterfaceDecl"), &handler)`，以及找到后做什么事情，将找到后的逻辑交给了一个 CallBack，即 `handler` 的 `void run(const MatchFinder::MatchResult &Result)` 方法
-- `size_t pos = decl->getName().find('_')` 用来找类名中有没有下划线 `_`。
-- `pos != StringRef::npos` 不等于 `StringRef::npos` 则说明找到了下划线，则执行括号里面的逻辑
-- `DiagnosticsEngine &D = ci.getDiagnostics()` 对象具有报错能力，`D.Report()`
-- 为了精确报错，需要找到具体的位置信息 `SourceLocation loc = decl->getLocation().getLocWithOffset(pos)`
-
-
-
-完整代码
-
-```c++
-#include 
-
-
-
-
-
-
-
-#### 有没有其他方式？
-
-利用 LLVM 编译前端 Clang + AST 的能力可以解决大多数编译器相关的问题，但是过程可能较为复杂。还有个思路是利用脚本能力，各种脚本语言，比如 Python、Node 都具备 `glob` 模块。`glob` 可以快速匹配并实现字符串的查找能力。
-
-利用关键词 `@interface 类名 : 父类名` 的特点，找到到所有的类名，判断类名带有 "_"，然后将类名保存起来，最后输出有问题的类信息。
-
-
-
-### 检查 Category 中重名的方法
-
-- 使用开源库 [LIEF](https://github.com/lief-project/LIEF) 的能力
-- 脚本 Python、Node glob 模块的快速匹配能力
-- 添加 Xcode 环境变量 `OBJC_PRINT_REPLACED_METHODS`，运行时候会打印出来。参考[官方文档](https://developer.apple.com/library/archive/qa/qa1908/_index.html)
-
- 此处再引申聊聊命名规范的事情。[官方文档](https://developer.apple.com/library/archive/qa/qa1908/_index.html) 也说了 Category 命名的的最佳实践
-
- > ## Category Method Name Best Practice
- >
- > It is not possible to tell whether a given method name will conflict with an existing method defined by the original class because classes often contain private methods that are not listed in the classes interface. Further, a future version of the class may add new methods that clash with methods previously defined in your category. In order to avoid undefined behavior, it’s best practice to add a prefix to method names in categories on framework classes, just like you should add a prefix to the names of your own classes. You might choose to use the same three letters you use for your class prefixes, but lowercase to follow the usual convention for method names, then an underscore, before the rest of the method name.
-
- 简单来说，虽然有些类的方法在 `.m` 中可能存在10个方法，但在 `.h` 中公开了3个方法，然后在迭代的过程中，可能另一个对象也新增了3个方法，这3个方法可能是公开的也可能是私有方法，由于大家都遵循常见的 OC 命名策略（见名知意）所以很容易造成命名 冲突。给 Category 或者动态库、静态库命名最好带前缀，以避免方法冲突。这个好处不只是命名规范上的，更是代码逻辑安全出发的，由于 OC 强大的 Runtime 消息机制，重名的方法容易被调用。
-
- 官方给的例子
-
- ```objective-c
- @interface UIView (MyCategory)
-
- // CORRECT: The method name is prefixed.
- - (BOOL)wxyz_isOccludedByView:(UIView*)otherView;
-
- // INCORRECT: The method name is not prefixed. This method may clash with an existing method in UIView.
- - (BOOL)isOccludedByView:(UIView*)otherView;
-
- @end
- ```
-
- 除了 CI、CD 最后一道防线的拦截外，事前，团队内宣讲统一代码风格，Code Review 阶段看到 Category 方法命名不合理的地方，即使给出严厉的 Comment，也能拦截和规范一部分情况。
-
-- 使用 LLVM 编写 Clang 插件，解析 AST 拿到所有的 `ObjCInterfaceDecl` 信息，然后结合 `ObjCMethodDecl` 信息便可获取 Category 中的 所有方法，再判断方法是否同名
-
-
-
-
-
-### Pass 插桩，实现精准测试
-
-这部分涉及到 Objective-C 和 Swift 的代码插桩逻辑的不同实现，篇幅较大，可以查看这篇文章 [精准测试最佳实践](./1.108.md)
-
-
-
-### 静态检测、静态分析
-
-通过语法树进行代码静态分析，找出非语法性错误。模拟代码执行路径，分析出 control-flow graph(CFG)。
-
-LLVM 项目中 clang 内置了一堆 checker，用于实现 lint。
-
-具体的使用可以查看这篇文章：[质量检测](./1.137.md)
-
-
-
-### CodeGen - IR 代码生成与 OC Runtime 桥接
-
-- Class/Meta Class/Protocol/Category 内存结构生成，并存放在指定的 section 中（如 Class：`_DATA, _objc_classrefs`）
-
-- Non-Fragile ABI：为每个 Ivar 合成 `OBJC_IVAR_$_` 偏移值常量
-
-- 存取 Ivar 的语句(_ivar = 123; int a = _ivar) 转成 base + `OBJC_IVAR_$_` 的形式
-
-- 将语法树中的 `ObjcMessageExpr` 翻译成相应版本的 `objc_msgSend`，super 翻译成 `objc_msgSendSuper`
-
-- 根据修饰符 strong、weak、copy、atomic 合成 @property 自动实现的 setter/getter。处理 `@synthesize`
-
-- ARC：分析对象引用关系，将 `objc_storeStrong` `objc_storeWeak` 等 ARC 代码插入
-
-- 将 ObjcAutoreleasePoolStmt 翻译成 `objc_autoreleasePoolPush`、`objc_autoreleasePoolPop`
-
-- 自动调用 `[super dealloc]`
-
- 
-
-- 为每个拥有 ivar 的 Class 合成` .cxx_destructor` 方法来自动释放类的成员变量，代替 MRC 时代的 `self.xxx = nil`
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
diff --git a/Chapter1 - iOS/1.103.md b/Chapter1 - iOS/1.103.md
deleted file mode 100644
index 28ec154..0000000
--- a/Chapter1 - iOS/1.103.md
+++ /dev/null
@@ -1 +0,0 @@
-# 设计模式及其场景
diff --git a/Chapter1 - iOS/1.104.md b/Chapter1 - iOS/1.104.md
deleted file mode 100644
index 22d3589..0000000
--- a/Chapter1 - iOS/1.104.md
+++ /dev/null
@@ -1,906 +0,0 @@
-# NSNotification底层原理
-
-> 有人聊起来 NSNotification 可以在不同的线程发和接收吗？对于不知道或者不确定的知识，有必要探究记录下
-
-
-
-## NSNotificationCenter
-
-```objectivec
-@property (class, readonly, strong) NSNotificationCenter *defaultCenter;
-// 添加 Observer
-- (void)addObserver:(id)observer selector:(SEL)aSelector name:(nullable NSNotificationName)aName object:(nullable id)anObject;
-// 发送通知
-- (void)postNotification:(NSNotification *)notification;
-- (void)postNotificationName:(NSNotificationName)aName object:(nullable id)anObject;
-- (void)postNotificationName:(NSNotificationName)aName object:(nullable id)anObject userInfo:(nullable NSDictionary *)aUserInfo;
-// 移除通知
-- (void)removeObserver:(id)observer;
-- (void)removeObserver:(id)observer name:(nullable NSNotificationName)aName object:(nullable id)anObject;
-// 添加 Observer
-- (id 
-
-
-
-当调用 UIView `[UIView setNeedsDisplay]` 方法时，系统会立刻调用其 Layer 的同名方法 `[view.layer setNeedsDisplay]` 方法，之后相当于给当前 Layer 打上一个脏标记，之后会在当前 RunLoop 快要结束的时候才会调用 Layer 的 `[CALayer display]` 方法。然后进入当前 UIView 真正的绘制流程中。
-
-其次，会判断 CALayer 的代理，有没有实现 `displayLayer:` 方法
-
-- 如果没有实现，则进入系统的绘制流程：比如：创建绘制上下文、调用 `drawInContext:`、生成内容并赋值给 `contents`
-- 如果实现了，则可能是异步绘制或者自定义渲染的实现。是**代理自定义绘制的入口**。代理可以在这个方法里直接设置`layer.contents`（比如异步绘制生成 UIImage 后赋值给`contents`），完全接管 layer 的内容渲染
-
-
-
-Demo1:
-
-自定义 View，不实现 `displayInContext` 方法
-
-```objective-c
-#import 
-
-
-
-
-
-接下来看看系统的绘制实现流程：
-
-
-
-如何实现异步绘制？
-
-`[layer.delegate displayPlayer:]`
-
-- 代理负责生成对应的 bitmap
-- 设置该 bitmap 作为 layer.contents 属性的值
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-## 渲染机制
-
-
-
-iOS 渲染框架可以分为4层，顶层是 UIKit，包括图形界面的高级 API 和常用的各种 UI 控件。UIKit 下层是 Core Animation，不要被名字误解了，它不光是处理动画相关，也在做图形渲染相关的事情(比如 UIView 的 CALayer 就处于 Core Animation 中)。Core Animation 之下就是由 OpenGL ES 和 CoreGraphics 组成的图形渲染层，OpenGL ES 主要操作 GPU 进行图形渲染，CoreGraphics 主要操作 CPU 进行图形渲染。上面3层都属于渲染图形软件层，再下层就是图形显示硬件层。
-
-iOS 图形界面的显示是一个复杂的流程，一部分数据通过 Core Graphics、Core Image 有 CPU 预处理，最终通过 OpenGL ES 将数据传输给 GPU，最终显示到屏幕上。
-
-
-
-- Core Animation 提交会话(事务)，包括自己和子树(view hierarchy) 的布局状态
-
-- Render Server 解析所提交的子树状态，生成绘制指令
-
-- GPU 执行绘制指令
-
-- 显示器显示渲染后的数据
-
-## Core Animation
-
-
-
-可以看到 Core Animation pipeline 由4部分组成：Application 层的 Core Animation 部分、Render Server 中的 Core Animation 部分、GPU 渲染、显示器显示。
-
-### Application 层 Core Animation 部分
-
-
-
-- 布局(Layout)：`layoutSubviews`、`addSubview`，这里通常是 CPU、IO 繁忙
-
-- 显示(Display)：调用 view 重写的 `drawRect` 方法，或者绘制字符串。这里主要是 CPU 繁忙、消费较多内存。每个 UIView 都有 CALayer，同时图层又一个像素存储控件，存储视图，调用 `setNeedsDisplay` 仅会设置图层为 dirty。当渲染系统准备就绪，调用视图的 `display` 方法，同时装配像素存储空间，建立一个 Core Graphics 上下文(CGContextRef)，将上下文 push 进上下文堆栈，绘图程序进入对应的内存存储空间。
-
-- 准备(Prepare)：图片解码、图片格式转换。GPU 不支持某些图片格式，尽量使用 GPU 能支持的图片格式
-
-- 提交(Commit)：打包 layers 并发送给 Render Server，递归提交子树的 layers。如果子树层级较多(复杂)，则对性能造成影响
-
-### Render Server 中 Core Animation 部分
-
-Render Server 是一个独立的渲染进程，当收到来自 Application 的 (IPC) 事务时，首先解析 layer 层级关系，然后 Decode。最后执行 Draw Calls(执行对应的 OpenGL ES 命令)
-
-### GPU 渲染
-
-- OpenGL ES 的 command buffer 进行定点变换，三角形拼接、光栅话变为 parameter buffer
-
-- parameter buffer 进行像素变化，testing、blending 生成 frame buffe
-
-### 显示器显示
-
-视频控制器从 frame buffer 中读取数据显示在显示屏上。
-
-## UIView 绘制流程
-
-
-
-- 每个 UIView 都有一个 CALayer，layer 属性都有 contents，contents 其实是一块缓存，叫做 backing store
-
-- 当 UIView 被绘制时，CPU 执行 drawRect 方法，通过 context 将数据写入 backing store 中(位图 bitmap)
-
-- 当 backing store 写完后，通过 Render Server 交给 GPU 去渲染，最后显示到屏幕上
-
-
-
-- 调用 `[UIView setNeedsDisplay]` 方法时，并没有立即执行绘制工作，而是马上调用 `[view.layer setNeedsDisplay]` 方法，给当前 layer 打上标记
-
-- 在当前 RunLoop 快要结束的时候调用 layer 的 display 方法，来进入到当前视图真正的绘制流程
-
-- 在 layer 的 display 方法内部，系统会判断 layer 的 layer.delegate 是否实现了 `displayLayer` 方法
-
- - 如果没有，则执行系统的绘制流程
-
- - 如果实现了，则会进入异步绘制流程
-
-- 最后把绘制完的 backing store 提交给 GPU
-
-### 系统绘制流程
-
-
-
-- 首先 CALayer 内部会创建一个 CGContextRef，在 drwaRect 方法中，可以通过上下文堆栈取出 context，拿到当前视图渲染上下文也就是 backing store
-
-- 然后 layer 会判断是否存在代理，若没有，则调用 CALayer 的 drawInContext
-
-- 如果存在代理，则调用代理方法。然后做当前视图的绘制工作，然后调用 view 的 drawRect 方法
-
-- 最后由 CALayer 上传对应的 backing store(可以理解为位图)提交给 GPU。
-
-### 异步绘制流程
-
-
-
-- 如果 layer 有代理对象，且代理对象实现了代理方法，则可以进入异步绘制流程
-
-- 异步绘制流程中主要生成对应的 bitmap。目的是最后一步，需要将 bitmap 设置为 layer.contents 的值
-
- - 左侧是主队列，右侧是全局并发队列
-
- - 调用了setNeedsDiaplay 方法后，在当前 Runloop 将要结束的时候,会有系统调用视图所对应 layer 的 display 方法
-
- - 通过在子线程中去做位图的绘制，此时主线程可以去做些其他的工作。在子线程中：主要通过 CGBitmapContextCreate 方法,来创建一个位图的上下文、通过CoreGraphic API，绘制 UI、通过 CGBitmapContextCreatImage 方法，根据所绘制的上下文，生成一张 CGImage 图片
-
- - 然后再回到主队列中，提交这个位图，设置给 CALayer 的 contents 属性
-
-## 图片加载库都做了什么事
-
-众所周知，iOS应用的渲染模式，是完全基于Core Animation和CALayer的（macOS上可选，另说）。因此，当一个UIImageView需要把图片呈现到设备的屏幕上时候，其实它的Pipeline是这样的：
-
-1. 一次Runloop完结 ->
-2. Core Animation提交渲染树CA::render::commit ->
-3. 遍历所有Layer的contents ->
-4. UIImageView的contents是CGImage ->
-5. 拷贝CGImage的Bitmap Buffer到Surface（Metal或者OpenGL ES Texture）上 ->
-6. Surface（Metal或者OpenGL ES）渲染到硬件管线上
-
-这个流程看起来没有什么问题，但是注意，Core Animation库自身，虽然支持异步线程渲染（在macOS上可以手动开启），但是UIKit的这套内建的pipeline，全部都是发生在主线程的。
-
-因此，当一个CGImage，是采取了惰性解码（通过Image/IO生成出来的），那么将会在主线程触发先前提到的惰性解码callback（实际上Core Animation的调用，触发了一个`CGDataProviderRetainBytePtr`），这时候Image/IO的具体解码器，会根据先前的图像元信息，去分配内存，创建Bitmap Buffer，这一步骤也发生在主线程。
-
-这个流程带来的问题在于，主线程过多的频繁操作，会造成渲染帧率的下降。实验可以看出，通过原生这一套流程，对于一个1000*1000的PNG图片，第一次滚动帧率大概会降低5-6帧（iPhone 5S上当年有人的测试）。后续帧率不受影响，因为是惰性解码，解码完成后的Bitmap Buffer会复用。
-
-所以，最早不知是哪个团队的人（可能是[FastImageCache](https://github.com/path/FastImageCache)，不确定）发现，并提出了另一种方案：通过预先调用获取Bitmap，强制Image/IO产生的CGImage解码，这样到最终渲染的时候，主线程就不会触发任何额外操作，带来明显的帧率提升。后面的一系列图片库，都互相效仿，来解决这个问题。
-
-具体到解决方案上，目前主流的方式，是通过CGContext开一个额外的画布，然后通过`CGContextDrawImage`来画一遍原始的空壳CGImage，由于在`CGContextDrawImage`的执行中，会触发到`CGDataProviderRetainBytePtr`，因此这时候Image/IO就会立即解码并分配Bitmap内存。得到的产物用来真正产出一个CGImage-based的UIImage，交由UIImageView渲染。
-
-## ForceDecode的优缺点
-
-上面解释了ForceDecode具体解决的问题，当然，这个方案肯定存在一定的问题，不然苹果研发团队早已经改变了这套Pipeline流程了
-
-优点：可以提升，图像第一次渲染到屏幕上时候的性能和滚动帧率
-
-缺点：提前解码会立即分配Bitmap Buffer的内存，增加了内存压力。举例子对于一张大图（2048*2048像素，32位色）来说，就会立即分配16MB(2048 * 2048 * 4 Bytes)的内存。
-
-由此可见，这是一个拿空间换时间的策略。但是实际上，iOS设备早期的内存都是非常有限的，UIKit整套渲染机制很多地方采取的都是时间换空间，因此最终苹果没有使用这套Pipeline，而是依赖于高性能的硬件解码器+其他优化，来保证内存开销稳定。当然，作为图片库和开发者，这就属于仁者见仁的策略了。如大量小图渲染的时候，开启Force Decode能明显提升帧率，同时内存开销也比较稳定。
-
-
-
-
-
-## iOS 图片解压缩到渲染过程
-
-- 假设我们使用 `+imageWithContentsOfFile:` 方法从磁盘中加载一张图片，这个时候的图片并没有解压缩
-
-- 然后将生成的 `UIImage` 赋值给 `UIImageView`
-- 接着一个隐式的 `CATransaction` 捕获到了 `UIImageView` 图层树的变化
-- 在主线程的下一个 `runloop` 到来时，`Core Animation` 提交了这个隐式的 `transaction` ，这个过程可能会对图片进行 `copy` 操作，而受图片是否字节对齐等因素的影响，这个 `copy` 操作可能会涉及以下部分或全部步骤
- - 分配内存缓冲区用于管理文件 IO 和解压缩操作
- - 将文件数据从磁盘读到内存中
- - 将压缩的图片数据解码成未压缩的位图形式，这是一个非常耗时的 CPU 操作
- - 最后 `Core Animation` 中 `CALayer` 使用未压缩的位图数据渲染 `UIImageView` 的图层
- - CPU 计算好图片的 Frame,对图片解压之后.就会交给 GPU 来做图片渲染
-- 渲染流程
- - GPU 获取图片的坐标
- - 将坐标交给顶点着色器（顶点计算）
- - 将图片光栅化（获取图片对应屏幕上的像素点）
- - 片元着色器计算（计算每个像素点的最终显示颜色值）
- - 从帧缓存区中渲染到屏幕上
-
-我们提到了图片的解压缩是一个非常耗时的 CPU 操作，并且它默认是在主线程中执行的。那么当需要加载的图片比较多时，就会对我们应用的响应性造成严重的影响，尤其是在快速滑动的列表上，这个问题会表现得更加突出
-
-
-
-## 为什么要解压缩图片
-
-既然图片的解压缩很耗费 CPU 时间，那么为什么还要对图片进行解压缩？是否可以不解压缩直接显示图片？不能
-
-
-
-其实位图，就是一个像素数组，数组中的每个像素就代表图片中的一个点。平时遇到的 png、jpeg 就是位图。
-
-
-
-```objective-c
-UIImage *image = [UIImage imageNamed:@"text.png"];
-CFDataRef rawData = CGDataProviderCopyData(CGImageGetDataProvider(image.CGImage));
-```
-
-rawData 就是图片原始数据。
-
-jpg、png 都是一种压缩格式，只不过 png 是无损压缩，支持 alpha 通道。而 jpeg 是有损压缩，可以指定0～100%压缩比。iOS 提供2个函数来生成 png、jpeg 图片。
-
-```objective-c
-// return image as PNG. May return nil if image has no CGImageRef or invalid bitmap format
-UIKIT_EXTERN NSData * __nullable UIImagePNGRepresentation(UIImage * __nonnull image);
-
-// return image as JPEG. May return nil if image has no CGImageRef or invalid bitmap format. compression is 0(most)..1(least)
-UIKIT_EXTERN NSData * __nullable UIImageJPEGRepresentation(UIImage * __nonnull image, CGFloat compressionQuality);
-```
-
-所以，在磁盘的图片渲染到屏幕之前，必须先得到图片的原始像素数据，才可以执行后续的操作。所以必须先解压缩。
-
-
-
-## 图片解压缩原理
-
-既然图片的解压缩不可避免，而我们也不想让它在主线程执行，影响 App 性能，那么是否有比较好的解决方案呢？
-
-我们前面已经提到了，当未解压缩的图片将要渲染到屏幕时，系统会在主线程对图片进行解压缩，而如果图片已经解压缩了，系统就不会再对图片进行解压缩。因此，也就有了业内的解决方案，在**子线程提前对图片进行强制解压缩**。
-
-而强制解压缩的原理就是**对图片进行重新绘制，得到一张新的解压缩后的位图**。其中，用到的最核心的函数是 `CGBitmapContextCreate`
-
-```objective-c
-CG_EXTERN CGContextRef __nullable CGBitmapContextCreate(void * __nullable data,
- size_t width, size_t height, size_t bitsPerComponent, size_t bytesPerRow,
- CGColorSpaceRef cg_nullable space, uint32_t bitmapInfo)
- CG_AVAILABLE_STARTING(__MAC_10_0, __IPHONE_2_0);
-```
-
-参数说明：
-
-- data：如果不为 `NULL` ，那么它应该指向一块大小至少为 `bytesPerRow * height` 字节的内存；如果 为 `NULL`，那么系统就会为我们自动分配和释放所需的内存，所以一般指定 `NULL` 即可；
-- width 和 height ：位图的宽度和高度，分别赋值为图片的像素宽度和像素高度即可；
-- bitsPerComponent：像素的每个颜色分量使用的 bit 数，在 RGB 颜色空间下指定 8 即可；
-- bytesPerRow ：位图的每一行使用的字节数，大小至少为 `width * bytes per pixel` 字节。当我们指定 0/NULL 时，系统不仅会为我们自动计算，而且还会进行 `cache line alignment` 的优化
-- space ：就是我们前面提到的颜色空间，一般使用 RGB 即可；
-- bitmapInfo ：位图的布局信息.`kCGImageAlphaPremultipliedFirst`
-
-
-
-参考 YYImage/SDWebImage 都有图片解压缩的实现
-
-```objective-c
-CGImageRef YYCGImageCreateDecodedCopy(CGImageRef imageRef, BOOL decodeForDisplay) {
- ...
-
- if (decodeForDisplay) { // decode with redraw (may lose some precision)
- CGImageAlphaInfo alphaInfo = CGImageGetAlphaInfo(imageRef) & kCGBitmapAlphaInfoMask;
-
- BOOL hasAlpha = NO;
- if (alphaInfo == kCGImageAlphaPremultipliedLast ||
- alphaInfo == kCGImageAlphaPremultipliedFirst ||
- alphaInfo == kCGImageAlphaLast ||
- alphaInfo == kCGImageAlphaFirst) {
- hasAlpha = YES;
- }
-
- // BGRA8888 (premultiplied) or BGRX8888
- // same as UIGraphicsBeginImageContext() and -[UIView drawRect:]
- CGBitmapInfo bitmapInfo = kCGBitmapByteOrder32Host;
- bitmapInfo |= hasAlpha ? kCGImageAlphaPremultipliedFirst : kCGImageAlphaNoneSkipFirst;
-
- CGContextRef context = CGBitmapContextCreate(NULL, width, height, 8, 0, YYCGColorSpaceGetDeviceRGB(), bitmapInfo);
- if (!context) return NULL;
-
- CGContextDrawImage(context, CGRectMake(0, 0, width, height), imageRef); // decode
- CGImageRef newImage = CGBitmapContextCreateImage(context);
- CFRelease(context);
-
- return newImage;
- } else {
- ...
- }
-}
-```
-
-自己也可以实现
-
-```objective-c
-- (void)setImage {
- SP_BEGIN_LOG(custome, gl_log, imageSet);
- [self decodeImage:[UIImage imageNamed:@"peacock"] completion:^(UIImage *image) {
- self.imageView.image = image;
- SP_END_LOG(imageSet);
- }];
-}
-
-- (void)decodeImage:(UIImage *)image completion:(void(^)(UIImage *image))completionHandler {
- if (!image) return;
- //在子线程执行解码操作
- dispatch_async(dispatch_get_global_queue(0, 0), ^{
- CGImageRef imageRef = image.CGImage;
- //获取像素宽和像素高
- size_t width = CGImageGetWidth(imageRef);
- size_t height = CGImageGetHeight(imageRef);
- if (width == 0 || height == 0) return ;
- CGImageAlphaInfo alphaInfo = CGImageGetAlphaInfo(imageRef) & kCGBitmapAlphaInfoMask;
- BOOL hasAlpha = NO;
- //判断颜色是否含有alpha通道
- if (alphaInfo == kCGImageAlphaPremultipliedLast ||
- alphaInfo == kCGImageAlphaPremultipliedFirst ||
- alphaInfo == kCGImageAlphaLast ||
- alphaInfo == kCGImageAlphaFirst) {
- hasAlpha = YES;
- }
- //在iOS中，使用的是小端模式，在mac中使用的是大端模式，为了兼容，我们使用kCGBitmapByteOrder32Host，32位字节顺序，该宏在不同的平台上面会自动组装换成不同的模式。
- /*
- #ifdef __BIG_ENDIAN__
- # define kCGBitmapByteOrder16Host kCGBitmapByteOrder16Big
- # define kCGBitmapByteOrder32Host kCGBitmapByteOrder32Big
- #else //Little endian.
- # define kCGBitmapByteOrder16Host kCGBitmapByteOrder16Little
- # define kCGBitmapByteOrder32Host kCGBitmapByteOrder32Little
- #endif
- */
-
- CGBitmapInfo bitmapInfo = kCGBitmapByteOrder32Host;
- //根据是否含有alpha通道，如果有则使用kCGImageAlphaPremultipliedFirst，ARGB否则使用kCGImageAlphaNoneSkipFirst，RGB
- bitmapInfo |= hasAlpha ? kCGImageAlphaPremultipliedFirst : kCGImageAlphaNoneSkipFirst;
- //创建一个位图上下文
- CGContextRef context = CGBitmapContextCreate(NULL, width, height, 8, 0, CGColorSpaceCreateDeviceRGB(), bitmapInfo);
- if (!context) return;
- //将原始图片绘制到上下文当中
- CGContextDrawImage(context, CGRectMake(0, 0, width, height), imageRef);
- //创建一张新的解压后的位图
- CGImageRef newImage = CGBitmapContextCreateImage(context);
- CFRelease(context);
- UIImage *originImage =[UIImage imageWithCGImage:newImage scale:[UIScreen mainScreen].scale orientation:image.imageOrientation];
- //回到主线程回调
- dispatch_async(dispatch_get_main_queue(), ^{
- !completionHandler ?: completionHandler(originImage);
- });
- });
-}
-```
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
diff --git a/Chapter1 - iOS/1.106.md b/Chapter1 - iOS/1.106.md
deleted file mode 100644
index 23df224..0000000
--- a/Chapter1 - iOS/1.106.md
+++ /dev/null
@@ -1,256 +0,0 @@
-# NSUserDefault 底层原理探究
-
-最近看到字节一篇文章 [卡死崩溃监控原理及最佳实践](https://mp.weixin.qq.com/s?__biz=MzI1MzYzMjE0MQ==&mid=2247488080&idx=1&sn=39d0386b97b9ac06c6af1966f48387fc&chksm=e9d0d9b2dea750a4a7d21fd383aefa014d63f0dc79f2e3a13c97ad52bba1578dca8b50d6a40a&scene=21&cur_album_id=1590407423234719749#wechat_redirect) ，里面写到 NSUserDefault 底层实现存在直接或者间接跨进程通信，在主线程同步调用容易卡死。以前只是用过，但是没有仔细研究，看到这里就有必要研究下底层实现啦。
-
-## 回顾
-
-NSUserDefault 不安全。因为数据自动保存在沙盒的 `Libarary/Preferences` 目录下。
-
-数据按照 plist （property list）格式存储在沙盒中。当攻击者破解 App 就可轻而易举拿到里面的数据（可能有些人会将 token、password、secret 明文存在里面）
-
-另外 App 卸载重装会导致之前存储的数据丢失。这里推荐使用 Keychain。Keychain 是 iOS 提供的安全存储数据的方案，用于存储一些账号、密码等敏感信息。数据也不在沙盒中，即使删除 App，重新安装则可以继续从 Keychain 中获取数据。
-
-NSUserDefaults 的原理和 plist 序列化不同。
-
-iOS 上应用必须被沙盒化，各个不同 App 之间的 Defaults Domain 不一样，通常是 Bundle Identifier，或者是 App Group 中约定的 Suite Name。当使用 NSUserDefaults 的时候会按照下面 Domain 顺序：
-
-- NSArgumentDomain
-
-- 应用的 Bundle Identifier
-
-- NSGlobalDomain
-
-- 系统语言的标识符
-
-- NSRegistrationDomain
-
-任何应用，通过 NSUserDefaults 访问值都需要经历从上到下搜索各个 Domain 的过程，期间如何某个 Domain 有这个值，就会取出其对应的值。如果全部访问完还是没找到，则返回 undefined result。
-
-## 如何保证多线程安全
-
-通过设置符号断点可以看出， NSUserDefaults 内部在读写时会通过 `os_unfair_lock` 加锁进行多线程安全保护。
-
-
-
-## 存储性能如何
-
-查看 GUN 源码
-
-```c
-- (BOOL) synchronize
-{
- BOOL isLocked = NO;
- BOOL wasLocked = NO;
- BOOL shouldLock = NO;
- BOOL defaultsChanged = NO;
- BOOL hasLocalChanges = NO;
- // 合法性校验
- if ([removed count] || [added count] || [modified count])
- {
- hasLocalChanges = YES;
- }
- if (YES == hasLocalChanges && NO == [owner _readOnly])
- {
- shouldLock = YES;
- }
- if (YES == shouldLock && YES == [owner _lockDefaultsFile: &wasLocked])
- {
- isLocked = YES;
- }
- NS_DURING
- {
- NSFileManager *mgr;
- NSMutableDictionary *disk;
- // 利用 NSFileManager 读取文件
- mgr = [NSFileManager defaultManager];
- disk = nil;
- if (YES == [mgr isReadableFileAtPath: path])
- {
- NSData *data;
- // 文件存在，则将里面的内容读取出来
- data = [NSData dataWithContentsOfFile: path];
- if (nil != data)
- {
- id o;
- // 将文件数据利用 NSPropertyListSerialization 序列化为 NSDictionary 信息
- o = [NSPropertyListSerialization
- propertyListWithData: data
- options: NSPropertyListImmutable
- format: 0
- error: 0];
- // 将之前已经持久化好的本地文件数据写入到 disk 可变字典
- if ([o isKindOfClass: [NSDictionary class]])
- {
- disk = AUTORELEASE([o mutableCopy]);
- }
- }
- }
- if (nil == disk)
- {
- disk = [NSMutableDictionary dictionary];
- }
- loaded = YES;
- // 判断是否有新数据
- if (NO == [contents isEqual: disk])
- {
- defaultsChanged = YES;
- if (YES == hasLocalChanges)
- {
- NSEnumerator *e;
- NSString *k;
- // 从标记为待删除的数据中遍历，删除 disk 可变字典中的数据
- e = [removed objectEnumerator];
- while (nil != (k = [e nextObject]))
- {
- [disk removeObjectForKey: k];
- }
- // 遍历需要添加的数据，添加到 disk 中
- e = [added objectEnumerator];
- while (nil != (k = [e nextObject]))
- {
- [disk setObject: [contents objectForKey: k] forKey: k];
- }
- // 遍历需要修改的数据，添加到 disk 中
- e = [modified objectEnumerator];
- while (nil != (k = [e nextObject]))
- {
- [disk setObject: [contents objectForKey: k] forKey: k];
- }
- }
- // 将 disk 数据拷贝到 contents
- ASSIGN(contents, disk);
- }
- if (YES == hasLocalChanges)
- {
- BOOL written = NO;
-
- if (NO == [owner _readOnly])
- {
- if (YES == isLocked)
- {
- // 判断 contents 字典是否有值，没有则给指定路径写入 nil
- if (0 == [contents count])
- {
- /* Remove empty defaults dictionary.
- */
- written = writeDictionary(nil, path);
- }
- else
- {
- /* Write dictionary to file.
- */
- // 判断 contents 字典有值，则将 contents 给指定路径写入
- written = writeDictionary(contents, path);
- }
- }
- }
- // 写入成功删除内存缓存
- if (YES == written)
- {
- [added removeAllObjects];
- [removed removeAllObjects];
- [modified removeAllObjects];
- }
- }
- if (YES == isLocked && NO == wasLocked)
- {
- isLocked = NO;
- [owner _unlockDefaultsFile];
- }
- }
- NS_HANDLER
- {
- fprintf(stderr, "problem synchronising defaults domain '%s': %s\n",
- [name UTF8String], [[localException description] UTF8String]);
- if (YES == isLocked && NO == wasLocked)
- {
- [owner _unlockDefaultsFile];
- }
- }
- NS_ENDHANDLER
- return defaultsChanged;
-}
-```
-
-会发现：性能也就那么回事，底层实现通过内存缓存 `contents` 来缓存数据写入文件。
-
-## NSUserDefaults 为什么触发 XPC 通信
-
-通过对代码添加符号断点 `xpc_connection_send_message_with_reply_sync` 可以看到下面的堆栈
-
-
-
-执行 `[NSUserDefaults standardUserDefaults];` 可以发现是调用了 XPC，创建名称为 “com.apple.cfprefsd.daemon” 的 XPC Connection，且会发送一个 `xpc_connection_send_message_with_reply_sync` 的消息。
-
-执行 `[defaults setObject:@"杭城小刘" forKey:@"name"];` 会调用 `xpc_connection_send_message_with_reply_sync`，发送一个消息。
-
-通过 Demo 得出结论：
-
-- `NSUserDefaults` 调用 `set...forKey:`， 会触发 XPC 通信，调用 `...ForKey:` 、`synchronized` 不会调用 XPC 通信
-
-- 为了提高性能，尽量减少调用 `set...forKey:`
-
-## 异步持久化
-
-XPC 该`xpc_connection_send_message_with_reply_sync` API 因为 XPC 同步通信，所以在主线程容易存在卡死。那么有没有异步调用的能力？
-
-发现2个 API 可以用于异步发送
-
-- xpc_connection_send_message
-
-- xpc_connection_send_message_with_reply
-
-所以想异步持久化，则需要自定义 XPC Connection，然后将数据用 xpc_dictionary_create 创造出的 Dictionary 去接，最后调用 `xpc_connection_send_message_with_reply` 去持久化数据
-
-```objectivec
- xpc_connection_t conn = xpc_connection_create_mach_service("com.apple.cfprefsd.daemon", NULL, XPC_CONNECTION_MACH_SERVICE_PRIVILEGED);
-#pragma mark - 开始构建信息
-// (lldb) po $rsi
-// 
-
-但，这些回归还是不能 cover 所有问题，我们需要为我们写的每行代码买单，如何衡量每行代码的效果呢？这就是精准测试要做的事情。
-
-iOS 工程来说，跨端项目暂时不在本文范畴，Native 侧主要是 OC 和 Swift 为主。本文将会从 OC/ Swift 2个技术栈展开说说如何获取精准测试覆盖率报告。
-
-
-
-## Objective-C 代码覆盖率
-
-### 理论分析
-
-#### 覆盖率检测原理
-
-统计代码覆盖率的实现抓手就是对代码进行插桩，OC 是 C 语言的一个超集，而 LLVM 诞生自 GCC，我们可以使用 GCC 的插桩器对 OC 代码进行编译插桩，具体流程如下：
-
-
-
-在编译阶段指定 `-fprofile-arcs` `-ftest-coverage` 等测试选项，LLVM 会做这么几件事：
-
-- 在输出目标文件中留出一段存储区保存统计数据
-
- 打开一个插桩工程，查看 MachO 文件可以印证。可以看到 `__llvm_prf_cnts`、`__llvm_prf_data` 、`__llvm_prf_names`、`__llvm_prf_vnds`、`__llvm_covfun`、`__llvm_covmap` 等 section 就是存储插桩信息的空间。
-
- 
-
-- 在源代码中为每个 Basic Block 进行插桩（Basic Block 下文会讲）
-
- 可以看到 `showAssets` 方法内存在一个 if，即2个 Basic Block，所以通过汇编查看的话，存在2个插桩点。
-
- 
-
-- 产生 `.gcno` 文件，它包含 Basic Block 和相应的源码行号信息
-
-- 在最终可执行文件中，进入 main 函数之前调用 `gcov_init` 内部函数初始化统计数据区，并将 `gcov_init` 内部函数注册为`exit_handers`，用户代码调用 exit 正常结束时，`gcov_exit` 函数得到调用，并继续调用 `__gcov_flush` 输出统计数据到 `.gcda` 文件。
-
-
-
-生成覆盖率报告，首先需要在 Xcode 中配置编译选项，编译后会为每个可执行文件生成对应的 **`.gcno`** 文件；之后在代码中调用覆盖率分发函数，会生成对应的 **`.gcda`** 文件。
-
-其中，`.gcno` 包含了代码计数器和源码的映射关系， `.gcda` 记录了每段代码具体的执行次数。覆盖率解析工具需要结合这两个文件给出最后的检测报表。
-
-
-
-#### .gcno
-
-利用 Clang 分别生成源文件的 AST 和 IR 文件，对比发现，AST 中不存在计数指令，而 IR 中存在用来记录执行次数的代码。查看 LLVM 源码可以看到 `GCDAProfiling.c` ，该文件主要作用是：覆盖率映射关系生成源码。
-
-覆盖率映射关系生成源码是 LLVM 的一个 Pass，用来向 IR 中插入计数代码并生成 .gcno 文件（关联计数指令和源文件）。
-
-
-
-
-
-
-
-#### Basic Block
-
-从编译器角度出发，基本块（Basic Block，BB）是代码执行的基本单元，LLVM 基于 BB 进行覆盖率计数指令的插入。BB 特点是：
-
-- 只有1个入口
-- 只有1个出口
-- 只要 BB 中第一条指令被执行，那么 BB 中所有指令都会按顺序执行1次
-
-1个 BB 中，不包含其他的 jump/return/if/switch 等流程控制语句，也就是一个最小可执行单元。
-
-基本块 BB 是程序中一个顺序执行的**语句序列**，同一个 BB 中所有语句的执行次数一定相同，一般由多个顺序执行语句后跟一个跳转语句组成。
-
-从一个 BB 到另一个 BB 的跳转称为一个 ARC。
-
-
-
-#### GCOV 工作原理
-
-如果跳转语句是有条件的，就产生了一个分支（ARC），该基本块就有2个基本块作为目的地。如果把每个基本块当作一个节点，那么一个函数中 的所有基本块就构成了一个有向图, 称之为基本块图. 只要知道 BB 或 ARC 的执行次数就可以推算出所有 的 BB 和所有的 ARC 的执行次数. GCOV 根据 BB 和 ARC 的统计情况来统计各 BB 内各行代码执行情况, 从而计算整个程序的覆盖率情况。
-
-
-
-
-
-
-
- 也就是说插桩的数量和函数内的代码行数、函数数量都不是一一对应的关系。**插桩数量和 BB 个数一一对应**。
-
-这样设计的好处是：BB 的概念存在已久，利用现有能力进行功能拓展（插桩分析覆盖率），而不是为每行原始代码都插桩，从而大大减少了可执行文件的大小并且提高了执行的速度，同时还能够精确分析到所有代码的执行情况。x
-
-覆盖率计数指令的插入会进行两次循环，外层循环遍历编译单元中的函数，内层循环遍历函数的基本块。函数遍历仅用来向 `.gcno` 中写入函数位置信息。
-
-对下面方法展示控制流程图展示：
-
-```objective-c
-- (void)showAssets {
- NSLog(@"I am a rich man");
- if (self.name) {
- [self.cat play];
- } else {
- NSLog(@"I am nobody");
- }
-}
-```
-
-
-
-
-
-
-
-#### .gcon 计数符号和文件位置关联信息
-
-`.gcon` 文件存储着计数插桩位置和源文件之间的关联信息。`GCOVPass` 通过2层循环插入计数指令的同时，会将文件及 BB 信息写入 `.gcon` 文件。
-
-- 创建 `.gcno` 文件，写入 Magic number(oncg + version)
-- 随着函数遍历写入文件地址、函数名和函数在源文件中的起止行数（标记文件名，函数在源文件对应行数）
-- 随着 BB 遍历，写入 BB 编号、BB 起止范围、BB 的后继节点编号（标记基本块跳转关系）
-- 写入函数中BB对应行号信息（标注基本块与源码行数关系）
-
-
-
-`.gcon` 文件由4部分组成：
-
-- 文件结构
-- 函数结构
-- BB 结构
-- BB 行结构
-
-
-
-
-
-#### .gcda
-
-关于 `.gcda` 的逻辑可以查看源码的 [GCDAProfiling.c 文件](https://github.com/llvm/llvm-project/blob/main/llvm/lib/Transforms/Instrumentation/GCOVProfiling.cpp)，也是覆盖率相关的核心逻辑。
-
-```c++
-void GCOVProfiler::emitGlobalConstructor(
- SmallVectorImpl
-
-
-
-Xcode 导出 `.gcda` 的时候，断点查看汇编如下
-
-
-
-
-
-#### .info 文件
-
-拿到 `.gcno` 和 `.gcda` 文件后，我们可以使用 LCOV 工具（基于 gcov ）来生成这个源代码文件的覆盖率信息。
-
-覆盖率信息 `.info` 文件包含以下内容：
-
-1. TN：测试用例名称
-2. SF：源码文件路径
-3. FN：函数名及行号
-4. FNDA：函数名及执行次数
-5. FNF：函数总数
-6. FNH：函数执行数
-7. DA：代码行及执行次数
-8. LF：代码总行数
-9. LH：代码执行行数
-
-在增量覆盖率信息统计的步骤中，覆盖率信息文件新增了用于统计增量信息的字段：
-
-1. CA：差异代码行及执行次数
-2. CF：差异代码行总数
-3. CH：差异代码行执行数
-
-
-
-#### 完整流程
-
-
-
-- 编译前, 在编译器中加入编译器参数 `-fprofile-arcs` `-ftest-coverage`
-- 源码经过编译预处理, 在生成汇编文件的阶段完成插桩，生成可执行文件，并且生成关联 BB 和跳转次数 ARC 的 `.gcno` 文件
-- 运行可执行文件，随着功能被执行，打点插桩的计数值不断更新，收集程序的执行信息
-- 生成具有 BB 和 ARC 的执行统计次数等数据的 `.gcda` 文件
-- 通过 lcov、genhtml 将代码覆盖率信息生成 html 格式的报告
-
-
-
-### 工程实践
-
-第一步，在 Xcode Build Settings 中，修改 Clang 编译参数 `Instrument Program Flow`、 `Generate Legacy Test Coverage File` 为 true，打开后即**开启插桩能力**。
-
-
-
-第二步，为了控制代码覆盖率保存的位置和文件名，需要我们设置一下 GCC 提供的环境变量
-
-- `GCOV_PREFIX` 环境变量用于指定代码覆盖率文件的存储路径
-- `GCOV_PREFIX_STRIP `环境变量用于指定在存储路径中去除的前缀部分。
-
-```objective-c
-NSString *covFilePath = [NSHomeDirectory() stringByAppendingPathComponent:@"Documents/coverage_files"];
-setenv("GCOV_PREFIX", [covFilePath cStringUsingEncoding: NSUTF8StringEncoding], 1);
-setenv("GCOV_PREFIX_STRIP", "100", 1);
-```
-
-第三步，开启插桩后即拥有了原始 BB 信息，也开启了插桩。等待用户操作 App 后，即记录了 BB 执行信息，这些信息需要被写入 `.gcda` 中。早期版本是 `gcov_flush()`。可以看到 `_gcov_flush` 已经不能用了，发现官方已经是 `_gcov_dump` 。修改后编译通过。
-
-```c++
-extern void __gcov_dump(void);
-__gcov_dump();
-```
-
-
-
-
-
-第四步，运行代码。完成测试后，我在屏幕点击事件里，将 BB 执行情况写入到 `.gcda` 中。
-
-
-
-第五步，获取 `.gcno` 信息。编译器生成与源代码同名的 `.gcno` 文件（note file），这种文件含有重建基本块依赖图和将源代码关联至基本块及源代码行号的必要信息。
-
-Xcode 选择 products，show In Finder。然后上上层的 `Intermediates.noindex` 目录存储，继续往下寻找，我个人电脑上路径为：`/Users/unix_kernel/Library/Developer/Xcode/DerivedData/CodeCoverageDemo-enpprvshxhvihgavktgzcmeoertf/Build/Intermediates.noindex/CodeCoverageDemo.build/Debug-iphonesimulator/CodeCoverageDemo.build/Objects-normal/x86_64`，存储了 `.gcno` 信息。
-
-
-
-
-
-
-
-
-
-第六步，将 `.gcno` 和 `.gcda` 文件，保存到一个文件夹下
-
-
-
-
-
-第七步，利用 `lcov` 指令可以将 `.gcno` 文件和 `.gcda` 文件结合生成代码覆盖率结果 info 文件
-
-指令格式为：`lcov -c -d . -o CodeCoverage.info` ，其中 `.` 代表当前目录
-
-`CodeCoverage.info` 文件内容大概如下（各个字段代表什么上面 info 文件这一节有说明）。
-
-
-
-
-
-第八步，利用指令 `genhtml -o html CodeCoverage.info` 将 info 文件和源代码文件结合转化为可视化网页形式。
-
-注意：执行 genhtml 指令必须保证和项目源代码（Xcode 项目叫 CodeCoverageDemo，源码则在 CodeCoverageDemo/CodeCoverageDemo 下）在同一文件夹下否则会报错。
-
-
-
-访问覆盖率路径为 html 目录下，和项目同名的文件夹里面的 `index.html`
-
-
-
-第九步，通过类的列表，针对覆盖率低的文件，点进去看看，看看那些代码没有被执行。思考是什么原因造成的：
-
-- if...else 代码是由于测试条件不满足，测试 case 不充足，导致另一个 case 没有被覆盖？？
-- 某些兜底代码太多，根本走不到？？？
-
-
-
-其中：蓝色部分代码已经执行的代码，橘色代表未执行的代码
-
-第十步，假设我们在另一台设备上进行了测试，对剩余的测试任务内容进行完善，这个时候该怎么处理？Demo 以针对 Person 类的覆盖率完善为例。
-
-1. 在另一台测试剩余 case 的机器上，执行测试流程。得到测试结果，即 `.gcda` 文件
-
-2. 新建测试数据分析文件夹 `CodeCoverageAnalysis2`
-
-3. 将上一步得到的 `.gcda` 文件拷贝到 ``CodeCoverageAnalysis2` 里面
-
-4. 进入打包产物 App 所在文件夹，进入文件夹 `Build/Intermediates.noindex/CodeCoverageDemo.build/Debug-iphonesimulator/CodeCoverageDemo.build/Objects-normal/x86_64`，可以看到一堆类似 `AppDelegate.d`、 `AppDelegate.dia` `AppDelegate.gcno` 、`AppDelegate.o` 这样的文件。同样移动到 ``CodeCoverageAnalysis2` 里面
-
- 
-
-5. 在 `CodeCoverageAnalysis2` 目录下利用指令 `lcov -c -d . -o CodeCoverage2.info` 生成新的一份覆盖率信息 `CodeCoverage2.info`
-
-6. 然后利用 `locv -a` 指令合并2个 `.info` 文件。指令为 `lcov -a CodeCoverage2.info -a https://github.com/FantasticLBP/knowledge-kit/raw/master/CodeCoverageAnalysis/CodeCoverage.info -o CodeCoverageCombined.info`
-
-7. 然后利用 `genhtml` 生成合并后的覆盖率可视化 html 文件 `genhtml -o html CodeCoverageCombined.info`
-
-8. 查看分析最新的覆盖率报告
-
-
-
-
-
-### 缺陷
-
-Person 类的 showAssets 方法，内部有 Cat 相关逻辑，且 Cat 是 Swift 代码。为什么在代码覆盖列表上看不到 Cat？
-
-
-
-因为，clang 是一个基于 LLVM 的编译器前端，它可以编译多种编程语言，包括 C、C++、Objective-C 和 Objective-C++。然而，虽然 clang 本身基于 LLVM，但它并不是 Swift 语言的默认编译器。Swift 语言的官方编译器是 **swiftc**，是基于 LLVM 但专门为 Swift 语言设计的。
-
-接下来看看 Swift 代码，如何获取代码覆盖率
-
-
-
-### 工程化
-
-工程化要解决的3个问题是：
-
-- 一般来说，iOS 现在采用模块化的方式：壳工程 + 各个业务域子工程 + 3方模块。可通过 ruby 脚本修改壳工程和相应的业务工程的编译配置，开启编译插桩能力。一般对于 Debug 包来说不插桩，所以需要有个配置文件，来对各个模块进行配置。
-- 单个版本不断测试，生成的代码覆盖率信息如何合并
-- 多版本增量覆盖率
-- 打包平台及其服务侧
-
-
-
-### 模块化配置
-
-对于各个模块在什么模式下插桩的配置， `CodeCoverageConfig.rb`
-
-```ruby
-ENABLE_PROJECTS = {
- "XXX/XXXPhone.xcodeproj" => "Enterprise",
- "XXXHD/XXXHD.xcodeproj" => "Enterprise",
- "Pods/XXXGoods.xcodeproj" => "Enterprise",
- // ...
-}
-```
-
-Ruby 脚本利用 [xcodeproj](https://github.com/CocoaPods/Xcodeproj) 对每个 target 的编译参数 `GCC_INSTRUMENT_PROGRAM_FLOW_ARCS` 、`GCC_GENERATE_TEST_COVERAGE_FILES`进行修改以开启插桩能力
-
-```ruby
-require 'xcodeproj'
-CONFIG_DIR = Pathname.new(File.join(File.dirname(__FILE__), ".https://github.com/FantasticLBP/knowledge-kit/raw/master/../..")).realpath
-CONFIG_FILE = File.join(CONFIG_DIR, "CodeCoverageConfig.rb")
-
-def update(args)
- enable = args[0] == "true" ? "YES" : "NO"
- debug = args[1] == "true" ? true : false
- load "#{CONFIG_FILE}"
- projects = ENABLE_PROJECTS
- projects.each do | proj, conf |
- proj_file = File.join(CONFIG_DIR, proj)
- project = Xcodeproj::Project.open(proj_file)
- project.build_configurations.each do |config|
- next if debug && config.name != "Debug"
- next if !debug && config.name != conf
- config.build_settings['GCC_INSTRUMENT_PROGRAM_FLOW_ARCS'] = enable
- config.build_settings['GCC_GENERATE_TEST_COVERAGE_FILES'] = enable
- end
- project.save
- end
-end
-
-update(ARGV)
-```
-
-
-
-### 单版本覆盖率
-
-代码不变的情况下，发现 QA 或者开发自己测试的情况下，发现代码覆盖率不高，测试没有全面，则继续测试。这样生成多分 `.gcda` 文件，
-
-- 生成覆盖率：`lcov -c -d {$SOURCE} -o {$DEST_INFO}`，比如 `lcov -c -d . -o CodeCoverage2.info`
-- 合并覆盖率：`lcov -a {$SOURCE_INFO_1} -a {$SOUCE_INFO_2} -o {$DEST_INFO}`，比如 `lcov -a CodeCoverage2.info -a https://github.com/FantasticLBP/knowledge-kit/raw/master/CodeCoverageAnalysis/CodeCoverage.info -o CodeCoverageCombined.info`
-
-
-
-### 多版本增量覆盖率
-
-一个常见的场景是，开发同学基于业务需求 A 做完功能，QA 测试后导出覆盖率报告，发现覆盖率较低；或者 QA 提了3个测试 Bug，开发针对这2个情况，去修改了代码，重新打包让 QA 回归。这个时候 QA 不会重新点点，较好的做法是只回归遗漏或者有问题的代码。
-
-
-
-核心思路是：基于上个版本的覆盖率数据，利用 git diff 查找出变化的部分，然后将旧版本覆盖率 `.info` 里面喝 git diff 得出的变化的部分关联，将值更新到新测试后的覆盖率 `.info` 里面。
-
-
-
-git diff 如何解读
-
-
-
-
-
-其中
-
-- `index.txt` 是文件名
-- `@@ -3,6 +3,6 @@` ，- 代表删除，+ 代表增加。整体意思为从第3行开始，删除了6行，从第3行开始，增加了6行
-
-所以步骤如下：
-
-- 解析 git diffFile：
- - 根据文件名匹配规则 `diff --git (.*)` 将 diffFile 解析为若干个文件的数组集合 diffInfoList，并且保存文件信息
- - 根据 diff 块匹配规则 `@@(.*)@@` 将每个文件的 diffInfo 解析为若干个 diff 块的 blockInfoList，并且保存块信息
- - 根据增 / 删代码匹配规则 `(\+|\-)(.*)` 将每个块的 blockInfo 解析为若干个修改行号的增 / 删行数，并保存增 / 删信息 `{'delLine': 3, 'delCount': 6, 'addLine': 3, 'addCount': 6}`
-
-- 解析 info 文件
- - 根据文件名匹配 `SF:*end_of_record:` 规则将 info 解析为若干个文件的 fileInfoList，并且保存文件信息
- - 根据函数行、函数执行次数、代码行及执行次数匹配规则 `FN、FNDA、DA` 将每个文件的 fileInfo 解析为若干个执行信息的 daList，并且保存数据信息 `{'lineNo': 12, 'exeCount': 1, 'funName': 'eat'}`
-
-- 生成 info 文件
- - 根据 diffFile 解析结果，遍历 blockInfo 匹配起始修改行号 `delLine` 及修改行数 `diffline = addCount - delCount`，将 info 的解析结果进行行号匹配和增 / 删操作 `if (lineNo > delLine) lineNo += diffLine`，修改 fileInfoList 。这一步其实就是根据 git diff 信息，将新的覆盖率中的 lineNo 进行更新
- - 将新的 fileInfoList 中的数据根据 info 的结构进行写入文件操作
-
-完成行号平移之后，两个版本的 .info 文件中的数据已经对齐了行号，可以用上述 LCOV 工具进行合并，合并完成后，用行号标记来统计差异的代码覆盖率数据。
-
-
-
-### 打包平台及其服务侧
-
-- 编写脚本在打包插桩后，将 `.gcno` 和源代码等信息上传到文件服务器上
-- 移动端各个测试设备测试后，App 可视化导出精准测试覆盖率报告，一键将 `.gcda` 文件上传到文件服务器上
-- 上传 `.gcda` 触发任务，利用 lcov 处理展示报告，同时也保存到文件服务器上
-- 最后 lark、企业微信通知能力，发送报告链接给开发、QA和相关人员
-- 同时 mPass 项目平台，买票上高铁的项目列表也有入口可以展示查看精准覆盖率报告
-
-
-
-## Swift 代码覆盖率
-
-这部分我将介绍：
-
->- 如何生成 `.profraw` 文件并通过命令行测量代码覆盖率
->- 如何在 Swift 项目里调用 c/c++ 方法
->
->- 如何在 Xcode 中测量完整 Swift App 项目的代码覆盖率
-
-
-
-### 理论支撑
-
-#### 编译器参数支持
-
-思路同 Objective-C 一样，参看 swiftc 编译器的编译参数 `swiftc --help` 可以看到
-
-
-
-可以看到这2个参数是大概收集代码覆盖率相关的。
-
-
-
-#### MachO 和汇编插桩验证
-
-利用 MachOView 查看产物里的 Mach-O 文件发现，MachO 多了一些和 LLVM 相关的 section，这些 section 看名字猜出来都是用来统计覆盖率的。
-
-
-
-当 Xcode 开启 Swift 插桩统计后，打断点查看汇编代码可以发现，在 sayHi 方法，也就是只有1个 Basic Block 的情况下，编译器只插入1个桩，插桩1次。
-
-
-
-可以把 `__profc_xxx` 理解为打点计数信息，具体的地址保存在 MachO 文件的 `__DATA` 段 `__llvm_prf_cnts` 节点中。在程序刚启动时，所有的计数器信息为0，每当该代码（BB块）被执行1次，其计数值会加一。
-
-重要的2个参数：
-
-- `-profile-generate`：负责插桩代码的生成，是统计插桩信息用来的。`__llvm_prf` 段。
-- `-profile-coverage-mapping` ：则生成一些 LLVM 相关的 `__LLVM_COV` 段。
-
-之所以要做这样的拆分，猜测可能的原因是，插桩信息除了可以用于覆盖率分析以外，还可以用来进行 PGO 优化。什么是 PGO？即 Profile Guided Optimization ，是编译器用于提升 Application 的性能的一项技术。具体可以查看这篇文章[编译器利用 PGO 优化 App 性能](./1.133.md)
-
-
-
-#### 导出原理
-
-`llvm-cov` 如何生成报告的？因为 `.profdata` 文件只有 BB 计数器的调用次数，在生成覆盖率的时候传入了源码，那计数器信息和源码关联应该就是靠 MachO 文件了。
-
-[LLVM Code Coverage Mapping Format](https://llvm.org/docs/CoverageMappingFormat.html#high-level-overview) 也说明了该细节
-
-> LLVM’s code coverage mapping format is designed to be a self contained data format that can be embedded into the LLVM IR and into object files. It’s described in this document as a **mapping** format because its goal is to store the data that is required for a code coverage tool to map between the specific source ranges in a file and the execution counts obtained after running the instrumented version of the program.
->
-> The mapping data is used in two places in the code coverage process:
->
-> 1. When clang compiles a source file with `-fcoverage-mapping`, it generates the mapping information that describes the mapping between the source ranges and the profiling instrumentation counters. This information gets embedded into the LLVM IR and conveniently ends up in the final executable file when the program is linked.
-> 2. It is also used by *llvm-cov* - the mapping information is extracted from an object file and is used to associate the execution counts (the values of the profile instrumentation counters), and the source ranges in a file. After that, the tool is able to generate various code coverage reports for the program.
-
-LLVM 的代码覆盖率映射格式被设计为一种自包含的数据格式，可以嵌入 LLVM IR 和 `.o` 文件中。在本文档中，它被描述为映射格式，因为它的目标是存储代码覆盖率工具在文件中的特定源范围和运行插入指令的程序版本后获得的执行计数之间进行映射所需的数据。
-在代码覆盖过程中，映射数据用于两个位置：
-
-- 当 clang 使用 `-fcoverage-mapping` 编译源文件时，它会生成描述源范围和分析检测计数器之间映射的映射信息。这些信息被嵌入LLVM IR中，并在链接程序时方便地最终出现在最终的可执行文件中。
-- 它也被 `llvm-cov` 使用-映射信息从对象文件中提取，用于关联文件中的执行计数（配置文件检测计数器的值）和源范围
-
-在此之后，该工具能够为程序生成各种代码覆盖率报告。
-
-
-
-完整流程为：
-
-
-
-覆盖率生成流程为：编译阶段使用 `-profile-generate` 和 `-profile-coverage-mapping ` 参数，其中` -profile-generate` 会开启插桩能力，为每个 BB 增加插桩代码，`-profile-coverage-mapping` 将记录 BB、计数器值、和文件源码的关联映射信息，并将这些信息存储在编译产物，也就是 `__LLVM_COV` 段中。编译产物运行的过程中， 随着 BB 被执行，计数器的值会不断增加，并且写入 `__DATA` 段。运行结束后生成 `.profraw` 文件，可以处理成 `.profdata` 文件，该文件记录了每个计数器以及调用次数。
-
-覆盖率解析流程为：利用指令提供的源代码路径，和可执行文件信息，结合 `.profdata` 信息，产出覆盖率报告。具体原理是：遍历 `profdata` 中的每一个计数器，先根据可执行文件中存储的映射关系，找到这个计数器所对应统计的那一段源码，从而生成行级别的覆盖率信息。
-
-
-
-### 实验
-
-用简单的单个 Swift 文件进行理论分析。
-
-第一步，创建一个名为 `test.swift` 的文件，内容如下：
-
-```swift
-func sayHi() {
- print("Hello swift world")
-}
-
-func add(_ x: Int, _ y: Int) -> Int {
- return x + y
-}
-
-func minuse(_ x: Int, _ y: Int) -> Int {
- return x - y
-}
-
-sayHi()
-print(add(2, 4))
-```
-
-第二步，在终端命令行，`test.swift` 所在路径下执行下面指令 `swiftc -profile-generate -profile-coverage-mapping test.swift`
-
-传递给编译器的选项 `-profile-generate` 和 `-profile-coverage-mapping` 将在编译源码时启用覆盖率特性。基于源码的代码覆盖功能直接对 AST 和预处理器信息进行操作。
-
-第三步，运行二进制文件 `./test`。然后在当前目录执行 `ls`，可以看到多出了一个名为 `default.profraw` 的文件。该文件由 llvm 生成，目的是衡量代码覆盖率。我们必须使用配套工具 llvm-profdata 来组合多个原始配置文件并同时对其进行索引。
-
-第四步，终端运行指令 `xcrun llvm-profdata merge -sparse default.profraw -o coverage.profdata`，得到一个名为 `coverage.profdata` 的文件，进一步处理，它可以用来展示覆盖率报告。
-
-第五步，在终端运行指令得到覆盖率信息
-
-```shell
-xcrun llvm-cov show ./test -instr-profile=coverage.profdata
-xcrun llvm-cov export ./test -instr-profile=coverage.profdata
-```
-
-整个步骤也可以看这张图
-
-
-
-在 `test.swift` 中编写的3个函数，只有2个执行了。查看覆盖率可以证实这一点，minuse 函数没有被执行。
-
-
-
-### 工程实践
-
-第一步，创建 Swift 项目，编写测试代码
-
-```swift
-// Cat.swift
-import Foundation
-class Cat {
- var kind: String
- init(kind: String) {
- self.kind = kind
- }
-
- func play() {
- print("I am a \(kind) cat, I am playing now.")
- }
-}
-
-// Person.swift
-import Foundation
-class Person {
- var name: String
- var cat: Cat?
-
- init(name: String, cat: Cat? = nil) {
- self.name = name
- self.cat = cat
- }
-
- func sayHi() {
- print("Hello world, I am \(name), I have a \(String(describing: cat?.kind)) cat")
- }
-
- func eat() {
- print("eat")
- }
-
- func sleep() {
- print("sleep")
- }
-
- func play() {
- cat?.play()
- }
-}
-```
-
-第二步，选择 ` Build Settings -> Swift Compiler — Custom Flags`，在 Other Swift Flags 添加 `-profile-generate` 和 `-profile-coverage-mapping` 选项。
-
-
-
-
-
-第三步，开启覆盖率收集选项
-
-
-
-第四步，要将覆盖率信息导出前，必须要调用 llvm 的一些 c/c++ api，所以要将需要用到的方法，导出为一个模块。
-
-创建一个名为 `InstrProfiling.h` 的头文件。内容为：
-
-```c++
-#ifndef PROFILE_INSTRPROFILING_H_
-#define PROFILE_INSTRPROFILING_H_int __llvm_profile_runtime = 0;void __llvm_profile_initialize_file(void);
-
-const char *__llvm_profile_get_filename();
-void __llvm_profile_set_filename(const char *);
-int __llvm_profile_write_file();
-int __llvm_profile_register_write_file_atexit(void);
-const char *__llvm_profile_get_path_prefix();
-
-#endif /* PROFILE_INSTRPROFILING_H_ */
-```
-
-创建一个 `module.modulemap` 文件并将所有内容导出为一个模块(创建的时候 Xcode 选择 empty 模版)
-
-```shell
-module InstrProfiling {
- header "InstrProfiling.h"
- export *
-}
-```
-
-第五步，判断时机，在需要导出覆盖率的地方编写函数。我在 ViewController 点击屏幕的时候导出:
-
-- 导入模块 `import InstrProfiling`
-- 编写导出方法 `__llvm_profile_set_filename` 和 `__llvm_profile_write_file`
-
-````
-import UIKit
-import InstrProfiling
-
-class ViewController: UIViewController {
- var cat: Cat?
- var person: Person?
-
- override func viewDidLoad() {
- super.viewDidLoad()
-
- self.cat = Cat(kind: "Ragdoll")
- self.person = Person(name: "FantasticLBP", cat: cat)
- }
-
- override func touchesBegan(_ touches: Set
-
-第七步，因为产出覆盖率的时候需要用到 MachO 文件。所以在项目根目录下创建名为 `DataAnalysis` 的文件夹。在终端利用 mv 将产物里的 MachO 移动到 `DataAnalysis` 文件夹下。也将 `.profraw` 移动进去。
-
-
-
-第八步，利用指令 `xcrun llvm-profdata merge -sparse SwiftCodeCoverage.profraw -o SwiftCodeCoverage.profdata`，将 `.profraw` 转换成 `.profdata` 文件
-
-第九步，利用指令 `xcrun llvm-cov show ./SwiftCodeCoverage.app/SwiftCodeCoverage -instr-profile=SwiftCodeCoverage.profdata` 在终端查看代码的覆盖情况
-
-
-
-第十步，终端查看代码执行情况还是不够直观，可以用 `llvm-cov` 命令生成 HTML 格式的覆盖率报告，指令格式为：
-
-```shell
-xcrun llvm-cov show\
- -use-color\ # 彩色报告
- -format=html\ # HTML 格式
- -arch=x86_64\ # 架构指令集
- -instr-profile=${.profdata 路径}\ # 指定 .profdata 文件路径
- ${MachO 文件路径}\ # 指定 MachO文件路径
- ${SourceCode 路径} # 项目源代码路径
- -output-dir ${Swift覆盖率报告路径} # 指定覆盖率报告保存的路径
-```
-
-我这边具体指令为：
-
-`xcrun llvm-cov show -use-color -format=html -arch=x86_64 -instr-profile=SwiftCodeCoverage.profdata SwiftCodeCoverage https://github.com/FantasticLBP/knowledge-kit/raw/master/ -output-dir ./SwiftCodeCoverageReport `
-
-第十一步，查看整体的覆盖率信息与单个文件的覆盖率，查看代码执行情况
-
-其中 `index.html` 是所有文件的覆盖率数据汇总，而每个文件精确到行级别的覆盖率信息，则保存在 `coverage` 文件夹中，每个文件对应一个 HTML 文件。
-
-
-
-第十二步，假设我们在另一台 CI 机器上也在执行测试任务。那不同机器上的测试结果如何合并？
-
-生成覆盖率报告是基于插桩实现的，最后 `xcrun llvm-cov` 生成 html 需要的是：Mach-O 文件、源代码路径、`.profdata` 文件。
-
-看得出来不同 CI 机器上，不同的只有 `.profdata` 文件，所以处理 `.profdata` 即可。所幸 `llvm-profdata` 就支持不同的 `.profraw` 的合并。
-
-比如第一台机器生成的是 `SwiftCodeCoverage.profraw` 得到的覆盖率如上图所示。第二台机器生成的是 `SwiftCodeCoverage.profraw`。
-
-接下去利用指令 ` xcrun llvm-profdata merge SwiftCodeCoverage.profraw SwiftCodeCoverage2.profraw -o SwiftCodeCoverageCombined.profdata` 将2份测试原始文件进行合并，然后再利用 `llvm-cov` 生成 html 报告
-
-
-
-第十三步，我们有时候有需求会更改操作生成的测试文件，`.profdata` 是没办法修改的，但 `llvm-profdata` 指令可以传递参数生成 `.text` 格式的文件，里面的内容可以修改。修改后再从 `.text` 转换为 `.profdata`，最后再利用 `llvm-cov` 生成 html 报告。
-
-下面演示下如何修改生成的覆盖率数据（注意：不修改 html，而是修改 BB 的计数值）
-
-1. 利用 ` xcrun llvm-profdata merge SwiftCodeCoverage.profraw SwiftCodeCoverage2.profraw -text -o SwiftCodeCoverageCombined.txt` 将2份 `.profraw` 数据合并为 `.txt` 格式的文件（记录了 BB 和技术值信息）
-
- 
-
-2. 编辑修改 `.txt` BB 的计数值，此处，故意把 `Person:sleep` 的1改为0
-
-3. 利用指令将 `.txt` 改为 `.profdata` 格式。`xcrun llvm-profdata merge SwiftCodeCoverageCombined.txt -o SwiftCodeCoverageCombinedFromText.profdata`
-
-4. 再根据合并后的 `.profdata` 生成 html 覆盖率报告。`xcrun llvm-cov show -use-color -format=html -arch=x86_64 -instr-profile=SwiftCodeCoverageCombinedFromText.profdata SwiftCodeCoverage https://github.com/FantasticLBP/knowledge-kit/raw/master/ -output-dir ./SwiftCodeCoveragCombinedReportFromText`
-
-效果如下：
-
-
-
-
-
-
-
-## 心得感悟
-
-下面是一个工作中的实际例子，冒烟用例也全部通过了，代码在 CR 后 MR 了，然后买票上车，开始高铁回归阶段。
-
-
-
-
-
-
-
-QA 去回归测试，然后会给开发一个精准测试报告。就是原始的本次业务开发分支上的代码执行情况。程序员去分析，覆盖率低的原因是什么，是兜底代码太多、还是某些技术实现是类似夸端的 Weex、RN、Flutter、还是测试 case 不充分以至于看上去用例通过，但是某些代码还是没有测试到，往往这些没有测试到、执行到的代码是线上用户在极端情况下容易走到的 case。所以需要根据精准测试覆盖率反推 QA 完善用例，或者开发自己优化代码。
-
-精准测试的价值很明显，但 ROI 就见仁见智了，有些人觉得要开发一套 CI 需要耗时耗力，每个项目完成后需要分析精准测试报告、反推 QA 完善用例很麻烦，但有些决策者就觉得这样能 cover 一些平时难以发现的问题。
-
-
-
-## 参考文章
-
-[Source-based Code Coverage](https://clang.llvm.org/docs/SourceBasedCodeCoverage.html#source-based-code-coverage)
-
-[llvm-cov - emit coverage information](https://llvm.org/docs/CommandGuide/llvm-cov.html)
-
-[LLVM Code Coverage Mapping Format](https://llvm.org/docs/CoverageMappingFormat.html#llvm-code-coverage-mapping-format)
-
-
-
diff --git a/Chapter1 - iOS/1.109.md b/Chapter1 - iOS/1.109.md
deleted file mode 100644
index f14415e..0000000
--- a/Chapter1 - iOS/1.109.md
+++ /dev/null
@@ -1,1023 +0,0 @@
-# 汇编学习
-
-## 基础知识回顾
-
-地址总线：它的宽度决定了 CPU 的寻址能力。比如8086地址总线宽度为20，则寻址能力为1M（2的20次方）
-数据总线：它的宽度决定了 CPU 单次数据传送量，也就是数据传输速度。比如8086的数据总线宽度为16，所以单次最大传递2个字节的数据/
-控制总线：它的宽度决定了 CPU 对其他其间的控制能力，能有多少种控制。
-
-内存的分段管理：起始地址+偏移地址=物理地址，计算出物理地址再去访问内存。
-
-偏移地址为16位，16位地址的寻址能力位64kb，所以一个段的长度最大为64kb。
-
-
-
-## CPU 的典型构成
-
-- 寄存器：信息存储
-
-- 运算器：信息处理
-
-- 控制器：控制其他器件进行工作
-
-对开发同学来说，CPU 中最主要的部件就是寄存器，“可以通过改变寄存器的内容来实现对 CPU 的控制”。
-
-不同的 CPU，寄存器个数、结构是不同的（比如8086是16为结构的 CPU，8086有14个寄存器）
-
-
-
-## 说明
-
-- 汇编中，小括号内存放的一定是内存地址。
-
-- 指令后面的字母代表操作数长度。比如 b = byte(8-bit)，s = short(16-bit integer or 32-bit floating point)、w = word(16-bit)、l=long(32-bit integer or 64-bit floating point)、q=quad(64 bit)、t=tem bytes(80-bit floating point)。比如 ` movq $0xa, 0x86c1(%rip)` 是 `let a:Int = 10` 的汇编实现。
-
-- rip 存储的说指令的地址。CPU 要执行的下一条指令地址就存储在 rip 中
-
-- rax、rdx 寄存器一般作为函数返回值使用
-
- ```swift
- func getValue() -> Int {
- return 10
- }
- var v = getValue()
- ```
-
-
-
- 
-
- 在第5行代码加断点，第4行汇编遇到 call 函数调用，LLDB 输入 `si` 进去，可以看到将十六进制 `0xa` 也就是10，保存到寄存器 `%eax` 也就是`%rax` 中。
-
- ```assembly
- SwiftDemo`getValue():
- -> 0x100003b20 <+0>: pushq %rbp
- 0x100003b21 <+1>: movq %rsp, %rbp
- 0x100003b24 <+4>: movl $0xa, %eax
- 0x100003b29 <+9>: popq %rbp
- 0x100003b2a <+10>: retq
- ```
-
- LLDB 输入 `finsh` 结束函数调用这段汇编，可以看到在汇编的第5行，将 `%rax` 保存的 10 赋值到 `%rip + 0x86d0 ` 地址。可以看 `%rip + 0x86d0` 是个全局变量，大概就是 v 的地址（可以继续用汇编验证，绝对是 v）。
-
- 
-
-- rdi、rsi、rdx、rcx、r8、r9 寄存器一般用来存储函数参数。
-
- 
-
- 可以看到第四行汇编的 `%edi` ... `%r9d` 和上面描述的寄存器顺序一致。
-
-- rsp、rbp 寄存器用于栈操作。栈顶指针，指向栈的顶部
-- leaq 和 movq 是有区别的。`leaq 0xd(%rip), %rax` 是从 `%rip + 0xd` 算出来的地址值赋值给 `%rax` ，`movq 0xd(%rip), %rax` 是从 `%rip + 0xd ` 算出来的地址值，取8个字节给 `%rax`。
-- `xorl` 异或运算。
-
-## 寄存器的高低位兼容设计
-
-汇编中高位对于低位寄存器的兼容性设计：
-%r 开头的寄存器都是64位（8 Byte）
-%e 开头的寄存器都是32位的（4 Byte）
-那如果所有的寄存器再去分 %r、%e 那就会存在很多寄存器了，使用和记忆很难了。
-
-同时早期的寄存器之下写的汇编代码，升级的时候要改写，成本太大了。如何设计才可以兼容升级呢？
-
-设计很巧妙。假设一个 %rax 的64位寄存器（0～63位）
-
-- 64位：则 all in 全部使用
-- 32位：为了兼容低的32位寄存器，则拿出低的4字节（0～31位）当作 %eax 32位寄存器来使用
-- 16位：为了兼容16位的寄存器，则拿出低的2个字节（0～15位）当作 %ax 16位寄存器来使用；
-- 8位：为了兼容8位的寄存器，则拿出低的2个字节（0～15位）分为2段，高8位、低8位来使用，分别是 %ah、%al 寄存器。
-
-
-
-
-寄存器：
-- r 开头：64 bit，8 Byte
-- e 开头：32 bit，4 Byte
-- ax、bx、cx、dx：16 bit，2 Byte
-- ah、al、bh、bl...：8 bit，1 Byte
-
-
-
-## 通用寄存器
-
-AX、BX、CX、DX 这4个寄存器通常用来存放一般性的数据，成为通用寄存器（有时候也有特定用途）
-
-通常 CPU 会把内存中的数据存储到通用寄存器中，然后再对通用寄存器中的数据进行运算
-
-例如：在内存中有一个内存空间a值为3，需要将它的值加1，然后将结果存储到内存空间b上。
-
-- `mov ax, a`。CPU 首先会将内存空间 a 的值放到寄存器 ax 中
-
-- `add ax, 1`。调用 add 指令，将 ax + 1
-
-- `mov b, ax`。调用 mov 将 ax 中的值赋值给内存空间 b
-
-
-
-### CS和IP
-
-CS 为代码段，IP 为指令指针寄存器，它们代表 CPU 当前要读取指令的地址
-
- 任意时刻，8086 CPU 都会将 `CS:IP` 指向的指令作为下一条需要取出执行的指令。
-
-IP 只为 CS 提供服务。
-
-8086 CPU 工作过程如下：
-
-- 从 `CS:IP` 指向的内存单元读取指令，读取的指令进入指令缓冲器
-
-- IP = IP + 当前所读取指令的长度。从而指向 IP 指向下一条指令
-
-- 执行指令，转到步骤1，重复执行
-
-在8086CPU 加电启动或者复位后（即 CPU 刚开始工作时）CS 被设置位 CS=FFFFH，IP 被设置为 IP=0000H，即在8086PC 机刚启动时，CPU 从内存 FFFF0H 单元中读取指令执行，FFFF0H 单元中的指令是 8086PC 机开机后执行的第一条指令。
-
-注意：在内存或者磁盘上，指令和数据其实没有差别，都是二进制信息。CPU 在工作时把有的信息看成指令，有些信息看数据，为同样的信息赋予了不同意义。
-
-那么 CPU 根据什么来判断这块内存上的信息是指令还是数据？
-
-- CPU 将 `CS:IP` 所指向的内存单元的内容看作指令
-
-- 如果内存中的某段内容曾被 CPU 执行过，那么它所在的内存单元肯定被 `CS:IP` 指向过
-
-
-
-### jmp 指令
-
-mov 指令不能用于设置 CS、IP 的值，8086没有提供该功能。可以通过 jmp 指令来实现修改 CS、IP 的值，这些指令被成为转移指令。
-
- `jmp 段地址:偏移地址` 可以实现同时修改 CS、IP 的值，表示用指令中给出的段地址修改 CS，偏移地址 IP。
-
-`jmp 2AE3:3` 执行后表示：CS=2AE3H，IP=0003H，CPU 将从2AE33H处读取指令。
-
-QA：下面3条指令执行完毕后，CPU 修改了几次 IP 寄存器？
-
-```shell
-mov ax, bx
-sub ax, ax
-jmp ax
-```
-
-修改了4次。每执行一条指令，IP 都会被修改1次（IP=IP+该条指令的长度），最后一条指令执行后，IP 寄存器的值也会被修改1次，共3+1=4次。
-
-`jmp *%rax` jmp 后面如果跟寄存器地址，则一定要加 `*`，地址存放在 `%rax` 中
-
-
-
-### ds 寄存器
-
-CPU 要读写一个内存单元时，必须要给出这个内存单元的地址，在8086中，内存地址由段地址和偏移地址组成。
-
-8086中有一个 DS 段寄存器，通常用来存放要访问数据的段地址
-
-```shell
-mov bx, 1000H
-mov ds, bx
-mov al, [0]
-```
-
-上面3条指令的意思是将 10000H （1000:0）中的内存数据，赋值到 al 寄存器中。
-
-`mov al, [address]` 的意思是将 DS：address 该地址中的内存数据赋值到 al 寄存器中。
-
-由于 al 是8位寄存器，所以上述命令是将一个字节的数据赋值给 al 寄存器。
-
-tips：8086 不支持将数据直接送入段寄存器，所以 `mov ds, 1000H` 是错误的。
-
-QA：写指令来实现将 al 中的数据写入到内存单元 10000H 中
-
-```shell
-mov ax, 1000
-mov ds, ax
-mov [0], al
-```
-
-QA：内存中有如下数据，写出下面指令执行后寄存器 ax 的值？
-
-| 10000H | 23 |
-| ------ | --- |
-| 10001H | 11 |
-| 10002H | 22 |
-| 10003H | 66 |
-
-```shell
-mov ax, 1000H
-mov ds, ax
-mov ax, [2]
-```
-
-代码分析：
-
-- 第一条指令，ax 寄存器存放了 1000H 这个地址
-
-- 第二条指令，将访问 ds 数据段，在 1000H 这个地址出访问
-
-- 第三条指令，将数据段中 1000H 这个地址处，偏移 2，也就是内存中 10002H 这个的值22写入到 ax 中，由于 ax 寄存器是16位，所以会取2个单位的数据，22和66。所以 ax 的值为2266。
-
-8086 CPU 下，AX、BX、CX、DX 等通用寄存器均被分为高位和低位，AX = AH + AL，其中高位寄存器和低位寄存器。高位和低位都是16位。所以会从10002H 开始取2个16位的数据赋值给 ax。
-
-思考：如果代码改变下呢，如下
-
-```shell
-mov ax, 1000H
-mov ds, ax
-mov al, [2]
-```
-
-此时 al 的值为多少？al 和 ax 的区别在于 ax = ah + al，所以 al 的情况下直接从 10002H 开始取1个16位的数据，所以 al 为 0022。
-
-
-
-### 大小端序
-
-小端序，指的是数据的高字节保存在内存的高地址中，数据的低字节保存在内存的低地址中
-
-大端序，指的是数据的高字节保存在内存的低地址中，数据的低字节保存在内存的高地址中。
-
-注意：这里的大小端序还存在网络大小端序 NBO 和主机大小端序 HBO，详细可以查看我[这篇文章](https://github.com/FantasticLBP/knowledge-kit/blob/master/Chapter5%20-%20Network/5.3.md)
-
-Big Endian：PowerPC、IBM、Sun
-
-Little Endian：x86、DEC
-
-ARM：大小端序模式下均可工作。
-
-16bit 宽的数0x1234 分别在大小端序模式的 CPU 内存存放形式为
-
-| 内存地址 | 小端序 | 大端序 |
-| ------ | ---- | ---- |
-| 0x4000 | 0x34 | 0x12 |
-| 0x4001 | 0x12 | 0x34 |
-
-32bit宽的 0x12345678 分别在大小端序模式的 CPU 内存存放形式为
-
-| 内存地址 | 小端序 | 大端序 |
-| ------ | ---- | ---- |
-| 0x4000 | 0x78 | 0x12 |
-| 0x4001 | 0x56 | 0x34 |
-| 0x4002 | 0x34 | 0x56 |
-| 0x4003 | 0x12 | 0x78 |
-
-QA：将 0x1122 存放在 0x40002 中，如何存储?
-
-分析 0x1122需要2个字节，0x40002 是1个字节，所以肯定需要在 0x40002和向后的一个字节中存储。然后考虑主机序的大小端情况。假设小端模式下：
-
-0x40000
-
-0x40001
-
-0x40002 0x22
-
-0x40003 0x11
-
-
-
-### 指令操作明确 CPU 操作的内存
-
-```shell
-mov ax, 1000H
-mov ds, ax
-mov word ptr [0], 66h
-```
-
-上述代码先把 1000H 写入 ax 寄存器，然后访问数据段的 1000H 内存，然后将66h写入到数据段的0位置，但是 word 告诉了 CPU 需要操作2个字节，也就是 00 66
-
-指令执行前：1000: 0000 11 22 00 00 00 00 00 00
-
-指令执行后：1000: 0000 00 66 00 00 00 00 00 00
-
-如果将第三行代码改为 `mov byte ptr [0], 66h`，意味着明确告诉计算机需要操作1个字节，也就是66 。
-
-指令执行前：1000: 0000 11 22 00 00 00 00 00 00
-
-指令执行后：1000: 0000 66 22 00 00 00 00 00 00
-
-
-
-## 栈
-
-栈是一种后进先出特点的数据存储空间（LIFO）
-
-
-
-- 8086 会将 CS 作为代码段的段地址，将 `CS:IP` 指向的指令作为下一条需要取出执行的指令
-
-- 8060会将 DS 作为数据段的段地址，`mov ax, [address]` 就是取出 `DS:address` 内存区域上的数据放到 ax 寄存器中
-
-- 8086会将 SS 作为栈段的段地址，`SS:SP` 指向栈顶元素
-
-- 8086提供了 PUSH 指令用来入栈，POP 出栈。PUSH ax 是将 ax 的数据入栈，pop ax 是将栈顶的数据送入 ax
-
-SS: 栈的段地址
-
-SP：堆栈寄存器存放栈的偏移地址
-
-
-
-### push
-
-
-
-`push ax` 指令执行，会拆解为：
-
-- `SP = SP-2` ，`SS:SP` 指向当前栈顶前面的单元，更新栈顶指针
-
-- 将 ax 中的数据送入到 `SS:SP` 所指向的内存单元处
-
-ax = ah + al，所以 ax 中的数据入栈需要占据2个单位（sp = sp - 2）
-
-
-
-### pop
-
-
-
-`pop ax` 指令执行，会拆解为：
-
-- 将 `SS:SP` 栈顶指向的内存单元中的数据（2个单位）写入到 ax 寄存器中
-
-- `SP = SP + 2`，更新 `SS:SP` 栈顶的地址
-
-注意：
-
-当一个栈空间是空的时候，`SS:SP` 指向栈空间最高地址单元的下一个单元。
-
-
-
-当一个栈空或者满的时候，执行 PUSH、POP 指令需要注意，因为 `SP = SP + 2`、`SP = SP - 2` 都会导致将错误的数据入栈或者错误的数据出栈，导致发生不可预期的事情。
-
-QA：将10000H~1000FH 这段空间当作栈，初始栈为空，AX = 001AH，BX=001BH，利用栈，交换 AX、BX 中的数据
-
-```shell
-push ax
-push bx
-pop ax
-pop bx
-```
-
-### 段总结
-
-数据段：存放数据的段
-
-代码段：存放代码的段
-
-栈段：将一个段当作栈
-
-对于数据段，将它的段地址放在 DS 中，用 mov、add、sub 等访问内存单元的指令时，CPU 则认为数据段中的内容是数据来访问
-
-对于代码段，将它的段地址存放在 CS 中，将段中的第一条指令的偏移地址放在 IP 中，这样 CPU 就将执行我们定义的代码段的指令（每执行一条指令之前，就会将 IP 的值更新，规则为 IP = IP + 当前指令的长度，以保证该条指令执行完可以根据 段地址 + 偏移地址获取到下条指令的地址）
-
-对于栈段，将它的段地址存放在 SS 中，将栈顶单元的偏移地址存放在 SP 中，这样 CPU 在进行栈操作（LIFO）的时候比如 push、pop 指令，就可以操作 SP，将我们定义的栈段当作栈空间来使用
-
-
-
-## 中断
-
-中断是由于软件或者硬件的信号，使得 CPU 暂停当前的任务，转而去执行另一段子程序。
-
-在程序运行过程中，系统出现了一个必须由 CPU 立即处理的情况，此时，CPU 暂时终止当前程序的执行转而处理这个新情况的过程就叫中断。
-
-中断分为：
-
-- 硬中断（外中断）：由外部设备（网卡、硬盘）随机引发的，比如当网卡收到数据包的时候，就会发出一个中断
-
-- 软中断（内中断）：由执行中断指令产生，可以通过程序控制触发
-
-汇编中主要指的是软中断，可以通过指令 `int n` 产生中断，其中 `n` 表示中断码，内存中有一张中断向量表，用来存放中断码对应中断处理程序的入口地址。
-
-Demo：写一个打印 Hello World 的汇编代码
-
-```powershell
-; 提醒开发者每个段的定义（增加可读性）
-assume cs:code, ds:data
-;------ 数据段 begin --------
-data segment
- age db 20h
- no dw 30h
- db 10 dup(6) ; 生成连续10个6
- string db 'Hello world!$'
-data ends
-;------ 数据段 end --------
-
-;------ 代码段 begin --------
-code sgement
-start:
- ; 设置 ds 的值
- mov ax, data
- mov ds, ax
-
- mov ax, no
- mov bl, age
-
- ; 打印字符串
- mov dx, offset string ; offset string 代表 string 的偏移地址（将地址赋值给 dx）
- mov ah, 9h
- int 21h ; 打印字符串其实也是一次中断
-
- ; 退出程序
- mov ax, 4c00h
- int 21h
-code ends
-end start
-;------ 代码段 end --------
-```
-
-- start 代表汇编程序的入口
-
-- `mov ax, 4c00h` 和 `int 21h` 代表程序正常中断
-
-QA：“全局变量的地址在编译那一刻就确定好了”怎么理解？
-
-全局变量存放在数据段，我们开发者写的代码存放在代码段，位置不一样，编译期就可以确定全局变量的地址。
-
-
-
-## call 和 ret 指令
-
-实现打印3次 "Hello"
-
-方法1
-
-```powershell
-assume ds:data, ss: stack, cs: code
-; 栈段
-stack segment
-
-ends stack
-
-; 数据段
-data segment
-
-
-ends data
-
-; 代码段
-code segment
-start:
- ; 设置 ds、ss
- mov ax, data
- mov ds, ax
- mov ax, stack
- mov ss, ax
-
- ; 业务逻辑
- ; 打印
- ; ds:dx 告诉字符串地址
- mov dx, offset string
- mov ah, 9h
- int 21h
-
- mov dx, offset string
- mov ah, 9h
- int 21h
-
- mov dx, offset string
- mov ah, 9h
- int 21h
-
- ; 程序正常退出
- mov ax, 4c00h
- int 21h
-code ends
-end start
-```
-
-有没有问题？重复出现2次以及以上，需要封装为函数，汇编也遵循这个原则
-
-方法2
-
-```shell
-assume ds:data, ss: stack, cs: code
-; 栈段
-stack segment
-
-ends stack
-
-; 数据段
-data segment
-
-
-ends data
-
-; 代码段
-code segment
-start:
- ; 设置 ds、ss
- mov ax, data
- mov ds, ax
- mov ax, stack
- mov ss, ax
-
- ; 业务逻辑
- call print
- call print
- call print
-
- ; 程序正常退出
- mov ax, 4c00h
- int 21h
-print:
- ; 打印
- ; ds:dx 告诉字符串地址
- mov dx, offset string
- mov ah, 9h
- int 21h
- ; 函数正常退出
- ret
-
-code ends
-end start
-```
-
-说明：
-
-call 会将下一条指令的偏移地址入栈；会转到标号（print:） 处执行指令
-
-ret 会将栈顶的值出栈，赋值给 `CS:IP` ，ret 即 return
-
-## 函数调用的本质
-
-函数的3要素：参数、返回值、局部变量
-
-
-
-### 返回值
-
-函数运算的结果，一般是放在 ax 通用寄存器中。可以拿 Xcode 将下面的代码执行下，断点开启在 test 方法内的 return 处（Debug - Debug WorkFlow - Always show Disassembly）
-
-```objectivec
-#import 
-
-2. 编写汇编代码
-
- ```assembly
- .text
- .global _test
-
- _test:
- movq $0x8, %rax;
- ret;
- ```
-
- 创建一个名为 `test` 的函数，内部给 rax 寄存器赋值为8，然后 ret 返回。
-
- `.text` 是保存在 _TEXT 段上。并将函数暴露给全局,函数名为 test，暴露的时候就要写 _test
-
-3. 汇编函数给外部调用，就需要声明一个头文件 `Asm.h`，写好需要暴露的方法声明
-
-4. 最后在使用的地方，引入暴露的汇编头文件 `Asm.h`，正常调用函数即可。
-
-
-
-
-
-
-
-
-
-## 汇编编写“函数”
-
-上面的例子也顺带看了汇编是如何编写“函数”的，为什么加引号，因为这个概念是不存在的，汇编只有指令，这个函数概念是方便组织代码，参考定义的。类似给一段代码打了个标签。
-
-1. 创建汇编文件
-
-2. 编写代码
-
- ```assembly
- .text
- .global _test, _add, _sub
-
- _test:
- movq $0x8, %rax;
- ret;
-
- _add:
- movq %rsi, %rax
- movq %rdi, %rbx
- addq %rbx, %rax
- retq
- _sub:
- movq %rdi, %rax
- movq %rsi, %rbx
- subq %rbx, %rax
- ret
- ```
-
- 
-
- 说明：笔者编写平台是老款 MBP，Xcode 连接模拟器跑的代码，也就是 X86_64 架构的汇编。真机运行一般跑 arm64 汇编语法，会 X86_64 的话 arm64 类似，翻译下写法就好。
-
- 看这2个函数，都是从 `rsi` `rdi` 寄存器里面获取函数参数，内部调用系统指令，做了减加运算逻辑后，将函数返回值保存到 `rax` 寄存器中，直接 return。不需要显示声明 `return rax`，汇编会自动将 `rax` 寄存器里的值，交给函数调用者。
-
-3. 汇编函数给外部调用，就需要声明一个头文件 `Asm.h`，写好需要暴露的方法声明
-
-4. 最后在使用的地方，引入暴露的汇编头文件 `Asm.h`，正常调用函数即可。
-
-
-
-
-
-## iOS 源码探索
-
-经常需要将黑盒的 iOS 代码结合 GNU 之外，还需要将源文件编译成汇编代码去分析。格式为：
-
-`xcrun --sdk iphoneos clang -S -arch arm64 main.m -o main.s`
-
-
-
-## arm64 汇编
-
-### 寄存器
-
-#### 通用寄存器
-
-- 64位： x0～x28
-- 32位：w0～w28（属于 x0～x28 的低32位）
-- x0～x7 经常用来存放函数的参数，更多的函数参数用堆栈来传递
-- x0 经常用来存放函数的返回值
-
-
-
-Demo：汇编定义加减法，OC 去调用
-
-```assembly
-// Asm.s
-.text
-.global _add, _sub
-
-_add:
- add x0, x0, x1
- ret
-_sub:
- sub x0, x0, x1
- ret
-
-// ViewContoller.m
-#import "Asm.h"
-NSInteger sum = add(2, 4) // 6
-NSInteger res = sub(4, 2) // 2
-```
-
-
-
-
-
-#### 程序计数器
-
-pc(Program Counter)
-
-
-
-#### 堆栈指针
-
-- sp（Stack Pointer）
-- fp（Frame Pointer），也就是 x29
-
-#### 链接寄存器
-
-lr（link register），也就是 x30
-
-
-
-#### 程序状态寄存器
-
-- cpsr（Current Program Status Register）
-- spsr（Saved Program Status Register），异常状态下使用
-
-
-
-### 指令
-
-- ret：函数返回
-
-- cmp：将2个寄存器的值相减，结果会影响 cpsr 寄存器的标志位
-
-- b：跳转指令。格式为：`b{条件} 目标地址` 。b 指令是最简单的跳转指令，一旦遇到一个 B 指令，ARM 处理器将立即跳转到给定的目标地址，从那里继续执行。
-
- 条件跳转一般搭配 cmp 使用。条件跳转对应 `if...else...`
-
- Demo：定义一段汇编代码一个标签，然后跳转执行。跳转前传递参数，跳转后读取并相加
-
- ```assembly
- .text
- .global _jump
-
- _jump:
- movq $0x1, %rsi
- jmp myCode
- myCode:
- movq %rsi, %rax
- movq $0x2, %rbx
- addq %rbx, %rax
- ret
- ```
-
- 
-
- 
-
- 上面是 x86_64 的汇编，`jmp` 跳转指令在 arm64 中对应 `b` 指令。类似下面代码
-
- ```assembly
- .text
- .global _jump:
-
- _jump:
- // ...
- b myCode
- myCode:
- // ...
- ```
-
- 条件跳转：`bgt conditionJump`
-
- ```assembly
- .text
- .global _jump
-
- _jump:
- mov x0, #0x5
- mov x1, #0x5
- cmp x0, x1
- bgt conditionJump
- conditionJump:
- mov x1, #0x6
- ret
- ```
-
-- bl：带返回值的跳转指令。格式为：`bl{条件} 目标地址`。bl 跳转前，会在寄存器 r14 中保存 pc 的当前内容，因此，可以通过将 r14 的内容重新加载到 pc 中，来返回到跳转指令之后的那个指令处执行。该指令是实现子程序调用的一个基本但常用的手段。在 x86_64 中就是 call 指令。
-
-
-
-
-
-### 条件域
-
-- EQ：equal 相等
-- NE：not equal 不想等
-- GT：great than 大于
-- GE：greater equal 大于等于
-- LT：less than 小于
-- LE：less equal 小于等于
-
-
-
-### 内存操作
-
-- load 从内存中装载数据
-
- - ldr
-
- `ldr x0, [x1]` 代表从地址 x1 处，取8个字节的数据，赋值给 x0（会将 x1 寄存器中存储的内存地址所指向的值加载到 x0 寄存器中）。`ldr w0, [x1]` 代表从地址 x1 处，取4个字节的数据，赋值给 w0。一般会搭配 CPU 寻址能力一起使用。
-
- - ldur
-
- 和 ldr 一样，作用都是从一个寄存器中存储的内存地址所指向的值加载到某个寄存器上。ldr 搭配正数地址，如 `ldr x1, [sp, #0x28]` ，ldur 搭配负数地址，如 `ldur w8, [x29, #-0x8]`
-
- - ldp， `ldp w0, w1, [x2, #0x10]` 代表从 x2 + 0x10 计算结果对应的内存出，取出前4个字节的值赋值给寄存器 w0，后4个字节对应的值赋值给寄存器 w1
-
-- store 往内存中存储数据
-
- - str。`str w0, [x1, #0x5]` 将 w0 寄存器的值赋值给 `x1 + #0x5` 地址开始，4个字节处。str 搭配正数地址偏移
-
- - stur。`str w0, [x1, #-0x5]` 将 w0 寄存器的值赋值给 `x1 - #0x5` 地址开始，4个字节处。stur 搭配正数地址偏移
-
- - stp。`stp w0, w1, [x1, #0x5]` 将 w0 寄存器的值赋值给 `x1 + #0x5` 地址开始，前4个字节处，w1 寄存器的值赋值给后4个字节
-
- - 零寄存器
-
- - wzr（32bit）即 word zero register。
- - xzr（64bit）
-
- ```objective-c
- int a = 0；
- long b = 0;
- ```
-
- 转换为 arm64 汇编就是
-
- ```assembly
- stur wzr, [x29, #-0x14]
- stur xzr, [x29, #-0x24]
- ```
-
-
-
-## 经验小结
-
-- 内存地址格式为：`0x7ab60(%rip)` 一般是全局变量
-- 内存地址格式为：`-0x50(%rbp)` 一般是局部变量
-- 源代码 -> 汇编 -> 机器码，从机器码到汇编是可逆的。但是无法做到汇编到源代码的反编译，因为不同的源代码可能生成的汇编代码是一样的。
-
-
-
diff --git a/Chapter1 - iOS/1.11 b/Chapter1 - iOS/1.11
deleted file mode 100644
index e8c608b..0000000
--- a/Chapter1 - iOS/1.11
+++ /dev/null
@@ -1,2 +0,0 @@
-//print(MemoryLayout.stride(ofValue: str1))
-//print(Mems.memStr(ofVal: &str1))
\ No newline at end of file
diff --git a/Chapter1 - iOS/1.11.md b/Chapter1 - iOS/1.11.md
deleted file mode 100644
index bfe0c99..0000000
--- a/Chapter1 - iOS/1.11.md
+++ /dev/null
@@ -1,51 +0,0 @@
-# iOS中的事件
-
-
-
-* 用户在使用App的时候会产生各种事件
-* 触摸事件、重力加速计事件、远程遥控事件
-* 只有继承自UIResponder才可以响应事件
-* UIView、UIApplication、UIViewController都可以响应事件
-* ## UIResponder
-* UIResponder内部提供了一些方法处理事件
-
-```
-//触摸事件
--(void)touchBegan:(NSSet *)touches withEvent:(UIEvent *)event;
--(void)touchMoved:(NSSet *)touches withEvent:(UIEvent *)event;
--(void)touchEnded:(NSSet *)touches withEvent:(UIEvent *)event;
--(void)touchCanceled:(NSSet *)touches withEvent:(UIEvent *)event;
-
-//加速计事件
--(void)motionBegan:(UIEventSubtype)motion withEvent:(UIEvent *)event;
--(void)motionEnded:(UIEventSubtype)motion withEvent:(UIEvent *)event;
--(void)motionCanceled:(UIEventSubtype)motion withEvent:(UIEvent *)event;
-
-//远程控制事件
--(void)remoteControlReceivedWithEvent:(UIEvent *)event;
-```
-
-# 事件的产生和传递
-
-* 发生触摸事件后，系统会将该事件加入到一个由UIApplication管理的事件队列中去
-* UIApplication会从事件队列中取出最前面的事件，并将事件分发下去以便处理，通常先分发事件给应用程序的主窗口（keyWindow）
-* 主窗口会在视图层次结构中寻找到一个最合适的视图来处理触摸事件，这也是整个事件处理过程中最重要的一步。
-
-
-
-找到合适的视图控件后，就会调用视图控件的touch方法来做具体的事件处理逻辑
-
-
-
-## UIView不接收事件的3种情况
-
-1. 不接收用户交互。view.userInteractionEnabled = NO
-2. 隐藏。view.hidden = YES
-3. 透明度很低。view.alpha = 0.0 ~ 0.01
-
-
-
-注意：UIImageView的userInteractionEnabled默认为NO，因此UIImageView及其它上面的子控件默认是不能接受触摸事件的。
-
-
-
diff --git a/Chapter1 - iOS/1.110.md b/Chapter1 - iOS/1.110.md
deleted file mode 100644
index 504c403..0000000
--- a/Chapter1 - iOS/1.110.md
+++ /dev/null
@@ -1,431 +0,0 @@
-## 妙用设计模式来设计一个客户端校验器
-
-
-> 业务逻辑千变万化，弹窗优先级不断改变，代码冗余问题和难以维护问题如何解决？
-> 本篇文章从设计模式角度出发，讨论责任链设计模式和工厂设计模式2个方式，如何去设计一个校验器，同时解决代码冗余和难以维护的问题
-
-
-## 问题背景
-
-订单在提交的时候会面临不同的校验规则，不同的校验规则会有不同的处理。假设这个处理就是弹窗。
-有的时候会命中规则1，则弹窗1，有的时候同时命中规则1、2、3，但由于存在规则的优先级，则会处理优先级最高的弹窗1。
-
-老的业务背景下，弹窗优先级或者说校验规则是统一的。直接用函数翻译实现，写多个 if 问题不大。
-但在新业务背景下，不同的条件，弹窗优先级不一致，之前的写法需要写大量的嵌套判断，代码难以维护。
-
-所以问题抽象为：如何设计一个校验器
-
-
-为了清晰说明问题，假设线上的弹窗校验规则为：A -> B -> C
-
-```Plain
-typedef NS_ENUM(NSUInteger, OrderSubmitReminderType) {
- OrderSubmitReminderTypeNormal = 0, // 没有命中校验规则
- OrderSubmitReminderTypeA, // 命中校验规则 A
- OrderSubmitReminderTypeB, // 命中校验规则 B
- OrderSubmitReminderTypeC, // 命中校验规则 C
-}
-```
-
-老规则比较简单，不存在不同的校验规则，所以需求可以直接用代码翻译，不需要额外设计
-
-```Shell
-+ (OrderSubmitReminderType)acquireOrderValidateType:(id)params {
- if ([OrderSubmitUtils validateA:params]) {
- return OrderSubmitReminderTypeA;
- }
- if ([OrderSubmitUtils validateB:params]) {
- return OrderSubmitReminderTypeB;
- }
- if ([OrderSubmitUtils validateC:params]) {
- return OrderSubmitReminderTypeC;
- }
- return OrderSubmitReminderTypeNormal;
-}
-```
-
-假设只有2个弹窗条件：是否是 VIP 账户（isVIP）、是否是付费用户（isChargedAccount）。
-
-- isVIP & isChargedAccount： A -> B -> C
-- isVIP & !isChargedAccount：B -> C-> A
-- !isVIP: C -> B -> A
-
-如果直接改，代码就是一坨垃圾了
-
-```Shell
-+ (OrderSubmitReminderType)acquireOrderValidateType:(id)params {
- if (isVIP) {
- if (isChargedAccount) {
- if ([OrderSubmitUtils validateA:params]) {
- return OrderSubmitReminderTypeA;
- }
- if ([OrderSubmitUtils validateB:params]) {
- return OrderSubmitReminderTypeB;
- }
- if ([OrderSubmitUtils validateC:params]) {
- return OrderSubmitReminderTypeC;
- }
- return OrderSubmitReminderTypeNormal;
- } else {
- if ([OrderSubmitUtils validateB:params]) {
- return OrderSubmitReminderTypeB;
- }
- if ([OrderSubmitUtils validateC:params]) {
- return OrderSubmitReminderTypeC;
- }
- if ([OrderSubmitUtils validateA:params]) {
- return OrderSubmitReminderTypeA;
- }
- return OrderSubmitReminderTypeNormal;
- }
- } else {
- if ([OrderSubmitUtils validateC:params]) {
- return OrderSubmitReminderTypeC;
- }
- if ([OrderSubmitUtils validateB:params]) {
- return OrderSubmitReminderTypeB;
- }
- if ([OrderSubmitUtils validateA:params]) {
- return OrderSubmitReminderTypeA;
- }
- return OrderSubmitReminderTypeNormal;
- }
-}
-```
-
-
-
-## 思路
-
-可能有些人会觉得，那不简单，我将不同组合条件下的弹窗抽取为3个方法，照样很简洁
-
-```Shell
-+ (OrderSubmitReminderType)acquireOrderValidateTypeWhenIsVIPAndChargedAccount:(id)params {
- // A->B->C
- if ([OrderSubmitUtils validateA:params]) {
- return OrderSubmitReminderTypeA;
- }
- if ([OrderSubmitUtils validateB:params]) {
- return OrderSubmitReminderTypeB;
- }
- if ([OrderSubmitUtils validateC:params]) {
- return OrderSubmitReminderTypeC;
- }
- return OrderSubmitReminderTypeNormal;
-}
-
-+ (OrderSubmitReminderType)acquireOrderValidateTypeWhenIsVIPAndNotChargedAccount:(id)params {
- // B -> C-> A
- if ([OrderSubmitUtils validateB:params]) {
- return OrderSubmitReminderTypeB;
- }
- if ([OrderSubmitUtils validateC:params]) {
- return OrderSubmitReminderTypeC;
- }
- if ([OrderSubmitUtils validateA:params]) {
- return OrderSubmitReminderTypeA;
- }
- return OrderSubmitReminderTypeNormal;
-}
-
-+ (OrderSubmitReminderType)acquireOrderValidateTypeWhenIsNotVIP:(id)params {
- // C -> B-> A
- if ([OrderSubmitUtils validateC:params]) {
- return OrderSubmitReminderTypeC;
- }
- if ([OrderSubmitUtils validateB:params]) {
- return OrderSubmitReminderTypeB;
- }
- if ([OrderSubmitUtils validateA:params]) {
- return OrderSubmitReminderTypeA;
- }
- return OrderSubmitReminderTypeNormal;
-}
-```
-
-其实不然，问题还是很多：
-
-- 虽然抽取为不同方法，但是每个方法内部存在大量冗余代码，因为每个校验规则的代码是一样的，重复存在，只不过先后顺序不同
-- 存在隐含逻辑。 return 顺序决定了弹窗优先级的高低（这一点不够痛）
-
-
-
-## 方案
-
-那能不能优化呢？有3个思路：责任链设计模式、工厂设计模式、策略模式
-
-策略模式：当需要根据客户端的条件选择算法、策略时，可用该模式，客户端会根据条件选择合适的算法或策略，并将其传递给使用它的对象。典型设计前端 Vue-Validator form 各种 rules
-
-职责链模式：当需要根据请求的内容选择处理器时，可用该模式，请求会沿着链传递，直到被处理，如 Node 洋葱模型
-
-不过目前来看，策略模式被 Pass 了
-
-### 责任链设计模式
-
-责任链模式即 Chain Of Responsibility，属于行为型模式。行为型模式不仅描述对象或类的模式，还描述他们之间的通信模式，比如对操作的处理该如何传递等等。
-
-为什么会有这个思路？
-
-主要来源于2个方向：Node 的洋葱模式、移动端的点击事件传递。
-
-移动端的事件响应模型：点击 view 看看能不能响应，不能响应则继续向上抛，直到抛到 window 为止；
-
-前端 JS 事件冒泡机制：点击事件假设是动态绑定到 DOM 节点上的，浏览器本身不知道哪些地方会处理点击事件，但又要让每层 DOM 拥有对该点击事件的平等处理权，所以就诞生了事件冒泡和组织冒泡的能力 `event.stopPropagation()`
-
-
-
-Node 洋葱模式：发送一个 Request 一层层中间件去处理，比如添加日志、添加请求拦截转发、处理核心业务逻辑、添加日志、添加自定义 response header等，一个中间件层只关注聚焦自己层需要做的事情，处理完继续向下一层抛。
-
-设想下如果没有中间价模型，假设实现一个记录请求事件和自定义 HTTP Header 的需求，业务逻辑 curd 代码和记录请求时间和自定义 Header 代码全都杂糅在一起，难以维护。
-
-责任链的核心就是：**使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它为止。**
-
-- 降低处理者对象之间的耦合度。一个对象无须知道到底是哪一个对象处理其请求以及链的结构，发送者和接收者也无须拥有对方的明确信息。
-
-- 增强了系统的可扩展性。可以根据业务需求增加或者调整新的请求处理类，满足开闭原则（类似维护链表的节点信息）
-
-- 可插拔，增强了给对象指派职责的灵活性。当工作流程发生变化，可以动态地改变链内的成员或者调动它们的次序，也可动态地新增或者删除责任。
-
-- 责任链简化了对象之间的连接。每个对象只需保持一个指向其后继者的引用，不需保持其他所有处理者的引用，这避免了使用众多的 if 或者 if···else 语句。
-
-- 责任分担。每个类只需要处理自己该处理的工作，不该处理的传递给下一个对象完成，明确各类的责任范围，符合类的单一职责原则。
-
-
-
-采用责任链设计模式。基类 `OrderSubmitBaseValidator` 声明接口，是一个抽象类：
-
-- 有一个属性 `nextValidator` 用于指向下一个校验器
-- 有一个方法 `- (void)validate:(id)params;` 用于处理校验，内部利用模版模式，默认实现是传递给下一个校验器
-
-```Shell
-//.h
-OrderSubmitBaseValidator {
- @property nextValidator;
-
- - (void)validate:(id)params;
- - (BOOL)isValidate:(id)params;
- - (void)handleWhenCapture;
-}
-
-
-// .m
-#pragma mark - public Method
-- (BOOL)isValidate:(id)params {
- Assert(0, @"must override by subclass");
- return NO;
-}
-- (void)validate:(id)params {
- BOOL isValid = [self isValidate:params];
- if (isValid) {
- [self.nextValidator validate:params];
- } else {
- [self handleWhenCapture];
- }
-}
-
-- (void)handleWhenCapture {
- Assert(0, @"must override by subclass");
-}
-```
-
-然后针对不同的校验规则声明不同的子类，继承自 `OrderSubmitBaseValidator`。根据A、B、C 3个校验规则，有：OrderSubmitAValidator、OrderSubmitBValidator、OrderSubmitCValidator。
-
-子类去重写父类方法
-
-```Shell
-OrderSubmitAValidator {
- - (BOOL)isValidate:(id)params {
- // 处理是否满足校验规则A
- }
-
- - (void)handleWhenCapture {
- // 当不满足条件规则的时候的处理逻辑
- displayDialogA();
- }
-}
-```
-
-为了设计的健壮，假设没有命中任何校验规则，需要如何处理？这个能力需要有兜底默认的行为，比如打印日志：`NSLog(@"暂无命中任何弹窗类型，参数为：%@"，params);` 也可以由业务方传递
-
-```Shell
-OrderSubmitDefaultValidator *defaultValidator = [OrderSubmitDefaultValidator validateWithBloock:^ {
- SafeBlock(self.deafaultHandler, params);
- if (!self.deafaultHandler) {
- NSLog(@"暂无命中任何弹窗类型，参数为：%@"，params);
- }
-}];
-```
-
-初始化多个校验规则
-
-```Shell
-OrderSubmitAValidator *aValidator = [[OrderSubmitAValidator alloc] initWithParams:params];
-OrderSubmitBValidator *bValidator = [[OrderSubmitBValidator alloc] initWithParams:params];
-OrderSubmitCValidator *cValidator = [[OrderSubmitCValidator alloc] initWithParams:params];
-```
-
-不同优先级的校验如何指定：
-
-```Shell
-if (isVIP) {
- if (isChargedAccount) {
- aValidator.nextValidator = bValidator;
- bValidator.nextValidator = cValidator;
- } else {
- bValidator.nextValidator = cValidator;
- cValidator.nextValidator = aValidator;
- }
-} else {
- cValidator.nextValidator = bValidator;
- bValidator.nextValidator = aValidator;
-}
-```
-
-但还是不够优雅，这个优先级需要用户感知。能不能做到业务方只传递参数，内部判断命中什么弹窗优先级组合。所以接口可以设计为
-
-```Shell
-[OrderSubmitValidator validateWithParams:params handleWhenNotCapture:^{
- NSLog(@"暂无命中任何弹窗类型，参数为：%@"，params);
-}];
-```
-
-上述方法其实等价于
-
-```Shell
-let validateType = [OrderSubmitValidator generateTypeWithParams:params];
-[OrderSubmitValidator validateWith:validateType];
-```
-
-利用策略模式 `validateWith` 方法内部根据 validateType 去组装 Map 的 key，然后从 Map 中取出具体规则组合，然后依次迭代遍历执行
-
-```
-let rulesMap = {
- isVIP && isCharged : [a-b-c-d],
- isVIP && !isCharged: [a-b-d-c],
- !isVIP: [a-c-d-b],
-}
-```
-这部分策略的生成也可以单独抽取出去，比如 ValidateStrategyFactory 去根据不同的信息，生成不同的策略。
-
-优点：
-
-1. 解决了现在的错误弹窗的隐含逻辑，后续人接手，弹窗优先级清晰可见，提高可维护性，减少出错概率
-2. 对于判断（校验）的增减都无需关心其他的校验规则。类似维护链表，仅在一开始指定即可，符合“开闭原则”
-3. 对于现有校验规则的修改足够收口，每个规则都有自己的 validator 和 validate 方法
-4. 目前弹窗优先级针对 isVIP、isCharged 存在不同优先级顺序，如果按照现有的方案实施，则会存在很多冗余代码
-5. 按照策略模式，不同的校验规则，组装不同的策略，也可以单独抽取出去，独立维护，更清晰
-6. validate 内部按照模版模式，调用 `isValidate` 方法，每个单独的 Validator 不需要额外去调用 next，设计更加健壮，防止别人漏写
-
-
-
-### 工厂设计模式
-
-设计基类
-
-```Shell
-OrderSubmitBaseValidator {
- - (void)validate;
-
- - (BOOL)validateA;
- - (BOOL)validateB;
- - (BOOL)validateC;
-}
-
-- (void)validate {
- Assert(0, @"must override by subclass");
-}
-
-- (BOOL)validateA {
- // 判断是否命中规则 A
-}
-- (BOOL)validateB {
- // 判断是否命中规则 B
-}
-
-- (BOOL)validateC {
- // 判断是否命中规则 C
-}
-```
-
-根据不同的弹窗优先级条件，声明3个不同的子类：`OrderSubmitAValidator`、`OrderSubmitBValidator`、`OrderSubmitCValidator`。各自重写 `validate` 方法
-
-```Shell
-OrderSubmitAValidator {
- - (void)validate {
- [self validateA];
- [self validateB];
- [self validateC];
- }
-}
-
-OrderSubmitBValidator {
- - (void)validate {
- [self validateB];
- [self validateC];
- [self validateA];
- }
-}
-
-OrderSubmitCValidator {
- - (void)validate {
- [self validateC];
- [self validateB];
- [self validateA];
- }
-}
-```
-
-设计工厂类`OrderSumitValidatorFactory`，提供工厂初始化方法
-
-```Shell
-OrderSumitValidatorFactory {
- + (OrderSubmitBaseValidator *)generateValidatorWithParams:(id)params;
-}
-
-+ (OrderSubmitBaseValidator *)generateValidatorWithParams:(id)params {
- if (isVIP) {
- if (isChargedAccount) {
- return [[OrderSubmitAValidator alloc] initWithParams:params];
- } else {
- return [[OrderSubmitBValidator alloc] initWithParams:params];
- }
- } else {
- return [[OrderSubmitCValidator alloc] initWithParams:params];
- }
-}
-```
-
-优点：
-
-- 没有重复逻辑，判断方法都守口在基类中
-- 优先级的关系维护在不同的子类中，各司其职，独立维护
-
-
-最后选什么？组合优于继承，个人倾向使用责任链模式去组织代码。关于责任链设计模式的文章也可以看这篇[文章](https://raw.githubusercontent.com/FantasticLBP/knowledge-kit/master/Chapter6%20-%20Design%20Pattern/6.23.md)
-
-
-
-## 拓展
-
-如果业务真的是高频迭代变化，但校验顺序不变的话，甚至可以做成多端协定后，对应业务校验编号和业务关联，动态下发
-
-```json
-// Version1
-{
- "validatorRuleOrder": ["1", "4", "3", "2"]
-}
-
-// Version2
-{
- "validatorRuleOrder": ["1", "3", "4", "2"]
-}
-```
-
-App 动态请求，然后执行业务逻辑。需思考一些问题：
-
-- 网络请求慢怎么处理？
-- 需不需要缓存？
-- 有缓存的话，更新策略是什么？
-- 需不需要内置的产品逻辑？
-
-当然，这不在本篇文章范畴内，不做展开。
diff --git a/Chapter1 - iOS/1.111.md b/Chapter1 - iOS/1.111.md
deleted file mode 100644
index 13494ab..0000000
--- a/Chapter1 - iOS/1.111.md
+++ /dev/null
@@ -1,364 +0,0 @@
-## 写给 iOSer 的鸿蒙开发 tips
-
-## 下载问题
-
-The other possible cause is that the system language of the PC is English and the region code is US. You could try to perform the following operations to change the region code to CN. Before changing the region code, close DevEco Studio.
-
-
-For Mac OS: ~/Library/Application Support/Huawei/DevEcoStudio3.0/options/country.region.xml
-
-修改为 CN
-
-```xml
-
-
-左侧的 UI 树和右侧的 Model 树，通过 `@ObjectLink` 、`@Observed` 来进行数据渲染和刷新。
-
-
-
-
-
-## 鸿蒙APO 探索之路
-
-AOP Aspect Oriented Programming 是一种编程范式，被允许开发者将关注点与业务逻辑中分离出来。
-
-AOP 优势：解耦、复用、模块化
-
-AOP 应用场景：日志、埋点、监控
-
-### AOP 的实现方案
-
-- 编译时：AspectJ
-- 类加载时：AspectJ
-- 链接时：fishhook
-- 运行时：Epic
-
-### 为什么使用 AOP？
-
-日志、网络、性能监控、埋点等多个 AOP 使用场景。
-
-### 鸿蒙 AOP 方案探索
-
-#### 痛点
-
-- 匿名函数、箭头函数：`Button.onClick(ClickEvent)`
-- 函数局部类： `HttpClient#Builder()#build()`
-
-```ts
-View().
-onClick(() => {
- // handle business logic
-})
-```
-
-- 属性不可修改场景：`router.pushUrl`
-
- `Object.defineProperty()` 当 writeable 特性设置为 false 的时候，该属性是不可修改的。尝试对一个不可修改的属性进行写入时不会改变它。在严格模式下还会报错。
-
- 鸿蒙也是基于 TS 的，所以也可以调用 `Object.freeze()` 冻结属性。比如鸿蒙早期路由实现，是基于 Router 的，很多 API 的参数，writeable 属性都是 false。
-
-解决方案
-
-无统一修改点场景一：箭头参数函数 `Button.onClick(ClickEvent)`
-
-构造一个第一个参数为函数的 wrappFn 函数，持有目标参数函数。就跟 Native 侧的 hook 一样。构造一个一样的 hook 函数。
-
-```ts
-function hookMethod(traget, action, beforeFn?, afterFn?) {
- wrapMethod(target, action, (originalMethod) => function(callback) {
- const wrappedCallback = (...args) => {
- beforeFn?.apply(this, args)
- callback.apply(this, args)
- afterFn?.apply(this, args)
- }
- originalMethod.call(this, wrappedCallback)
- });
-}
-```
-
-使用
-
-```ts
-Aspect.addBefore(Button, 'onClick', () => {
- router.pushUrl({url: 'pages/Index' })
- logger.w(TAG, '1.Aspect add before --- Button#onClick()#action, do your business...');
-}, true)
-```
-
-无统一修改点场景二：局部类 `HttpClient#Builder()#build()`
-
-AOP 的本质是关注点分离，面对这种情况，每次通过 HttpClient 获取 Budiler() 就会产生不同的对象，所以传统的通过 hook 某个类的方法形式，已经不再适用了。所以需要通过更高层的 hook，即 `Object.defineProperty`
-
-通过属性定义拦截 HttpClient 的 Builder() 属性的获取，builder 的获取，都会被收口拦截。
-
-```ts
-function hookMethod(target: any, propertyName: string, methodName: string, beforeFn?: (context: any, args: any[]) => void, afterFn?: (context: any, args: any[], result: any) => void) {
-
- const propertyDescriptor = Object.getOwnPropertyDescriptor(target, propertyName)
- if (propertyDescriptor && propertyDescriptor.get) {
- Object.defineProperty(target, propertyName, {
- get() {
- const originalTarget = propertyDescriptor.get!.call(this)
- const originalMethod = originalTarget.prototype[methodName]
- originalTarget.prototype[methodName] = function (...args: any[]) {
- beforeFn?.call(this, this, args)
- let result = originalMethod.apply(this, args)
- afterFn?.call(this, this, args, result)
- return result
- }
- return originalTarget
- }
- })
- }
-}
-```
-
-使用
-
-```ts
-Apsect.hookMethod({
- target: HttpClient,
- methodNameOrProperty: 'Builder',
- beforeFn: (context: args) => {
- const builderContext = context as InstanceType
-
-如何实现编译时替换？
-
-鸿蒙提供了 Hvigor Plugin 编译时自定义插件，用于实现定制化构建。思路：直接利用 Hvigor Plugin hook 某个编译 task
-
-
-
-那到底 hook 哪个编译 task？
-
-
-
-问题：
-
-- output 修改无效
-
- 
-
-
-
- ArkTS 编译之后会产生临时目录，将 ets 编译为 ts。那是不是可以直接修改产物，看看最后能不能影响方舟字节码。
-
- 发现修改了 index.protoBin 、ts 文件，发现最终无法影响编译产物 `*.abc` 文件
-
- 联系了鸿蒙团队的工程师，验证了说是2条并行链路。并不是先编译产生临时文件，再通过临时文件产生 `*.abc` 文件。事实上是2个并行过程。所以此路不通
-
-- input 无法 hook，Hvigor plugin 暂未开放相关能力
-
- 
-
- Hvigor 目前开放的能力有限，仅支持在默认的 task 前后加一些钩子函数。但无法修改 input。此路不通
-
-- 既然没法直接修改默认 task，怎么实现？
-
- 思路：copy -> modify -> revert
-
- 
-
-
-
- 插桩只能影响产物，不能影响源码。所以先对源码进行备份。
-
- ```ts
- export function HllEntreyPlugin(): HvigorPlugin {
- return {
- pluginId: 'HllEntryPlugin',
- apply: (node: HvigorNode) => {
- node.registerTask({
- name: 'HllEntreyPluginInjectTask',
- run: () => {
- dispatcherToPlugins(node) // copy & modify
- }
- });
- node.registerTask({
- name: 'HllEntryPluginResetTask',
- run: () => {
- resetPluginCodes(originalBackUpFiles) // revert
- },
- dependcies: ['default@CompileArkTS'],
- postDependencies: ['assembleHap']
- })
- }
- }
- }
- ```
-
- 如何修改 AST？
-
- 鸿蒙目前没有提供修改 AST 的能力。如何做？
-
- ArkTS 虽然没有提供 AST 相关 API。但从 CompileArkTS Task 产物来看，ArkTS 最终会编译成 TS。
-
- 且 TS 提供 AST 相关 API。TS 是开源的，TS 开源代码中有关于 AST 的模块。[TS Compiler API](https://github.com/microsoft/TypeScript/wiki/Using-the-Compiler-API)
-
- 可以基于源码中 AST 相关的 API 可以抽取封装一下。
-
- 于是，整个流程就变成了
-
-
-
- 可以利用 [Typescript AST Viewer](https://github.com/dsherret/ts-ast-viewer) 来查看 AST 抽象语法树信息。可以在线查看 AST，官网地址为：[Typescript AST Viewer](https://ts-ast-viewer.com)
-
-
-
- 
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-#### Aspect（运行时）
-
-官方在 API 11 开始提供的方案，可快速实现对类方法前后进行插桩或替换。
-
-关键点一：属于可修改-即 addBefore、addAfter、replace 接口的原理，基于 class
-
-
-
-#### AspectPro V1（编译时<正则> + 运行时）
-
-#### AspectPro V2（编译时
-
-- `season = Season.summer`，此时可以看到第一个字节的位置是1.
-
- 
-
-- `season = Season.antumn` ，此时可以看到第一个字节的位置是2
-
- 
-
-结论：查看内存信息，可以看到**不带关联值、不带原始值的基础枚举，只占1个字节大小空间，且值为默认值**
-
-延伸：对于无关联值、无原始值的简单枚举，Swift 编译器会进行内存优化：
-
-- 当枚举 case ≤ 256 个时，使用 1 字节（UInt8）
-- 当 case ≤ 65536 时，使用 2 字节（UInt16）
-
-
-
-## 只有原始值的枚举
-
-不带关联值、只有原始值的枚举
-
-```swift
-enum Season : Int {
- case spring = 1
- case summer = 2
- case antumn = 3
- case winter = 4
-}
-
-//print(MemoryLayout
-
-- `season = .winter` 基础枚举，当赋值为 winter 的时候，可以看到第一个字节的位置是3
-
- 
-
-结论：**只带有原始值的枚举，同样只占用1个字节，该字节的值为枚举的位置索引（比如1、2），而非原始值。原始值不占用枚举的内存**
-
-
-
-## 只带有关联值的枚举
-
-```swift
-enum Season {
- case spring(Int, Int, Int)
- case summer(Int, Int)
- case antumn(Int)
- case winter(Bool)
- case unknown
-}
-
-print(MemoryLayout
-
- 其内存信息如下（8字节为1组，对应上图）
-
- ```shell
- 01 00 00 00 00 00 00 00
- 02 00 00 00 00 00 00 00
- 03 00 00 00 00 00 00 00
- 00
- 00 00 00 00 00 00 00
- ```
-
- 这段内存信息怎么看？我划分了下
-
- ```shell
- case spring 的关联值的第1个 Int： 01 00 00 00 00 00 00 00
- case spring 的关联值的第2个 Int： 02 00 00 00 00 00 00 00
- case spring 的关联值的第3个 Int： 03 00 00 00 00 00 00 00
- 表明哪个 case 的索引值: 00
- 内存对齐占用： 00 00 00 00 00 00 00
- ```
-
- 下面的几组一样
-
-- `season = Season.summer(4, 5)` 带有关联值的枚举，`.summer` 这个枚举关联值有2个 Int，单个 Int 占8个字节空间，所以红色框代表 summer 第一个关联值 4，蓝色框代表 summer 第二个关联值 5，绿色框为空，黄色框代表枚举的第2个 case，剩余7个字节，为空。
-
- 
-
- 其内存信息如下（8字节为1组，对应上图）
-
- ```shell
- case summer 的关联值的第1个 Int： 04 00 00 00 00 00 00 00
- case summer 的关联值的第2个 Int： 05 00 00 00 00 00 00 00
- 空（按照最大内存预留的位置）: 00 00 00 00 00 00 00 00
- 表明哪个 case 的索引值: 01
- 内存对齐占用： 00 00 00 00 00 00 00
- ```
-
-- `season = Season.antumn(6) 带有关联值的枚举，`. `antumn` 存在关联值 1个 Int，单个 Int 占8个字节空间，所以红色框代表 antumn 的6，蓝色框为空，绿色框为空，黄色框代表枚举的第3个 case，剩余7个字节，为空。
-
- 
-
- 其内存信息如下（8字节为1组，对应上图）
-
- ```shell
- case autumn 的关联值的第1个 Int： 06 00 00 00 00 00 00 00
- 空（按照最大内存预留的位置）: 00 00 00 00 00 00 00 00
- 空（按照最大内存预留的位置）: 00 00 00 00 00 00 00 00
- 表明哪个 case 的索引值: 02
- 内存对齐占用： 00 00 00 00 00 00 00
- ```
-
-- `season = Season.winter(true)` 带有关联值的枚举，`. `winter` 关联值是 1个 Bool，单个 Bool 占1个字节空间，所以红色框代表 winter 的 true，蓝色框为空，绿色框为空，黄色框代表枚举的第4个 case，剩余7个字节，为空。
-
- 
-
- 其内存信息如下（8字节为1组，对应上图）
-
- ```shell
- case winter 的关联值的第1个 Int： 01 00 00 00 00 00 00 00
- 空（按照最大内存预留的位置）: 00 00 00 00 00 00 00 00
- 空（按照最大内存预留的位置）: 00 00 00 00 00 00 00 00
- 表明哪个 case 的索引值: 03
- 内存对齐占用： 00 00 00 00 00 00 00
- ```
-
-- `season = Season.unknown` 带有关联值的枚举，`unknown` 没有关联值，所以红色框为空，蓝色框为空，绿色框为空，黄色框代表枚举的第5个 case，剩余7个字节，为空。
-
- 
-
- 其内存信息如下（8字节为1组，对应上图）
-
- ```shell
- case unknown 关联值的第1个Int: 00 00 00 00 00 00 00 00
- 空(按照最大内存预留的位置): 00 00 00 00 00 00 00 00
- 空(按照最大内存预留的位置): 00 00 00 00 00 00 00 00
- 表明哪个 case 的索引值: 04
- 内存对齐占用: 00 00 00 00 00 00 00
- ```
-
-- `MemoryLayout
-
-可以看到 enum 只有1个 case 的时候，内存大小只和最大关联值大小有关，1个 case 的情况下不需要额外的空间来判断所属哪个 case。
-
-因此此时枚举的内存大小 = 最大关联值的内存大小 = 8
-
-
-
-## 用汇编验证下内存
-
-```swift
-enum Season {
- case spring(Int, Int, Int)
- case summer(Int, Int)
- case antumn(Int)
- case winter(Bool)
- case unknown
-}
-
-var season: Season = Season.spring(1, 2, 3)
-print(Mems.ptr(ofVal: &season))
-season = Season.summer(4, 5)
-season = Season.antumn(6)
-season = Season.winter(true)
-season = Season.unknown
-print("over")
-```
-
-断点停到 `var season: Season = Season.spring(1, 2, 3)` 位置
-
-
-
-将断点处的汇编单独摘出来研究
-
-```assembly
-0x10000334b <+11>: movq $0x1, 0x8eaa(%rip) ; demangling cache variable for type metadata for Swift.Array
-
-实验2：struct 内不自己加 init
-
-```swift
-struct Point {
- var x: Int = 0
- var y: Int = 0
-}
-var point = Point()
-```
-
-在`var point = Point()`处加 断点，如下所示
-
-
-
-现象：可以看到加不加自定义初始化器的汇编代码基本相同。
-
-结论：**如果没有为结构体声明初始化器，编译器会自动生成1个初始化器。目的是保证所有成员都有初始值。**
-
-
-
-## 结构体内存布局
-
-```swift
-struct CustomDate {
- var year: Int
- var month: Int
- var isLeapYear: Bool
-}
-var date = CustomDate(year: 2024, month: 3, isLeapYear: false)
-print(MemoryLayout
-
-乍一看如果不认识的话，先找字面量（立即数），比如红色框内的 `0xa`，就是 10，`0x14` 就是20。[之前](./109.md)学过寄存器的设计，64位寄存器是兼容32位寄存器的。红色框内将 `0xa`，也就是 10 保存到 `%edi ` 寄存器内部，也就是保存到 `%rdi` 中，将 `0x14` 也就是20，保存到 `%esi` 也就是保存到 `%rsi` 寄存器中。
-
-LLDB 模式下输入 `si` 进入 init 方法内部。
-
-
-
-可以查看到将 `%rsi` 里的10 保存到 `%rdx` 中了；将 `%rdi` 里的20 保存到 `%rax` 中了。这也就是 struct `init` 方法做的事情。
-
-LLDB 模式下输入 `finish` 结束 init 方法。
-
-可以看到下面几句汇编
-
-```assembly
-0x1000035ac <+44>: movq %rax, -0x10(%rbp) // rbp - 0x10
-0x1000035b0 <+48>: movq %rdx, -0x8(%rbp) // rbp - 0x8
-0x1000035b4 <+52>: movq %rax, -0x20(%rbp) // rbp - 0x20
-0x1000035b8 <+56>: movq %rdx, -0x18(%rbp) // rbp - 0x18
-0x1000035bc <+60>: movq $0xb, -0x20(%rbp)
-0x1000035c4 <+68>: movq $0x16, -0x18(%rbp)
-```
-
-可以看到分别将 `%rax` 里的10赋值给内存地址为 `%rbp - 0x10` ，`%rdx` 里的20赋值给内存地址为 `%rbp - 0x8` 了。
-
-可与看到 `0x10` 和 `0x8` 地址相差8，且地址连续，也就是 point1 的内存地址。同样下面的 `0x20` 和 `0x18` 地址相差8，且地址连续，也就是 point2 的内存地址。
-
-第五行将 `0xb` 也就是11 赋值给 `%rbp - 0x20`的地址，`0x16` 也就是22赋值给 `%rbp-0x18`的地址，也就是 point2 的 x、y
-
-
-
-### COW 机制
-
-**值类型的赋值操作：Swift 标准库中的 String、Array、Dictionary 和 Set 确实采用了 Copy-On-Write（COW，写时复制） 技术，这是一种内存优化策略，旨在提升性能并减少不必要的内存复制**
-
-核心思想：
-
-- **延迟复制**：当多个变量引用同一份数据时，它们共享底层存储，直到某个变量尝试修改数据时，才会真正复制一份独立的副本。
-- **节省资源**：避免对不可变数据进行冗余复制，减少内存占用和计算开销
-
-仅当有“写”操作时，才会真正执行拷贝操作：
-
-- 对于标准库值类型的赋值操作，Swift 能确保最佳性能，所以没必要为了保证最佳性能来避免赋值
-- 自定义的值类型，比如结构体，在赋值的时候，就会立马发生深拷贝
-
-举个例子
-
-```swift
-var array1 = [1, 2, 3]
-var array2 = array1 // 此时共享底层存储
-
-array2.append(4) // 触发 COW：array1 和 array2 的存储分离
-```
-
-工作过程：
-
-- 赋值时：`array2` 与 `array1` 共享同一块内存
-- 修改时：当 `array2` 被修改时，检查引用计数。如果引用计数 > 1（即存在多个所有者），则复制底层存储，确保修改不影响其他变量
-
-写操作触发检查机制：
-
-- **修改前检查**：执行写操作（删除、添加、修改）时，检查缓冲区的引用计数
-
-- **唯一性检查**：若引用计数为1，则直接修改缓冲区；否则，复制缓冲区并修改新副本
-
- 伪代码
-
- ```swift
- // 伪代码逻辑
- mutating func append(_ element: Element) {
- if !isUniquelyReferenced(&buffer) {
- buffer = buffer.copy() // 复制缓冲区
- }
- buffer.append(element) // 修改新副本
- }
- ```
-
-#### 什么是缓冲区
-
- Array 结构体（值类型）
- +-------------------+
- | 指向缓冲区的指针 |-----→ Buffer 类（引用类型）
- | | +----------------+
- | 其他元数据（长度、容量） | | 存储元素的内存块 |
- +-------------------+ | [1, 2, 3, ...] |
- +----------------+
-
-1. **结构体轻量级**：
- `Array` 结构体本身只包含一个指针和少量元数据（如长度、容量），占用固定大小（如 8 字节指针 + 8 字节长度 + 8 字节容量 = 24 字节）。
-2. **缓冲区动态分配**：
- 实际存储元素的连续内存块由缓冲区动态分配在堆上，容量可扩展。
-3. **共享与复制**：
- - **赋值时**：仅复制结构体的指针（浅拷贝），多个数组共享同一缓冲区。
- - **修改时**：通过 COW（写时复制）机制，仅在需要时复制缓冲区。
-
-
-
-### 引用类型
-
-引用赋值给 var、let 或者给函数传参，是将内存地址拷贝一份。属于浅拷贝
-
-```swift
-func testReferenceType() {
- class Size {
- var width: Int
- var height: Int
- init(width: Int, height: Int) {
- self.width = width
- self.height = height
- }
- }
-
- var size1 = Size(width: 10, height: 20)
- var size2 = size1
- size2.width = 11
- size2.height = 22
-}
-testReferenceType()
-```
-
-下断点，可以看到下面的汇编：
-
-
-
-在调用（汇编的 call）完 `allocating_init` 方法后，方法返回值用 `%rax` 保存的。然后打印出 `%rax` 寄存器的值，查看内存信息如下
-
-
-
- 红色框代表类信息的地址，蓝色框代表引用计数，绿色框代表10，黄色框代表20.
-
-汇编的第17行，`movq %rdi, -0x50(%rbp)` 应该就是将 `%rdi` 里面的 对象内存地址赋值到 `%rbp - 0x50` 中去，也就是 `size1` 指针地址。
-
-汇编的第20行，`movq %rdi, -0x10(%rbp)` 应该就是将 `%rdi` 里面的 对象内存地址赋值到 `%rbp - 0x10` 中去，也就是 `size12 指针地址。
-
-再接下去的汇编
-
-```swift
-0x100003525 <+133>: movq -0x50(%rbp), %rax
-0x100003529 <+137>: movq $0xb, 0x10(%rax)
-0x100003531 <+145>: callq 0x100007434 ; symbol stub for: swift_endAccess
-0x100003536 <+150>: movq -0x50(%rbp), %rdi
-0x10000353a <+154>: callq 0x100007476 ; symbol stub for: swift_release
-0x10000353f <+159>: movq -0x68(%rbp), %rdx
-0x100003543 <+163>: movq -0x60(%rbp), %rcx
-0x100003547 <+167>: movq -0x50(%rbp), %rdi
-0x10000354b <+171>: addq $0x18, %rdi
-0x10000354f <+175>: leaq -0x48(%rbp), %rsi
-0x100003553 <+179>: movq %rsi, -0x58(%rbp)
-0x100003557 <+183>: callq 0x100007410 ; symbol stub for: swift_beginAccess
-0x10000355c <+188>: movq -0x58(%rbp), %rdi
-0x100003560 <+192>: movq -0x50(%rbp), %rax
-0x100003564 <+196>: movq $0x16, 0x18(%rax)
-```
-
-可以看到将 `%rbp - 0x50 ` 的值赋值给 `%rax` ，然后将 `oxb` 也就是 11 保存到 `%rax` 也就是 size1 指针的所指向的内存的 `0x10`处，为什么是前面空了16位？因为前8位保存类信息、后8位保存引用计数信息，所以从16位开始。
-
-`movq $0x16, 0x18(%rax)` 将 `0x16` 也就是 22 保存到 `%rax` 也就是 size1 指针的所指向的内存的 `0x18`处，为什么是前面空了24位？因为前8位保存类信息、中间8位保存引用计数信息，后8位保存 Int 的 width，所以从24位开始。
diff --git a/Chapter1 - iOS/1.114.md b/Chapter1 - iOS/1.114.md
deleted file mode 100644
index 5fc2a74..0000000
--- a/Chapter1 - iOS/1.114.md
+++ /dev/null
@@ -1,590 +0,0 @@
-# Swift 闭包研究
-
-## 方法占用对象内存吗？
-
-实验一：
-
- ```swift
-class Point {
- var test = true
- var age = 29
- var height = 175
-}
-var p = Point()
-print(Mems.size(ofRef: p)) // 48
- ```
-
-为什么是48，而不是40？
-
-Point 类前16位的前8位表示类信息，后8位表示引用计算信息，2个 Int 占2*8 = 16 Byte，Bool 占用1 Byte。所以实际占用 8 + 8 + 2 * 8 + 1 = 33 Byte。但由于存在内存对齐（内存对齐以8为 base，都是8的整数倍），但 malloc 函数分配的内存都是 16的倍数，所以占用48 Byte。
-
-
-
-Demo:
-
-```swift
-class Person {
- var age = 29
- func sayHi () {
- var height = 175
- print("局部变量", Mems.ptr(ofVal: &height))
- print("I am \(age) old")
- }
-}
-func sayOuterHi () {
- print("Hello world")
-}
-
-var p = Person()
-p.sayHi()
-sayOuterHi()
-
-print("全局变量", Mems.ptr(ofVal: &p))
-print("堆空间", Mems.ptr(ofRef: p))
-```
-
-
-
-
-
-代码段：Person.sayHi 0x1000034d0
-
-代码段：sayOuterHi 0x1000038e0
-
-全局变量： 0x000000010000c388
-
-堆空间： 0x20c820
-
-局部变量（栈）： 0x00007ff7bfeff2f8
-
-可以看到写在类里面的方法地址和写在 Class 外部的方法地址差不多，都在代码段。
-
-结论：方法不占用对象的内存。方法、函数存放于代码段。
-
-
-
-## 闭包
-
-### 定义
-
-什么是闭包？一个函数和它所捕获的变量/常量环境组合起来，称为闭包。
-
-- 一般指定义在函数内部的函数
-- 一般捕获的是外层函数的局部变量、常量
-
-
-
-### 原理窥探
-
-Demo
-
-```swift
-func exec(a: Int, b: Int, fn: (Int, Int) -> Int) {
- print(fn(a, b))
-}
-// 写法1
-func sum(a: Int, b: Int) -> Int { return a + b }
-exec(a: 1, b: 2, fn: sum)
-
-// 写法2:闭包
-exec(a: 1, b: 2, fn: {
- (a: Int, b: Int) -> Int in
- return a + b
-})
-// 写法3:闭包简写
-exec(a: 1, b: 2, fn: {
- a,b in return a + b
-})
-// 写法4:闭包简写
-exec(a: 1, b: 2, fn: {
- a,b in a + b
-})
-// 写法5:闭包简写。用$0、$1来获取参数。
-exec(a: 1, b: 2, fn: { $0 + $1 })
-// 写法5:闭包简写。用 + 来代表操作，让编译器进行推断
-exec(a: 1, b: 2, fn: + )
-```
-
-如果将一个很长的闭包表达式作为函数的最后一个实参，使用尾随闭包可以增强函数的可读性。尾随闭包是一个被书写在函数调用括号外面（后面）的闭包表达式
-
-上面的写法等价于
-
-```swift
-// 写法6:尾随闭包
-exec(a: 1, b: 2) {
- $0 + $1
-}
-```
-
-如果闭包表达式是函数的唯一实参，而且使用饿尾随闭包的语法，那就不需要在函数名后面写圆括号
-
-```swift
-func exec(fn: (Int, Int) -> Int) {
- print(fn(1, 2))
-}
-
-exec(fn: { $0 + $1 }) // 3
-exec() { $0 + $1 } // 3
-exec{ $0 + $1 } // 3
-```
-
-来个 Demo 看看系统数组的排序
-
-```swift
-var array = [1, 8, 9, 12, 32, 2]
-//array.sort()
-func compare(a: Int, b: Int) -> Bool {
- return a < b
-}
-// 写法1
-//array.sort(by: compare)
-
-// 写法2
-// array.sort { $0 < $1 }
-
-// 写法3
-//array.sort { a, b in
-// return a < b
-//}
-
-// 写法4
-//array.sort(by: {
-// (a: Int, b: Int) -> Bool in
-// return a < b
-//})
-
-// 写法5
-//array.sort(by: <)
-
-// 写法6
-array.sort() { $0 < $1 }
-
-print(array) // [1, 2, 8, 9, 12, 32]
-```
-
-
-
-Demo2
-
-闭包的变量捕获
-
-```swift
-typealias Fn = (Int) -> Int
-func getFn() -> Fn {
- var num = 0
- func plus(_ i: Int) -> Int {
- return i
- }
- return plus
-}
-var fn = getFn()
-print(fn(1)) // 1
-print(fn(2)) // 2
-print(fn(3)) // 3
-```
-
-
-
-
-
-简单修改下代码
-
-```swift
-typealias Fn = (Int) -> Int
-func getFn() -> Fn {
- var num = 0
- func plus(_ i: Int) -> Int {
- num += i
- return num
- }
- return plus
-}
-var fn = getFn()
-print(fn(1)) // 1
-print(fn(2)) // 3
-print(fn(3)) // 6
-```
-
-
-
-
-
-可以看到上面有 `allocObject` 方法调用，说明产生了堆空间对象，用于存放 `num` 。是由 `var fn = getFn()` 造成的，调用1次 `getFn` 则产生1次堆空间分配，用于保存 num。
-
-也就是说如果一个内层函数访问了外层函数的局部变量，也就会发生变量捕获，做法就是延长局部变量的生命周期，在堆空间申请一段内存，用户保存局部变量。
-
-对代码进行修改
-
-```swift
-typealias Fn = (Int) -> Int
-func getFn() -> Fn {
- var num = 1
- func plus(_ i: Int) -> Int {
- num += i
- return num
- }
- return plus
-}
-var fn1 = getFn()
-var fn2 = getFn()
-var fn3 = getFn()
-print(fn1(1)) // 2
-print(fn2(2)) // 3
-print(fn3(3)) // 4
-```
-
-我们在汇编 `swift_allocObject` 下面下个断点
-
-
-
-
-
-第一次：可以看到 `alloc` 在堆空间申请后的内存被存放到寄存器 `rax` 中，此时只是申请内存，没有赋值的。利用 `Debug -> Debug Workflow -> View Memory` 查看内存信息`0x0000600000210000`。此时还没值。
-
-敏感点，查看到字面量1，给汇编代码15行加断点，执行完15行，继续查看内存信息
-
-
-
-可以看到内存数据发生了改变。绿色框内有了值1。
-
-
-
-第二次：可以看到 `alloc` 在堆空间申请后的内存被存放到寄存器 `rax` 中，此时只是申请内存，没有赋值的。利用 `Debug -> Debug Workflow -> View Memory` 查看内存信息`0x00006000002042c0`。此时还没值。
-
-敏感点，查看到字面量1，给汇编代码15行加断点，执行完15行，继续查看内存信息
-
-
-
-第三次：可以看到 `alloc` 在堆空间申请后的内存被存放到寄存器 `rax` 中，此时只是申请内存，没有赋值的。利用 `Debug -> Debug Workflow -> View Memory` 查看内存信息`0x000060000020d460`。此时还没值。
-
-敏感点，查看到字面量1，给汇编代码15行加断点，执行完15行，继续查看内存信息
-
-
-
-打印结果也说明了问题，因为调用3次 `getFn()` 所以会在堆上 alloc 3块内存，用于保存捕获的变量。所以调用 fn1 得到 2，调用 fn2 得到 3，调用 fn3 得到 4。
-
-BTW，堆空间分配的内存，如果没有 `init` 或者赋特定的值，数据会是随机的。因为有可能是之前别的地方使用过的内存。
-
-
-
-### 闭包内存结构
-
-先来个简单的函数，看看指针内存结构
-
-```swift
-func sum(_ a: Int, _ b: Int) -> Int { return a + b }
-var fn = sum
-print(fn(1, 2)) // 3
-```
-
-在 `var fn = sum` 处下断点，可以看到下面汇编
-
-
-
-我们知道 `leaq` 是从 `%rip + 0x10f` 算出来的地址，赋值给 `%rax`。所以大概可以推测 `%rip + 0x10f` 就是 `sum` 函数地址。LLDM p 打印 `sum` 地址为 `0x0000000100003a30`。
-
-`%rip` 是下一条指令的地址 `0x100003921`，`%rip + 0x10f` 也就是 `0x0000000100003a30`。和猜想一致。
-
-第六行汇编的意思就是将 `sum` 函数的地址赋值给 `%rax`。
-
-第七行汇编的意思是将保存在 `%rax` 内的地址，从 `%rip + 0x88d8` 处，取8个字节用来保存 `%rax` 的地址。`0x100003928 + 0x88d8 = 0x10000C200`
-
-第八行汇编的意思是将保存在 `%rax` 内的地址，从 `%rip + 0x88d85` 处，取8个字节用来保存 `$0x0` 。`0x100003933 + 0x88d5 = 0x10000C208`
-
-`0x10000C200` 到 `0x10000C208` 差8位，也是连续的。说明分配了一个函数指针，长度为16位。通过`MemoryLayout.stride(ofValue: sum)` 看到也是16位。符合猜想。
-
-
-
-直奔主题，研究闭包内存
-
-
-
-可以看到在调用完第六行的函数后将寄存器 `rax`、`rdx` 里的值取出来使用了。进入函数内部看看发生了什么，LLDB 输入 `si`
-
-
-
-可以看到 `rax` 里面存放了 `plus` 函数地址。第7行汇编是异或运算，2个 `ecx` 异或，结果为0，写入到 `ecx` 里。然后第8行汇编将 `ecx` 里的0写入到 `edx`，`edx` 也就是 `rdx`。走完第6行的汇编，继续看第7、8行
-
-
-
-将第6行函数的返回结果 `rax` 里的函数地址赋值给 `rip +0x89e7 = 0x100003819 + 0x89e7 = 0x10000C200 `， 第7行的`rdx` 的值赋值个给 `rip +0x89e8 = 0x100003820 + 0x89e8 = 0x10000C208`。
-
-也就是 fn1 前8个字节存放 plus 的函数地址，后8个字节存放0.
-
-
-
-继续对比实验，查看闭包放了什么东西(注意和上面的实验不同，下面存在闭包)
-
-
-
-基本可以断定：函数会返回一个长度为16 Byte 的内存。分别保存在 `rax` 和 `rdx`上。所以针对性的研究 `rdx` 和 `rax`
-
-汇编第10行，经过在堆上为捕获的变量 alloc 内存后，将内存保存到 `rax` 中，然后赋值给 `rdi`，第11行，将 `rdi` 再赋值给 `rbp - 0x10` 的地址。所以汇编19行的 `rbp - 0x10 ` 保存的也就是堆内存，赋值给 `rdx ` 了。
-
-20行的 `rax` 保存了一个看似是 `plus` 的函数地址。具体是：`rip + 0x167 = 0x100003969 + 0x167= 0x100003C37 `
-
-
-
-继续走，走到真正的 `plus` 方法内，可以看到函数地址是 `0x100003970` 。所以返回的 `rax` 里面可能是间接调用真正的 `plus` 函数的。
-
-
-
-问题变得微妙起来了，`getFn` 方法返回一个地址，占用16个字节，但是前8个字节存储 `plus` 方法地址，后8个字节存储闭包捕获后在堆上申请内存存放的数据地址。那如何根据一个地址的前8位去真正调用方法？
-
-
-
-Tips：由于地址是动态生成的，所以真正去调用 plus 的时候一定不是写死的地址，一定是动态生成的。这种属于间接调用。
-
-- call 后面直接加一个函数地址，属于直接调用。类似 `callq 0x100003970`
-- call 后面的函数地址不是固定的，而是动态生成的叫间接调用。在 `at&t` 汇编里面，间接调用前面要加 `*` 。类似 `callq *%rax`，意思是从 `%rax` 里面取出一个地址值出来，当成函数地址，去调用
-
-顺着思路，分析下汇编：
-
-
-
-我们看到25行 `callq *%rax` 存在动态调用，所以需要找到 `%rax` 里的值是哪里来的。然后顺着向上找，找到23行 `movq -0x30(%rbp), %rax`。然后继续向上看到16行 `movq %rax, -0x30(%rbp)`。继续向上看到15行 `movq 0x88db(%rip), %rax`。相当于就是在 `rip + 0x88db ` 处取出8个字节出来，当作函数地址调用（汇编代码的右边写了，`fn1` ），地址为：`0x88db(%rip) = rip + 0x88db = 0x10000392d + 0x88db = 0x10000C208` 。
-
-断点继续放开，在汇编25行处加断点 `callq *%rax`
-
-
-
-可以看到在方法内部，第6行汇编处，直接调用一个代码段的函数地址 `jmp 0x1000039f0 `
-
-指令 `jmp`、`call` 的区别在于：
-
-- `jmp` 指令控制程序直接跳转到目标地址执行程序，程序总是顺序执行，指令本身无堆栈操作过程。
-- `call` 指令跳转到指定目标地址执行子程序，执行完子程序后，会返回 `call` 指令的下一条指令处执行程序，执行 `call` 指令有堆栈操作过程
-
-LLDB 输入 `si`，可以看到是 `plus` 函数真正的地址
-
-
-
-
-
-`fn1` 函数调用的时候，参数如何传递？
-
-
-
-汇编17行 `movq 0x88d8(%rip), %r13 ; SwiftDemo.fn1 : (Swift.Int) -> Swift.Int + 8`可以看到将返回的 fn1 本身16字节的后8个字节，也就是堆地址空间值，保存到寄存器 `edi` 也就是寄存器 `rdi` 上了。
-
-汇编24行 `movl $0x1, %edi` 将参数1传给寄存器 `rdi` 了。
-
-然后 LLDB 输入 `si` 去分析 callq 内部
-
-
-
-
-
-可以看到 `movq %r13, %rsi` 将寄存器 r13 的值写入到 `rsi` 了。目前为止：`rdi` 保存参数1，`rsi` 保存堆地址值。
-
-继续输入 `si`
-
-
-
-可以看到汇编的第5行 `movq %rsi, -0x50(%rbp)` 将 `rsi` 里的1，保存到 `rbp - 0x50` 处。第6行汇编 `movq %rdi, -0x58(%rbp)` 将 `rdi` 堆地址值保存到 `rbp - 0x58` 处。
-
-汇编26行 `movq -0x58(%rbp), %rdi` 将 `rbp - 0x58` 的值写入到 `rdi`，也就是堆地址值。第27行 `movq -0x50(%rbp), %rsi` 将 `rbp - 0x50` 的值写入到 `rsi`，也就是参数值1。
-
-然后真正做 `plus` 加法运算的就是28行的 `addq 0x10(%rsi), %rdi`， 从 `rsi` 堆地址值的第16个字节的地方取出8个字节的值，也就是捕获的外部变量 `num` 再和参数1相加。
-
-
-
-可以看到第6行堆地址空间的值写入到 `rbp -0x58` ，第26行又将 `rbp -0x58` 写入到 `rdi`，29行将 `rdi` 的值，写入到 `rbp - 0x48`，34行将 `rbp - 0x48` 写入到 `rcx`，35行将 `rcx` 的地址值，写入到 `rax` 对应的存储空间。也就是堆上的 `num` 值已经修改，被覆盖了。
-
-
-
-总结：当 `getFn` 内部没有发生闭包的时候，fn1 的地址就是16 Byte，前8 Byte就是 `plus` 的函数地址。当发生函数闭包的时候，`fn1` 的16 Byte，前8 Byte 存储间接调用 `plus` 函数的中转函数，后8 Byte 存储着捕获的且在堆上分配内存的地址值。真正调用 `plus` 的时候会通过寄存器传递2个参数：1个是 fn1 函数的参数，1个是堆空间的地址值。
-
-```swift
-var fn1 = getFn()
-fn1(1) // 2
-fn1(3) //4
-```
-
-因为只调用1次 `getFn` 所以堆内存分配了1个被捕获的变量地址，调用过1次 fn1 后，堆地址所指向的内存上的数被修改了。当第二次调用的时候操作的还是同一块堆内存地址，也就是同一个被捕获的堆地址所指向的变量。
-
-```swift
-var fn1 = getFn()
-fn1(1) // 2
-fn1(3) //4
-var fn2 = getFn()
-fn2(2) // 3
-fn2(4) // 5
-```
-
-因为调用了2次 `getFn` 所以堆内存分配了2个被捕获的变量地址，调用过1次 fn1 后，堆地址所指向的内存上的数被修改了。当第二次调用的时候操作的还是同一块堆内存地址，也就是同一个被捕获的堆地址所指向的变量。当调用 fn2 的时候操作的是被捕获的新的一个堆地址空间所指向的变量。
-
-且 fn1 所占用的16个字节，fn2 所占用16个字节。2者的前8字节内容相同，都是包装了 `plus` 函数的一个地址。
-
-
-
-### “闭包就是对象”
-
-捕获了外部变量的闭包类似于一个类，里面存在存储属性和方法
-
-```swift
-class {
- var num: Int
- func fn(_ i: Int) -> Int {
- return i + num
- }
-}
-```
-
-
-
-
-
-
-
-## 自动闭包
-
-**自动闭包是一种自动创建的，用来把作为实际参数传递给函数的表达式打包的闭包**。它不接受任何实际参数，并且当它被调用时，它会返回内部打包的表达式的值
-
-这个语法的好处在于通过写普通表达式代替显示闭包，而使你省略包围函数的形式参数的括号.
-
-比如系统的断言 `assert`
-
-```swift
-public func assert(_ condition: @autoclosure () -> Bool, _ message: @autoclosure () -> String = String(), file: StaticString = #file, line: UInt = #line)
-
-```
-
-
-
-```swift
-// 语法糖。自动闭包
-func getPositiveValue(_ v1: Int, _ v2: @autoclosure () -> Int) -> Int {
- return v1 > 0 ? v1 : v2()
-}
-
-//print(getPositiveValue(10, {20}))
-//print(getPositiveValue(-10) {20})
-//print(getPositiveValue(-20) {
-// let a = 10
-// return a + 1
-//}
-//)
-
-print(getPositiveValue(-10, 22))
-```
-
-`@autoclosure` 会自动将 22 封装成闭包 `{ 22 }`。
-
-`@autoclosure` 只支持 `() -> T` 无参数，并且有一个返回值的闭包。
-
-`@autoclosure` 并非只支持最后1个参数。
-
-`??` 函数的本质就是自动闭包
-
-
-
-自动闭包允许延迟处理，因此任何闭包内部的代码直到你调用的时候才会运行。对于有副作用或者占用资源的代码来说很有用。因为它可以允许你控制代码何时进行求值
-
-```swift
-var group = ["zhangsan", "lisi", "wangwu"]
-//print(group.count)
-//let groupRemover = { group.remove(at: 0) }
-//print(group.count)
-//
-////print("execute remove function \(groupRemover())")
-//print(group.count)
-
-
-func serve(customer customerProvider: @autoclosure () -> String) {
- print("Now serving \(customerProvider())!")
-}
-serve(customer: group.remove(at: 0))
-// Now serving zhangsan!
-```
-
-如果一个闭包作为参数，是可以去掉 `{}` 的，参数加了 `@autoclosure` 后，是会自动转换为闭包的。
-
-但如果函数参数没有加 `@autoclosure`，在调用函数的时候，传参没有加 `{}` 编译器是会报错的
-
-
-
-正确的做法是：要么加 `@autoclosure` 要么在函数调用的时候加 `{}`
-
-```swift
-// 改法1
-func collectCustomerProviders(_ customerProvider: @escaping () -> String) {
- customerProoviders.append(customerProvider)
-}
-collectCustomerProviders( { group.remove(at: 0) })
-// 改法2
-func collectCustomerProviders(_ customerProvider: @autoclosure @escaping () -> String) {
- customerProoviders.append(customerProvider)
-}
-collectCustomerProviders(group.remove(at: 0))
-```
-
-如果你的自动闭包允许逃逸，就可以同时使用 `@autoclosure` 和 `@escaping `
-
-```swift
-var customerProoviders: [() -> String] = []
-func collectCustomerProviders(_ customerProvider: @autoclosure @escaping () -> String) {
- customerProoviders.append(customerProvider)
-}
-collectCustomerProviders(group.remove(at: 0))
-```
-
-
-
-## 闭包和闭包表达式的区别
-
-### 闭包
-
-定义：闭包是自包含的功能代码块，可以在代码中被传递和使用。它能捕获并存储其所在上下文的常量和变量（即“闭合”环境）
-
-种类：
-
-- 全局函数（有名称，不捕获任何值）
-- 嵌套函数（有名称，可捕获外曾函数的变量）
-- 闭包表达式（匿名，轻量语法，可以捕获上下文变量）
-
-闭包强调的是：捕获上下文的能力。不管是函数还是闭包表达式
-
-### 闭包表达式
-
-定义：是 Swift 中一种简洁的语法格式，用于编写匿名闭包。是闭包的一种实现方式之一（函数和闭包表达式都可以实现闭包）
-
-特点：
-
-- 没有函数名
-- 语法清凉，支持参数类型推断、隐式返回、简写参数名（如 $0、$1）等特性
-- 通常用于作为函数的参数传递
-
-
-
-### 总结
-
-- **闭包**是广义概念，包含所有能捕获上下文的代码块（如函数、闭包表达式）。
-- **闭包表达式**是闭包的一种具体实现方式，专指用轻量语法编写的匿名闭包。
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
diff --git a/Chapter1 - iOS/1.115.md b/Chapter1 - iOS/1.115.md
deleted file mode 100644
index e59869c..0000000
--- a/Chapter1 - iOS/1.115.md
+++ /dev/null
@@ -1,673 +0,0 @@
-# 属性
-
-## 实例相关属性分类
-
-### 存储属性
-
-英文叫 Stored Property
-
-- 类似于成员变量的概念
-- 为什么叫存储属性？属性的内存直接存储在实例的内存中
-- 结构体、类，都有存储属性
-- **枚举不可以定义存储属性**
-
-
-
-### 为什么 enum 不可以定义存储属性？
-
-最基础的枚举，内存占用1个字节，只用来存储哪个 case 的索引值
-
-```swift
-enum Season {
- case spring
- case summer
- case antumn
- case winter
-}
-```
-
-带有关联值的枚举
-
-```swift
-enum Season {
- case spring(Int, Int, Int)
- case summer(Int, Int)
- case antumn(Int)
- case winter(Bool)
- case unknown
-}
-var season: Season = Season.spring(1, 2, 3)
-print(MemoryLayout
-
-然后断点继续，在 `let diameter = circle.diameter` 处加断点，可以看到调用了 getter 方法
-
-
-
-计算属性的本质就是方法，看上去是属性，但是不占用结构体的内存。而是独立在代码段中，所以只占用1个 Int 即8个字节的大小。
-
-
-
-- **计算属性可以有只读计算属性**
-
- 也就是只有 getter，没有 setter 方法
-
- ```swift
- struct Circle {
- var radius: Int // 存储属性
- var diameter: Int { radius*2 }
- }
- ```
-
-
-
-### 延迟存储属性
-
-常规写法
-
-```swift
-class Car {
- init () {
- print("Car init")
- }
-
- func run () {
- print("Car is running")
- }
-}
-
-class Person {
- let car:Car = Car()
- init () {
- print("Person init")
- }
-
- func goOut() {
- car.run()
- }
-}
-
-
-let p = Person()
-print("---")
-p.goOut()
-
-// console
-Car init
-Person init
----
-Car is running
-```
-
-但是想实现一个需求，就是在 Person 初始化的时候先不初始化 Car，当调用 Person 对象的 goOut 方法的时候再初始化，该怎么办？
-
-**使用 lazy 可以定义一个延迟存储属性，在第一次用到属性的时候才会进行初始化**
-
-对 Person 改造如下
-
-```swift
-class Person {
- lazy var car:Car = Car()
- init () {
- print("Person init")
- }
-
- func goOut() {
- car.run()
- }
-}
-// console
-Person init
----
-Car init
-Car is running
-```
-
-注意：延迟属性 lazy 必须和 var 搭配使用，不能是 let
-
-
-
-## 异同点
-
-存储属性：
-
-- 类似于成员变量
-
-- 存储在实例的内存中
-
-- 结构体、类可以定义存储属性
-
-- 枚举不可以定义存储属性
-
-- 在创建类、结构体的实例时，必须为所有的存储属性设置一个合适的初始值
-
-- 延迟存储属性必须是 `var`，不能是 `let`。 因为 Swift 规定 let 必须在实例的初始化方法完成之前就拥有值
-
-- `lazy` 在多线程情况下，无法保证属性只被初始化1次。
-
- ```swift
- struct Point {
- var x:Int
- lazy var y = 0
- init(_ x: Int = 0) {
- self.x = x
- }
- }
- var p = Point(2)
- print(p.y)
- ```
-
-- 当结构体包含一个延迟存储属性时，只有 var 才能访问延迟存储属性（因为延迟属性初始化的时候需要改变结构体内存）。Class 的话，实例可以用 let 修饰，访问延迟存储属性是可以的。
-
- QA：为什么结构体包含一个延迟存储属性时，只有 var 才能访问延迟存储属性？
-
- 之前在 [Swift 结构体和类的内存布局](./1.113.md) 探究过 `struct` 的内存布局，`struct` 的成员变量在内存中是连续存储的。由于是延迟存储属性，等真正使用的时候才会执行延迟属性的初始化逻辑，才会更改 `struct `的内存，所以 `let` 无法满足更改内存的需求。
-
- ```swift
- struct Point {
- var x = 0
- lazy var y = 0
- }
-
- let p = Point()
- print(p.y) // Cannot use mutating getter on immutable value: 'p' is a 'let' constant
-
- var p2 = Point()
- print(p2.y) // 0
-
-
- class Point {
- var x:Int
- lazy var y = 0
- init(_ x: Int = 0) {
- self.x = x
- }
- }
-
- let p = Point(2)
- print(p.y) // 0
- ```
-
-计算属性：
-
-- 本质就是方法
-- 不占用实例内存
-- 枚举、结构体、类都可以定义计算属性
-- 计算属性只能用 var，不能用 let
-
-
-
-
-
-## 枚举 rawValue 的原理
-
-枚举原始值 rawValue 的本质：只读的计算属性，不占用实例内存。
-
-```swift
-enum Season: Int {
- case spring = 10
- case summer = 20
- case autumn = 30
- case winter = 40
-}
-
-let season = Season.summer
-// season.rawValue = 22 // Cannot assign to property: 'rawValue' is immutable
-print(season.rawValue)
-```
-
-
-
-通过汇编 `SwiftDemo.Season.rawValue.getter` 可以看到，在调用 **`enum` 的 `rawvalue` 的时候本质是通过计算属性调用 `getter` 来实现的**。
-
-类似于：
-
-```swift
-enum Season: Int {
- case spring = 10
- case summer = 20
- case autumn = 30
- case winter = 40
-
- var rawValue: Int {
- get {
- switch self {
- case .spring:
- return 10
- case .summer:
- return 20
- case .autumn:
- return 30
- case .winter:
- return 40
- }
- }
- }
-}
-
-let season = Season.summer
-print(season.rawValue)
-```
-
-也侧面证明了 rawValue 不占用枚举的内存空间（是方法，存储在代码段）
-
-
-
-## 属性观察器
-
-- 可以为非 `lazy` 的 `var` 存储属性设置属性观察期
-
-- 计算属性由于有 set 和 get，因此不能有属性观察器 willSet 和 didSet
-
-- 在初始化器中设置属性值不会触发 `willSet`、`didSet`
-
-- 属性观察器、计算属性的功能，同样可以应用在全局变量、局部变量上
-
- ```swift
- var num: Int {
- get {
- return 10
- }
- set {
- print("newValue", newValue)
- }
- }
- num = 11
- print(num)
- // console
- newValue 11
- 10
-
- func test () {
- var age: Int {
- set {
- print("new age is ", newValue)
- }
- get {
- 28
- }
- }
- age = 29
- print(age)
- }
- test()
- // console
- new age is 29
- 28
- ```
-
-
-
-## Inout 核心原理
-
-### 普通的存储属性
-
-```swift
-struct Shape {
- var width: Int
- var side: Int {
- willSet {
- print("willset side", newValue)
- }
- didSet {
- print("didset side", oldValue, side)
- }
- }
- var girth: Int {
- set {
- width = newValue/side
- print("set girth ", newValue)
- }
- get {
- print("get girth")
- return width * side
- }
- }
- func show() {
- print("width is \(width), side is \(side), girth is \(girth)")
- }
-}
-
-func changeValue(_ value: inout Int) {
- value = 20
-}
-
-var shape = Shape(width: 10, side: 4)
-changeValue(&shape.width)
-shape.show()
-
-// console
-get girth
-width is 20, side is 4, girth is 80
-```
-
-在 `changeValue(&shape.width)` 处加汇编可以看到断点停在第10行 `leaq 0x953c(%rip), %rdi ` 即将 `rip + 0x953c = 0x100002cbc + 0x953c = 0x10000C1F8 ` 赋值给 `rdi`。
-
-第16行也是一样，`leaq 0x9523(%rip), %rdi ` 即将 `rip + 0x9523 = 0x100002cd5 + 0x953c = 0x10000C1F8 ` 赋值给 `rdi`。
-
-
-
-
-
-然后看到17行的关键代码，LLDB 输入 `si`，可以看到在第6行 `movq $0x14, (%rdi)`，将16进制的 `0x14` 也就是20，移动到指定的内存地址 `rdi` 上
-
-
-
-因为 `struct` 结构体内存布局中，成员变量在内存中是连续存储的。所以 `struct `的地址也就是 `struct` 中第一个成员变量 `width` 的地址。
-
-
-
-总结：普通的存储属性，在调用方法的时候，如果参数是 `inout` 传递引用，则直接传递存储属性的地址值即可。在方法内部，对该地址对应的值进行修改即可。
-
-
-
-### 计算属性
-
-对调用的代码进行调整
-
-```swift
-var shape = Shape(width: 10, side: 4)
-changeValue(&shape.girth)
-shape.show()
-// console
-get girth
-set girth 20
-get girth
-width is 5, side is 4, girth is 20
-```
-
-在 `changeValue(&shape.girth)` 处下断点，查看汇编
-
-
-
-核心思路：方法参数用 `inout`修饰，则传递的是引用（内存地址）。
-
-- 汇编19行 `callq 0x1000030e0 ; SwiftDemo.Shape.girth.getter : Swift.Int at main.swift:16` 调用了 `girth` 计算属性的 `getter`，`getter` 的返回值存放在寄存器 `rax` 上
-
-- 20行将 `movq %rax, -0x28(%rbp)` 函数返回值 `rax` 存放在 `main` 函数的栈空间上（虽然没有写调用函数，但是代码主入口就是 `main` 函数），且 `rbp` 到 `rsp` 之间都是函数的栈空间。也就是一个局部变量
-
-- 21行 `leaq -0x28(%rbp), %rdi` 将栈空间上 `-0x28(%rbp)` 的地址值赋值给 `rdi` 寄存器
-
-- 22行 `callq 0x1000037b0 ; SwiftDemo.changeValue(inout Swift.Int) -> () at main.swift:26` 调用 `changeValue` 方法，参数通过寄存器 `rdi` 传递，里面是栈空间 getter 值的地址。
-
-- LLDB 输入 `si` 查看 changeValue 内部。可以看到第6行 `movq $0x14, (%rdi)` 直接将20赋值给 `rdi`
-
- 
-
-
-
-- LLDB 输入 `finish` 结束 `changeValue` 细节，查看外部23行汇编 `movq -0x28(%rbp), %rdi` ，将 `main` 函数栈空间上 `getter` 返回值的内存对应的值，保存到寄存器 `rdi` 上。
-
-- 25行 `callq 0x100003250 ; SwiftDemo.Shape.girth.setter : Swift.Int at main.swift:12` 调用计算属性的 `setter`，函数参数为 `rid` 寄存器里的值（也就是20）
-
-总结：带有计算属性的存储属性，如果调用的方法参数是 `inout` 类型，系统真正实现，不能直接将对应的地址传进去，因为传进去很多简单，满足了修改值的需求。但是属性观察器的 `set`、`get` 就没办法触发了。所以为了触发属性观察器系统的设计是：
-
-- 第一步：先将传递进去的属性调用 `getter` ，保存在函数的栈地址空间内的某个内存上
-- 第二步：然后调用带有 `inout` 属性的方法，将步骤一得到的内存传递当作参数传进去。修改该内存对应的值
-- 第三步：将步骤二得到的值后，调用 `setter` 方法。
-
-这个流程下来，满足了修改值，且触发了原始属性观察器的需求。
-
-
-
-### 带有属性观察器的存储属性
-
-对调用的代码进行调整
-
-```swift
-var shape = Shape(width: 10, side: 4)
-changeValue(&shape.side)
-shape.show()
-// console
-willset side 20
-didset side 4 20
-get girth
-width is 10, side is 20, girth is 200
-```
-
-在 `changeValue(&shape.side)` 处添加断点，查看汇编
-
-
-
-分析：
-
-- 17行 `movq 0x9549(%rip), %rax ; SwiftDemo.shape : SwiftDemo.Shape + 8` 将地址格式为 `0x9549(%rip)` 一个全局变量，也就是 `shape` 的地址 + 8 的值，赋值给 `rax` 寄存器
-
-- 18行 `movq %rax, -0x28(%rbp)` 将寄存器 `rax` 里的值，赋值给 `main` 函数的栈空间上的局部变量 `-0x28(%rbp)`
-
-- 19行 将 `main` 函数的栈空间上的局部变量 `-0x28(%rbp)` 的地址值，赋值给寄存器 `rdi`
-
-- 20行 `callq 0x1000037b0 ; SwiftDemo.changeValue(inout Swift.Int) -> () at main.swift:26` 调用 `changeValue `方法。函数参数通过寄存器 `rdi` 传递，函数内部修改了该内存上的值
-
-- 21行 `movq -0x28(%rbp), %rdi` 将 `main` 函数的栈空间上的局部变量 `-0x28(%rbp)` 的值，赋值给寄存器 `rdi`。也就是修改后的20
-
-- 23行 `callq 0x100002db0 ; SwiftDemo.Shape.side.setter : Swift.Int at main.swift:3` 调用 setter
-
-- LLDB 输入 `si`，可以看到 `setter` 方法内部，调用了 `willSet`、`didSet`
-
- 
-
-
-
-总结：带有属性观察器的存储属性，如果调用的方法参数是 `inout` 类型，系统真正的实现，并不是直接将 inout 参数的地址传进去，因为传进去很简单，满足了修改值的需求，但属性观察器的 `willSet`、`didSet` 就没办法触发了。
-
-问题症结是：**直接传递 inout 参数的地址，可以满足直接修改值的需求，但直接修改没办法触发属性观察器的 willSet 和 didSet**
-
-所以为了触发属性观察器系统的设计是：
-
-- 第一步：先将传递进去的地址，保存在函数的栈地址空间内的某个内存上
-- 第二步：然后调用带有 `inout` 属性的方法，将步骤一得到的内存传递当作参数传进去。修改该内存对应的值
-- 第三步：将步骤二得到的值后，调用一个 `setter` 方法，`setter` 方法内，先调用 `willSet`，再修改真正的带有观察属性的存储属性的值，最后调用 `didSet` 方法。
-
-这个流程下来，满足了修改值，且触发了原始属性观察器的需求。
-
-
-
-
-
-### 总结
-
-1. 如果实参有内存地址，且没有设置属性观察器和计算属性，实现是直接将实参的内存地址传入带 `inout` 函数
-2. 如果实参是计算属性或者设置了属性观察器：系统采用了 **Copy In Copy Out** 的策略
- - 调用带 `inout` 函数时，先复制实参的值，产生副本 （get。栈空间上的局部变量 rbx + offset）
- - 将副本的内存地址传入带 `inout` 函数（副本进行引用传递），在函数内部修改副本的值
- - 函数返回后，再将副本的值覆盖实参的值（set。willSet、didSet）
-
-
-
-## 类型属性
-
-- 不同于存储属性，类型属性必须设置初始值，永伟类型属性不像存储属性那样有 `init` 初始化器来初始化存储属性
-
-- 类型属性就不存储在每个实例的内存里
-
-- 存储属性默认就是 `lazy`，会在第一次使用的时候才初始化
-
-- 存储属性就算被多个线程同时访问，但系统会保证只初始化1次
-
-- 存储类型属性可以是 `let`
-
-- 存储属性可以用 `static` 修饰
-
-- **枚举 enum 里面不可以实例存储属性，但是可以定义类型存储属性**
-
- ```swift
- enum Season {
- static let age: Int = 0
- case spring, summer, antumn, winter
- }
- var season = Season.summer
- ```
-
-- 类型属性的经典场景就是单例模式
-
- ```swift
- class FileManager {
- private init() {}
- public static let sharedInstance: FileManager = FileManager()
- }
-
- var manager1 = FileManager.sharedInstance
- var manager2 = FileManager.sharedInstance
- var manager3 = FileManager.sharedInstance
- print(Mems.ptr(ofRef: manager1)) // 0x0000600000008030
- print(Mems.ptr(ofRef: manager2)) // 0x0000600000008030
- print(Mems.ptr(ofRef: manager3)) // 0x0000600000008030
- ```
-
-
-
-### 内存角度分析：类型属性存储在哪
-
-Demo1:
-
-
-
- `movq $0xa, 0x86d1(%rip) ` num1 的地址为: `rip + 0x86d1 = 0x100003b0f + 0x86d1 = 0x10000C1E0 `
-
-`movq $0xb, 0x86ce(%rip)` num2 的地址为: `rip + 0x86ce = 0x100003b1a + 0x86ce = 0x10000C1E8 `
-
- `movq $0xc, 0x86cb(%rip) ` num3 的地址为: `rip + 0x86cb = 0x100003b25 + 0x86cb = 0x10000C1F0 `
-
-可以看到 `0x10000C1E0` `0x10000C1E8` `0x10000C1F0` 在内存上是连续的，间隔8Byte。可见分配的3个全局变量内存是连续的
-
-
-
-Demo2
-
-
-
-`movq $0xa, 0x8b65(%rip)` num1 的内存为 `rip + 0x8b65 = 0x1000037c3 + 0x8b65 = 0x10000C328 `
-
-可以看到15行将11赋值给 rax，所以直接读取 rax 的地址：`0x000000010000c330`
-
-`movq $0xc, 0x8b38(%rip) ` num1 的内存为 `rip + 0x8b38 = 0x100003800 + 0x8b38 = 0x10000C338 `
-
-可以看到 `0x10000C328` `0x10000c330` `0x10000C338` 也是内存连续的。所以**类型属性就是带有访问控制（必须通过类来访问）的全局变量**
-
-
-
-### 类型属性是线程安全的
-
-看个 Demo
-
-```swift
-class Manager {
- static var count = Int.random(in: 1...100)
-}
-
-Manager.count = 10
-Manager.count = 11
-```
-
-下断点可以看到，调用了**地址访问器函数**。为什么需要地址访问器函数：
-
-- 线程安全初始化首次访问时触发初始化（可能包含 `dispatch_once` 逻辑）
-- 抽象内存访问隐藏实际存储位置（可能位于不同段或延迟分配）
-- 支持属性观察（didSet）通过封装访问点插入回调逻辑
-
-
-
-lldb 输入 si 查看具体实现
-
-
-
-可以看到底层调用了 `swift_once` 函数，函数传递了2个参数， rsi 存储 dispatch_once 的 block 参数，rdi 存储了 onceToken
-
-继续敲 si 可以看到底层调用的就是 GCD 的 `dispatch_once` 函数。
-
-
-
-
-
-类型属性如何保证线程安全的？如何保证只会初始化一次
-
-底层会调用 `swift_once` 进而调用 `dispatch_once_f`，`dispatch_once_t` 会传递一个函数地址进去执行，类型属性的初始化代码将会被包装成一个函数。 由 `dispatch_once_t` 保证线程安全和只初始化1次。
-
-所以类型存储属性底层通过 dispatch_once 保证了只会初始化1次，线程安全。
-
-
diff --git a/Chapter1 - iOS/1.116.md b/Chapter1 - iOS/1.116.md
deleted file mode 100644
index 67d00bd..0000000
--- a/Chapter1 - iOS/1.116.md
+++ /dev/null
@@ -1,1012 +0,0 @@
-# Swift 类底层剖析
-
-## 类的内存结构
-
-```swift
-class Person {
- var age: Int = 0
-}
-
-class Student: Person {
- var score: Int = 0
-}
-
-class Worker: Student {
- var salary: Int = 0
-}
-
-let person = Person()
-person.age = 28
-print(Mems.size(ofRef: person))
-print(Mems.memStr(ofRef: person))
-
-32
-0x000000010000c400 0x0000000000000003
-0x000000000000001c 0x0000000000000000
-
-let student = Student()
-student.score = 100
-print(Mems.size(ofRef: student))
-print(Mems.memStr(ofRef: student))
-32
-0x000000010000c4b0 0x0000000000000003
-0x000000000000001c 0x0000000000000064
-
-let worker = Worker()
-worker.salary = 1000
-print(Mems.size(ofRef: worker))
-print(Mems.memStr(ofRef: worker))
-48
-0x000000010000c580 0x0000000000000003
-0x000000000000001c 0x0000000000000064 0x00000000000003e8 0x00007ff8501c0938
-```
-
-- 内存对齐都是16 Byte 的整数倍
-- 一个类内存中，至少占16字节的内存。前8位是类信息、其次的8位是引用计数信息，接着是属性内存区域
-- 由于类存在继承，所以子类中，前16字节存储类信息和引用计数信息，其次是属性内存，存在继承的话，前面的属性是父类的属性，后面才是自己的属性。
-
-所以：
-
-- Person 类的内存： 8 Byte 的类信息 + 8 Byte 引用计数信息 + 8 Byte Int Age 属性 = 24 Byte，由于需要16的倍数，所以是32 Byte
-- Student 类的内存： 8 Byte 的类信息 + 8 Byte 引用计数信息 + 8 Byte Int Age 属性 + 8 Byte 的 Int Score 属性 = 32 Byte，由于需要16的倍数，所以是32 Byte
-- Worker 类的内存： 8 Byte 的类信息 + 8 Byte 引用计数信息 + 8 Byte Int Age 属性 + 8 Byte 的 Int Score 属性 + 8 Byte 的 Int Salary 属性 = 40 Byte，由于需要16的倍数，所以是 48 Byte
-
-
-
-## 继承
-
-值类型（枚举、结构体）不支持继承，只有类支持继承
-
-没有父类的类，称为基类。Swift 并不像 OC、Java 那样规定：任何类最终都要继承自某个基类（OC 的 NSObject）。
-
-```swift
-import Foundation
-class Person {}
-class Student: Person {}
-print(class_getSuperclass(Student.self)!) // Person
-print(class_getSuperclass(Person.self)!) // _TtCs12_SwiftObject
-```
-
-丛输出可以看出 Swift 还存在一个隐藏基类：`Swift._SwiftObject`，可查看 [Swift 源码](https://github.com/apple/swift/blob/main/stdlib/public/runtime/SwiftObject.h)
-
-
-
-## 方法
-
-结构体和枚举是值类型，默认情况下，值类型的属性是不能被自身的实例方法修改。
-
-如果想在方法内修改，需要在 `func` 前加 `mutating` 才可以
-
-```swift
-struct Point {
- var x: Double = 0.0
- var y: Double = 0.0
- func moveBy(_ delatX: Double, _ delatY: Double) {
- self.x += delatX
- self.y += delatY
- }
-}
-var point = Point()
-point.moveBy(0.2, 0.2)
-// compiler error
-Left side of mutating operator isn't mutable: 'self' is immutable
-```
-
-改进
-
-```swift
-struct Point {
- var x: Double = 0.0
- var y: Double = 0.0
- mutating func moveBy(_ delatX: Double, _ delatY: Double) {
- self.x += delatX
- self.y += delatY
- }
-}
-var point = Point()
-point.moveBy(0.2, 0.4)
-print(point.x, point.y)
-// 0.2 0.4
-```
-
-
-
-## 重写方法
-
-`override`
-
-被 class 修饰的类型方法、下标，允许被子类重写
-
-被 static 修饰的类型方法、下标，不允许被子类重写
-
-```swift
-class Animal {
- static var innerValue:Int = 0
- class func speak() {
- print("Animal speak")
- }
-
- class subscript(index: Int) -> Int {
- set {
- innerValue = newValue
- }
- get {
- innerValue
- }
- }
-}
-
-class Dog: Animal {
- override class func speak() {
- super.speak()
- print("dog is bark")
- }
- override class subscript(index: Int) -> Int {
- set {
- innerValue = newValue
- }
- get {
- innerValue
- }
- }
-}
-
-Animal.speak() // Animal speak
-Animal[5] = 3
-print(Animal[5]) // 3
-Dog.speak() // Animal speak dog is bark
-```
-
-但如果将 `Animal` 方法的 `class` 改为 `static`，就无法 `override` 了
-
-
-
-
-
-
-- 如果父类的方法是被 class 修饰的，子类继承后重写时，可以将 class 改为 static。
-- 虽然子类可以将父类方法的 class 改为 static。但影响的是当前子类的子类，无法再重写方法了。
-
-
-
-## 重写属性
-
-- 子类不可以将父类的属性改写为存储属性
-- 子类可以将父类的属性（存储属性、计算属性）重写为计算属性
-- 只能重写 var 属性，不能重写 let 属性
-- 重写时，属性名、类型要一致
-- 子类重写后的属性权限（读写），不能小于父类属性的权限
- - 如果父类属性是只读的，子类重写后的属性要么是只读的，要么是可读可写的
- - 如果父类的属性是可读可写的，子类重写后的属性也必须是可读可写的
-
-
-
-## 重写类型属性
-
-- 被 class 修饰的计算类型属性，可以被子类重写
-- 被 static 修饰的类型属性（存储、计算），不可以被子类重写
-- 可以在子类中为父类属性（除了只读的计算属性、let 属性）增加属性观察器
-
-```swift
-class Shape {
- var radius: Int = 1 {
- willSet {
- print("Shape will set radius", newValue)
- }
- didSet {
- print("Shape did set radius", oldValue, radius)
- }
- }
-}
-class Circle: Shape {
- override var radius: Int {
- willSet {
- print("Cirle will set radius", newValue)
- }
- didSet {
- print("Circle did set radius", oldValue, radius)
- }
- }
-}
-var circle = Circle()
-circle.radius = 2
-// console
-Cirle will set radius 2
-Shape will set radius 2
-Shape did set radius 1 2
-Circle did set radius 1 2
-```
-
-可以看到输出类似 Node 的洋葱模型，willset 从外到里，didset 从里到外。
-
-
-
-## final
-
-- 被 final 修饰的方法、属性、下标是禁止被重写的
-
-- 被 final 修饰的类，禁止被继承
-
-
-## Swift 协议（Protocol）中声明的属性必须使用 var 关键字
-
-协议的核心目标：定义“能力”而非“实现”
-协议是描述类型应该具备什么能力的抽象蓝图，而不是具体实现。
-属性在协议中本质上定义的是对外的访问接口（读、写），而不是存储方式（常量或变量）。
-因此，**协议中的属性声明必须明确其访问权限（{ get } 或 { get set }），而 var 是唯一能表达这种动态性的关键字**。
-
-- 协议中的属性用 var：统一表示“访问接口”，支持动态约束（{ get } 或 { get set }）。
-- 遵循类型可用 let 或 var：只要满足协议的访问权限要求即可。
-- let 无法用于协议：因其无法表达可写性，违背协议动态描述能力的初衷。
-
-
-
-
-## 多态的实现原理
-
-- OC： Runtime
-- C++：虚函数表
-- Swift：没有 Runtime，所以多态的实现类似 C++
-
-来个 Demo
-```swift
-class Animal {
- func speak () {
- print("Animal speak")
- }
- func eat () {
- print("Animal eat")
- }
- func sleep () {
- print("Animal sleep")
- }
-}
-
-class Dog: Animal {
- override func speak() {
- print("Dog speak")
- }
- override func eat() {
- print("Dog eat")
- }
- func run () {
- print("Dog run")
- }
-}
-
-var animal = Animal()
-animal.speak()
-animal.eat()
-animal.sleep()
-
-animal = Dog()
-animal.speak()
-animal.eat()
-animal.sleep()
-// console
-Animal speak
-Animal eat
-Animal sleep
-Dog speak
-Dog eat
-Animal sleep
-```
-
-在 `animal.speak()` 处加断点，可以看到
-
-
-
-
-
-解释：
-
-- 汇编84行 `movq 0x9356(%rip), %r13 ` 是将全局变量 `animal` 的地址赋值给 `r13`
-- 汇编90行 `movq (%r13), %rax` 将 `r13` 处取出内存的前8个字节，赋值给 `rax`
-- 汇编91行 `callq *0x50(%rax)` ，也就是计算出 `rax + 0x50` 的地址，然后取出8 Byte 出来，也就是 `Dog.speak` 然后调用
-- 汇编107行 `callq *0x58(%rax)` ，也就是计算出 `rax + 0x508` 的地址，然后取出8 Byte 出来，也就是 `Dog.eat` 然后调用
-- 汇编123行 `callq *0x60(%rax)` ，也就是计算出 `rax + 0x60` 的地址，然后取出8 Byte 出来，也就是 `Animal.sleep` 然后调用
-
-
-
-画了张图，也就是说 `rax` 中存放了 Dog 对象内存中的前8个字节，也就是下图的最右侧
-
-
-
-
-
-核心是上面的内存布局图。结合汇编就知道多态是如何实现的。
-
-1. Swift 多态的实现原理
-
-Swift 的多态通过 虚函数表（vtable） 实现，这是一种 编译时确定的动态派发机制。其核心逻辑是：
-
-- 每个类类型在编译时会生成一个 虚函数表，表中存储了类的方法实现指针
-- 子类继承父类时，会复制父类的虚函数表，并替换重写方法的指针为自己的实现
-- 在运行时，通过对象的 类型元数据指针 找到对应的虚函数表，从而调用正确的方法
-
-动态派发与静态派发的区别：
-- 动态派发：通过虚函数表实现（例如普通类方法），允许子类重写。
-- 静态派发：编译时直接绑定方法地址（例如 final 方法、static 方法、结构体和枚举的方法），性能更高
-
-2. 虚函数表（vtable）的作用
-
-虚函数表的核心作用是为 动态派发 提供支持：
-- 方法重写：子类通过覆盖虚函数表中的方法指针，实现多态。
-- 运行时方法查找：对象调用方法时，通过虚函数表找到实际的方法实现。
-- 类型安全性：保证方法调用的正确性，即使对象被向上转型（例如 父类引用 = 子类对象）。
-
-
-总结： **虚函数表**（vtable）是一种用于实现动态多态性的机制，通常用于面向对象的编程语言中（C++ 也是一样）。在 Swift 中，虚函数表用于存储类或协议中方法的地址，以便在运行时进行动态分派。
-
-在 Swift 中，虚函数表的作用是为每个类或协议创建一个表，其中包含了对应方法的地址。当调用对象的方法时，运行时系统会根据对象的实际类型查找对应的虚函数表，然后调用表中存储的方法地址，从而触发特定的实现。
-
-虚函数表在 Swift 中的作用是实现动态分派，使得在运行时根据对象的实际类型确定调用的具体实现。这为 Swift 中的多态性提供了基础，允许相同的方法名称根据对象的类型触发不同的实现，从而实现灵活的对象行为。
-
-最小内存占用：一个没有属性的类对象至少占用 16 字节（类型元数据指针 8 字节 + 引用计数 8 字节）。
-属性存储：属性从第 17 字节开始存储
-引用计数细节：
-- 默认情况下，引用计数直接存储在对象头部。
-- 当引用计数溢出时，Swift 会使用 Side Table 扩展存储，此时对象头部的引用计数字段会指向 Side Table。
-
-
-## 类的类型信息存储在哪
-
-说明：同一个类的不同对象，它的类信息是一样的。也就是说不通的对象指针，所指向的类信息内存是同一块。
-
-```swift
-var dog1 = Dog()
-var dog2 = Dog()
-```
-
-存储在全局区。可以利用 MachOView 去查看。
-
-
-
-## 初始化器
-
-### 初始化器可以继承
-- convenience 便捷初始化器只可以横向调用，不可以纵向调用（比如子类继承父类后，子类重写指定初始化器的时候，必须加 override 且子类中只能调用父类的指定初始化器，不能调用便捷初始化器）
-- 便捷初始化器是不能被子类调用的
-
-
-### 自动继承
-- 如果子类没有自定义任何指定初始化器，则会自动继承父类所有的指定初始化器
-
-
-### require
-
-- 用 required 修饰的指定初始化器，表明其所有的子类都必须实现该初始化器（通过继承或者重写来实现）
-- 如果子类重写了 required 初始化器，也必须加上 required，不用加 override
-
-
-
-### 可失败初始化器
-
-类、结构体、枚举都可以使用 `init?` 定义可失败初始化器，也可以用 `init!` 来定义可失败初始化器。区别下面会讲
-
-```swift
-class Person {
- var name: String
- init?(_ name: String) {
- if name.isEmpty {
- return nil
- }
- self.name = name
- }
-}
-
-var person1 = Person("")
-print(person1) // nil
-var person2 = Person("FantasticLBP")
-print(person2) // Optional(SwiftDemo.Person)
-print(person2!) // SwiftDemo.Person
-```
-
-这种设计系统中也存在，比如 Int 的可失败初始化器：`@inlinable public init?(_ description: String)`
-
-```swift
-var num = Int("12e2")
-print(num) // nil
-num = Int("12")
-print(num) // Optional(12)
-```
-
-注意点：
-
-1. 不允许同时定义参数标签、参数个数、参数类型相同的可失败初始化器和非可失败初始化器。因为在外部调用的时候，不知道到底是使用哪个初始化方法。编译器会报错 `Invalid redeclaration of 'init(_:)'`
-
- 
-
-2. 可以用 `init!` 来定义隐式解包的可失败初始化器
-
-3. 可失败初始化器可以调用非可失败初始化器，非可失败初始化器调用可失败初始化器需要进行解包。如果直接调用会报错 `A non-failable initializer cannot delegate to failable initializer 'init(_:)' written with 'init?'`
-
- ```swift
- class Person {
- var name: String
- init?(_ name: String) {
- if name.isEmpty {
- return nil
- }
- self.name = name
- }
- convenience init() {
- self.init("")! // 极端 case，设计不合理
- }
- }
- ```
-
- 非可失败初始化器也可以调用可失败初始化器的隐式解包。
-
- ```swift
- class Person2 {
- var name: String
- init!(_ name: String) {
- if name.isEmpty {
- return nil
- }
- self.name = name
- }
- convenience init() {
- self.init("")
- }
- }
- ```
-
- 
-
- 且前面的写法比较危险，假设第一个 `init?` 返回 `nil`，第二个 `convenience init()` 去对 nil 强制解包，则会 crash
-
-4. 可以用一个非可失败初始化器重写一个可失败初始化器，但反过来不行
-
-5. 如果初始化器调用一个可失败初始化器导致初始化失败，那么整个初始化过程都失败，并且之后的代码都停止执行
-
- ```swift
- class Person {
- var name: String
- init?(_ name: String) {
- if name.isEmpty {
- return nil
- }
- self.name = name
- }
- convenience init?() {
- self.init("")
- print("我是后面的代码1")
- print("我是后面的代码2")
- }
- }
-
- var person1 = Person()
- print(person1)
- ```
-
- `init` 初始化失败，后面的 `我是后面的代码1` 均不会执行
-
-### 可失败初始化器设计哲学
-
-- 安全性优先：Swift 注重安全性，可失败初始化器的设计使得对象的初始化过程更加可靠和安全。通过返回一个可选值来表示初始化成功或失败，可以避免在初始化失败时产生不确定的对象状态
-- 错误处理：可失败初始化器与 Swift 的错误处理机制结合使用，使得在初始化失败时能够更好地捕获和处理错误。这种设计哲学强调了对异常情况的处理和错误信息的传递。
-- **灵活性**：可失败初始化器提供了一种灵活的初始化机制，允许开发者更加精确地控制对象的初始化过程。这种设计哲学使得对象初始化更加灵活和可定制。
-
-
-
-### OC alloc init，为什么 Swift 只需要 init？
-
-1. 语言设计哲学的分歧
-
- OC 显示控制与动态性。OC 是 C 的超集，继承了对底层内存管理的直接控制。`alloc` 和 `init` 的分离体现了**职责分离**原则：
-
- - **`alloc`**：类方法（`+alloc`），负责**内存分配**（计算对象大小、向系统申请内存空间，返回一个“空白”实例）。
- - **`init`**：实例方法（`-init`），负责**状态初始化**（设置属性默认值、建立对象依赖关系等）。
- - 这种分离允许开发者灵活干预内存分配（例如自定义 `+allocWithZone:`）或初始化过程（例如工厂方法 `+new`）。
-
- Swift 简洁性与安全性
-
- - Swift 作为现代语言，追求代码简洁和安全性。`Person()` 的语法**隐藏了内存分配细节**，开发者只需关注初始化逻辑。编译器会自动插入内存分配代码（类似 `__allocating_init`）并调用初始化方法。类似 `let person = Person.__allocating_init()`
- - Swift 强制在初始化完成前为所有存储属性赋值，并通过两段式初始化（Phase 1: 分配内存并设置默认值；Phase 2: 自定义初始化）避免未定义状态
-
-2. 编译器与运行时的工作
-
- OC：运行时开放性
-
- Objective-C 的 `+alloc` 方法由运行时动态处理。开发者可以重写 `+alloc` 或 `+allocWithZone:` 实现自定义内存分配策略（例如对象池、单例）。为了实现这种灵活性，更需要显式调用 alloc
-
- ```objective-c
- // 自定义 alloc 方法
- + (instancetype)alloc {
- if (单例条件) {
- return sharedInstance;
- }
- return [super alloc];
- }
- ```
-
- Swift: 编译时的静态优化
-
- - 内存分配的编译时确定：Swift 的对象大小和内存布局在编译时即可确定（值类型更是完全静态）。编译器直接生成内存分配指令，无需运行时动态计算。
- - 初始化器的静态派发：Swift 的初始化方法通过静态派发（或虚表派发）调用，无需 Objective-C 的消息转发开销。编译器能安全地合并内存分配和初始化步骤。
-
-为什么 Swift 可以省略 `alloc`？
-
-1. **编译器自动化**：内存分配由编译器隐式插入代码处理，无需开发者参与。
-2. **类型安全性**：严格的初始化规则确保对象在初始化完成后处于合法状态。
-3. **现代语法设计**：隐藏底层细节，提升代码可读性和编写效率。
-4. **静态优化**：编译时确定对象内存布局，无需运行时动态分配逻辑。
-
-而 Objective-C 保留 `alloc` 和 `init` 的分离，既是对历史的兼容，也为需要精细控制内存或动态行为的场景保留了灵活性。
-
-
-
-### deinit
-
-deinit 也叫反初始化器，类似于 C++ 的析构函数、OC 中的 dealloc 方法
-
-当类的实例对象被释放内存时，就会调用实例对象的 deinit 方法
-
-```swift
-class Person {
- deinit {
- print("Person deinit")
- }
-}
-
-class Student: Person {
- deinit {
- super.deinit() // Deinitializers cannot be accessed
- print("Student deinit")
- }
-}
-
-func test() {
- let st = Student()
-}
-test()
-```
-
-上述代码编译报错：Deinitializers cannot be accessed
-
-deinit 的基本规则：
-
-- **不可继承性**：`deinit` 本身不会被继承。每个类必须定义自己的 `deinit` 方法（显式或隐式）。
-- **自动链式调用**：无论子类是否重写 `deinit`，父类的 `deinit` 方法总会在子类析构完成后被自动调用，无需手动调用 `super.deinit()`。
-
-## 可选链
-
-```swift
-var dict:[String: (Int, Int) -> Int] = [
- "sum": (+),
- "minus": (-),
- "multiple": (*),
- "divide": (/)
-]
-print(dict["sum"]) // Optional((Function))
-var result = dict["divide"]?(40, 20) // 2
-print(result!)
-```
-
-- 如果可选项为 nil，调用方法、下标、属性失败，结果为 nil
-- 如果可选项不为 nil，调用方法、下标、属性成功，结果会被包装为可选项
-- 如果结果本来是可选项，则不会进行再次包装
-- 如果链中任何一个节点为 nil，那么整个链就会调用失败。`var weight = person?.dog?.weight // Int?`
-- 多个 `?` 可以链接在一起 `var weight = person?.dog?.weight`
-
-
-
-## 可选项 Optional 的本质
-
-可选项的本质是 **enum 类型 + 泛型**
-
-```swift
-@frozen public enum Optional
-
-在第二行代码下断点，可以看到关键的汇编是第8行和第12行：
-
-- 第14行可以看到 `rip + 0x89ae = 0x10000396a + 0x89ae = 0x10000C318 `，明显是一个堆地址空间，也就是全局变量 `person`
-
-- 第15行可以看到 `rip + 0x89af = 0x100003971 + 0x89af = 0x10000C320 `，明显是一个堆地址空间，也就是全局变量 `personType`
-
-- 顺着关键代码找上去，看看 `rax`、`rcx` 的值是哪来的
-
-- 第8行调用函数后可以看到 Xcode 的说明，获取 `metadata`，函数返回值保存到 `rax`，LLDB 打印出为 `0x000000010000c248`
-
-- 第11行初始化堆内存后，将地址保存到寄存器 `rax`，LLDB 打印出地址为 `0x0000600000004010`，然后查看 `0x0000600000004010` 对应的对象信息，可以看到内存的前8个字节的值，就是上面得到的 `metadata` 对象的地址值
-
-- person 对象的内存布局中，前8个字节就是 personType 的地址。
-
-- `metadata` 结构类似下图右侧
-
-
-
-
-
-`X.self` 和 `type(of:x)` 效果等价
-
-```swift
-class Person { }
-var person: Person = Person()
-print(Person.self == type(of: person)) // true
-```
-
-`AnyObject.Type` 的用法
-
-```swift
-class Person {
-
-}
-class Student: Person {
-
-}
-
-var anyType: AnyObject.Type = Person.self
-anyType = Student.self
-
-public typealias AnyClass = AnyObject.Type
-
-var anyType2: AnyClass = Person.self
-anyType2 = Student.self
-
-```
-
-
-
-### 元类型的应用
-
-```swift
-class Person {
- required init() {}
-}
-class Worker: Person {}
-class Student: Person {}
-func createInstance(_ items: [Person.Type]) -> [Person] {
- var people:[Person] = Array
-
-查表是一种简单、易实现、性能可预知的方式。然而，这种派发方式比起直接派发来说，还是慢了一点（从字节码的角度来看，多了两次读和一次跳转。由此带来了性能损耗）。另一个慢的原因在于编译器可能会由于函数内执行的任务，导致无法优化（如果函数带有副作用的话）
-
-这种基于数组的实现，缺陷在于函数表无法拓展。子类会在虚函数表的最后插入新函数，没有位置可以让 extension 安全地插入函数。
-
-
-
-#### 消息机制派发（Message Dispatch）
-
-消息机制是调用函数最动态的方式，也是 Cocoa 的基石，催生了 KVO、UIAppearance、CoreData 等，这种运作方式的关键在于开发者可以在运行时改变函数的行为。不止可以通过 swizzling 来改变，甚至可以用 isa-swizzling 修改对象的继承关系，可以在面向对象的基础上实现自定义派发。
-
-
-
-### OC 运行时
-
-主要体现在
-- 动态类型（dynamic typing）
-- 动态绑定（dynamic binding）
-- 动态装载（dynamic loading）
-
-
-
-### Swift 运行时
-- 纯 Swift 类的函数调用已经不再是 Objective-C 的运行时发消息，而是类似 c++ 的虚表 vtable，在编译时就确定了调用哪个函数，所以没办法通过 runtime 获取方法、属性
-- 而 Swift 为了兼容 Objective-C，凡是继承自 NSObject 的类都会保留其动态性，所以能够通过 runtime 拿到方法。老版本的 swift（如2.2）是编译期隐式的自动帮你加上了 `@objc`，而4.0以后版本的 swift 编译期去掉了隐式特性，必须显示声明
-- 不管是 Swift 类，还是继承自 NSObject 的类，只要在属性和方法前面加 `@objc` 关键字，就可以使用 runtime
-
-
-
-| | 原始定义 | 拓展 |
-| -------------------- | ---------- | ---------- |
-| 值类型 | 直接派发 | 直接派发 |
-| 协议 | 函数表派发 | 直接派发 |
-| 类 | 函数表派发 | 直接派发 |
-| 继承自 NSObject 的类 | 函数表派发 | 函数表派发 |
-
-
-
-- 值类型总是会使用直接派发，简单易懂
-- 协议和类的 extension 都会使用直接派发
-- NSObject 的 extention 会使用消息机制进行派发
-- NSObject 声明作用域的函数都会使函数表进行派发
-- 协议里声明的，并且带有默认实现的函数会使用函数表进行派发
-
-
-
-修饰符
-
-| final | 直接派发 |
-| ---------------- | ---------------------- |
-| dynaminc | 消息机制派发 |
-| @objc & @nonobjc | 改变在 oc 里的可见性 |
-| @inline | 告诉编译器可以直接派发 |
-
-
-
-有个特殊的组合 final 和 @objc。在标记为 final 的同时，也可以使用 @objc 来让函数可以使用消息机制派发。这么做的结果就是，调用函数的时候会使用直接派发，但也会在 Objective-C 的运行时里注册对应的 selector，函数可以响应 `perform(selector:)` 以及别的 Objective-C 特性，但在直接调用时，又可以有直接派发的性能。
-
diff --git a/Chapter1 - iOS/1.117.md b/Chapter1 - iOS/1.117.md
deleted file mode 100644
index a02889d..0000000
--- a/Chapter1 - iOS/1.117.md
+++ /dev/null
@@ -1,266 +0,0 @@
-# Swift 协议探究
-
-- 协议可以用来定义属性、方法、下标的声明，协议可以被类、枚举、结构体遵守（多个协议用逗号隔开）
-
-- 协议中定义的方法不能有默认参数值
-
-- 协议中定义属性必须是 `var`
-
-- 实现协议时定义的属性权限，要不小于协议中定义的属性权限
-
-- 协议定义属性是 `get`、`set` 时，用 `var` 存储属性或者 `get`、`set` 计算属性实现
-
-- 为了保证通用，协议中必须用 `static` 定义类型方法、类型属性、类型下标
-
-- 只有将协议中的实例方法标记为 `mutating`
-
- - 才可以允许结构体、枚举对象在方法里修改自身内存。否则编译器会报错：`Cannot assign to property: 'self' is immutable`
- - 类遵循协议，实现方法的时候不用加 `mutating`，枚举、结构体的实现需要加 `mutating`
-
-
-
- ```swift
- protocol Drawable {
- func draw()
- }
-
- class Size: Drawable {
- var width: Int = 0
- func draw() {
- width = 10
- }
- }
- var size = Size()
- print(size.width) // 0
- size.draw()
- print(size.width) // 10
-
- struct Point: Drawable {
- var x : Int = 0
- var y: Int = 0
- func draw() {
- x = 10 // Cannot assign to property: 'self' is immutable
- y = 10 // Cannot assign to property: 'self' is immutable
- }
- }
- ```
-
- 要想修改需要加 `mumating`
-
- ```swift
- struct Point: Drawable {
- var x : Int = 0
- var y: Int = 0
- mutating func draw() {
- x = 10
- y = 10
- }
- }
- var point = Point()
- print(point.x, point.y)
- point.draw()
- print(point.x, point.y)
- ```
-
-- 协议中还可以定义初始化器 `init`，非 `final` 类实现协议时， `init` 方法必须加 `required`
-
- ```swift
- protocol Drawable {
- init(x: Int, y: Int)
- }
- class Point: Drawable {
- var x: Int = 0
- var y: Int = 0
- required init(x: Int, y: Int) {
- self.x = x
- self.y = y
- }
- }
- final class Size: Drawable {
- var x: Int = 0
- var y: Int = 0
- init(x: Int, y: Int) {
- self.x = x
- self.y = y
- }
- }
-
- var point = Point(x: 10, y: 20)
- print(point.x , point.y) // 10 20
- var size = Size(x: 30, y: 40)
- print(size.x , size.y) // 30 40
- ```
-
-- 如果协议声明了初始化器，某个类遵循协议并实现了初始化器。且该初始化器也恰好是父类指定初始化器，那么这个初始化必须同事加 `required` 和 `override`
-
- ```swift
- protocol Drawable {
- init(x: Int, y: Int)
- }
-
- class Shape {
- init(x: Int, y: Int) {}
- }
-
- class Circle: Shape, Drawable {
- var x: Int = 0
- var y: Int = 0
- required override init(x: Int, y: Int) {
- super.init(x: x, y: y)
- self.x = x
- self.y = y
- }
- }
- var circle = Circle(x: 10, y: 20)
- print(circle.x , circle.y) // 10 20
- ```
-
-- 协议也可以继承
-
-- 协议也可以组合
-
- ```swift
- protocol Drawable {}
- protocol Colorable {}
- func test1(obj: Shape) {} // 参数接收 Shape 类或者 Shape 类的子类
- func test2(obj: Drawable) {} // 参数接收遵循 Drawable 的实例
- func test3(obj: Drawable & Colorable) {} // 参数接收同时遵循 Colorable 和 Drawable 2个协议的实例
- func test4(obj: Shape & Drawable & Colorable) {} // 参数接收同时遵循 Colorable 和 Drawable 2个协议，且是 Shape 的子类的实例
- ```
-
-- 遵循 `CustomStringConvertible` 可以自定义打印的字符串内容
-
- ```swift
- class Person: CustomStringConvertible {
- var name: String
- var age: Int
- init(name: String, age: Int) {
- self.name = name
- self.age = age
- }
- var description: String {
- "My name is \(name), age is \(age)"
- }
- }
- var p = Person(name: "杭城小刘", age: 28)
- print(p) // My name is 杭城小刘, age is 28
- ```
-
-
-
-## Any、AnyObject
-
-Swift 提供了2种特殊的类型：Any、AnyObject
-
-- Any 可以代表任意类型（枚举、结构体、类、函数类型）
-- AnyObject：代表任意类类型。比如可以在协议后面加上 AnyObject 则代表只有类能遵循这个协议。编译器会做检查 `Non-class type 'point' cannot conform to class protocol 'Eatable'`
-
- ```swift
- protocol Eatable: AnyObject {}
- class Person: Eatable { }
- struct point: Eatable {} // Non-class type 'point' cannot conform to class protocol 'Eatable'
- ```
-
-
-
-## 关联类型
-
-关联类型的作用：给协议中用到的类型，定义一个占位名称
-
-协议中可以拥有多个关联类型
-
-```swift
-protocol Stackable {
- associatedtype Element
- mutating func push(_ element: Element)
- mutating func pop() -> Element
- func top() -> Element
- func size() -> Int
-}
-
-class Stack
-
-可以看到：
-
-- 在第一处调用 `swapValue ` 方法的时候，将8字节的 metadata 信息保存到 `rdx` 寄存器了。也就是在调用 `swapValue` 方法的时候，分别将 `i1`（0x000000000000000b，也就是11）的地址值赋值给 rdi 寄存器，将 `i2`（0x0000000000000016，也就是22）的地址值赋值给 rsi 寄存器
-- 将 `Int` 的 `metadata` 赋值给 `rdx` 寄存器
-- 然后调用 `swapValue` 方法
-- 后续的 `String` 的 `SwapValue` 过程类似
-
-所以编译器最后在执行的时候，会将泛型真正的类型对应的 metadata 信息当作函数参数，传递进去，再去执行函数
-
-
-
-## 泛型类型约束
-
-泛型必须遵循协议，可以在方法后加 `<>`，在 `<>` 内写泛型 `T: 需要继承的类 & 协议` （也可以是其他名字，大多数语言都写 T），
-
-```swift
-protocol Runable {}
-class Person {}
-func swapValue
-
-简单分析下：
-
-- 第4行 `leaq 0x3d45(%rip), %rdi` 将 `rip + 0x3d45` 计算出的地址值赋值给寄存器 `rdi`
-- 第5行 `movl $0xa, %esi` 将 10 赋值给寄存器 `esi`，也就是 `rsi`
-- 第6行 `movl $0x1, %edx` 将 1 赋值给寄存器 `edx`，也就是 `rdx `
-- 第7行 `callq 0x100007578 ; symbol stub for: Swift.String.init(_builtinStringLiteral: Builtin.RawPointer, utf8CodeUnitCount: Builtin.Word, isASCII: Builtin.Int1) -> Swift.String `
-- 调用完第7行的方法有2个返回值，保存到寄存器 `rax` 、`rdx` 中
-- 第8行 `movq %rax, 0x86cf(%rip)` 将 `rax` 的值赋值给 `rip + 0x86cf `
-- 第8行 `movq %rdx, 0x86d0(%rip) ` 将 `rdx` 的值赋值给 `rip + 0x86d0 `
-
-可以看到 String 指针占用8 + 8 = 16个字节.
-
-
-
-QA：这个10是什么东西？1是什么东西？
-
-结合调用 `Swift.String.init(_builtinStringLiteral: Builtin.RawPointer, utf8CodeUnitCount: Builtin.Word, isASCII: Builtin.Int1)` 方法猜测，10 应该是 `utf8CodeUnitCount` 即 utf8格式的字符个数，1 应该是 `isASCII` 即是 ASCII
-
-做个实验验证下
-
-```swift
-var str1: String = "01234"
-```
-
-
-
-可以看到其他和上面的没变化，唯一不同的是 `movl $0x5, %esi` 将5赋值给寄存器 `esi`，即寄存器 `rsi`。实验的字符串 "01234" UTF8 字符个数为5
-
-继续改变
-
-```swift
-var str1: String = "01234😄"
-```
-
-
-
-可以看到将9赋值给寄存器 `esi` 即 `rsi`，字符串赋值给寄存器 `rdi`，`xorl %edx, %edx` 异或运算结果 0 赋值给寄存器 `edx` 即 `rdx`，也就是不纯粹为
-
-所以猜想正确。具体字符串创建过程可以查看 [Swift String 源码](https://github.com/apple/swift/blob/81812eaf2a6589610054a5db655bf7de3f3c8de6/stdlib/public/core/String.swift#L774)
-
-```swift
-// stdlib/public/core/String.swift
-extension String: _ExpressibleByBuiltinStringLiteral {
- @inlinable @inline(__always)
- @_effects(readonly) @_semantics("string.makeUTF8")
- public init(
- _builtinStringLiteral start: Builtin.RawPointer,
- utf8CodeUnitCount: Builtin.Word,
- isASCII: Builtin.Int1
- ) {
- let bufPtr = UnsafeBufferPointer(
- start: UnsafeRawPointer(start).assumingMemoryBound(to: UInt8.self),
- count: Int(utf8CodeUnitCount))
- if let smol = _SmallString(bufPtr) {
- self = String(_StringGuts(smol))
- return
- }
- self.init(_StringGuts(bufPtr, isASCII: Bool(isASCII)))
- }
-}
-```
-
-
-
- 也就是说 String 本身会占用16个字节长度，会调用 `Swift.String.init(_builtinStringLiteral: Builtin.RawPointer, utf8CodeUnitCount: Builtin.Word, isASCII: Builtin.Int1) -> Swift.String` 方法，该方法传递3个参数：字符串真实地址、字符串 UTF8 格式的个数、是否是 ASCII 。
-
-
-
-### 字符串长度小于15位的创建
-
-继续探索：
-
-
-
-可以看到 `str1` 地址为 `rip + 0x8853 = 0x1000039a5 + 0x8853 = 0x10000C1F8 `，然后读取对应堆上的内容为：
-
-```shell
-0x10000c1f8: 30 31 32 33 34 35 36 37 38 39 00 00 00 00 00 ea 0123456789......
-0x10000c208: 00 00 00 00 00 00 00 00 ff ff ff ff ff ff ff ff ................
-```
-
-打印出 `0x3736353433323130 0xea00000000003938`。怎么理解呢？
-
-从 [ASCII 码表](https://www.ascii-code.com) 可以看出 0 对应 `0x30`，1 对应 `0x31`，所以字符串`0123456789` 从 `0x30` 到 `0x39`
-
-`ea` 代表什么?
-
-a 即10，代表10个字符。最大为 f，只能存储15个字符。e 代表字符串类型。
-
-```swift
-var str1: String = "0123456789ABCDE"
-print(Mems.memStr(ofVal: &str1)) // "0x3736353433323130 0xef45444342413938"
-```
-
-当把字符改为15个时，输出的内存上的值为 `0x3736353433323130 0xef45444342413938`。
-
-也就是说：当字符串长度小于16位的时候，通常会使用内联存储来存储字符串的内容。内联存储意味着字符串的实际内容会直接存储在字符串对象本身的内存空间中，而不需要额外的内存分配。类似 OC `NSString` 的 `NSTaggedPointerString`
-
-
-
-### 字符串长度大于15位
-
-```swift
-var str1: String = "0123456789ABCDEF"
-print(Mems.memStr(ofVal: &str1))
-```
-
-
-
-分析下：
-
-- 第12行 `cmpq $0xf, %rsi` 拿 `0xf` 15 和寄存器 `rsi` 的值进行比较。上面已经分析过了，`rsi` 里面存放的是字符串的长度
-
-- 第13行 `jle 0x7ff81a7b9017 ` 如果12行比较结果为真，则跳转到 `0x7ff81a7b9017`
-
-- 实际发现，字符串长度大于15，则继续向下执行
-
-- 第20行 `movabsq $0x7fffffffffffffe0, %rdx` 则会把立即数 `0x7fffffffffffffe0` 移动到寄存器 `rdx`
-
-- 第21行 `addq %rdx, %rdi` 将 `rdx` + ` rdi` 的值赋值给 `rdi`，也就是 `rdi` 存放了: 字符串的真实地址 + `0x7fffffffffffffe0 相加后的值。`
-
- 所以字符串真实地址 = `rdx 的地址` - `0x7fffffffffffffe0`。
-
- 寄存器 `rdi` 读取出地址为 `0x8000000100007800` 。所以字符串真实地址为：`0x8000000100007800` - `0x7fffffffffffffe0` = `0x100007820`。
-
- LLDB 读取下 `x 0x100007820 ` 看到 30、31...46刚好是字符串 `0123456789ABCDEF` 的 ASCII 值。
-
- 所以 **`字符串真实地址 = 指针内存8个字节地址 - 0x7fffffffffffffe0`**，又等价于 `字符串真实地址 = 指针内存8个字节地址 + 0x20`
-
-- 经过23行后 `orq %rdi, %rdx` 可以看到 `rdx` 、`rdi` 里面存储的都是：`字符串真实地址` + `0x7fffffffffffffe0`
-
-- LLDB 输入 finish 结束函数细节，外部可以看到第10行 `movq %rdx, 0x8864(%rip) ` 将 `rdx` 寄存器里的值（也就是：`字符串真实地址` + `0x7fffffffffffffe0` ）赋值给 `str1` 指针的后8个字节
-
- 
-
-
-
-
-
- `字符串真实地址 = 指针内存8个字节地址 - 0x7fffffffffffffe0`，等价于 `字符串真实地址 = 指针内存8个字节地址 + 0x20`
-
-
-
-### 字符串存储在内存中什么地方
-
-```swift
-var str1: String = "0123456789ABCDEF"
-```
-
-字符串地址为 ` 0x10000397f + 0x3ea1 = 0x100007820`，看着像全局变量、也有可能是常量区？字符串内容写死的情况下，编译器编译后内存地址应该可以确定，那到底在什么地方呢？利用 `MachOView` 窥探下 `MachO` 文件吧
-
-
-
-
-
-利用 MachOView 打开如下
-
-
-
-
-
-X86_64 架构下，我们在 MachOView 看到的地址，真实对应地址为： `0x10000000 + 00007820 = 0x10007820` 好巧啊，发现计算出的值刚好就是字符串 `str1` 的真实地址。MachOView 右侧也显示了字符串的内容，刚好就是 str1
-
-解释下：
-
-在 macOS 和 iOS 的二进制文件（如 Mach-O 格式的可执行文件或动态库）中，`Section64` 是一个结构体，用于描述二进制文件中的一个段（section）。每个段包含特定类型的数据或代码，并且具有特定的属性，比如是否可写、是否可执行等。
-
- `Section64(__TEXT,__cstring)` 中：
-
-- `__TEXT` 是段的段名（segment name），存储**只读且可执行**的内容，包括代码和只读数据。**典型节（Sections）**：
- - `__text`：存放机器指令（代码段）。
- - `__cstring`：存放字符串常量。
- - `__const`：存放其他常量数据。
-
-- **`__DATA` 段**：存储**可读写**的数据（如全局变量、静态变量）。
-- `__cstring` 节：
- - **功能**：`_cstring` 专门存储硬编码的字符串常量（如 `"Hello, World!"`）。
- - **内存权限**：映射到内存时，`__TEXT` 段整体为**只读**（`r--` 或 `r-x`），但 `_cstring` 本身**不可执行**，仅用于数据存储
- - **所属区域**：
- - 逻辑上属于**常量区**（类似 ELF 格式的 `.rodata`）。
- - 物理上可能与代码段（`__text`）同属 `__TEXT` 段，但用途和权限不同。
-
-
-因此，`Section64(__TEXT,__cstring)` 描述的是二进制文件中存储 C 字符串字面量的一个节。这个节位于 `__TEXT__` 段中，并且包含的是只读数据。
-
-
-
-再做下调整
-
-```swift
-var str1: String = "0123456789ABCDEF"
-var str2: String = "012345"
-print(Mems.memStr(ofVal: &str1)) // 0xd000000000000010 0x8000000100007800
-print(Mems.memStr(ofVal: &str2)) // 0x0000353433323130 0xe600000000000000
-```
-
-
-
-可以看到：
-
-- str1、str2 指针长度为均为16个字节，且内存连续 `00007820`、`00007830`
-- 字符串长度小于15的时候，打印出 str2 的内存值的前8个字节存储的就是字符串本身 `0x0000353433323130`，后8个字节 `0xe600000000000000` e 代表字符串类型，6代表字符串长度
-- 字符串长度大于15的时候，内存值的前8位 `0xd000000000000010` 最后的10也就是16，代表字符串长度。内存的后8位代表字符串计算后的地址（`字符串真实地址` + `0x7fffffffffffffe0` ）
-- 字符串是存储在 `__TEXT__` 段的 `__cstring` 节中，属于常量区。
-
-做了调整，可以看到 str3 内存值的前8个字节 `0xd000000000000015` 中的15也就是21位字符串，符合预期。
-
-```swift
-var str1: String = "0123456789ABCDEF"
-var str2: String = "012345"
-var str3: String = "0123456789ABCDEFGHIJK"
-print(Mems.memStr(ofVal: &str1)) // 0xd000000000000010 0x80000001000077e0
-print(Mems.memStr(ofVal: &str2)) // 0x0000353433323130 0xe600000000000000
-print(Mems.memStr(ofVal: &str3)) // 0xd000000000000015 0x8000000100007800
-```
-
-
-
-### Swift 字符串存储本质
-
-Swift 字符串存储的两种模式：
-
-- **内联存储（Small String Optimization，SSO）**：
- - **条件**：字符串长度 ≤15 个 **ASCII 字符**（或 ≤7 个 **UTF-16 字符**）。
- - **特点**：字符串内容直接存储在 `StringObject` 的 16 字节内存中，无需堆分配。有点类似 Objective-C 的 **Tagged Pointer**
-- **堆存储（Heap-Allocated）**：
- - **条件**：字符串长度超过上述限制（字符串长度 > 15 个 **ASCII 字符** 或 > 7 个 **UTF-16 字符**）
- - **特点**：字符串内容存储在堆内存。其指针结构是一个 16 字节的 `StringObject`，`StringObject` 存储堆地址和元数据
-
-
-
-#### 内联存储（SSO）的具体实现
-
-内存布局：前8个字节（元数据 + 部分字符） + 后8个字节（剩余字符 + 填充）
-
-元数据编码：
-
-最低有效位（LSB）用于标识存储模式:
-
-- **0**：内联存储
-- **1**：堆存储
-
-其余位存储字符串长度和编码信息（ASCII 或 UTF-16）
-
-Demo
-
-````Swift
-let str = "Hello" // 5 个 ASCII 字符
-内存布局如下：
-0x0000000000000a05 // 元数据（长度=5, ASCII, 内联标志位=0）
-0x48656c6c6f000000 // ASCII 字符 "Hello" 的十六进制表示 + 填充
-````
-
-与 Objective-C Tagged Pointer 的区别
-
-| **特性** | **Swift 内联存储 (SSO)** | **Objective-C Tagged Pointer** |
-| :----------- | :------------------------- | :------------------------------ |
-| **存储位置** | 字符串对象的 16 字节内存中 | 指针值本身（64 位） |
-| **标识方式** | 元数据的最低有效位 (LSB) | 指针的最高有效位 (MSB) |
-| **兼容性** | 需考虑 Unicode 编码复杂性 | 仅支持有限类型（如短 NSString） |
-| **内存安全** | 完全由编译器管理 | 需运行时特殊处理 |
-
-
-
-
-
-
-
-## 字符串拼接
-
-### 长度小于15的字符串拼接
-
-```swift
-var str1: String = "012345"
-print(Mems.memStr(ofVal: &str1)) // 0x0000353433323130 0xe600000000000000
-str1.append("ABC")
-print(Mems.memStr(ofVal: &str1)) // 0x4241353433323130 0xe900000000000043
-str1.append("DEFGHI")
-print(Mems.memStr(ofVal: &str1)) // 0x4241353433323130 0xef49484746454443
-```
-
-可以看到不管字符串怎么拼接，只要拼接后的内容小于小于等于15，则依旧是在字符串的内容存放在自身的16个字节中。
-
-
-
-### 长度大于15的字符串拼接
-
-```swift
-var str1: String = "0123456789ABCDEF"
-print(Mems.memStr(ofVal: &str1)) // 0xd000000000000010 0x8000000100007800
-str1.append("G")
-print(Mems.memStr(ofVal: &str1)) // 0xf000000000000011 0x0000600001700440
-print("explore")
-```
-
-可以看到：长度为16的字符串拼接后
-
-- 内存的前8个字节，从 `0xd000000000000010` 变到了 `0xf000000000000011`，最后2位代表字符串长度，16进制的10就是16。从16位变成17位。
-- 内存的后8个字节，字符串的地址改变了
-
-上面可知， `字符串真实地址 = 指针内存8个字节地址 - 0x7fffffffffffffe0`，又等价于 `字符串真实地址 = 指针内存8个字节地址 + 0x20`
-
-
-
-字符串真实地址：`0x0000600001700440 + 0x20 = 0x0000600001700460`，LLDB `x 0x0000600001700460 ` 可以看到字符串拼接后的结果。看上去是存储在堆上。如何验证？
-
-
-
-我们知道堆上的内存初始化在 Swift 侧，关键方法为 `swift_allocObject ` -> `swift_slowAlloc` -> `malloc `。给 malloc 下断点，然后在断点出查看调用堆栈，可以看到在 `string.append()` 后有堆分配内存
-
- 
-
-结束当前函数调用，在外层可以看到 str2 地址值的后8个字节为 `0x000060000170410`，再 + `0x20` 就是字符串真实地址，打印如下。
-
-
-
-0x20 是什么？这32个字节存放了什么信息？存储字符串的描述信息，比如：引用计数、字符串长度等信息。
-
-
-
- 总结：
-
-- 当字符串长度小于等于 0xF(也就是15)，字符串内容直接存放在指针变量对应的内存中
-- 当字符拼接时候，拼接后字符串长度小于等于15，则字符串内容依旧存储在指针变量的内存中
-- 当字符串长度大于 0xF(也就是15)，字符串的内容存放在 `__TEXT,__cstring` 中（常量区）。字符串的地址值信息存放在指针变量的后8个字节中，且真正的地址值为 （`后8个字节值` + `0x20` ），前32字节存储字符串的基础信息（长度、引用计数等）
-
-
-
-## dyld_stub_binder
-
-`__TEXT` 是 Mach-O 文件中通常包含代码和只读数据的段。这个段包含了程序的主要执行代码，以及常量字符串、符号表等。
-
-`dyld_stub_binder` 是一个由动态链接器（dyld）在运行时生成和使用的函数。它的主要目的是在首次调用某个动态链接的符号（如函数或方法）时，将该符号的实际地址绑定到调用点
-
-Swift 中 `String` 类型的初始化方法（`init`）的地址是否采用延迟绑定（Lazy Binding），取决于 **编译环境、优化级别和具体方法实现**
-
-### 延迟绑定的基本原理
-
-在编译时，对于动态链接的符号，编译器会生成一个桩（stub），而不是直接调用该符号。桩是一个小段的代码，当被首次执行时，它会触发 `dyld_stub_binder` 的调用。`dyld_stub_binder` 的任务就是找到该符号的实际地址，并将其写入桩中，从而替换桩的原始代，这样，下一次调用该符号时，就可以直接跳转到实际的地址，而无需再次通过桩和 `dyld_stub_binder`。
-
-延迟绑定（Lazy Binding）是动态链接的机制，用于推迟符号（如函数、方法）地址的解析到首次调用时。其核心步骤为：
-
-1. **编译阶段**：生成存根（Stub），指向符号占位地址。
-2. **启动阶段**：存根指向动态链接器（如 `dyld`）的解析函数（如 `dyld_stub_binder`）。
-3. **首次调用**：触发符号解析，动态链接器填充真实地址到存根。
-4. **后续调用**：直接跳转到已解析的地址。
-
-
-
-替换桩，位于 `__DATA,__la_symbol_ptr` 数据段可读可写，所以可以修改。
-
-
-
-
-
-`__stub_helper` 节是 `__TEXT` 段中的一个特定节，它包含了用于处理符号懒加载的辅助函数和代码。当动态链接的符号首次被调用时，这些辅助函数会被触发，以解析符号并将其地址绑定到调用点。
-
-这个过程也叫 `Lazy_binding`。懒加载是一种优化技术，允许程序在启动时不必立即解析和绑定所有动态链接的符号。相反，这些符号的解析和绑定被推迟到它们实际被使用时进行。这种延迟可以减少应用程序启动时的内存和性能开销。
diff --git a/Chapter1 - iOS/1.12.md b/Chapter1 - iOS/1.12.md
deleted file mode 100644
index 78acdff..0000000
--- a/Chapter1 - iOS/1.12.md
+++ /dev/null
@@ -1,224 +0,0 @@
-
-# NSFileManager
-
-> 想操作文件，该去了解下NSFileManager
-
-注意：//小窍门：打印数组或者字典，里面包含中文，直接用%@打印会看不到中文，可用for遍历访问
-
-* 单例方法得到文件管理者对象
-
-```
- NSFileManager *fileManager = [NSFileManager defaultManager];
-```
-
-* 判断是否存在指定的文件
-
-```
- #define LogBool(value) NSLog(@"%@",value==YES?@"YES":@"NO");
-
- NSString *filepath = @"/Users/geek/Desktop/data.plist";
- BOOL res = [fileManager fileExistsAtPath:filepath];
- LogBool(res)
-```
-
-* 根据给出的文件路径判断是否存在文件，且判断路径是文件还是文件夹
-
-```
-NSString *filepath1 = @"/Users/geek/Desktop/data.plist";
- BOOL isDirectory = NO;
- BOOL isExist = [fileManager fileExistsAtPath:filepath1 isDirectory:&isDirectory];
- if (isExist) {
- NSLog(@"文件存在");
- if (isDirectory) {
- NSLog(@"文件夹路径");
- }else{
- NSLog(@"文件路径");
- }
- }else{
- NSLog(@"给定的路径不存在");
- }
-```
-
-* 判断文件或者文件夹是否可以读取
-
-```
- //这是一个系统文件（不可读）
- NSString *filePath2 = @"/.DocumentRevisions-V100 ";
- BOOL isReadable = [fileManager isReadableFileAtPath:filePath2];
- if (isReadable) {
- NSLog(@"文件可读取");
- } else {
- NSLog(@"文件不可读取");
- }
-```
-
-* 判断文件是否可以写入
-
-```
- //系统文件不可写入
- BOOL isWriteAble = [fileManager isWritableFileAtPath:filePath2];
- if (isWriteAble) {
- NSLog(@"文件可写入");
- } else {
- NSLog(@"文件不可写入");
- }
-```
-
-* 判断文件是否可以删除
-
-```
-//系统文件不可删除
- BOOL isDeleteAble = [fileManager isDeletableFileAtPath:filePath2];
- if (isDeleteAble) {
- NSLog(@"文件可以删除");
- } else {
- NSLog(@"文件不可删除");
- }
-```
-
-* 获取文件信息
-
-
-```
- NSError *error = nil;
- NSDictionary *fileInfo = [fileManager attributesOfItemAtPath:filepath1 error:&error];
-// NSLog(@"文件信息:%@,错误信息:%@",fileInfo,error);
- NSLog(@"文件大小:%@",fileInfo[NSFileSize]);
-```
-
-* 获取指定目录下的所有目录（列出所有的文件和文件夹）
-
-```
-NSString *filePath3 = @"/Users/geek/desktop";
- NSArray *subs = [fileManager subpathsAtPath:filePath3];
- NSLog(@"Desktop目录下所有的所有文件和文件夹");
- //小窍门：打印数组或者字典，里面包含中文，直接用%@打印会看不到中文，可用for遍历访问
- for (NSString *item in subs) {
- NSLog(@"%@",item);
- }
-```
-
-* 获取指定目录下的子目录和文件（不包含子孙）
-
-```
-NSError *erroe = nil;
- NSArray *children = [fileManager contentsOfDirectoryAtPath:filePath3 error:&erroe];
- NSLog(@"Desktop目录下的文件和文件夹");
- for (NSString *item in children) {
- NSLog(@"%@",item);
- }
-```
-
-* 在指定目录创建文件
-
-```
- NSString *filePath1 = @"/Users/geek/Desktop/data.text";
- NSData *data = [@"我要学好OC" dataUsingEncoding:NSUTF8StringEncoding];
- BOOL createFile = [fileManager createFileAtPath:filePath1 contents:data attributes:nil];
- if (createFile) {
- NSLog(@"文件创建成功");
- } else {
- NSLog(@"文件创建失败");
- }
-```
-
-* 在指定目录创建文件夹（参数说明：withIntermediateDirectories后的参数为Bool代表。YES：一路创建；NO：不会做一路创建）
-
-
-
-
-
-设置一路创建为NO，如果文件夹不存在则停止创建文件
-
-```
- NSString *filePath2 = @"/Users/geek/Desktop/海贼王";
- NSError *error = nil;
- BOOL createDirectory = [fileManager createDirectoryAtPath:filePath2 withIntermediateDirectories:NO attributes:nil error:&error];
- if (createDirectory) {
- NSLog(@"文件夹创建成功");
- } else {
- NSLog(@"文件夹创建失败，原因：%@",error);
- }
-
-
-
- //一路创建失败（文件夹不存在就不创建）
- NSString *filePath3 = @"/Users/geek/Desktop/海贼王";
- BOOL createDirectory1 = [fileManager createDirectoryAtPath:filePath3 withIntermediateDirectories:NO attributes:nil error:&error];
- if (createDirectory1) {
- NSLog(@"文件夹创建成功");
- } else {
- NSLog(@"文件夹创建失败，原因：%@",error);
- }
-```
-
-* 复制文件
-
-```
- NSString *filePath4 = @"/Users/geek/Desktop/动漫";
-
- BOOL copyRes = [fileManager copyItemAtPath:filePath3 toPath:filePath4 error:nil];
- if (copyRes) {
- NSLog(@"文件复制成功");
- } else {
- NSLog(@"文件复制失败");
- }
-```
-
-* 移动文件
-
-```
- NSString *filePath5 = @"/Users/geek/Downloads/动漫";
- BOOL moveRes = [fileManager moveItemAtPath:filePath3 toPath:filePath5 error:nil];
- if (moveRes) {
- NSLog(@"文件移动成功");
- } else {
- NSLog(@"文件移动失败");
- }
-```
-
-* 可以给文件重命名
-
-```
- //可以给文件重命名
- NSString *filePath6 = @"/Users/geek/Downloads/卡通";
- [fileManager moveItemAtPath:filePath5 toPath:filePath6 error:nil];
-```
-
-* 删除文件
-
-```
- BOOL deleteRes = [fileManager removeItemAtPath:filePath6 error:nil];
- if (deleteRes) {
- NSLog(@"文件删除成功");
- } else {
- NSLog(@"文件删除失败");
- }
-```
-
-# NSFileManager小病毒
-```
- //单例方法得到文件管理者对象
- NSFileManager *fileManager = [NSFileManager defaultManager];
- NSString *filePath = @"/Users/geek/desktop/delete/";
- while (1) {
- //判断该文件路径是否存在
- BOOL exist = [fileManager fileExistsAtPath:filePath];
- if (exist) {
- //找出该路径下的所有文件
- NSArray *subs = [fileManager contentsOfDirectoryAtPath:filePath error:nil];
- if (subs.count > 0) {
- for (int i=0; i
-上面的代码会发生循环引用，会导致局部变量的 p 无法释放（看不到 Person 的 deinit 方法调用）
-
-解法：
-- **在闭包表达式的捕获列表声明 weak 或者 unowned 引用，解决循环引用的问题**
-因为在闭包里，声明的捕获列表中将 p 用 weak 修饰，所以可以为 nil。p 使用到的地方必须用 `p?.run()`
-```swift
-class Person {
- var fn:(() -> ())?
- func run () { print("run") }
- deinit { print("deinit") }
-}
-
-func test () {
- let p = Person()
- p.fn = {
- [weak p] in
- p?.run()
- }
-}
-
-test()
-// deinit
-```
-另一种写法
-```swift
-p.fn = {
- [unowned p] in
- p.run()
-}
-```
--
-```swift
-class Person {
- lazy var fn:() -> () = {
- self.run()
- }
- func run () { print("run") }
- deinit { print("deinit") }
-}
-```
-
-## @escaping
-
-- 非逃逸闭包、逃逸闭包，一般都是当作参数传递给函数
-- 非逃逸闭包：闭包调用发生在函数结束前，闭包调用在函数作用域内
-- 逃逸闭包：闭包油可能在函数结束后调用， 闭包调用逃离了函数的作用域，需要通过 `@eascaping` 声明
-
-```swift
-typealias Fn = () -> ()
-var globalFn:Fn?
-func setFn(_ fn: @escaping Fn) {
- globalFn = fn
-}
-setFn {
- print("Hello world")
-}
-globalFn?() // Hello world
-```
-
-
-
-注意点：逃逸闭包不可以捕获 `inout` 参数
-
-```swift
-typealias Fn = () -> ()
-func other1(_ fn: Fn) {
- fn()
-}
-
-func other2(_ fn: @escaping Fn) {
- fn()
-}
-
-func test(value: inout Int) -> Fn {
- other1 {
- value += 1
- }
- other2 { // compile error:Escaping closure captures 'inout' parameter 'value'
- value += 1
- }
- func add() {
- value += 1
- }
- return add // compile error:Escaping closure captures 'inout' parameter 'value'
-}
-```
-
-原因：因为 `inout` 参数的本质是要求函数在调用期间直接操作变量的内存地址，而逃逸闭包可能会在函数返回后的任何时刻调用（不确定），这时 `inout` 参数所在的内存地址可能已经不再有效或者已经被其他值覆盖。因此，允许逃逸闭包捕获 `inout` 参数会导致潜在的数据不一致和安全问题。
-
-
-
-
-
-## 内存访问冲突
-
-Confilicting Access to Memory， 内存访问冲突发生在：
-
-- 至少一个是写入操作
-- 它们访问的是同一块内存
-- 它们的访问时间重叠(比如在同一个函数内)
-
-
-
-Demo1:
-
-```swift
-var step = 1
-func increament(_ num: inout Int) {
- num += step
-}
-increament(&step)
-```
-
-
-
-
-
-解决办法就是打破3个条件之一。显然不可以换函数，只有改变「同时访问一块内存地址」这个条件了
-
-```swift
-var step = 1
-func increament(_ num: inout Int) {
- num += step
-}
-var stepCopy = step
-increament(&stepCopy)
-step = stepCopy
-```
-
-
-
-Demo2：
-
-```swift
-func balance(_ x: inout Int, _ y: inout Int) {
- let sum = x + y
- x = sum/2
- y = sum - x
-}
-
-var num1 = 1
-var num2 = 2
-balance(&num1, &num2) //
-balance(&num1, &num1) // compile error: Inout arguments are not allowed to alias each other
-```
-
-Demo3: 下面代码虽然看着传入的是不同内存地址，但是 health 和 power 都属于元祖，还是同一个内存地址。
-
-
-
-
-
-如何解决？
-
-Swift 规定以下 case，就说明重叠访问结构体的属性就是安全的
-
-- 只访问实例存储属性，不是计算属性或者类属性
-- 结构体是局部变量而非全局变量
-- 结构体要么没有被闭包捕获，要么只被非逃逸闭包捕获
-
-```swift
-func balance(_ x: inout Int, _ y: inout Int) {
- let sum = x + y
- x = sum/2
- y = sum - x
-}
-func testConflictingAccessToMemory() {
- var tumple = (health: 100, power: 100)
- balance(&tumple.health, &tumple.power)
-}
-testConflictingAccessToMemory()
-```
-
-
-
-
-
-## 指针
-
-Swift 也有专门的指针类型，都被定义为 Unsafe（不安全的），有：
-
-- `UnsafePointer
-
-问题本质是：`inout` 关键词代表要对函数的参数进行写操作，而函数内部的实现利用 step 进行反问操作。读写同时存在就有问题。
-
-如何解决？产生一个备份，然后调用函数，最后将备份产生的结果覆盖老值
-```
-var step = 1
-func increment(_ number: inout Int) {
- number += step
-}
-// make an explicit copy
-var copyOfStep = step
-// invoke
-increment(©OfStep)
-// update the original value
-step = copyOfStep
-print(step) // 2
-```swift
\ No newline at end of file
diff --git a/Chapter1 - iOS/1.122.md b/Chapter1 - iOS/1.122.md
deleted file mode 100644
index b00f1c0..0000000
--- a/Chapter1 - iOS/1.122.md
+++ /dev/null
@@ -1,86 +0,0 @@
-# Swift 字面量本质
-
-## 常见的字面量默认类型
-
-- `public typealias IntegerLiteralType = Int`
-- `public typealias FloatLiteralType = Float`
-- `public typealias BooleanLiteralType = Bool`
-- `public typealias StringLiteralType = String`
-
-可以通过 typealias 修改字面量的默认类型，Demo 如下：
-
-```swift
-typealias IntegerLiteralType = UInt8
-var val = 8
-val
-```
-
-
-
-
-
-## 字面量协议
-
-Swift 自带的数据类型基本都可通过字面量初始化，本质原因是遵循了对应的协议
-
-| | | |
-| ------------- | ------------------------------------------------------ | ------------------------------------------------------------ |
-| Bool | ExpressibleByBooleanLiteral | var b:Bool = false |
-| Int | ExpressibleByIntegerLiteral | var num:Int = 2 |
-| Float、Double | ExpressibleByIntegerLiteral、ExpressibleByFloatLiteral | var height:Float = 175 var height1:Float = 175.2
var weight:Double = 130
var weight1:Double = 130.1 | -| Dictionary | ExpressibleByDictionaryLiteral | var dic:Dictionary = ["name": "FantasticLBP"] | -| String | ExpressibleByStringLiteral | var name:String = "FantasticLBP" | -| Array、Set | ExpressibleByArrayLiteral | var arr:Array = [1, 2, 3] | -| Optional | ExpressibleByNilLiteral | var o:Optional
-
-LLDB 输入 `si` 进去窥探下
-
-
-
-看样子，函数还没到底，看到地址 `0x00007ff81a86f530` 很大很大，猜测应该是一个系统动态库方法地址，继续跟进去研究 `si`
-
-
-
-
-
-可以看到内部还有函数调用
-
-
-
-继续跟进 `si`
-
-
-
-看上去是在做继续 `clasedRange` 区间符合的判断，继续跟进 `si`，里面确实是在判断是否命中区间的判断。不一一研究了，这次目的是判断 switch...case pattern 的实现。
-
-
-
-
-
-结论：switch case pattern 模式匹配，系统底层实现是依赖
-
-
-
-## 模式匹配的应用
-
-自定义模式匹配。根据上面通过汇编进行分析，我们知道
-
-- `static func ~=(pattern: case 后面的值, value: switch 后面的值)` pattern 代表的是 case 后面的值，value 代表 switch 后面的值。
-
-- 当 case 有不同类型的时候，如果编译报错，则需要重写 `static func ~=(pattern: ,value: )` 方法，调整 pattern 的数据类型，数据类型应该和 case 后的数据类型一致（可以是函数等）
-
-```swift
-struct Student {
- var score = 0
- var name = ""
-
-
- /// Student 和 Int 模式匹配的方法
- /// - Parameters:
- /// - pattern: case 后面的内容
- /// - value: switch 后面的内容
- /// - Returns: 是否命中
- static func ~= (pattern: Int, value: Student) -> Bool {
- value.score >= pattern
- }
- static func ~= (pattern: Range
-
- 可以看到即使在 Swift 代码中，调用 OC 对象方法，本质上还是走 Objc Runtime 的一套流程。50行代码，将 showPower 的地址赋值给 `rsi` 寄存器，然后调用 `objc_msgSend` 方法。
-
- LLDB 下 输入 `si` 窥探下实现。
-
- 
-
- 可以看到一个很大的地址 `0x00007ff80002d7c0` 就是动态库的符号方法地址。同时 Xcode 很智能，右侧给出了函数名称。
-
-3. OC 调用 Swift 底层又是如何调用的？在 OC 类 Person 中，底层调用 Swift Cat 类的 sayHi 方法。
-
- 断点加在 `[self.cat sayHi]` 处，可以看到本质上还是 Runtime objc_msgSend 那一套。
-
- 
-
-4. `cat.run()` 底层是怎么调用的？
-
- 如果一个 Swift 类，不继承自 NSObject，那么方法调用的本质就是走虚表那套逻辑，找到指针的前8个字节，根据前8个字节找到类信息，然后在类信息中，前面一些内存地址存储类型信息，后续根据偏移在方法列表中，找到需要调用的函数地址。类似下面的图。
-
- 
-
- 那 Swift 类继承自 NSObject 后，依然在 Swfit 中调用方法，背后的原理是什么？
-
- 在 ViewController.swift 中 `cat.sayHi()` 下断点
-
- 
-
-
-
-## Swift 方法如何走 Runtime 消息机制
-
-可以看到，即使一个 Swift 类继承自 NSObject，但依旧在 Swift 中调用对象方法，本质上还是走虚表那套方法调用流程，不会走 Runtime 消息机制。
-
-如果想让 Swift 方法调用走 Runtime 消息机制，可以在方法前加 `@objc dynamic`
-
-```swift
-dynamic func sayHi () {
- print("My name is \(name)")
-}
-```
-
-断点查看，发现在 Swift 代码中调用同样的 Swift 对象方法，此时走了 Runtime 消息机制。
-
-
-
-
-
-## Swift OC 混编，内存布局会改变吗
-
-如果一个 Swift 类继承自 NSObject，内存布局会改变
-
-```swift
-class Person {
- var age: Int = 28
- var height: Int = 175
-}
-let p: Person = Person()
-print(Mems.memStr(ofRef: p))
-// console
-0x0000000100010540 0x0000000000000003 0x000000000000001c 0x00000000000000af
-```
-
-可以看到一个 Swift 类，前8个字节用来存放类信息的指针，其次8个字节用来存放引用计数信息，后16个字节用来存放28和175，就是存储属性信息
-
-调整下：
-
-```swift
-import Foundation
-class Person: NSObject {
- var age: Int = 28
- var height: Int = 175
-}
-let p: Person = Person()
-print(Mems.memStr(ofRef: p))
-// console
-0x011d8001000104e9 0x000000000000001c 0x00000000000000af 0x0000000000000000
-```
-
-可以看到当 Swift 类继承自 NSObject 后，前8个字节存放的是 isa 指针，其次的16个字节存放存储属性信息，最后的8个字节用来内存对齐。
-
-
-## 混编
-### OC 调用 Swift
-OC 项目，使用 Swift 开发默认会创建 `项目名-Swift.swift` 文件。Swift 类都可以在该文件中找到
-
-默认情况下生成的 Swift class 是不可以直接在 OC 中使用的，如果需要**访问需要在 class 前加 `@objc` 且继承自 NSObject**，编译器生成的代码如下：
-
-
-class 不仅需要创建对象，还需要访问属性和方法，可以在属性或者方法前加 `@objc`，效果如下
-
-
-但这样很麻烦，需要给每个属性、方法添加 `@objc`。有简便方法，可以直接在 class 前加 `@objcMembers`，这样该 class 所有的属性、方法都可以在 OC 中访问
-
-
-**Swift 写的 extension，在`项目名-Swift.swift` 文件中可以看到，是被编译器编译为 OC 的分类 Category**。
-```swift
-@objcMembers class Car : NSObject {
- var price: Double
- var band: String
- init(price: Double, band: String) {
- self.price = price
- self.band = band
- }
-}
-
-extension Car {
- func test() {
- print("Car test")
- }
-}
-```
-
-```objective-c
-@interface Car : NSObject
-@property (nonatomic) double price;
-@property (nonatomic, copy) NSString * _Nonnull band;
-- (nonnull instancetype)initWithPrice:(double)price band:(NSString * _Nonnull)band OBJC_DESIGNATED_INITIALIZER;
-@end
-
-@interface Car(SWIFT_EXTENSION(TestSwift))
-- (void)test
-@end
-
-```
-
-可以通过 `@objc(name)` 重命名 Swift 暴露给 OC 的符号名（类名、属性名、函数名等）
-
-
-### Swift 中访问 OC 的对象、方法
-要在 Swift 中访问 OC 类，需要创建桥接文件，OC 工程首次创建 Swift 文件时，Xcode 默认创建桥接文件 `项目名-Bridging-Header.h`。如果是手动创建的，则需要配置（在项目的 Build Settings 中，找到 Objective-C Bridging Header 设置项，并指定桥接头文件的路径。确保桥接头文件的路径正确无误，并且文件名和扩展名都正确）。
-
-在桥接文件中（`项目名-Bridging-Header.h`） 写好需要在 Swift 中使用的 objective-C 类。
-
-Swift 中不允许访问 objective-c 的方法或者需要换个方法名去调用，该怎么实现？
-
-
-`- (void)showPower NS_SWIFT_NAME(diaplayPower());` oc 对象方法名，在 Swift 中使用时，想换个名字，可以用 `NS_SWIFT_NAME(新的方法名())`
-`- (void)displayPower NS_SWIFT_UNAVAILABLE("请使用 showPower");` oc 对象方法名，不想在 Swift 使用时，可以加 `NS_SWIFT_UNAVAILABLE(原因)`
-
-### 符号名映射
-`@_silgen_name` 是 Swift 中用于底层符号控制的工具，适合需要直接操作函数符号的场景
-
-- 符号名称映射
- 将 Swift 函数直接映射到指定的 C 函数名（或其他语言符号），绕过 Swift 默认的名称修饰（name mangling）
-
- 声明 `@_silgen_name("my_c_function") func mySwiftFunction()` 后，意味着在 Swift 代码中调用 `mySwiftFunction` 会直接链接到 C 函数 `my_c_function` 中
-- 与系统 API 或 C 函数交互
- 直接调用系统库函数或 C 函数，无需通过 Swift 的桥接机制（如 @_cdecl 或 Objective-C 兼容层）。
- 适用于需要精确控制符号名称的场景（如调用 libc 函数、系统调用等
-- 导出 Swift 函数供外部使用
- 强制 Swift 函数在编译后使用特定名称导出，方便其他语言（如 C、Python）通过动态链接调用。
-
-
-## QA
-### 为什么 Swift 暴露给 OC 的类，最终都要继承自 NSObject？
-什么时候会用到一个类？肯定是抽象一个问题为类吧，那么也一定会访问该类的属性或者方法吧。但在 OC 的世界中，一切皆对象，也遵循 NSObject 的内部布局，也会走 Runtime 的标准流程。
-
-1. OC 运行时依赖
-- 必须是 OC 对象：Objective-C 的 id 类型指向的对象，本质是 objc_object 结构体，其核心是通过 isa 指针关联到类（objc_class）
-- 必须支持运行时、消息系统的：Objective-C 的方法调用依赖运行时动态查找方法实现（通过 `objc_msgSend`），而这一机制需要类继承自 NSObject
-
-如果 Swift 类不继承 NSObject，则：
-- 它的实例在内存中缺少 isa 指针，无法被 Objective-C 运行时识别为有效对象。
-- Objective-C 代码无法通过 id 类型接收该对象，也无法调用其方法。
-
-2. NSObject 基类提供的基础能力
-NSObject 是 Objective-C 的根类，定义了对象的基本行为：
-- 内存管理：实现引用计数（retain/release）和 weak 指针、 dealloc 方法
-- 运行时元数据：提供 class、respondsToSelector: 等反射方法
-- 协议支持：实现 NSObjectProtocol（如 isEqual:、hash、description）。
-若 Swift 类不继承 NSObject，则无法直接使用这些基础功能，导致与 Objective-C 交互时出现兼容性问题。
-
-
-3. 互操作性的桥梁
-- 当 Swift 类继承 NSObject 时，编译器会生成一个 Objective-C 兼容的类结构（包括 isa 指针和元数据）
-- 若使用 @objc 修饰非 NSObject 子类，编译器会报错
-
-
-### `p.run()` 底层是怎么调用的？
-Demo1: Swift 调用 Swift 对象方法
-
-
-
-纯 Swift 环境中，调用对象的方法，走的是虚表的逻辑。最终底层会调用 `callq *0x78(%rax)`
-
-可以看到：Swift 调用 Swift 对象和方法，断点处显示直接调用方法地址，lldb 模式下输入 `si` 可以看到汇编代码停在了 **SwiftDemo`Cat.sayHi():** 的地方。所以走的是虚函数表逻辑。
-
-Demo2: OC 调用 Swift 对象方法
-1. Swift 类继承自 NSObject，在前面加 `@objcMembers` 暴露给 OC 环境
-2. Swift 环境调用 OC 对象和方法
-3. OC 方法中调用 Swift 对象和方法
-4. 给 OC 环境中，调用 Swift 对象方法的地方下个断点，查看走的是 OC 的 Runtime 还是 Swift 的虚函数表的逻辑
-断点截图如下：
-
-
-可以看到在 OC 环境中，调用 Swift 对象的方法，本质上走的是 Runtime 的流程，汇编可以看到走的是 `objc_msgSend` 流程，效果类似 `objc_msgSend(p, @selector(run))`
-
-结论：OC 类暴露给 Swift 环境后，调用 OC 对象的方法，本质走的是 Runtime 流程。
-
-### 被 @objcMembers 修饰的 Swift 对象，在 Swift 中调用
-
-Demo3: 暴露给 OC 的 Swift 对象，被 Swift 环境调用
-1. 继承自 NSObject 的 Swift 类
-2. 被 `@objcMembers` 修饰
-3. 在 Swift 环境中调用暴露给 OC 的 Swift 对象方法
-4. 断点查看方法调用的本质
-
-
-可以看到，在 Swift 环境中，即使某个 Swift 类暴露给了 OC，调用其对象方法的本质，依旧是走虚函数表。因为此时用不到 Runtime 的能力
-
-Demo4: 在 Demo3 的基础上，swift 方法内部调用 OC 对象方法
-
-也就是说：
-1. Cat 类继承自 NSObject，被 `@objcMembers` 修饰
-2. 在 Swift 中调用 Cat 对象的 sayHi 方法
-3. 在 sayHi 方法内部，调用 OC Person 对象的 run 方法
-
-下断点可以看到：
-
-
-
-分为2个阶段：
-1. 第一阶段：在 Swift 环境调用虽然暴露给 OC 的 Swift 对象方法，但因为没有和 OC 直接交互，所以走的是 Swift 虚函数表逻辑
-2. 第二阶段：在 Swift 环境调用 OC 对象方法，因为底层是 OC 方法调用，所以走的是 OC Runtime 逻辑
-
-思考：想让 Swift 方法也走 OC 的 Runtime，可以利用 **`dymanic`** 关键词修饰方法。如下：
-
-
-
-
-## dynamic 的作用
-在 Swift 中，dynamic 关键字用于强制方法或属性通过 Objective-C 运行时（Runtime）进行动态派发，即使该方法或属性在纯 Swift 代码中被调用。它的核心应用场景与 Objective-C 运行时的动态特性（如 KVO、方法交换、动态解析等）紧密相关
-
-核心作用：绕过 Swift 的静态优化
-Swift 默认会尝试优化方法派发（如使用虚函数表或直接派发），而 dynamic 会强制方法或属性始终通过 Objective-C 的 objc_msgSend 机制调用，确保动态性。
-启用 Objective-C 运行时特性
-
-若需要实现以下功能，必须使用 dynamic：
-- 键值观察（KVO）：标记为 dynamic 的属性会自动支持 KVO。
-- 方法交换（Method Swizzling）：运行时替换方法实现。
-- 动态方法解析：通过 resolveInstanceMethod: 动态添加方法实现。
-- 消息转发：通过 forwardingTargetForSelector: 或 forwardInvocation: 处理未实现的方法。
-
-
-### 支持 KVO
-Swift 中默认的存储属性不支持自动 KVO 通知，但通过 dynamic 标记属性后，属性访问会通过 Objective-C 运行时，从而触发 KVO 机制。
-```swift
-@objcMembers class Cat: NSObject {
- dynamic var name: String // 支持 KVO
- init(name: String) { self.name = name }
-}
-```
-在 OC 中监听 name 变化
-```Objective-c
-Cat *cat = [[Cat alloc] initWithName:@"PiPi"];
-[cat addObserver:self forKeyPath:@"name" options:NSKeyValueObservingOptionNew context:nil];
-```
-
-### 方法交换
-若要在运行时替换方法实现（如 AOP 编程、调试 Hook），必须确保目标方法是动态派发的。
-
-```swift
-@objcMembers class Cat: NSObject {
- dynamic func sayHi() { print("Original") }
-}
-```
-在 Objective-C 中交换方法实现
-```Objective-c
-Method originalMethod = class_getInstanceMethod([Cat class], @selector(sayHi));
-Method swizzledMethod = class_getInstanceMethod([Cat class], @selector(swizzled_sayHi));
-method_exchangeImplementations(originalMethod, swizzledMethod);
-```
-
-### 动态解析未实现的方法
-当调用一个未实现的方法时，可通过 resolveInstanceMethod: 动态添加实现。
-```swift
-@objcMembers class Cat: NSObject {
- dynamic func sayHi() { print("Hello") } // 假设此方法未实现，运行时动态添加
-}
-```
-Objective-C 运行时动态解析
-```Objective-c
-+ (BOOL)resolveInstanceMethod:(SEL)sel {
- if (sel == @selector(sayHi)) {
- class_addMethod([self class], sel, (IMP)dynamicSayHi, "v@:");
- return YES;
- }
- return [super resolveInstanceMethod:sel];
-}
-
-void dynamicSayHi(id self, SEL _cmd) {
- NSLog(@"Dynamic Hello");
-}
-```
-
-### 动态调用
-当 Swift 类的方法需要被 Objective-C 或其他动态语言（如通过 performSelector:）调用时，若方法未被标记为 dynamic，可能因编译器优化导致动态调用失败。
-```swift
-@objcMembers class Cat: NSObject {
- dynamic func sayHi() { print("Hello") }
-}
-```
-Objective-C 中动态调用
-```Objective-c
-Cat *cat = [[Cat alloc] init];
-[cat performSelector:@selector(sayHi)]; // 需 dynamic 支持
-```
-
-
-## 数据类型转换
-在 Swift 和 Objective-C 的类型桥接机制中，String 与 NSString 可以互相转换，而 String 不能直接与 NSMutableString 互相转换，但 NSMutableString 可以转为 String。类似的情况也出现在 Array/NSArray/NSMutableArray 和 Dictionary/NSDictionary/NSMutableDictionary 之间
-
-### 核心原因
-可变性的语义差异：
-- Swift 的值类型（String、Array、Dictionary） 被设计为不可变的值语义。每次修改会产生新实例（Copy on Write）。比如 `var str = "A"; str += "B"`
-会创建新字符串 'AB'，而非修改原内存
-- OC 的类型 NSString 是不可变的引用类型，NSMutableString 是可变的引用类型，允许直接修改内容
-这种差异导致桥接时需要严格处理可变性，确保类型安全和语义一致。
-
-
-### Swift string 与 OC NSString
-双向隐式桥接。因为两者都是不可变的，语义一致，没有副作用，都可以直接互相转换。
-
-```swift
-// Swift -> OC
-let swiftStr1: String = "Hello"
-let nsStr1: NSString = swiftStr1 as NSString
-// OC -> Swift
-let nsStr12: NSString = "World"
-let swiftStr2: String = nsStr12 as String
-```
-### Swift string 与 OC NSMutableString
-
-Swift string 与 OC NSMutableString 是单向桥接的。OC NSMutableString 可以转为 Swift String。但 Swift String 不能转为 OC NSMutableString
-
-原因：OC NSMutableString 是可变类型，转为 Swift String 时会创建一份不可变的副本，避免被 Swift String 修改造成意外修改。
-若允许 Swift String 直接转换为 OC NSMutableString，则可能通过 OC 代码修改 String 的值，破坏 Swift 值语义。
-```swift
-// Objective-C → Swift（允许）
-let mutableStr: NSMutableString = "Hello".mutableCopy() as! NSMutableString
-let swiftStr: String = mutableStr as String // 隐式桥接，生成不可变副本
-
-// Swift → Objective-C（禁止隐式桥接）
-let swiftStr = "Hello"
-let mutableStr = swiftStr as NSMutableString // ❌ 编译错误
-```
-
-### 类似情况
-- Swift Array 与 OC NSArray 可以互相转换。
-- OC 的 NSMutableArray 可以转换为 Swift Array。但是 Swift Array 不能转换为 OC NSMutableArray
-
-### 底层原理
-1. 类型桥接的实现方式：Swift 编译器通过 `_ObjectiveCBridgeable` 协议实现与 OC 类型的桥接。
-例如 String 实现了 `_ObjectiveCBridgeable`，使其能与 NSString 自动转换
-
-2. 可变类型桥接限制
-Swift String：
-- 值类型：Swift String 是结构体，遵循值语义。每次赋值或者修改都会生成新的独立副本，确保数据不可变性和线程安全
-- 不可变：即使用 var 声明，修改 String 也会通过创建新实例实现，而非直接修改内存
-Objective-C 的 NSMutableString
-- 引用类型（Reference Type）：NSMutableString 是类（class），遵循引用语义。变量持有的是指向内存地址的指针。
-- 可变（Mutable）：允许直接修改内存中的内容（如追加、删除字符），所有持有该引用的代码都会感知到变化。
-
-3. 为什么 String 不能直接桥接为 NSMutableString？
-
-- 原因 1：值语义与引用语义的冲突
-若允许将 Swift 的 String 直接桥接为 NSMutableString，则相当于将一个值类型强制转换为可变的引用类型。
-风险示例：
-```swift
-let swiftStr = "Hello"
-let mutableStr = unsafeBridgeToNSMutableString(swiftStr) // 假设存在这种桥接
-mutableStr.append("!") // 修改 mutableStr
-print(swiftStr) // 若桥接是共享内存，此处会输出 "Hello!"，违背值语义！
-```
-
-这会导致 Swift 的 String 失去其不可变性保证，破坏类型安全。
-
-- 原因 2：内存管理的不兼容
-Swift 的 String 可能存储在栈内存或静态区（尤其是短字符串），而 NSMutableString 必须分配在堆内存。
-直接桥接可能导致内存访问错误（如悬垂指针）。
-
-- 原因 3：设计哲学的保护
-Swift 强调安全性，禁止隐式共享可变状态。若允许直接桥接，开发者可能无意中在多个地方修改同一块内存，导致难以调试的问题。
-
-QA: 如何显式实现 String → NSMutableString？
-若需要将 Swift String 转为 NSMutableString，必须显式创建新对象，而非直接桥接：
-```swift
-let swiftStr = "Hello"
-let mutableStr = NSMutableString(string: swiftStr) // 显式拷贝
-mutableStr.append("!") // 安全修改
-```
-
-在 Swift 和 Objective-C 的互操作中，`String` 和 `NSMutableString` 之间的转换规则是由两者的**类型语义**和**内存管理机制**共同决定的。以下是具体原因和底层逻辑：
-
----
-
-### **1. 类型语义的根本差异**
-#### **Swift 的 `String`**
-- **值类型（Value Type）**：
- Swift 的 `String` 是结构体（`struct`），遵循值语义。每次赋值或修改都会生成新的独立副本，确保数据不可变性和线程安全。
-- **不可变（Immutable）**：
- 即使使用 `var` 声明，修改 `String` 也会通过创建新实例实现，而非直接修改内存。
-
-#### **Objective-C 的 `NSMutableString`**
-- **引用类型（Reference Type）**：
- `NSMutableString` 是类（`class`），遵循引用语义。变量持有的是指向内存地址的指针。
-- **可变（Mutable）**：
- 允许直接修改内存中的内容（如追加、删除字符），所有持有该引用的代码都会感知到变化。
-
----
-
-### **2. 为什么 `String` 不能直接桥接为 `NSMutableString`？**
-#### **原因 1：值语义与引用语义的冲突**
-- 若允许将 Swift 的 `String` 直接桥接为 `NSMutableString`，则相当于将一个值类型强制转换为可变的引用类型。
- **风险示例**：
- ```swift
- let swiftStr = "Hello"
- let mutableStr = unsafeBridgeToNSMutableString(swiftStr) // 假设存在这种桥接
- mutableStr.append("!") // 修改 mutableStr
- print(swiftStr) // 若桥接是共享内存，此处会输出 "Hello!"，违背值语义！
- ```
- 这会导致 Swift 的 `String` 失去其不可变性保证，破坏类型安全。
-
-#### **原因 2：内存管理的不兼容**
-- Swift 的 `String` 可能存储在栈内存或静态区（尤其是短字符串），而 `NSMutableString` 必须分配在堆内存。
- 直接桥接可能导致内存访问错误（如悬垂指针）。
-
-#### **原因 3：设计哲学的保护**
-- Swift 强调安全性，禁止隐式共享可变状态。若允许直接桥接，开发者可能无意中在多个地方修改同一块内存，导致难以调试的问题。
-
----
-
-### **3. 为什么 `NSMutableString` 可以转为 `String`？**
-当 `NSMutableString` 桥接到 Swift 时，**会生成一个不可变的副本**，切断与原对象的关联：
-```swift
-let mutableStr: NSMutableString = "Hello".mutableCopy() as! NSMutableString
-mutableStr.append("!") // 修改原对象
-
-let swiftStr = mutableStr as String // 桥接生成新副本
-print(swiftStr) // "Hello!"
-mutableStr.append("?") // 继续修改原对象
-print(swiftStr) // 仍然是 "Hello!"，不受影响
-```
-- **行为安全**：生成的 `String` 是独立的不可变副本，与原 `NSMutableString` 解耦。
-- **符合语义**：Swift 的 `String` 仍然是值类型，后续修改不会影响副本。
-
----
-
-### **4. 如何显式实现 `String` → `NSMutableString`？**
-若需要将 Swift `String` 转为 `NSMutableString`，必须**显式创建新对象**，而非直接桥接：
-```swift
-let swiftStr = "Hello"
-let mutableStr = NSMutableString(string: swiftStr) // 显式拷贝
-mutableStr.append("!") // 安全修改
-```
-- **显式拷贝**：通过 `NSMutableString` 的构造器生成独立可变对象，避免共享内存。
-
----
-
-### **5. 类似场景：`Array` ↔ `NSMutableArray`**
-同样的规则适用于集合类型：
-- **Swift `Array`**：
- 值类型，桥接到 `NSArray`（不可变），但无法直接桥接为 `NSMutableArray`。
-- **`NSMutableArray` → `Array`**：
- 生成不可变副本，与原对象解耦。
-
-```swift
-let swiftArray = [1, 2, 3]
-let mutableArray = NSMutableArray(array: swiftArray) // 显式拷贝
-mutableArray.add(4) // 安全修改
-```
-
-Swift 通过严格的类型桥接规则，确保值类型的不可变性和引用类型的可控性。这种设计虽然牺牲了部分灵活性，但从根本上避免了数据竞争、意外修改等风险，符合其安全至上的哲学。
-
-
-
-| Swift 数据类型 | 单向转换 or 双向转换 | OC 数据类型 |
-| -------------- | -------------------- | ------------------- |
-| String | <--------> | NSString |
-| String | <-------- | NSMutableString |
-| Array | <--------> | NSArray |
-| Array | <-------- | NSMutableArray |
-| Dictionary | <--------> | NSDictionary |
-| Dictionary | <-------- | NSMutableDictionary |
-
diff --git a/Chapter1 - iOS/1.125.md b/Chapter1 - iOS/1.125.md
deleted file mode 100644
index b086ada..0000000
--- a/Chapter1 - iOS/1.125.md
+++ /dev/null
@@ -1,220 +0,0 @@
-# Swift 函数式编程
-
-## 定义
-
- 函数式编程（Funtional Programming，简称 FP）是一种编程范式，也就是如何编写程序的方法论
-
-- 主要思想：把计算过程尽量分解成一系列可复用函数的调用
-- 主要特征：函数是“第一等公民”。函数与其他数据类型一样的地位，可以赋值给其他变量，也可以作为函数参数、函数返回值
-
-
-
-函数式编程最早出现在 LISP 语言，绝大部分的现代编程语言也对函数式编程做了不同程度的支持，比如：Haskell、JavaScript、Python、Swift、Kotlin、Scala 等
-
-
-
-函数式编程中几个常用的概念：
-
-- Higher-Order Function、Function Currying
-- Functor、Applicative Functor、Monad
-
-
-
-## 高阶函数
-
- 高阶函数是至少满足下列一个条件的函数:
-
-- 接受一个或多个函数作为输入（map、filter、reduce等）
-- 返回一个函数
-
-FP中到处都是高阶函数
-
-
-
-## 柯里化（Currying）
-
-将一个接受多个参数的函数变换成为一系列只接受单个参数的函数
-
-Demo：
-
-```swift
-// 函数式编程，为了过程的复用
-let num = 10
-func add(_ v: Int) -> (Int) -> Int {{ $0 + v }}
-func sub(_ v: Int) -> (Int) -> Int { { $0 - v } }
-func multiple( _ v: Int) -> (Int) -> Int { { $0 * v }}
-func divide(_ v: Int) -> (Int) -> Int { { $0 / v } }
-func mod(_ v: Int) -> (Int) -> Int { { $0 % v }}
-
-// 函数合成，泛型
-infix operator >>> : AdditionPrecedence
-func >>>
-
-
-
-Demo2：将一个三个参数的函数变成柯里化
-
-```swift
-func addThree(_ v1: Int, _ v2: Int, _ v3: Int) -> Int { v1 + v2 + v3 }
-func addThree(_ v1: Int) -> ((Int) -> (Int) -> Int) {
- return { v2 in
- return { v3 in
- return v1 + v2 + v3
- }
- }
-}
-
-func currying
-
-奇怪的事情发生了：AppDelegate 不见了，也没地方构建 keyWindow，怎么办？为什么文件叫 `SwiftUIDemoApp`？
-
-其实：
-
-- SwiftUIDemo 是项目名称，SwiftUI 规范约定，默认生成 `项目名 + App.swfit`
-- Apple 设计 SwiftUI 的时候，打算让 UIKit、AppKit 退居二线，所以默认没有 AppDelegate、KeyWindow
-- `@mian` 属性告诉编译器，这是应用程序主入口。编译器会自动生成一个入口函数，类似传统的 main 函数，内部初始化应用程序和启动 RunLoop
-
-
-
-如果需要使用 AppDelegate 来处理一些逻辑，可以按照下面的方式：
-
-- 声明一个类，需继承自 NSObject、遵循 `UIApplicationDelegate` 协议，实现协议方法
-- 在主入口处，添加 `@UIApplicationDelegateAdaptor` 标记
-
-```swift
-class AppDelegate: NSObject, UIApplicationDelegate {
- func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey : Any]? = nil) -> Bool {
- print("applicationDidFinishLaunching")
- return true
- }
- func applicationDidReceiveMemoryWarning(_ application: UIApplication) {
- print("applicationDidReceiveMemoryWarning")
- }
-}
-
-@main
-struct SwiftUIDemoApp: App {
- @UIApplicationDelegateAdaptor(AppDelegate.self) var appDelegate
- var body: some Scene {
- WindowGroup {
- ContentView()
- }
- }
-}
-```
-
-QA：需要注意的是，在 SwiftUI 中只有部分代理可以使用。为什么？
-
-iOS 13 以前，由 UIApplicationDelegate 来控制生命周期，iOS 13 以后，由 UISceneDelegate 来控制生命周期。在 iOS 13 之后，用UIScene 替代了之前 UIWindow 来管理视图，背后的设计考量主要是为了解决 iPadOS 展示多窗口的问题。
-
-在 iOS 14 之后，Apple 又给 SwiftUI 提供了更优雅的 API 来显示和控制 Scene。所以控制应用展示可以这样：
-
-```swift
-@main
-struct SwiftUIDemoApp: App {
- @UIApplicationDelegateAdaptor(AppDelegate.self) var appDelegate
- @Environment(\.scenePhase) var scenePhase
- var body: some Scene {
- WindowGroup {
- ContentView()
- }.onChange(of: scenePhase) { newScenePhase in
- switch newScenePhase {
- case .active:
- print("应用启动了")
- case .inactive:
- print("应用休眠了")
- case .background:
- print("应用在后台展示")
- @unknown default:
- print("default")
- }
- }
- }
-}
-```
-
-SwiftUI 的文档写的还是不错。
-
-
-
-
-
-ContentView.swift 及其效果如下：
-
-
-
-上面的代码 `some view` 中，view 是 SwiftUI 一个核心的协议，代表了闭包中元素描述。如下代码所示，其是通过一个 associatedtype 修饰的，带有这种修饰的协议不能作为类型来使用，只能作为类型约束来使用。
-
-通过 Some View 的修饰，其向编译器保证：每次闭包中返回的一定是一个确定，而且遵守 view 协议的类型。这样的设计，为开发者提供了一个灵活的开发模式，抹掉了具体的类型，不需要修改公共 API 来确定每次闭包的返回类型，也降低了代码书写难度。
-
-@State 内部是在 Get 的时候建立数据源与视图的关系，并且返回当前的数据引用，使视图能够获取，在 Set 方法中会监听数据发生变化、会通知 SwiftUI 重新获取视图 body，再通过 Function Builders 方法重构 UI，绘制界面，在绘制过程中会自动比较视图中各个属性是否有变化，如果发生变化，便会更新对应的视图，避免全局绘制，资源浪费。
-
-
-
-## Xcode 对于 SwiftUI 的支持
-
-- Xcode 支持预览
-
- 
-
-- 在预览界面选中某个空间，同时按住 `command + 单击`，可以调出一个操作面板。第一个是 UI 检查器，可以查看和修改
-
- 
-
- 在代码区域选中控件，同时按住 `command + 单击`，同样可以调出一个操作面板
-
- 
-
-- 预览模式下，支持代码和预览界面的实时刷新同步。
-
-
-
-## FunctionBuilder
-
-Swift 源代码路径：`lib/Parse/ParseDecl.cpp`
-
-```swift
-// Historical name for result builders.
-checkInvalidAttrName("_functionBuilder", "resultBuilder",
- DeclAttrKind::ResultBuilder, diag::attr_renamed_warning);
-```
-
-遵循 View 协议的，其实本质上都是调用 body 来绘制 UI 的。`@ViewBuilder` 其实就是 `@_functionBuilder`，编译器会对它所包含的方法有一定的要求，其隐藏在各个容器类型的最后一个闭包参数中。
-
-```swift
-@available(iOS 13.0, macOS 10.15, tvOS 13.0, watchOS 6.0, *)
-public protocol View {
-
- /// The type of view representing the body of this view.
- ///
- /// When you create a custom view, Swift infers this type from your
- /// implementation of the required ``View/body-swift.property`` property.
- associatedtype Body : View
-
- /// The content and behavior of the view.
- ///
- /// When you implement a custom view, you must implement a computed
- /// `body` property to provide the content for your view. Return a view
- /// that's composed of built-in views that SwiftUI provides, plus other
- /// composite views that you've already defined:
- ///
- /// struct MyView: View {
- /// var body: some View {
- /// Text("Hello, World!")
- /// }
- /// }
- ///
- /// For more information about composing views and a view hierarchy,
- /// see 
-
-
-
-
-
-这种设计有以下好处：
-
-- 声明式编程：通过将 `foregroundColor` 设计为 `ViewModifier`，符合声明式编程范式。意味着你可以通过描述你想要的界面外观和行为，而不是通过编写更新界面的代码，来构建用户界面。这种方式使代码更易于阅读和维护，同时也减少了与界面状态同步相关的错误
-- 链式调用与组合性：`ViewModifier` 允许开发者以链式调用的方式组合多个修饰符，从而轻松创建复杂的视图层次结构
-
-
-
-## SwiftUI 元控件
-
-在 SwiftUI 系统中我们使用结构体遵守 `View` 协议，通过组合现有的控件描述，实现 `Body` 方法，但 `Body` 的方法会不会无限递归下去？
-
-在 SwiftUI 系统中定义了 6 个元/主 View `Text` `Color` `Spacer` `Image` `Shape` `Divider`, 它们都不遵守 View 协议，只是基本的视图数据结构。
-
-其他常见的视图组件都是通过组合元控件和修饰器来组合视图结构的。如 `Button` `Toggle` 等。
-
-
-
-## 状态管理
-
-不像 Vue/React，SwiftUI 关键字太多了，容易搞混淆：@State、@Binding、ObservableObject、@ObservedObject、.environmentObject()、@EnvironmentObject、@StateObject
-
-### @State
-
-和一般的存储属性不同，@State 修饰的值，在 SwiftUI 内部会被自动转换为一对 setter 和 getter，对这个属性进行赋值的操作将会触发 View 的刷新，它的 body 会被再次调用，底层渲染引擎会找出界面上被改变的部分，根据新的属性值计算出新的 View，并进行刷新。
-
-```swift
-import SwiftUI
-
-struct StateDemoView: View {
- @State var name: String = ""
- var body: some View {
- VStack {
- Text(name)
- Spacer().frame(height: 100)
- Button {
- name = "杭城小刘"
- } label: {
- Text("change name")
- }
- }
- }
-}
-```
-
-### @Binding
-
-和 @State 类似，@Binding 也是对属性的修饰，它做的事情是将值语义的属性“转换”为引用语义。对被声明为 @Binding 的属性进行赋值，改变的将不是属性本身，而是它的引用，这个改变将被向外传递.
-
-```swift
-struct Dog {
- var name: String = "Unknown"
-}
-struct BindDemoView: View {
- @State var dog: Dog = Dog()
- var body: some View {
- VStack {
- Text(dog.name)
- Spacer().frame(height: 100)
- ChildView(childDog: $dog)
- }
- }
-}
-
-struct ChildView: View {
- @Binding var childDog: Dog
- var body: some View {
- Button {
- childDog.name = "TaoTao"
- } label: {
- Text("点我")
- }
- }
-}
-```
-
-```swift
-@available(iOS 13.0, macOS 10.15, tvOS 13.0, watchOS 6.0, *)
-@frozen @propertyWrapper @dynamicMemberLookup public struct Binding
-
-
-
-
-
-### 第二种方式：UIViewControllerRepresentable
-
-- 按照传统的方式写一个 Swift Class。可以按照纯代码的方式写，也可以按照 StoryBoard 结合代码的方式写
-
- CustomViewController.swift
-
- ```swift
- import UIKit
-
- class CustomTableViewCell: UITableViewCell {
-
- @IBOutlet weak var titleLabel: UILabel!
- @IBOutlet weak var contentLabel: UILabel!
-
- override func awakeFromNib() {
- super.awakeFromNib()
-
- }
- }
-
- class CustomViewController: UIViewController {
-
- @IBOutlet weak var tableView: UITableView!
-
- override func viewDidLoad() {
- super.viewDidLoad()
- tableView.delegate = self
- tableView.dataSource = self
- }
- }
-
- extension CustomViewController: UITableViewDataSource, UITableViewDelegate {
- func tableView(_ tableView: UITableView, numberOfRowsInSection section: Int) -> Int {
- 100
- }
-
- func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell {
- var cell:CustomTableViewCell? = tableView.dequeueReusableCell(withIdentifier: "CustomTableViewCell") as? CustomTableViewCell
- if cell == nil {
- cell = UITableViewCell(style: .default, reuseIdentifier: "CustomTableViewCell") as? CustomTableViewCell
- }
- cell?.titleLabel.text = "第\(indexPath.row + 1)行"
- cell?.contentLabel.text = "我是内容\(indexPath.row + 1)"
- return cell!
- }
-
- func tableView(_ tableView: UITableView, heightForRowAt indexPath: IndexPath) -> CGFloat {
- 50
- }
-
- func tableView(_ tableView: UITableView, didSelectRowAt indexPath: IndexPath) {
- print("点击了第\(indexPath.row + 1)行")
- }
- }
- ```
-
-- 在使用的地方，新建一个结构体，遵循 `UIViewControllerRepresentable` 协议，实现协议方法
-
- - `associatedtype UIViewControllerType : UIViewController` 指定 `associatedtype UIViewControllerType : UIViewController` 关联类型声明，该关联类型指定 `UIViewControllerRepresentable` 对象将桥接的具体的 UIViewController 子类型
- - `@MainActor func makeUIViewController(context: Self.Context) -> Self.UIViewControllerType` 负责创建并配置 `UIViewController` 实例。这个方法在第一次需要创建视图控制器时被调用，允许你在 SwiftUI 中集成和使用 UIKit 中的视图控制器。
- - `@MainActor func updateUIViewController(_ uiViewController: Self.UIViewControllerType, context: Self.Context)` 方法在视图控制器的生命周期中可能会被多次调用，用于更新视图控制器的状态或属性。
-
- UIKitGeneratedViewController.swift
-
- ```swift
- import SwiftUI
-
- struct UIKitGeneratedViewController: View {
- var body: some View {
- VStack {
- CustomViewControllerWarpper()
- }
- }
- }
-
- struct CustomViewControllerWarpper: UIViewControllerRepresentable {
- typealias UIViewControllerType = CustomViewController
-
- func makeUIViewController(context: Context) -> CustomViewController {
- // 纯代码生成的用 CustomViewController()。 StoryBoard 生成的用 UIStoryboard(name:bundle).instantiateInitialViewController()
- let vc = UIStoryboard(name: "Main", bundle: nil).instantiateViewController(identifier: "CustomViewController") as! CustomViewController
- return vc
- }
-
- func updateUIViewController(_ uiViewController: CustomViewController, context: Context) {
- print(context)
- }
- }
-
- struct UIKitGeneratedViewController_Previews: PreviewProvider {
- static var previews: some View {
- UIKitGeneratedViewController()
- }
- }
- ```
-
- 使用
-
- ```
- @main
- struct SwiftUIDemoApp: App {
- var body: some Scene {
- WindowGroup {
- UIKitGeneratedViewController()
- }
- }
- }
- ```
-
-
-
-
-
-## 最佳实践
-
-SwiftUI 是个 UI 框架、也是个组件库，核心是为了解决 UI 构建复杂、繁琐的问题。Redux 在前端由来已久，有 store、state、action、middleware、reducer 等角色，多个角色各司其职，不存在团队规范和约定后不遵守的情况。通过 store 来管理状态，状态变化后，使用到该状态的 UI 组件会收到通知，更新 UI。用户点击操作 UI，产生 action，action 经历过一系列 middleware 后来到了 store，store 让 reducer 根据 action 和当前的 state 计算，得到一个新的 state。新的 state 变化了，使用到的地方的 UI 也会自动更新。（数据和 UI 的双向绑定）
-
-
-
-对比 MVC：
-
-- 苹果早期官方给的 MVC 缺少了状态管理能力，导致了实现状态管理，控制器的代码很复杂。
-- 另一个问题是状态传递很混乱，不同的开发有自己的偏好： callback、delegate、kvo、notification，代码中可能存在多种状态传递的手段，代码的可读性、可维护性下降，团队协作很困难。
-- 很难看出某些状态会和哪些 UI 相关，在实际开发迭代、修复 bug 的过程中很容易引入新 bug
-
-对比 MVVM：
-
-- 状态绑定的代码比较多，代码冗余比较多，比较枯燥且可能出错。选哪个技术手段也容易受到挑战。而 Redux 则是框架已经帮忙处理好了状态绑定。
-- 可测性。容易测试业务逻辑，相对于 ViewModel 的测试，对 reducer 进行测试更容易编写，reducer 是纯函数，对于给定的输入，输出也恒定，不会修改外部状态。
-- 代码风格较 Redux 不够统一，导致代码易读性不如 Redux。Redux 多个角色清晰分明，没有理解成本，对于框架层的东西，团队小伙伴不需要按照“素质”、“约定”去遵循实现。
-- 状态的改变较 Redux 不容易跟踪。如果出了问题，需要调试比较麻烦。
-- 状态传递不太方便。如果需要将状态传递到比较深的视图上，往往是不太方便的。而 Redux 可以通过框架的能力轻松的将状态送到任何地方。
-
-
-
-### 开源项目
-
-Apple 推出了 SwiftUI，但没有像最早 MVC 一样，在 SwiftUI 中推出一个状态管理的官方架构，虽然 SwiftUI 有 `@State`、`@ObservedObject` 、`@StateObject` 等，但这些东西在不同父子组件、兄弟组件的状态传递、状态管理 case 下，该如何组织是一个没有规范的问题。另外单测困难，因为逻辑代码耦合在 View 相关的代码中。为此，业界借鉴前端领域的 Redux， Redux-like 的方案很多，比较有名的是 [ReSwift](https://github.com/ReSwift/ReSwift) 和 [TCA](https://github.com/pointfreeco/swift-composable-architecture)，个人更倾向于 TCA，全称是 The Composable Architecture。
-
-利用 TCA 做一个简易版的计数器 App
-
-安装依赖：File -> Add Packages，输入 `swift-composable-architecture` 搜索，点击右下角 Add Package 即可。
-
-
-
-然后开始开发：先编写 Reducer 部分，再开发相关 UI
-
-```swift
-// Counter.swift
-import ComposableArchitecture
-import SwiftUI
-
-struct Counter: Reducer {
- // State
- struct State: Equatable {
- var count: Int = 0
- }
- // Action
- enum Action {
- case increment
- case decrement
- case reset
- case setCount(String)
- }
- // Reducer
- var body: some Reducer
-
-说明：
-
-- 发送消息，而非直接改变状态。按钮响应事件里，通过 store 发送 action 的方式 `store.send(.increment)`
-- 只在 Reducer 中改变状态。类似 `func reduce(into state: inout State, action: Action) -> Effect
-
-如果需要在测试的时候使用“重复测试”功能，右击测试按钮，在弹出框里做重复测试的配置修改。
-
-
-
-### 动手做一个简易版 Redux
-
-新建 `Redux.swift ` 是一个纯逻辑 Swift 文件。
-
-```swift
-//
-// Redux.swift
-// SwiftUIDemo
-//
-// Created by Unix_Kernel on 4/3/24.
-//
-
-import Foundation
-
-protocol Action {}
-class IncreaseAction: Action {}
-class DecreaseAction: Action {}
-
-struct ReduxState {
- var count: Int
- init(count: Int) {
- self.count = count
- }
-}
-
-typealias Reducer = (ReduxState, Action) -> ReduxState
-
-final class Store: ObservableObject {
- var reducer: Reducer
- @Published private (set) var state: ReduxState
-
- init(reducer: @escaping Reducer, state: ReduxState) {
- self.reducer = reducer
- self.state = state
- }
-
- func dispatch(_ action: Action) {
- self.state = self.reducer(self.state, action)
- }
-}
-```
-
-使用的地方
-
-工程入口文件 `SwiftUIDemoApp.swift`
-
-```swift
-@main
-struct SwiftUIDemoApp: App {
- @UIApplicationDelegateAdaptor(AppDelegate.self) var appDelegate
- @Environment(\.scenePhase) var scenePhase
- var body: some Scene {
- WindowGroup {
- let state = ReduxState(count: 0)
- let reducer: Reducer = { (state, action) -> ReduxState in
- switch action {
- case is IncreaseAction:
- return ReduxState(count: state.count + 1)
- case is DecreaseAction:
- return ReduxState(count: state.count - 1)
- default:
- return ReduxState(count: state.count)
- }
- }
- let store: Store = Store(reducer: reducer, state: state)
- ReduxDemoView().environmentObject(store)
- }
- }
-}
-```
-
-另一个展示的页面 `ReduxDemoView.swift`
-
-```swift
-//
-// ReduxDemoView.swift
-// SwiftUIDemo
-//
-// Created by Unix_Kernel on 4/3/24.
-//
-
-import SwiftUI
-
-struct ReduxDemoView: View {
- @EnvironmentObject private var store: Store
- var body: some View {
- VStack {
- Text("数据：\(store.state.count)")
- Spacer()
- .frame(height: 50)
- HStack {
- Button {
- store.dispatch(IncreaseAction())
- } label: {
- Text("+1")
- }
- Spacer()
- .frame(width: 100)
- Button {
- store.dispatch(DecreaseAction())
- } label: {
- Text("-1")
- }
- }.buttonStyle(.borderedProminent)
- }
- }
-}
-
-struct ReduxDemoView_Previews: PreviewProvider {
- static var previews: some View {
- ReduxDemoView()
- }
-}
-```
-
-实现效果如下：
-
-
-
-## 核心技术
-
-### SwiftUI 的渲染机制
-
-Render loop 是驱动 SwiftUI 进行渲染更新的重要机制，了解它的原理和策略，可以揭秘 SwiftUI 高性能背后的秘密。
-
-- event loop：事件循环，基于消息事件的循环，例如触摸被系统包装成一个事件一层一层传递给 UI 组件并最终触发 UI 组件渲染。
-
-- render loop：渲染循环，是一个更小的概念，更多关注在消息处理和屏幕渲染上
-
-- invalidated：无效、失效，类似于 Flutter 的 dirty 。当一个 View 的关联属性改变了，或者其他原因导致 View 需要刷新，View 就会被标记为 invalidated，此时框架会对 View 的body 进行 evaluate 。
-
-- evaluate：直译是评估，我更倾向于翻译成计算，也就是当框架发现一个 View 被标记为 invalidated 后，框架会尝试比对改变前和改变后的 body 内容。如果框架认为 body 内容改变了，就会重新渲染。注意，evaluation 并不一定会导致重新渲染，这取决于框架对 body 的评估结果。评估虽然不会必然导致渲染，但框架仍需读取 body 数据并进行（可能复杂的）计算以确定内容是否改变。
-
-GUI 的本质离不开 EventLoop，对于 iOS 来说，无论 UIKit 还是 SwiftUI 背后都是 RunLoop。RunLoop 会向 UI 代码分发消息，进而出发屏幕的一部分重新渲染。消息的处理和屏幕上的图形渲染构成一个应用程序的 render loop。
-
-#### onAppear
-
-在 SwiftUI 中，我们没法得到像 UIKit 中那么丰富的视图生命周期。如果我们想在一个视图出现时执行一个动作，我们只能使用一个函数：`onAppear` 。但是它到底是什么时候被调用的呢？是不是像 `viewWillAppear` 那样，在视图被渲染并在屏幕上可见之前调用？如果是的话，我们可以信赖它吗？
-
-```swift
-// ViewModel.h
-import Foundation
-class ViewModel: ObservableObject {
- @Published var statusText: String = "invalid"
-
- func fetch() {
- self.statusText = "loading"
- }
-}
-// ContentView.swift
-struct ContentView: View {
- let store: StoreOf
-
-如果你在 Xcode 调试器中暂停一个 iOS 应用程序，主线程的堆栈信息中便会出现下面的调用栈
-
-```shell
-* frame #0: libsystem_kernel.dylib`mach_msg_trap + 10
- frame #1: libsystem_kernel.dylib`mach_msg + 59
- frame #2: CoreFoundation`__CFRunLoopServiceMachPort + 319
- frame #3: CoreFoundation`__CFRunLoopRun + 1249
-```
-
-`mach_msg` 是系统调用，`CFRunLoop` 用它来等待多个可能的事件中的任何一个。在这期间，我们的应用程序没有使用 CPU ，或者至少主线程没有使用。
-
-一个 `CFRunLoop` 被配置为一组传递事件的输入源。当一个应用程序被启动时，它在主线程上启动一个 run loop ，用一个 input sources（输入源）来传递触摸事件。其他的输入源之后也可以被添加到其中。你也可以在辅助线程上启动新的 run loop 。我们可以用一个带有两个输入源的 `CFRunLoop` 实现一个处理用户输入和网络事件的命令行程序。
-
-来自输入源的事件会按照特定的顺序[进行处理](https://link.juejin.cn/?target=https%3A%2F%2Fdeveloper.apple.com%2Flibrary%2Farchive%2Fdocumentation%2FCocoa%2FConceptual%2FMultithreading%2FRunLoopManagement%2FRunLoopManagement.html)。run loop 一共有 4 种类型的输入源:
-
-- input sources 0。这是自定义的输入源，它们手动调用 `CFRunLoop` 函数来传递事件。iOS 应用程序中的触摸事件在一个辅助线程上处理，然后通过 input sources 0 送到主线程的 run loop 中。
-- input sources 1。这是基于机器端口的输入源。例如 CADisplayLink，可用于将绘图代码与显示器刷新率同步。异步网络代码也可以使用 input sources 1。(然而，请注意，许多网络库在内部调度队列上使用阻塞的 I/O 调用来代替网络调用，然后通过主调度队列将代码调度到主线程)
-- Timer sources。计时器，如Timer，使用这种特殊的输入源。
-- The main dispatch queue。调度到主队列的代码，以及与主队列相关的调度源也构成了一个输入源。这允许旧代码和基于调度的代码之间的沟通。（其他队列没有基于 `CFRunLoop` 实现）
-
-除了添加输入源，我们还可以向 `CFRunLoop` 添加观察者，当 run loop 到达特定周期时会发送通知。run loop 的周期是由 `CFRunLoopActivity` 定义的，观察者可以选择对其中的一个或几个周期进行监听。run loop 观察者在苹果自己的框架中被广泛使用
-
-```c
-__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__
-__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__
-__CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__
-__CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__
-__CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__
-```
-
-
-
-#### Core Animation & render Server
-
-你是否有过这样的经历：当一个应用程序出现卡顿时，你认为它不可能是卡顿，因为还有一些动画在进行中？即使应用程序的主线程被卡住，指示器（菊花）仍在旋转，这总是让我困惑。即使主线程繁忙或暂停，iOS中的动画也可以继续。这不是因为动画发生在另一个**线程**中，而是因为它们发生在另一个**进程**中。
-
-Core Animation 与 render server 对话，告诉它要画什么和做什么动画。一般来说，我们会对一个视图进行多次修改，作为对用户操作的反馈。在 UIKit 中，为了响应一个按钮的点击，你可能会同时改变一个视图的大小和背景颜色，或者你可能会调用多个方法来触发 `setNeedsDisplay` 。如果我们每改变一个参数就渲染一次，很明显效率会非常低，也会导致一些奇怪的问题。为了告诉系统该把哪几个参数打包一起渲染，Core Animation 框架暴露了 `CATransactions` 。
-
-`CATransaction` 包含了 `begin` 和 `commit` 两个方法。你可以手动 begin （启动）和 commit （提交）一个 `CATransaction` 事务。如果你不主动调用 `CATransaction` API，`CATransaction` 也会在引擎下被隐式调用。
-
-Demo
-
-```swift
-@IBAction func buttonPress() {
- self.view.backgroundColor = .red
- sleep(2)
- self.view.backgroundColor = .white
-}
-```
-
-在按下按钮后，应用程序被卡住 2 秒，但它所处的视图的背景颜色保持为白色。视图层的变化在睡眠前没有被渲染。这是因为设置背景颜色启动（begin）了一个隐式渲染事务，而这个事务在睡眠前没有提交（commit）。
-
-改进
-
-```swift
-@IBAction func buttonPress() {
- CATransaction.begin()
- self.view.backgroundColor = .red
- CATransaction.commit()
- sleep(2)
- self.view.backgroundColor = .white
-}
-```
-
-我们现在按下这个按钮，它所在的视图的背景颜色就会变成红色，然后在应用程序卡住的时候保持红色两秒钟，然后变成白色。我们主动提交（commit）了一个事务，因此视图在睡眠之前改变了颜色。由此可以推断，仅仅改变一个视图的背景颜色（不主动调用 CATransaction ），只会隐式地创建渲染事务，并不会去提交这个事务。
-
-那么隐式的事务究竟何时提交？答案是：每当一个隐式事务被启动，就会在当前 run loop 周期结束时被安排提交。它的底层是用一个 run loop 观察者来完成的，这个观察者是由 Core Animation 添加到主 `CFRunLoop` 中的，观察的周期是 `CFRunLoopActivity.beforeWaiting`。
-
-`CATransaction` 是可嵌套的。你可以在一个 `CATransaction` 里面启动另一个 `CATransaction` ，**但是只有外部事务会被用来渲染和改变屏幕内容**。外层事务可以是一个被隐式地启动的事务。举个例子：有些控件可能在调用它们的 action handlers 之前就已经调用了动画代码，动画代码启动了一个隐式事务。然后当你在 action handlers 内使用显式事务（手动调用 `CATransaction.commit()` ）对一个图层进行修改时，提交它不会立即产生任何效果（需要等外层的隐式事务提交时才会改变）。
-
-虽然你在 SwiftUI 应用程序中不直接使用 CATransactions，但 SwiftUI 框架在内部仍然使用 Core Animation 和 CATransactions 进行绘制和动画。与 render server 一起，Core Animation 对 iOS 来说是非常基础的。
-
-#### 触摸事件和显示器刷新率
-
-需要自定义动画或使用物理引擎的应用程序可以使用 `CADisplayLink` 来使绘图代码与显示器的刷新率同步。在这个 API 可用之前，特别是游戏开发者很难做到这一点，他们不得不使用 `NSTimer` 并想办法绕过很多限制。
-
-应用程序从操作系统接收触摸事件的频率与显示屏刷新的频率相同。这是合理的，因为我们使用触摸来更新视图，如果比显示的频率更高，那就是一种浪费。但是，如果我们将收到这些触摸事件的时间与 `CADisplayLink` 启动的时间进行比较，我们会看到它们并不完全同步。
-
-在具有高触摸刷新率的 iPhone 上，一个显示刷新周期内会发生多个触摸事件，但我们不会单独接收它们。在 UIKit 中，我们可以从 UITouch 对象中获得那些中间的触摸事件。
-
-所有的 run loop 输入源，包括用于实现 `CADisplayLink` 和接收触摸的输入源，都以不同的方式应对系统繁忙的情况。如果多个触摸事件发生时，应用程序仍在忙于响应前一个触摸，它们将不会被单独传递，但仍可从最近的触摸事件中恢复触摸。相反，如果在下一次显示刷新即将发生时系统仍在忙碌， `CADisplayLink` 根本不会通知我们。
-
-
-
-#### 全貌
-
-
-
-
-
-
-
-当 APP 不做任何事情时，一个 SwiftUI 应用程序将有一个空闲的 CFRunLoop 。CFRunLoop 将等待来自输入源的事件，如触摸、网络事件、定时器或显示器刷新。为了响应触摸，SwiftUI 可能会调用一个 Button 的 `action handler`。如果我们在 `action handler` 中设置一个断点，我们会在堆栈跟踪中看到 `__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__` 。这是因为触摸事件是由 input sources 0 输入源传递的。
-
-为了响应来自输入源的事件，我们可能会修改视图的一些 `@State` 变量，或者在 `@ObservedObject ` 上调用一个函数，进而触发 `objectWillChange`，SwiftUI 视图会被标记为 invalidated（无效），意味着它的 body 需要被重新评估，但它不是立即重新评估，之后会评估。因为会可能存在这样一个 case：T1 时刻，值修改为1，T2 时刻修改为2，T3 时刻修改为1，如果每次都立即评估，效率会很低。
-
-那之后是什么时候？给 body 方法内加断点，在 LLDB 输入` bt` 可以看到
-
-```shell
-(lldb) bt
-* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 2.1
- * frame #0: 0x000000010c64f2cd TCADemo`closure #1 in closure #2 in ContentView.body.getter(self=TCADemo.ContentView @ 0x00007ff7b38aea80, viewStore=0x0000600003ccd140) at ContentView.swift:19:22
- frame #1: 0x000000010c65100e TCADemo`partial apply for closure #1 in closure #2 in ContentView.body.getter at 
-
-
-
-上图中这两只狗狗，到底是不是同一个呢？我们似乎无法准确地给出答案。为什么呢？因为我们缺乏一些关键信息，那就是 Identity。
-
-所以当 SwiftUI 处理你的界面描述时，它也需要 Identity 这个关键信息区分视图是否是同一个。
-
-
-
-让我们来看下上面这个 Good Dog, Bad Dog 的小应用，你可以点击屏幕上的任何位置来切换狗狗的状态。但是我们从技术层面分析，上面的界面可以有两种 SwiftUI 的描述方式：
-
-1. 自定义两个完全不同的 SwiftUI View，根据当前狗狗的状态去做逻辑判断描述
-2. 把上面的界面描述成一个 SwiftUI 自定义 View，在区别展示的地方，用不同的颜色来区分
-
-这两种 SwiftUI 的描述方式，会让视图从一种状态过渡到另一种状态的方式截然不同：
-
-- 按照第一种方式，由于是完全不同的视图，就意味着上面狗爪子的图标应该独立执行过渡动画，最终看起来只有淡入和淡出的效果
-- 按照第二种方式，SwiftUI 内部认为它是同一个视图，这就意味着在过渡期间，狗爪子图标会执行在屏幕上滑动的动画效果
-
-可以看出 SwiftUI 在处理过渡动画的时候，会根据不同状态下的 View 是如何连接的来进行处理，而决定 View 连接方式的关键就是 **View Identity**:
-
-- 共享 Identity 的 View 代表的是同一个 UI 界面元素，只是处在不同状态下而已 (Same identity = Same element)
-- 代表不同 UI 界面元素的 View，它的 Identity 也总是不同 (Different identities = Distinct elements)
-
-Identity 既然这么重要，那么开发者是如何用代码来定义的呢？在 SwiftUI 中分两种方式来定义 Identity：
-
-- 声明式 Identity，一般是在 View 上添加一个 `id(_:)` 修饰器或者在数据驱动列表控件中显示声明 Identifier，如 ForEach、List。参考前端 Vue、React List 中的 id
-- 结构性 Identity，是 SwiftUI 根据 View 的类型和层级结构来动态识别，虽然这种 Identity 不需要开发者指定，但也需要开发者清晰的将 View 的层级结构描述出来，方便 SwiftUI 内部识别。类似 xpath，根据 UI 层级和结构，生成唯一的 Identity
-
-
-
-##### 声明式 Identity
-
-
-
-就像上面这两只狗狗，仅通过图片，很难判断这是不是同一只狗狗，但如果我们能用名字来标识它们。就很容易得出结论。像这样给狗狗起名字来标识它们的方式，就是在显式声明 Identity。
-
-需要注意的是，声明式 Identity 是非常强大且灵活的。我们在之前 AppKit 或 UIKit 中编写界面的方式，其实就是采用的显式声明 Identity 的方式。怎么理解？由于 UIView 和 NSView 都是类，引用类型，所以它们的实例其实是一个指针，这个指针指向了一块内存空间。其中指针所代表的内存地址就是一种显式声明的 Identity。
-
-我们可以通过视图的指针来标识每个视图，如果多个视图指针，都共享同一块内存空间，那么它们其实是同一个视图，如下图所示：
-
-
-
-
-
-问题来了，SwiftUI 中的 View 都是结构体， 值类型，没有指针的概念，那 SwiftUI 怎么来唯一标识一个 View 的呢？
-
-其实，SwiftUI 是用另外一种形式来显式标识 View。通过下面的例子能更好的理解，例如在这个救援犬列表里，用 dogTagID KeyPath 获取相应属性，在参数里指定到 id 上，就是在显式声明 View 的 Identity。这样就能标识出每条数据对应的展示视图。一旦列表数据发生变化， SwiftUI 可以根据这些 ID 来判断，哪些视图需要新生成，哪些视图重复使用，只需要执行动画。
-
-
-
-##### 结构性 Identity
-
-不显式声明 Identity，这并不意味着这些 View 根本没有 Identity，也就是说每个 View 都有一个 Identity，即使它不是显式声明出来的。在这种情况下 SwiftUI 内部会对没有显式 Identity 的 View 根据它的描述层级结构生成一种隐式的 Identity，就叫做结构性 Identity。
-
-
-
-如上图，假设我们有两只相似的狗狗，但我们不知道它们的名字，我们仍然还要标识出它们。这时候可以通过它们坐的位置来标识，如 `左边的狗` 或 `右边的狗`。
-
-像这种利用排列位置的不同，来区分它们的方式就是所谓的 **结构性 Identity**。
-
-SwiftUI 几乎在所有地方都采用了这种结构化 Identity 的方式来标识 View。一个典型的例子就是在 SwiftUI 中 使用 if else 条件判断的时候，条件语句的结构使得 SwiftUI 能够明确的识别每个 View，如下图，第一个 AdoptionDirectory 只在条件为 True 的时候显示，第二个 DogList 只在条件为 False 的显示。
-
-
-
-但是 SwiftUI body 计算属性需要一个明确一致的返回类型，但 if else 条件判断使得返回类型不一致了，会引起编译失败。这时候 SwiftUI 引入了一个的黑魔法 - **ViewBuilder (默认是附加在 body 计算属性上的，不需要开发者单独指定)**。ViewBuilder 帮助 SwiftUI 把各种条件判断，封装成 _ConditionalContent 的数据结构。但为了区分在不同分支下的类型不同，用泛型来进行了区分，这样即保证了返回数据的一致性，又保证了 SwiftUI 内部可以通过泛型识别出不同分支下结构性 Identity。
-
-见源代码：
-
-
-
-
-
-如下图，我们只用一个 PawView 自定义View，在这个自定义的 View 的 Modifier 上利用三目运算的方式来动态改变需要变化部分的数值，当在不同状态之间发生界面切换的时候，由于始终是一个视图元素，所以就会执行平滑的滑动动画。
-
-其实，如果你回到 UIKit 中理解，也是一样的，我们在 UIView 上执行动画的时候，一般也是在同一个 UIView 的实例里去动态改变它的属性去修改样式， 才会有那种平滑过渡的效果；相反，如果虽然是同一个类型的 UIView，但是对应的是不同的实例，去做那种平滑的过渡效果，也是很难实现的。
-
-
-
-综上，**在使用结构性 Identity 的时候，第二种描述 View 的方式是更好的选择。应该尽量避免切换 Identity，这样做会给动画和性能都带来良好的效果，也有利于维持视图的生命周期和数据状态。**
-
-
-
-#### 危险的 AnyView
-
-说起 AnyView ，这家伙绝对是 Identity 的克星。
-
-
-
-上图是一个使用 AnyView 的示例代码。在这个自定义 View 中，为了保证最终返回一个明确一致的数据类型，每个分支都用一个 AnyView 包裹起来。由于 AnyView 隐藏了所包装视图的类型，让 SwiftUI 无法在条件判断中识别出结构性 Identity，在 SwiftUI 眼里，它看到的都是一些擦除类型的 AnyView，更要命的是，这段代码阅读起来特别困难。
-
-那么，接下来让我们用正确的方式来重构这段代码：
-
-- 第一步：消除 AnyView 包裹，把内部具体的 View 类型暴露出来
-- 第二步：去掉 所有的 return 关键字
-- 第三步：在方法上添加 @ViewBuilder 标识，保证最终返回的是一个明确的类型，编译通过
-- 第四步：由于我们只是在 dog 的 breed 状态之间来回判断，那么把 if else 改为 switch case 会更合适
-
-重构后，最终代码和 View 层级结构如下图：
-
-
-
-一般情况下，还是尽量避免使用 AnyView，因为 AnyView 有如下缺陷：
-
-- 代码难于阅读
-- 由于擦除了所有的 View 类型，无法在编译的过程中给出相应的提示
-- 可能会导致不必要的性能损失
-
-
-
-
-
-### 生命周期(Lifetime)
-
-#### Lifetime 与 Identity 的关系
-
-
-
-如上图，这里有个叫 Theseus 的小猫。他在一天中可能有各种不同的状态，一会装可爱，一会睡觉，一会发火，但是无论处于何种状态，他都是那只叫 Theseus 的小猫。
-
-视图在整个生命周期内有各种不同的状态，每个状态在 SwiftUI 中由不同的 View 实例(值类型)来描述，而 Identity 将这些不同状态下的 View 值随着时间的推移关联起来，它们都对应着同一个视图元素。这就是 Identity 与视图生命周期建立联系的本质。
-
-
-
-让我们用上面的代码来更清晰的理解这一点，这里我们有一个简单的自定义 View - PurrDecibelView，用来显示猫叫声的强度。一开始的时候 SwiftUI 调用 body 计算属性，获取到叫声为 25 的 View，但是突然小猫饿了，希望获得更多的关注，叫声变大为50，这时候 SwiftUI 监听到叫声这个状态的变化，重新调用 body 计算属性，获取到一个全新的 View，这两个 View 是完全截然不同的两个值。SwiftUI 会在后台对这两个值进行对比并对比出哪些部分发生了变化。得出对比结果后，告诉渲染视图执行变化部分的渲染操作，同时，用完的 View 值也会被销毁。
-
-这里非常重要的一点就是 View 的值跟 Identity 生命周期是不同的。值类型的 View 生命周期是非常短暂的。开发者要控制好的其实是它们的 Identity。也就是说，随着时间的推移， SwiftUI 创建很多新的 View 用来描述视图当前状态下的显示方式，但是 SwiftUI 内部只是拿这些 View 来进行样式和布局的对比，用完了这些 View 值就会销毁，其内部用 Identity 唯一标识的那个视图(RenderNode)会一直在内存中，并且一直都是同一个。但是一旦 Identity 发生变化，内部的视图元素生命周期也会结束。
-
-所以，如下图，我们经常用到的生命周期方法 onAppear 和 onDisappear，其实是在视图显示和消失的时候触发，而不是 View 创建和销毁的时候触发。
-
-
-
-所以最终我们得出如下公式来阐述 View，LifeTime，Identity 三者之间的关系：
-
-- View Value ≠ View Identity
-- View(视图)'s LifeTime = duration of the Identity
-
-视图和 struct 值类型的 View 没有严格对应关系，但持续可见的视图必然对应一个 identity。一个视图对应 >= 1个 DSL 描述的 View（也就是结构体）
-
-
-
-#### Lifetime 与 State 的关系
-
-理解了 Identity 与视图生命周期之间的联系，也能够帮助你更好地理解 SwiftUI 如何维持数据状态
-
-提到维持数据状态，那肯定要用到 State 和 StateObject。这两个状态管理工具可以保证在不同的 View 实例被创建的时候，封装的数据能够一直维持在内存中，相当于一种内存记忆。但是你去看它们的定义会发现它们都是结构体。按理说，在每次创建新的 View 实例后，应该就销毁重新生成了，那咋维持数据的呀？其实它们内部都会有一个 Storage 类，用来存储它们所修饰的数据。当一个视图根据 Identity 第一次创建的时候，SwiftUI 在内部为 State 和 StateObject 的 Storage 分配相应的内存空间，用来保存状态的初始值。**注意这里的 Storage 跟 Identity 是对应的，生命周期也是一致的**。
-
-如下图的 CatRecorder 自定义 View，每次的 title 发生变化，由于他被 @State 修饰，SwiftUI 内部会在内存中保存这个数据，并且监听他的变化，一旦发生变化，就调用 body，重新计算。
-
-
-
-下面，让我们来看一下在有分支的情况下，视图生命周期和数据状态之间的关系。
-
-
-
-如上图代码，分支里的两个 CatRecorder 由于结构性 Identity 不同，所以它们被 SwiftUI 视为是两个不同的视图。之前说过这样会影响动画效果，其实也会影响它们内部数据状态的维持。
-
-比方说，第一次进入的是 True 分支，SwiftUI 会为 CatRecorder 生成一个新的视图，并为数据分配内存空间，以存储状态的初始值。当 CatRecorder 内部状态发生变化时，只要都是在 True 分支下，由于 Identity 没变，所以还是同一个视图，所以状态也会连续性的变化，不会有数据丢失的情况。但是一旦 dayTime 发生变化，进入了 False 分支，SwiftUI 发现 Identity 发生了变化，会生成新的视图和与之对应状态的内存空间，这时候新的 CatRecorder 内部的所有状态都是初始值。True 分支下的视图和对应的状态接下来也会被释放。如果我们再切回到 True 分支，之前 True 分支的状态也回不来了，因为相较于上次的 View 类型，这又是一个全新的 Identity，会重新创建视图和数据状态存储空间。所以，最终分支切换后，在界面上有时候会发现记录的小猫状态突然丢失了。
-
-所以可以得出的结论是：View Identity 一旦变化，视图内部对应的数据状态也会被重新替换。也就是说：
-
-`State's Lifetime = 视图's Lifetime != View's Lifetime`
-
-
-
-### 稳定的 Identity
-
-保证 Identity 稳定，这一点非常重要，尤其是在使用数据驱动型的列表控件时，在下面这些控件中，往往都需要用数据的 id 来给 View 显式声明 Identity。
-
-
-
-下面两张图是两种不同的 ForEach 的用法。其中第一种用法是一个常数的 Range，SwiftUI 可以直接用 Range 的值来为视图生成 Identity，以确保在视图的整个生命周期内 Identity 是稳定的。但当使用一个动态的 Range 时，会导致声明式的 Identity 数值是不可预期的，Identity 一旦切换，视图都会重新生成，这样就会出现性能问题。 所以在 Xcode 12 的时候，检查到这种使用方式会编译报错，而在新版本的 Xcode 13 这将变为一个警告 (beta 版本似乎不生效)。
-
-```swift
-ForEach(0..<5) { offset in
- Text("🐑 \(offset)")
-}
-
-ForEach(0..
-
-看上面这张图的话，是一个树结构，但是有可能多个视图都依赖同一个状态。有可能某个子视图也依赖顶级视图中的状态。情况越来越复杂后，这就不再是一个树结构。重新整理，避免让连接线之间交叉，如下图，可以看出它们之间的关系实际上是一个图结构。我们可以称之为**依赖关系图**。
-
-
-
-深入的理解这个依赖关系图很重要，因为它保证了 SwiftUI 只更新那些需要重新调用 body 的 View。以最底部的依赖关系为例。如果我们检查这个依赖关系，会发现有两个 View 依赖它，当依赖的数据状态发生变化，只有这两个 View 会被标记为无效。同时 SwiftUI 开始调用每个视图的 body 计算属性，只为标记为无效的视图产生一个新的 body 值。
-
-
-
-状态管理工具，在 SwiftUI 依赖关系的建立就是通过它们来实现的：
-
-- @Binding
-- @Environment
-- @State
-- @StateObject
-- @ObservableObject
-- @EnvironmentObject
-
-
-
-### 改进 Identity
-
-Identity 就是依赖关系图的灵魂，重要性不言而喻。正如之前所说，Identity 用来标识一个视图，所以 SwiftUI 会根据 Identity 来高效的判断哪些视图需要更新，哪些视图需要新建，哪些视图需要销毁。
-
-#### 稳定性
-
-对于开发者来说，首先要确保的就是 Identity 的稳定性。稳定的 Identity 会给 SwiftUI 带来如下好处：
-
-- 确保视图生命周期的准确性，一个视图的生命周期是由 Identity 来决定的，一个不稳定的 Identity 会导致视图生命周期意外缩短
-- 提高应用程序的性能，SwiftUI 无需在依赖关系图更新的过程中为不必要的视图和状态重新分配内存空间
-- 缩小影响依赖关系影响的范围
-- 保证数据状态不会无故丢失
-
-在下图的例子中，每次都生成一个 UUID 和 直接用 Indices 来显式声明 Identity 都是不稳定的方式，因为它们都会随着时间推移发生变化，不能准确地标识一个视图，最终导致的结果就是，当我们在列表头部新插入数据时，整个列表都会重新刷新。相反，我们如果用一个 databaseID 就是可以的，因为这个 ID 只对应一个数据，能够清晰的标识一个与该数据对应的视图。这时候我们在头部新插入数据，所有的动画效果都非常自然了。
-
-
-
-
-
-
-
-#### 唯一性
-
-但是只保证 Identity 的稳定性还是不够的。好的 Identity 还要确保唯一性。每个 Identity 都应该准确映射到一个单一的视图。
-
-唯一的 Identity 会给 SwiftUI 带来如下好处：
-
-- 平滑的动画效果
-- 同样可以提高性能
-- 准确地的反应视图和状态之间的依赖关系
-
-像下面的代码中使用 name 的 KeyPath 来给 View 显式声明 Identity，是不合理的，因为我们无法保证 name 的唯一性，一旦出现重名的情况，新的视图很有可能不会展示出来。但当把 name 换成 serialNumber，一切都正常了
-
-
-
-
-
-
-
-#### 去分支
-
-上面，我们都是用声明式 Identity 来说明如何改进 Identity，接下来看看如何改进结构性 Identity。
-
-
-
-上面的代码，乍一看似乎没什么问题。但是仔细分析会发现，这里有个性能问题。**content 在不同的分支条件下，会产生不同的结构性 Identity，这就导致了分支切换后针对同一个 View 会生成两个不同的视图元素，也就是在内存中分配两份内存空间**。这点其实是可以避免的。虽然这里我们很轻易的发现了这个问题，但当项目大了之后，有可能这些 ViewModifier 的代码都不在一起，所以这种问题很容易被忽视。
-
-修改：把分支结构去掉，改为在 opacity 修饰器上添加三目运算的方式来动态修改透明度。由于去掉了分支结构，所以 content 只会生成单一的结构性 Identity，也就避免了不必要的内存开销，提高了性能。
-
-
-
-像上面代码直接把透明度设置为 1，也就是跟初始状态一致，其实 SwiftUI 发现这种情况是不执行任何渲染操作的。我们把这样的修饰器称为 "惰性修饰器"，因为它们不影响渲染的结果。
-
-#### 最佳实践
-
-是不是跟觉得在 SwiftUI 中使用条件分支很可怕？不要担心，想用分支的时候还是得用，只是用完之后，要多考虑下这个地方用分支来描述 View 结构的必要性，也就是要考虑当前代码的 View 到底是用来代表多个视图还是代表同一个视图的不同状态。
-
-如果是代表同一个视图的不同状态，那么使用一个惰性修饰器来标识一个单一的视图，往往是更好的选择。
-
-在下图中还给出了一些其他的惰性修饰器作为参考：
-
-
-
-
-
-### 总结
-
-日常开发的时候可能对 Identity 的思考、认知不够，不知道它原来影响动画、视图生命周期、状态生命周期都有关系。Identity 帮助 SwiftUI 系统做了很多决策。
-
--SwiftUI View 和 视图元素之间采用 Identity 关联起来，它们之间并非一一对应，Identity 有声明式的，也有结构式的。在 SwiftUI 中每当状态发生变化，都会调用对应的 body 生成新的 View 值，但是否生成新的视图则完全由 Identity 来决定。如果 Identity 一致，就会根据 Identity 去内存中查找之前创建的视图，换言之，相当于保持之前视图的生命周期，并且在内存中用类维持住之前的数据状态，只对更改数据后，视图变化的部分进行渲染操作。如果 Identity 不一致，则会新建视图元素，同时视图所依赖的状态也会被重新分配，回到初始值。
-
-总而言之，View Identity 对 SwiftUI 来说是至关重要的。我们一定要时刻注意 View 的 **显式 Identity** 和 **结构性 Identity**，并提高 Identity 的稳定性，确保 Identity 的唯一性。
-
-
-
-## 开发 tips
-
-要回答好这个问题，其实就是在**聊 UIKit SwiftUI 的能力边界在哪里**？它们各有优缺点，开发人员可以根据具体需求和场景来选择如何搭配使用它们。
-
-SwiftUI 的优势：
-
-- 声明式 UI：和主流的前端框架一样，提供了声明式 UI 编程模式，使得构建和管理 UI 变得简单直观。但它不只是一个开发框架，更是一个组件库，具备一些常见的 UI 组件能力（能力小于等于 UIKit）
-- 响应式 UI：支持响应式编程，可以轻松处理各种状态，聚焦于逻辑。又和前端主流框架做了一样的事情（不如说是大前端优秀的设计在客户端落地，并在官方侧取得了支持）
-- 跨平台特性：SwiftUI 可用于 iOS、macOS、watchOS、tvOS 的应用程序，具备较好的跨平台特性
-
-UIKit 的优势：
-
-- 成熟的生态系统：UIKit 拥有丰富的第三方库和组件，可以满足各种复杂的 UI 和功能需求
-- 定制能力：UIKit 提供了更多的自定义和底层控制能力，适用于需要高度定制化的界面和交互
-
-在实际开发中，可以根据以下场景来搭配使用 SwiftUI 和 UIKit：
-
-- 逐步迁移：对于已有的 UIKit 项目，可以逐步引入 SwiftUI，例如在新功能或模块中使用 SwiftUI，逐步迁移现有界面和功能。但需要考虑的是 SwiftUI 必须用 Swift 语言开发，新语言开发简单，但背后的比如 Crash 监控、热修复、动态路由、打包构建系统等，新语言如何与现有的基建打通是需要调研和考虑的一个事情。不过都2024了，Apple 官方拥抱了类似大前端很成熟的声明式开发、响应式编程，客户端同学该开始 SwiftUI 了。
-- 混合使用：可以在同一个应用程序中同时使用 SwiftUI 和 UIKit，根据具体需求选择合适的界面构建方式。例如，可以使用 SwiftUI 构建应用程序的主界面，同时使用 UIKit 来展示特定的复杂界面或功能。因为 SwiftUI 封装的是大多数常见、高频使用的 UI 组件，所以不可能满足所有需求，那些交互复杂的，还需要使用 UIKit 的能力。
-- 复用现有组件：可以将现有的 UIKit View 或者 ViewController 封装为 SwiftUI 可以用的组件。遵循 `UIViewRepresentable` 或 `UIViewControllerRepresentable` 协议即可。
-- 跨平台开发：对于需要在多个平台上展示相似界面的应用程序，可以使用 SwiftUI 来实现跨平台的 UI 共享，同时使用 UIKit 来处理特定平台的细节和定制化
-
-一言以蔽之：大多数情况下，使用 UIKit 足以，但想要使用新的框架， SwiftUI 很棒，但某些交互复杂的功能无法实现，还需要借助 UIKit 的能力，包括丰富的组件库和开源项目的支持。
-
-
-
-
-
-## 参考资料
-
-- [The SwiftUI render loop](https://rensbr.eu/blog/swiftui-render-loop/?utm_campaign=iOS%2BDev%2BWeekly&utm_medium=rss&utm_source=iOS%2BDev%2BWeekly%2BIssue%2B558)
diff --git a/Chapter1 - iOS/1.129.md b/Chapter1 - iOS/1.129.md
deleted file mode 100644
index eca7a42..0000000
--- a/Chapter1 - iOS/1.129.md
+++ /dev/null
@@ -1,29 +0,0 @@
-# Swift Dictionary 扩容机制
-
-
-
-## Dictionary
-
-```swift
-let dic = ["d": 4, "a": 1, "b": 2, "c": 3]
-print(dic)
-// ["c": 3, "d": 4, "a": 1, "b": 2]
-```
-
-Dictionary 顺序会乱序
-
-
-
-## KeyValuePairs
-
-KeyValuePairs 顺序不会乱序
-
-```swift
-let kvs: KeyValuePairs = ["d": 4, "a": 1, "b": 2, "c": 3]
-print(kvs)
-// ["d": 4, "a": 1, "b": 2, "c": 3]
-```
-
-
-
-开放寻址法
\ No newline at end of file
diff --git a/Chapter1 - iOS/1.13.md b/Chapter1 - iOS/1.13.md
deleted file mode 100644
index 2a3b9cf..0000000
--- a/Chapter1 - iOS/1.13.md
+++ /dev/null
@@ -1,226 +0,0 @@
-# UINavagationController重写push和pop方法
-
-> 有个需求就是在App的Tab的首页需要显示浮动着的交互动画的机器人，该机器人具有机器学习的特点，因此可以不断的与用户交互，怎么样实现只浮动在App的5个tab首页，当点击跳转不是首页的时候不需要显示
-
-因为5个tab上是5个自定义的导航控制器，所以我们可以监听导航控制器的push和pop事件，并且在push和pop的事件中判断当前控制器的字控制器的数量来判断窗口上的机器人是否需要显示，其实这里要说的就是如何监听push和pop事件。
-
-```
-/**
-* 重写这个方法的目的:为了拦截整个push过程,拿到所有push进来的子控制器
-*
-* @param viewController 当前push进来的子控制器
-*/
--(void)pushViewController:(UIViewController *)viewController animated:(BOOL)animated
-{
- // if (viewController != 栈底控制器) {
- if (self.viewControllers.count > 0) {
-
- for (UIView *view in [UIApplication sharedApplication].keyWindow.subviews) {
- if ([view isKindOfClass:[XLRobotImageView class]]) {
- if (self.viewControllers.count > 0) {
- self.robotView = (XLRobotImageView *)view;
- [view removeFromSuperview];
- }
- }
- }
-
-
- // 当push这个子控制器时, 隐藏底部的工具条
- viewController.hidesBottomBarWhenPushed = YES;
-
- UIButton *backButton = [UIButton buttonWithType:UIButtonTypeCustom];
- backButton.frame = CGRectMake(0, 0, 44, 44);
- [backButton setImage:[UIImage imageNamed:@"backArror"] forState:UIControlStateNormal];
- [backButton setTitleColor:[UIColor whiteColor] forState:UIControlStateNormal];
-
- backButton.adjustsImageWhenHighlighted = NO;
- backButton.contentHorizontalAlignment = UIControlContentHorizontalAlignmentLeft;
-
- backButton.titleLabel.font = [UIFont systemFontOfSize:16];
-
- [backButton addTarget:self action:@selector(back) forControlEvents:UIControlEventTouchUpInside];
- [backButton setImageEdgeInsets:UIEdgeInsetsMake(0, 5 * BoundWidth/375, 0, 0)];
- viewController.navigationItem.leftBarButtonItem = [[UIBarButtonItem alloc] initWithCustomView:backButton];
- }
-
- // 将viewController压入栈中
- [super pushViewController:viewController animated:animated];
-}
-
-
--(UIViewController *)popViewControllerAnimated:(BOOL)animated{
- //在5个tab的首页需要显示
- NSArray *vcs = self.viewControllers;
- UIViewController *topVC = vcs[vcs.count - 2];
- if (self.viewControllers.count >= 2) {
- if ([topVC isKindOfClass:[MZPregnancyHomeController class]] ||
- [topVC isKindOfClass:[HLSettingViewController class]] ||
- [topVC isKindOfClass:[BBXEditViewController class]] ||
- [topVC isKindOfClass:[HLFriendTopicController class]] ||
- [topVC isKindOfClass:[MZBookViewController class]]
- ) {
- [[UIApplication sharedApplication].keyWindow addSubview:self.robotView];
- }
- }
- return [super popViewControllerAnimated:animated];
-}
-
-```
-
-**敲黑板，注意啦**
-
-因为我做的一个全局的机器人只需要浮动在App的5个模块的首页，所以当页面进入第二层的时候就需要隐藏机器人，当App的顶层控制器是最外层的首页的时候再显示机器人，用导航控制器的push和pop监听就可以实现这个需求，但是遇到的一个问题就是当App从首页进入到第二层页面，用于手动右滑且滑到一半停止，这样子页面还是停留在第二层但是此时也会触发pop方法上面的代码就有点问题
-
-因此想办法需要监听导航控制器里面每个控制器的出现事件，找到一个方法 **- (void)navigationController:(UINavigationController *)navigationController didShowViewController:(UIViewController *)viewController animated:(BOOL)animated;** 恰好满足需求，以前没用过记录下来
-
-```
--(void)navigationController:(UINavigationController *)navigationController didShowViewController:(UIViewController *)viewController animated:(BOOL)animated{
- self.interactivePopGestureRecognizer.enabled = [self.viewControllers count] > 1 ;
-
- if ([viewController isKindOfClass:[MZPregnancyHomeController class]] ||
- [viewController isKindOfClass:[HLSettingViewController class]] ||
- [viewController isKindOfClass:[BBXEditViewController class]] ||
- [viewController isKindOfClass:[HLFriendTopicController class]] ||
- [viewController isKindOfClass:[MZBookViewController class]]
- ) {
- [[UIApplication sharedApplication].keyWindow addSubview:self.robotView];
- }
-}
-
-```
-
-
-
-
-
-```
-#
-
-
-@interface HLNavigationController ()
-
-### 使用
-
-- 创建 cartfile 文件 `touch cartfile`
-- 修改 cartfile 文件
-```
-github "Alamofire/Alamofire" "5.0.0-rc.3"
-github "onevcat/Kingfisher"
-github "SnapKit/SnapKit" ~> 5.0.0
-```
-
-
-
-
-
-### cartfile - dependency origin
-
-Carthage 支持两种类型的源，一个是 github，一个是 git
-- github 表示依赖源，告诉 Carthage 去哪里下载文件。依赖源之后跟上要下载的库，格式为 `Username/ProjectName`
-- git 关键字后面跟的是资料库的地址，可以是远程的 URL 地址，使用 `git://` `http://` `ssh://` 或者是本地资料库地址。
-
-
-
-### cartfile - dependency version
-
-告诉 Carthage 使用哪个版本，这是可选的。不指定的话，默认使用最新版本
-
-- `==1.0` 表示使用 `1.0` 版本
-- `>= 1.0` 表示使用 `1.0` 或更高的版本
-- `~> 1.0` 表示使用版本 `1.0` 以上，但是低于2.0的最新版本，例如：1.2， 1.6
-- branch 名称/ tag 名称/ commit 名称，意思是使用特定的分支/标签/提交。比如可以说分支名 master，也可以是 commit id： 5c8w72
-
-
-
-### 更新
-
-`carthage update` 但默认会编译4个平台（macOS、iOS、watchOS、tvOS） 会比较耗时，所以可以优化下，指定特定平台
-`carthage update --platform iOS`
-
-
-
-
-### 安装后生成的文件
-
-#### Cartfile.resolved
-该文件是生成后的依赖关系以及各个库的版本号，不能修改。
-该文件确保提交的项目可以使用完全相同的配置与方式运行启用。跟踪项目当前所用的依赖版本号，保持多端开发一致，出于这个原因。建议提交这个文件到版 本控制中。
-```
-github "Alamofire/Alamofire" "5.0.0-rc.3"
-github "onevcat/Kingfisher"
-github "SnapKit/SnapKit" ~> 5.0.0
-```
-
-#### Carthage 目录
-
-该目录包含2个子目录：
-- Checkouts 保存从 git 拉取的依赖库源文件
-- Build 包含编译后的文件，包含了4个平台(Mac、iOS、tvOS、watchOS)对应的 `.framework`
-
-```
-- Carthage
- - Build
- - Checkouts
-```
-
-
-
-### 项目配置
-
-`Target -> Build Setting -> Search Paths -> Framework Search Paths` 添加 `$(PROJECT_DIR)/Carthage/Build/iOS`
-
-此时可以正常编写代码，和使用库的 api，但项目运行会 crash，报错为：`dyld: Library not loaded: @rpath/SnapKit.framework/SnapKit Referenced from: ...`
-
-
-
-由于是非侵入式，所以需要程序员自己配置依赖，`Target -> Build Phases -> '+' -> New Run Script Phase`
-
-- 添加脚本 `/usr/local/bin/Carthage copy-frameworks`。
-- 添加 "Input Files" `$(SRCROOT)/Carthage/Build/iOS/Alamofire.framework` 等等
-
-## Swift Package Manager
-
-Swift Package Manager 是苹果推出的用于管理分发 swift 代码的工具，可以用于创建使用 swift 的库和可执行程序
-
-能够通过命令快速创建 library 或者可执行的 swift 程序，能够跨平台使用，是开发出来的项目能够运行在不同的平台上。
-
-
-### Xcode 集成
-
-Xcode 菜单栏：File -> Swift Packages -> Add Package Dependency...
-输入项目地址后，在弹出框 Rules 里选择版本策略。
-
-
diff --git a/Chapter1 - iOS/1.132.md b/Chapter1 - iOS/1.132.md
deleted file mode 100644
index 78f8dbf..0000000
--- a/Chapter1 - iOS/1.132.md
+++ /dev/null
@@ -1,518 +0,0 @@
-# 动态调试
-
-
-
-## Xcode 调试的原理
-
-Xcode 是电脑端的程序，Xcode 使用 LLDB 进行调试。真机连接 Xcode 运行起来，点击屏幕，对应的事件处理方法里加了断点。手机是如何与 Xcode 断点连接同步的呢？
-
-
-
-
-
-Xcode 编译器：GCC -> LLVM
-
-Xcode 调试器：GDB -> LLDB
-
-- `debugServer` 存放在：`/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/DeviceSupport/12.2/DeveloperDiskImage.dmg/usr/bin/debugserver`
-- 当 Xcode 识别到手机设备时，Xcode 会自动将 `debugserver` 安装到 iPhone 上。`/Developer/usr/bin/debugserver`
-- 一般情况下，Xcode 只可以调试通过 Xcode 安装的 App
-
-
-
-
-
-## 动态调试任意 App
-
-### 核心原因
-
-
-
-
-
-上面说了 `debugserver` 只能调试 Xcode 连接安装的程序。这句话不够严谨，Xcode 连接 iPhone 的时候，会自动将 `debugserver` 安装到 iPhone 上，但是权限会做收敛。具体表现就是权限 plist。
-
-所以我们可以自行修改权限，重新签名即可：
-
-- 将 `debugserver` 拷贝到电脑上
-
-- 利用 ` ldid -e debugserver > debugserver.entitlements` 命令导出权限文件
-
-- 打开 `debugserver.entitlements` 添加 `get-task-allow`、`task_for_pid-allow` 2个权限
-
- ```shell
-
-
- 
-
-
-
-### expression
-
-`expression 
-
-
-
-
-
-### 方法返回
-
-`thread return [
-
-### frame variable
-
-`frame variable [
-
-
-
-### 调试指令
-
-`thread continue`、`continue`、`c`：程序继续运行
-
-`thred step-over`、`next`、`n` ：单步运行，把字函数当作整体一步执行
-
-`thread step-in`、`step`、`s`：单步运行，遇到子函数会进入子函数
-
-`thread step-out`、`finish`：直接执行完当前函数的所有代码，返回到上一个函数
-
-`si` 、`ni` 和 `s` `n`：类似
-
-- `s` `n` 是源码级别
-
-- `si`、`ni` 是汇编指令级别
-
-
-
-### breakpoint
-
-设置断点的指令
-
-#### 函数名
-
-`breakpoint set -n "函数名"`，但可能存在多个断点，因为同样方法名称的方法，都会被设置断点
-
-比如 Person 类和 ViewController 类，都有 `- (NSInteger)add:(NSInteger)a withB:(NSInteger)b` 方法。` breakpoint set -n "add:withB:"` 指令设置了2个断点。
-
-
-
-
-
-当有多个方法同名的时候，只对当前类设置断点，指令格式为 `breakpoint set -n "[类名 方法名]"`。
-
-比如通过 `breakpoint set -n "[ViewController add:withB:]"` 对 ViewController 类的 `- (NSInteger)add:(NSInteger)a withB:(NSInteger)b` 方法设置断点
-
-
-
-如果一个方法没有参数，也可以通过 `breakpoint set -n sayHi` 的方式设置断点
-
-
-
-#### 函数地址
-
-在逆向，调试别人的 App 的时候我们无法知道函数名称，所以给函数地址打断点就很重要了。
-
-`breakpoint set -a 函数地址`。注意：函数地址是需要处理的，因为 iOS 有 `ASLR 技术`。
-
-
-
-#### 正则表达式
-
-`breakpoint set -r 正则表达式`，效果就是给所有函数名符合正则表达式的函数，设置断点。
-
-
-
-#### 动态库
-
-`breakpoint set -s 动态库 -n 函数名`
-
-
-
-#### 列出所有断点
-
-`breakpoint list` 用于列出所有的断点，每个断点都有自己的编号
-
-
-
-
-
-#### 断点的删除、禁用、开启
-
-`breakpoint disable 断点编号` ，比如 `breakpoint disable 2.1 2.2` 禁用了2个断点
-
-
-
-`breakpoint delete 断点编号`，比如 `breakpoint delete 2`。
-
-
-
-比较奇怪，断点开启、禁用是可以跟子序号的，比如2.1 2.2，而断点删除必须是一级序号
-
-
-
- #### 断点指令信息
-
-`breakpoint command add 断点编号`，该指令会给断点预先设置需要执行的命令，到触发断点时，就会按照指令添加的顺序执行。
-
-指令可以添加多个，最后以 "DONE" 结束。
-
-
-
-
-
-`breakpoint command list 断点编号` 用于查看该断点下的所有指令
-
-`breakpoint command delete 断点编号` 用于删除该断点下的所有指令
-
-
-
-
-
-
-
-
-
-### 内存断点
-
-在内存数据发生改变时触发
-
-`watchpoint set variable 变量`
-
-在 `viewDidLoad` 中 通过 `watchpoint set variable self->_age` 给 age property 设置了断点。当改变的时候就触发断点
-
-
-
-
-
-`watchpoint set expression 变量地址`
-
-在 `viewDidLoad` 中 通过 `watchpoint set expression 0x00007fcd20306a60` 给 age property 设置了断点。当改变的时候就触发断点
-
-
-
-
-
-`watchpoint list`
-
-`watchpoint disable 断点编号`
-
-`watchpoint enable 断点编号`
-
-`watchpoint disable 断点编号`
-
-`watchpoint delete 断点编号`
-
-`watchpoint command add 断点编号`
-
-`watchpoint command list 断点编号`
-
-`watchpoint command delete 断点编号`
-
-
-
-### image
-
-#### image list
-
-`image list` 列举所加载的模块信息
-
-
-
-
-
-`image list -o -f` 打印出模块的偏移地址、全路径
-
-
-
-#### image lookup
-
-`image lookup -t 类型`：查找某个类型的信息
-
-
-
-
-
-`image lookup -a 地址`：根据内存地址查找在模块中的位置
-
-举例：声明一个数组，只有5个元素，但通过下标6来访问数组的时候 crash 了，假设我们代码很长，crash 后想知道具体是哪一行代码造成了 crash，怎么办呢？
-
-我们项目叫做 Demo111，那么 crash 堆栈中第4行有个地址 `0x000000010d534dfc`，可以通过该地址来分析具体的 crash 位置。通过
-
-`image lookup -a 0x000000010d534dfc` 可以知道 `Summary: Demo111 -[ViewController touchesBegan:withEvent:] + 108 at ViewController.m:29:18` 是在 ViewController 的29行处发生了 crash。
-
-
-
-`image lookup -n 符号或者函数名`：查找某个符号或者函数的位置
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
diff --git a/Chapter1 - iOS/1.133.md b/Chapter1 - iOS/1.133.md
deleted file mode 100644
index 36b37c2..0000000
--- a/Chapter1 - iOS/1.133.md
+++ /dev/null
@@ -1,61 +0,0 @@
-# 编译器利用 PGO 优化 App 性能
-
-## 什么是 PGO？
-
-> Profile Guided Optimization (PGO) is an advanced feature for wringing every last bit of performance out of your app. It is not hard to use but requires some extra build steps and some care to collect good profile information. Depending on the nature of your app’s code, PGO may improve performance by 5 to 10 percent, but not all applications will benefit from it. If you have performance-sensitive code that needs that extra optimization, PGO may be able to help.
-
-PGO 即 Profile Guided Optimization，
-
-[Using Profile Guided Optimization](https://developer.apple.com/library/archive/documentation/DeveloperTools/Conceptual/xcode_profile_guided_optimization/pgo-using/pgo-using.html) 官方文档大概意思是：PGO 是一种根据运行时 profiling data 来进行优化的技术。用起来不难，但需要一些额外的构建步骤和一些收集良好的 profile 文件。如果一个 application 的使用方式没有什么特点，那么我们可以认为代码的调用没有什么倾向性。但实际上，我们操作一个 application 的时候，往往有一套固定流程，尤其在程序启动的时候，这个特点更加明显。采集这种“典型操作流”的 profiling data，然后让编译器根据这些 data 重新编译代码，就可以把运行时得到的知识，运用到编译期，从而获得一定的性能提升。然而，值得指出的一点是，这样获得的性能提升并不是十分明显，通常只有 5-10%。如果已经没有其他办法，再考虑试试 PGO。
-
-
-## 何时使用 PGO？
-正常情况下不用，通常来说 LLVM 经过编译前端，通过词法分析、语法分析、语义分析构建出 AST，然后转换为 IR，IR 经过一些列优化 Pass，常见的 Pass 比如死代码消除等，LLVM 已经做了大量的优化工作。所以通常来说，我们需要正向的优化代码、优化算法、设计正确合理的架构、合理的 UI 层级。除此之外，你还想让 App 获得更好的性能，可以考虑采用 PGO 技术。
-
-## PGO 怎么样工作的？
-PGO 假设你的应用程序的行为是可预测的，这样一个有代表性的配置文件就可以捕捉代码所有性能敏感方面的未来行为。当启用 PGO 时，Xcode 会构建一个专门检测的应用程序版本，然后运行它。您可以手动运行该应用程序，也可以使用 UI 自动化 XCTest 测试 App。当应用程序运行时，会统计并记录每条语句的执行次数。
-
-应该收集一份具有典型、能够代表 App 真正用户行为的 profile 数据，PGO 统计每个语句的执行次数，并创建一个为该行为建模的概要文件。依据该文件，LLVM 编译器将优化工作集中在最重要的代码上。
-
-举个例子：有一个稍微长一点的函数，刚好长到编译器不对它的调用进行 inline 优化，但是实际上，这个函数是一个热点调用，在运行时被调用的次数非常多。那么如果此时编译器也能帮我们把它优化掉，是不是很好呢？但是，编译器怎么能知道这个“稍微长一点的函数”是一个热点调用呢？PGO 根据这个 profile 文件进行优化
-
-是一种优化编译器的技术，通过收集程序的实际运行数据，例如程序执行的分支情况，来指导编译器生成更优化的代码。
-
-
-## tips
-首先，Xcode 已经提供了 PGO 的 UI 操作（[详情可参考](https://developer.apple.com/library/archive/documentation/DeveloperTools/Conceptual/xcode_profile_guided_optimization/Introduction/Introduction.html#//apple_ref/doc/uid/TP40014459-CH1-SW1)），所以如果是简单的 application，可以直接使用 UI 操作的方式，简单省事。不过，UI 操作有一些缺陷，具体表现在：
-
-- 控制粒度粗糙，要么不打开 PGO，要么对所有 code 进行 PGO。如果项目中有 swift 代码，那么这种方式就不能用了，因为 swift 不支持 PGO；
-- 只支持两种方式采集 profiling data。第一种是每次手动运行，运行结束后退出 application，Xcode 会产生一个 xxx.profdata，之后的编译，都会用这个文件，来进行优化；如果代码发生变更，Xcode 会提示 profdata file out of date。第二种方法是借助 XCTest 来采集 profiling data，这种方法提供了一定的 automation 能力，但是另一方面也限制了 automation team 的手脚，他们可能在使用另一些更好用的工具而不是 XCTest。
-
-因为 PGO 优化是靠的 Profile 文件，所以每次代码变化后需要保证生成最新的 Profile 文件。
-随着继续开发和更改应用项目中的代码，优化配置文件会过时。LLVM 编译器会识别出配置文件何时不再与应用程序的当前状态良好匹配，并提供警告。当收到此警告时，可以再次使用 Generate Optimization Profile 命令来创建更新的配置文件。每次重新生成优化配置文件时，Xcode 都会替换现有的配置文件数据。
-
-这个很难办，所以需要利用 CI 手段，可以借助 `-fprofile-instr-generate` 和 `-fprofile-instr-use` 这两个 Clang 提供的编译选项搭配 CI。
-
-## LLVM 利用 PGO 大概怎么优化代码
-
-LLVM利用PGO（Profile-Guided Optimization）可以实现多种优化，其中一些主要优化包括：
-- 函数内联（Function Inlining）：PGO可以根据实际运行时的函数调用情况，选择性地内联函数，减少函数调用的开销，提高程序执行效率。
-- 循环展开（Loop Unrolling）：通过分析循环执行次数和循环体内的代码，PGO可以决定是否展开循环，减少循环控制开销，提高循环执行效率。
-- 代码重排（Code Reordering）：根据实际运行时的代码执行路径，PGO可以优化代码的布局顺序，使得频繁执行的代码更容易被CPU缓存命中，提高程序的局部性和性能。
-- 分支优化（Branch Optimization）：PGO可以根据实际运行时的分支预测情况，优化分支指令，减少分支预测错误，提高程序的执行效率。
-- 常量传播（Constant Propagation）：根据实际运行时的数据流分析，PGO可以更好地进行常量传播，减少不必要的变量存储和加载操作，提高程序的执行效率。
-- 内存访问优化（Memory Access Optimization）：PGO可以根据实际运行时的内存访问模式，优化内存访问方式，减少内存访问延迟，提高程序的内存访问效率。
-通过这些优化手段，PGO可以根据实际运行时的数据和行为模式，生成更加针对性和高效的优化代码，从而提高程序的性能和执行效率
-
-
-## PGO 和二进制重排的异同
-PGO 是一个编译器特性，能够过程序实际执行的方法进行打点统计，找出最常执行的代码路径（热点函数），并根据这些信息对程序进行优化，这种优化包括重排代码已减少分支预测错误、优化内存使用以提高缓存命中率、函数内联、分支优化等等，这是一种动态优化技术，会根据实际程序运行收集到的 profile 信息做改变。
-
-二进制重排则是程序编译完成后，对二进制代码进行优化的技术，主要要解决的是内存缺页异常的问题，可以减少缓存的错失率。这是一种静态优化技术，因为它不需要实际运行程序就能进行。
-
-
-## 为什么我的App需要重排的符号个数这么少
-二进制重排主要通过调整二进制文件中的代码顺序，以改善性能。以 iOS 举例，App 启动慢的一个原因就是 App 启动过程中用到的函数方法、可能排布在不同的 page 上，所以由于不断的切换 page，导致启动慢。App 发生大量「内存缺页」的时机就是 App 刚启动的时候。所以优化手段就是「将影响 App 启动的方法集中处理，放到某一页或者某几页」（虚拟内存中的页）。Xcode 工程允许开发者指定 「Order File」，可以「按照文件中的方法顺序去加载」，可以查看 linkMap 文件（需要在 Xcode 中的 「Buiild Settings」中设置 Order File、Write Link Map Files 参数）。
-
-然而，虽然理论上所有的代码都可以进行重排，但实际上，根据应用程序的特性，可能只有一部分代码是频繁执行的，也就是所谓的"热点"代码。这部分代码会被优先考虑进行重排，因为这样可以最大化性能提升。
-
-另外，重排过程需要考虑到许多限制和约束，如符号之间的依赖关系，这可能会限制哪些符号可以移动和重新排序。如果一些符号因为它们之间的关系而不能被移动，那么这些符号就不会被考虑在重排中。
-
-因此，你看到的"需要重排的符号个数"相对较少，可能是因为只有这些符号是被识别出来的"热点"代码，或者它们是唯一可以在不违反任何约束和限制的情况下被移动的符号
\ No newline at end of file
diff --git a/Chapter1 - iOS/1.134.md b/Chapter1 - iOS/1.134.md
deleted file mode 100644
index c67c067..0000000
--- a/Chapter1 - iOS/1.134.md
+++ /dev/null
@@ -1,69 +0,0 @@
-# 去除无用代码
-
-通用方案
-Mach—O
-
-__DATA ， __objc_selrefs 标记方法被调用信息
-
-otools -v -s _DATA _objc_selrefs Mach-O
-
-
-linkmap - selfrefs = 无用方法
-
-问题：不准（OC 语言，动态性）
-
-
-## clang plugin
-
-重载
-RecursiveASTVistor::visitDecl
-RecursiveASTVistor::visitStmt
-
-上线前，通过静态方式去查找。不安全、不全面
-
-
-## 运行时查找
-Code Coverage
-clang -fprofile-instr-generate -fcoverafe-mapping a.m -o a
-swiftc -profile-generate -peofile-coverage-mapping a.swift
-
-
-缺点：难以定制
-
-## Fuzzing 方案
-
-## Sanitizee Coverage
-缺点： 编译慢、且无法进一步定制，包体积负向影响
-
-## 自定义 llvm Pass
-
-针对 LLVM IR 进行处理。
-
-低级别编程语言，类似 RISC 指令集。和高级语言对应，LLVM 利用一些列 Pass 对 IR 进行优化。
-
-LLVM 的优化是由 Pass 完成的，每个 Pass 完成特定的优化
-自己开发 Pass 是独立的，不会影响 LLVM 的结构
-Pass 之间可以有关联，也可分租
-
-LLVM 有c/c++ 接口，还可以用 c/Swift 编写 Pass
-
-c 接口较稳定，C++ 接口更新较新
-
-
-LLVM 内置 Pass
-memcpyopt： memset 指令替换 memcpy
-always_inline: 总是内联用 alwaysinline 修饰的函数
-dce：死代码消除
-loop_deletion:删除未使用的循环
-
-
-Pass 生成：
-静态：在 LLVM 工程中设置 CMake，重新构建 opt
-动态：opt 用 `-load-pass-plugin` 选项加载
-
-怎么写 Pass？
-对 IR 分析，继承 AnalysisInfoMixin
-对 IR 转换，继承 PassInfoMixin
-
-
-
diff --git a/Chapter1 - iOS/1.135.md b/Chapter1 - iOS/1.135.md
deleted file mode 100644
index e92530c..0000000
--- a/Chapter1 - iOS/1.135.md
+++ /dev/null
@@ -1,234 +0,0 @@
-# 框架设计
-
-
-
-## 图片框架
-
-### 角色
-
-- Manager
- - 内存
- - 磁盘
- - 网络
-- Code Manager
- - 图片解码
- - 图片压缩/解压缩
-
-
-
-### 图片读写过程
-
-- 以图片 url 的 hash 值为 key，存储
-
-
-
-### 读取过程
-
-
-
-
-
-### 内存设计
-
-- 内存存储的空间
-
- - 10kb 以下，使用场景多，设计50张容量
- - 100kb 以下，使用场景次之，设计20张容量
- - 100kb 以上，使用场景最小，设计10张容量
-
-- 淘汰策略
-
- 队列实现，先进先出。
-
-
-
-### 淘汰策略
-
-LRU，最近最久未使用算法。比如3天内没有使用过的，则认为需要被淘汰。
-
-
-
-### 淘汰时机
-
-- 定时检查，比如 30分钟检查一次
-
-- 提高检查频率：
-
- - 每次进行图片读写时
- - 前后台切换时
-
-
-
-### 磁盘设计
-
-- 存储方式
-- 大小限制（如200MB）
-- 淘汰策略：如果某一张图片存储时间距今已经超过7天
-
-
-
-### 网络设计
-
-- 图片请求的最大并发量
-- 请求超时策略。超时重试1次，再次超时则取消
-- 请求优先级
-
-
-
-### 图片解码
-
-对于不同格式的图片，图片解码怎么处理？
-
-应用**策略模式**，对不同图片格式进行解码。一方面可以解码不同格式、另一个方面替换解码算法，对于稳定性有帮助
-
-在哪个阶段进行解码？
-
-磁盘读取后、网络请求返回后
-
-
-
-### 线程处理
-
-
-
-## 阅读时长记录器
-
-
-
-### 记录器种类
-
-- 页面式：普通的 push、pop 页面
-- feed 流式：类似 weibo 这种 feed 流式的记录
-- 自定义式：可拓展性的体现，面向未来
-
-
-
-QA：为什么要有不同类型的记录器？
-
-- 基于不同分类场景提供的关于记录的封装、适配
--
-
-### 记录数据存储
-
-- 内存缓存
-- 磁盘存储
-
-
-
-### 准确性
-
-数据收集（存储）、上报（移除）2个核心流程。准确性也和这2个方面息息相关。
-
-- 定时写磁盘 从内存中 flush 到本地磁盘。定时器1分钟 flush 一次
-- 限定内存缓存条数。超过该条数，即写磁盘。内存记录每满10条 flush 一次
-
-
-
-### 上传策略
-
-思考：
-
-- 需要立马上传吗？每收集到1次页面阅读时长就需要立马上传1次吗？ROI 衡量。性能、线程数
-- 关于延时上传的场景有哪些？
-
-
-
-上传时机：
-
-- 定时器，比如每5分钟上传1次。
-- 前后台切换，比如从后台切换到前台触发1次上传逻辑
-- 无网切换到有网
-
-
-
-### 网络上传效率
-
-自定义报文，高效传输。
-
-iOS 小端序，网络大端序。
-
-
-
-
-
-## 复杂页面架构设计
-
-- MVVM
-
-- Redux 数据流
-
-
-
-## 客户端架构
-
-
-
-## 业务之间解耦后的通信方式
-
-- openURL
-- 依赖注入：中间层
-
-
-
-## AFNetworking
-
-### 主要类关系图
-
-
-
-
-
- ### AFURLSessionManager
-
-- 创建和管理 NSURLSession、NSURLSessionTask
-- 实现 NSURLSessionDelegate 协议代理方法，处理网络请求的重定向、认证、网络数据的处理
-- 引入 AFSecurityPolicy，用来保证请求安全
-- 引入 AFNetworkReachabilityManager 监控网络状态
-
-
-
-## SDWebImage
-
-### 架构图
-
-
-
-
-
-## 图片加载流程
-
-- 查找内存缓存
-- 查找磁盘缓存
-- 网络下载图片并磁盘缓存
-
-
-
-## AsyncDisplayKit
-
-### 主要处理问题
-
-主要通过减轻主线程压力，尽量将一些可以放到子线程的任务都放到子线程处理，减轻主线程压力
-
-主要分3方面：
-
-- UI 布局 layout：文本宽高计算、视图布局计算
-- 渲染 Rendering：文本渲染、图片解码、图形绘制
-- UIKit Objects：对象创建、调整、销毁
-
-
-
-### 基本原理
-
-
-
-- UIView 作为 CALayer 的代理实现。CALayer 作为 UIView 的实例变量，负责展示规工作。
-
-- 针对 UIView 的修改，都抽象为针对 ASNode 的修改，这些修改可以在子线程进行。针对 ASNode 的修改和提交，会对其进行封装，提交到一个全局容器中。
-- 对 Runloop 状态进行监听，进入休眠前，ASDK 执行该 loop 内提交的所有任务。
-
-
-
-
-
-
-
diff --git a/Chapter1 - iOS/1.136.md b/Chapter1 - iOS/1.136.md
deleted file mode 100644
index 9ccb5c9..0000000
--- a/Chapter1 - iOS/1.136.md
+++ /dev/null
@@ -1,380 +0,0 @@
-# 工程化
-
-## 多环境配置
-Project、Target、Scheme 主要管理什么？
-- Project：包含了项目所有的代码、资源文件，所有信息
-- Scheme：对于指定 Target 的环境配置
-- Target：对于指定代码和资源文件的具体构建方式
-
-多环境配置的3种方式：
-- 多 target 配置
-- Scheme 多 target 进行环境配置
-- xconfig 文件配置
-
-
-
-## 多环境配置的不同方式
-
-### 多 Target 的方式
-
-#### 方案
-
-针对需要多配置的项目，在 Xcode 中，对其进行复制，存在多个 Target。 **多 Target（Targets）** 是管理不同应用变体（如免费版/付费版、测试版/生产版、多客户定制版）的高效方式。
-
-所以，**为了区分不同的环境，做一些逻辑的控制。所以需要搭配不同的宏定义，来实现控制逻辑的效果。**
-
-注意：duplicate 之后，target 虽然多了一份，但是代码和资源不变
-
-
-
-#### 关键步骤
-
-
-
-
-
-
-
-##### 管理配置文件
-
-1. **独立的 Info.plist**
-
- - 复制原 `Info.plist` 并重命名（如 `Pro-Info.plist`）
-
- 当对某个 Target “Duplicate” 之后，会产生一份新的 plist 文件
-
- 
-
- - 在新 Target 的 `Build Settings` → `Packaging` → `Info.plist File` 指定新路径
-
-2. **环境配置分离**
-
- - 创建 `Config-Pro.xcconfig` 文件定义专属配置：
-
- ```shell
- // Config-Pro.xcconfig
- API_URL = https://api.pro.com
- APP_NAME = Pro App
- ```
-
- - 在 Target 的 `Build Settings` → `Base Configuration` 指定配置文件
-
-
-
-##### 宏定义
-
-- OC：Build Settings -> Preprocessor Macros 里面的 Debug/Release 模式下添加自定义宏。比如在 debug 模式下 `IsOCDebug = 1`
-- Swift：Build Settings -> Other Swift Flags 里的 Debug/Release 模式下添加自宏定义。注意命名有格式要求：`-D + 宏名称`
-
-
-
-#### 思考
-
-该方式还是存在弊端：
-
-- 工程存在多份 info.plist（实际上 plist 文件很少改动，所以没有这种需求）
-- 配置比较零散、比较乱
-
-
-
-### 多 Scheme 的方式
-
-#### 方案
-
-针对多 Target 方案存在的问题，可以用**「多 Scheme + 多 Configuration 」**的方式解决。
-
-
-
-#### 关键步骤
-
-##### 创建 Configuration
-
-针对一个 Target 可以添加多个 **Configuration**，步骤如下:
-
-先选中 Project，然后在右侧选择 Info 选项卡，在 Configurations Section ，点击 "+" ，即可创建新的 Configuration。
-
-
-
-
-
-创建好之后，该 Target 存在3份 Configuration 了。不同的 Configuration 有什么作用呢？设置宏定义的时候可以针对不同的 Configuration 进行设置。
-
-
-
-
-
-针对 OC、Swift 分别设置了很多宏定义，接下去需要跑 Beta 配置的代码，怎么办？
-
-
-
-点击 Edit Scheme，在 Run 里面选择对应的 Configuration。
-
-但这样好像蛮烦的，每次运行不同配置的代码，都需要手动切换 Configuration。有没有什么办法解决切换问题呢。
-
-
-
-##### 创建实体 Scheme
-
-创建 Scheme 步骤：Xcode -> New Scheme，再弹出的方框内，选择对应的 Target，然后输入需要创建的 Scheme 名称。此次我们创建了：Debug、Beta 2个新的 Scheme。
-
-
-
-
-
-创建好之后，可以看到实体 Configuration 和虚拟 Scheme 存在多对多的关系。但我们可以基于此，选择实体的 Scheme，然后在 Run 里面 “Build Configuration” 里面选择对应的 Configuration 与之对应。
-
-
-
-
-
-##### plist 暴露自定义字段
-
-1. 创建之后就可以根据 Configuration 设置值，在 `Build Settings -> User-Defined` 下添加自定义的字段，同时可以根据 Configuration 设置不同的值。
-2. 设置后的值怎么使用？将自定义的变量用 plist 存储。之后读取再使用。
-
-完整如下图：
-
-
-
-切换不同的 Scheme，可以运行不同的效果，当前 case 下，选择 Debug Scheme，输出不同结果 `HOST_URL: http://www.debug.baidu.com`
-
-
-
-#### 思考
-
-目前的方案已经优雅不少，该方式还是存在弊端：自定义宏的时候需要选择不同的 Scheme，过程繁琐
-
-
-
-### Xcconfig
-
-#### 方案
-
-使用过 CocoaPods 的都会留意到工程存在 `*.Pro.xcconfig` 文件。里面是一些工程相关的配置。所以我们也可以用该方式处理工程问题。
-
-
-
-#### 关键步骤
-
-Xcode 自带的 Configuration Settings File 可以支持自定义一些宏，还可以修改 Build Settings 里面的选项。
-
-第一：创建步骤如下：
-
-
-
-文件命名为：`文件夹名称-项目名称.scheme名称.xcconfig`，比如 `Config-Xcconfig.debug.xcconfig`
-
-几个 Scheme 就创建几个对应的 Xcconfig 文件。
-
-
-
-第二：修改和完善创建的 Xcconfig 配置文件里的内容。之后在 Xcode 的 Project 选项下，找到 Configurations，选择对应的 Target，然后选择右边对应的 Xcconfig 文件。如下图
-
-
-
-
-
-我们只在 `Config-Xcconfig.debug.xcconfig` 文件中添加了 `OTHER_LDFLAGS = -framework "AFNetworking"`，Xcode 切换到 debug scheme 下，然后 Command + B 编译。
-
-
-
-验证结果：
-
-- 编译前切换到 Build Settings 后，查看 ”Other Linker Flags“ 的 Debug 项为空
-- 编译后切换到 Build Settings 后，查看 ”Other Linker Flags“ 的 Debug 项为 `-framework ”AFNetworking“`
-
-因为 Xcconfig 文件，具有操作和修改 Build Settings 的能力，所以用好 Xcconfig 文件，不只可以实现替代宏定义和切换繁琐的问题，还可以实现很多其他手动修改 Build Settings 的问题。
-
-
-
-说明：在 Xcode Build Settings 手动配置的信息，和通过 Xcconfig 方式编写的信息，不会冲突。
-
-对于 xcconfig 文件，我们其实并不陌生、因为在使用 Cocoapods 的时候就已经在使用这个文件了，只是很多人不知道其中变量的含义。
-
-
-
-#### 注意
-
-在 `.xcconfig` 里添加的内容，根据使用场景的不同，细节存在差异：
-
-1. 仅编译时使用（无需 plist 声明）：**不需要在 plist 中声明 `HOST_URL`，值会直接注入编译环境**
-
-2. 运行时通过 Info.plist 访问（需 plist 声明）：
-
- - 在 `.xcconfig` 文件里添加了：`HOST_URL=127.0.0.1`
- - 在 plist 中需要加一栏：key 为 `HOST_URL`，value为 `${HOST_URL}`
-
- 
-
- - 代码中使用
-
- ```swift
- let host = Bundle.main.object(forInfoDictionaryKey: "ServerHost") as! String
- let apiKey = Bundle.main.object(forInfoDictionaryKey: "ApiSecretKey") as! String
- print("Host: \(host), API Key: \(apiKey)")
- ```
-
-
-
-QA：思考一个问题：为什么在 `xcconfig` 文件中设置的值，最后会显示在 Xcode 的 Build Settings 的 GUI 面板上？
-
-这便是接下去的内容：「Xcode 配置的层级机制」
-
-
-
-## Xcode 配置的层级机制
-
-### 层级机制
-
-Xcode 的 Build Settings 是一个**多层叠加系统**，优先级从高到低如下：
-
-**Target 设置 > Project 设置 > .xcconfig 文件 > Xcode 默认值**
-
-Apple 在 [Build Settings Reference](https://help.apple.com/xcode/mac/current/#/itcaec37c2a6) 中明确说明：
-
-> **继承规则**：
->
-> - Target 设置继承 Project 设置，Project 设置继承底层默认值。
-> - 若 Target 显式定义某配置项，则覆盖 Project 中的相同项16。
-
-**关键推论**：
-
-> Target 作为具体构建目标，其配置需独立于 Project 的通用设置。若二者冲突，**Target 优先级更高**。
-
-根据 [Xcode Build System Guide](https://developer.apple.com/library/archive/documentation/DeveloperTools/Conceptual/XcodeBuildSystem/)：
-
-> - `.xcconfig` 是**基础配置层**，通过 `baseConfigurationReference` 字段被 Project/Target 引用23。
-> - 若 Project 或 Target 显式设置了某值（即使为空），**将覆盖 .xcconfig 中的定义**24。
-
-
-
-典型案例：当 `project.pbxproj` 中定义 `OTHER_LDFLAGS = ""`（空字符串）时，它会覆盖 `.xcconfig` 中的非空值，导致链接标志失效
-
-说明： xcconfig 优先级低于前2者。
-
-结论：配置的优先级顺序为：**Target 设置 > Project 设置 > .xcconfig 文件 > Xcode 默认值**
-
-
-
-### 为什么 xcconfig 的结果会显示在 Build Settings 中
-
-1. **配置文件的显式声明**
- `.xcconfig` 文件是 Build Settings 的合法数据源。通过以下方式关联：
-
- ```
- OTHER_LDFLAGS = -framework "AFNetworking"
- ```
-
- Xcode 会将其视为项目配置的一部分，并在 GUI 中显示。
-
-2. **Build Settings 的“继承”特性**
- Xcode 的 Build Settings 界面本质是一个**实时计算的合并视图**，它会展示：
-
- - 所有直接通过 GUI 设置的值
- - 从 `.xcconfig` 导入的值
- - 继承的默认值（如 `$(inherited)`）
-
-3. 如果使用 CocoaPods 安装的依赖，则会生成2个 CocoaPods 生成的 `.xcconfig` 文件。如果开发者自己再创建 `.xcconfig` 则需要处理2者的逻辑，因为 Xcode 一个工程只可以选择一个 `.xcconfig` 文件
-
-
-
-### Xcode Project Management Guide
-
-这份[文档](https://developer.apple.com/library/archive/documentation/DeveloperTools/Conceptual/XcodeBuildSystem/000-Introduction/Introduction.html#//apple_ref/doc/uid/TP40006904-CH1-SW1)深入讲解了 Xcode 项目结构、Build Settings 的继承关系、环境变量（如 `$(SRCROOT)`）等，适合想系统理解设置机制的人
-
-聊起工程化，不得不查看 CocoaPods 的 [Podfile 配置指南](https://guides.cocoapods.org/syntax/podfile.html)
-
-
-
-### 实践验证
-
-#### Demo1
-
-第一步：新建 Xcode iOS 工程。
-
-第二步：新建的工程配置了一份基础的 `Base.xcconfig` 来配置基础的编译信息。`Dev.xcconfig` 包含 `Base.xcconfig` 信息，在此基础上增加了一些编译参数。
-
-`Base.xcconfig` 配置如下：
-
-```shell
-BASE_LD_CONFIG = -framework "WantUIKit"
-OTHER_LDFLAGS = $(BASE_LD_CONFIG)
-```
-
-`Dev.xcconfig` 配置如下：
-
-```shell
-#include "Base.xcconfig"
-TEMP_LDFLAGS = $(BASE_LDFLAGS) -framework "AFNetworking" -framework "SDWebImage" -framework "PrismClient"
-OTHER_LDFLAGS = $(TEMP_LDFLAGS)
-```
-
-
-
-第三步：
-
-- 当前 xcconfig 是为 Dev 模式下设置的。所以项目的 scheme 选择 `Debug` 模式。
-- 选中 `PROJECT`，然后在 `Configurations` 下给 `Debug` 配置 `Dev.xcconfig` 文件。
-
-
-
-结果：编译工程，可以看到报错了。符合预期
-
-
-
-原因：本 Demo 的目的就是通过 `xcconfig` 文件和继承关系来验证对 Xcode Build Settings 中的 `Other Linker Flags` GUI 面板来验证 xcconfig 及其层级关系会正确影响到最终的编译参数上。
-
-注意：为什么不用 `$(inherited)`？
-
-`$(inherited)` 的作用范围：
-
-- 仅继承来自 **Xcode 构建系统层级**的值（Target 设置 → Project 设置）
-- 不继承 **同一配置文件链** 中通过 `#include` 引入的值
-
-所以此时用**中间变量**的方法。
-
-
-
-#### Demo2
-
-验证 `$(inherited)` 的继承效果。
-
-第一步：创建工程，配置 Podfile 文件。Podfile 文件内容如下
-
-```shell
-source 'https://mirrors.tuna.tsinghua.edu.cn/git/CocoaPods/Specs.git' # 清华源
-
-platform :ios, '16.2'
-inhibit_all_warnings! # 屏蔽第三方库警告
-
-target 'LDExploreDemo' do
- # Pods for InstallDyanmicAndStaticFramework
- pod 'SDWebImage'
- pod 'AFNetworking'
-end
-```
-
-第二步：`pod install` 后，可以看到自动生成的 xcconfig 文件内容如下。
-
-为了测试 xcconfig 配置信息的继承，故意把生成的原始信息注释掉。去掉了 `-framework "ImageIO"`
-
-
-
-第三步：创建 `Base.xcconfig` 文件。引入 Cocoapods 自动生成的 `Pods-LDExploreDemo.debug.xcconfig` 然后声明 `OTHER_LDFLAGS = $(inherited) -framework "ImageIO"`由2部分组成，一部分是 `$(inherited)` 一部分是新加的 `-framework "ImageIO"`
-
-第三步：创建 `Dev.xcconfig` 文件。引入第三步创建的 `Base.xcconfig` 文件。声明 `OTHER_LDFLAGS = $(inherited)` 为继承来的配置。
-
-第四步：项目的 `AppDelete.m` 中引入 `#import 
-
-说明：
-
-- Cocoapods install 后，自动创建链接器所需参数。都在 `Pods-项目名.debug.xcconfig` 配置文件中
-- 我们可以自己创建的 `*.xcconfig` 是可以引入自动生成的配置文件的。并在此基础上可以修改。然后在 Xcode Project Configuration 里可以指定为新创建的 xcconfig 文件
-- 并且是可以生效的
diff --git a/Chapter1 - iOS/1.137.md b/Chapter1 - iOS/1.137.md
deleted file mode 100644
index fd3626d..0000000
--- a/Chapter1 - iOS/1.137.md
+++ /dev/null
@@ -1,143 +0,0 @@
-# 质量检测
-
-## 静态检测
-### 概念
-
-静态分析器是一个 Xcode 内置的工具，使用它可以在不运行源代码的状态下进行静态的代码分析，并且找出其中的 Bug，为 app 提供质量保证。
-
-静态分析器工作的时候并不会动态地执行你的代码，它只是进行静态分析，因此它甚至会去分析代码中没有被常规的测试用例覆盖到的代码执行路径。
-
-静态分析器只支持 C/C++/Objective-C 语言，因为静态分析器隶属于 Clang 体系中。不过即便如此，它对于 Objective-C 和 Swift 混编的工程也可以很好地支持。
-
-其中包括了安全、逻辑、以及 API 方面的问题。分析器可以帮你找到以上的这些问题，并且解释原因以及指出代码的执行路径。
-
-
-
-
-### 原理
-
-- 通过语法树进行代码静态分析，找出非语法性错误
-- 模拟代码执行路径，分析出 control-flow graph（CFG）
-- 预置了常用的 checker
-
-一个大型项目代码行数非常多，所有跑完全部的 CFG 必定很耗时。
-
-
-
-### 如何使用
-
-Xcode 静态分析功能是在程序未运行的情况下，对代码的上下文语义、语法、和内存情况进行分析，可以检测出代码潜在的文本本地化问题（Localizability Issue）、逻辑问题（Logic error）、内存问题（Memery error）、数据问题（Dead store）和语法问题（Core Foundation/Objective-C）等。
-功能入口在： `菜单栏 -> Product -> Analyze`。可以使用快捷键：Command+Shift+B
-
-#### 文本国际化
-
-Xcode Target -> Build Settings -> Static Analysis - Issues - Apple APIs -> Miss Localizablity 设置为 YES。可以帮助检测发现，缺少国际化的文本。
-
-
-提示说明 `User-facing text should use localized string macro` 缺少本地化的 API，正确的采用下面一行的写法。
-
-#### 逻辑问题
-
-分母不能为0.
-
-
-
-#### 内存问题
-
-虽然 Xcode 默认使用 ARC 管理内存，但是某些 C API 还需要开发者自己进行内存管理。比如 CF 框架下的 API。
-以及 block nil 判断等。
-
-
-
-
-
-#### 数据问题
-
-在编码过程中，一些数据问题可以通过Analyze很好的提示出来。比如下图：
-
-
-
-
-
-#### Xcode 13 新增的检查项
-
-在 Xcode 13 中，静态分析器也得以升级，现在它可以捕获更多的一些逻辑问题：
-
-1. 断言 Assert 的副作用
-2. 死循环
-3. 无用的冗余代码（例如多余的分支条件）
-4. C++ 中 move 和 forward 的滥用导致的潜在问题
-
-一部分的改进来自于开源作者们对 Apple Clang 编译器的贡献。
-
-
-
-##### NSAssert 中的副作用
-
-使用 NSAssert 规避非预期的代码逻辑是很常见的好习惯，但是不规范地使用也会带来一些副作用，例如在 NSAssert 的判断条件中对变量或内存进行修改操作。
-
-本来 `self.count` 默认为0，经过 `mockAssertIssue` 方法中，赋值为1，然后写了 NSAssert 是为了增加健壮性，但这个断言有副作用，虽然判断了赋值后是1，再自增判断等于2，但这不符合预期。经过断言已经修改为2了。
-
-
-
-
-
-##### 死循环
-
-下面是一个很常见的死循环的案例，这种稍微复杂一些的逻辑，乍眼一看，似乎没有什么问题：
-
-
-
-这段代码中，是一个二层循环，但是在内层的循环中，没有对 j 做递增，而是做了 result 的递增，这个问题虽然会隐晦，但是新版本的静态检查器会检测出来。
-
-
-
-Analyze 功能强大，其实际能检测出的问题会更多。
-
-
-
-### 自定义分析器参数
-
-Xcode 也为静态分析器提供了很多的自定义项，方便开发者根据自身工作流进行定制。在 BuildSetting 中通过搜索 `Static Analysis` 关键字，可以筛选出跟分析器相关的设置项。
-
-
-
-### 每一次编译都执行静态分析
-
-通过打开 `Analyze During 'Build'` 可以使得每一次编译操作都执行分析器：
-
-
-
-### 设置静态分析器的运行模式
-
-`Mode of Analysis for 'Analyze'` 可以配置分析器运行的模式，Xcode 提供了两种运行模式：
-
-- `Shallow(faster)` ：`Shallow`规避了去检查一些耗时复杂的检查操作，所以 Shallow 运行的更快
-- `Deep` 则进行深入的检查，能抛出更全面的错误
-
-同一个工程，分别看看 Shallow 和 Deep 的耗时差别：
-
-
-
-
-
-### 专项检查配置
-
-静态分析器也提供了一些专项检查的配置，可以根据工程情况定制选择。假设，项目有严格的安全检查，可以打开下图中选中的这些配置项目：
-
-
-
-
-
-再或者，如果静态分析器抛出的一些问题不想关注，可以在 Xcode Build Settings 中关闭掉。从而更聚焦于感兴趣、更关注的问题。
-
-
-
-### 单个文件的分析
-
-也可以针对单个文件做静态检查。操作路径为：Product -> Perform Action -> Analyze "FileName"。
-
-这样只会对单个文件检测，且不会分析 import 进来的文件（可以看到右边的 Person.m 的问题没有被检测出来）
-
-
-
diff --git a/Chapter1 - iOS/1.138.md b/Chapter1 - iOS/1.138.md
deleted file mode 100644
index 91ecf2d..0000000
--- a/Chapter1 - iOS/1.138.md
+++ /dev/null
@@ -1,131 +0,0 @@
-# AFNetworking 源码解读
-
-
-
-## 结构
-
-核心包含5个功能模块：
-
-- 网络通信模块(AFURLSessionManager、AFHTTPSessionManger)
-- 网络状态监听模块(Reachability)
-- 网络通信安全策略模块(Security)
-- 网络通信信息序列化/反序列化模块(Serialization)
-- 对于iOS UIKit库的扩展(UIKit)
-
-AF 是基于 NSURLSession 来封装的，所以核心类 AFURLSessionManager 也是针对 NSURLSession 做的封装，其余的4个模块，是为了网络通信（请求、响应数据的序列化、HTTPS 安全认证、UIKit 推展）
-
-
-
-其中 AFHTTPSessionManager 继承自 AFURLSessionManager，一般的网络请求都是用这个类，但是该类本身没有处理实际的网络，而是做了一些封装，把请求逻辑分发给父类 AFURLSessionManager 或者其他类去做。
-
-
-
-## 以 get 请求为例
-
-```objective-c
-AFHTTPSessionManager *manager = [[AFHTTPSessionManager alloc]init];
-
-[manager GET:@"https://somehost.com/goods" parameters:nil progress:nil success:^(NSURLSessionDataTask * _Nonnull task, id _Nullable responseObject) {
-
-} failure:^(NSURLSessionDataTask * _Nullable task, NSError * _Nonnull error) {
-
-}];
-```
-
-调用初始化方法生成一个 manager，去看看具体做了什么
-
-```objective-c
-- (instancetype)init {
- return [self initWithBaseURL:nil];
-}
-
-- (instancetype)initWithBaseURL:(NSURL *)url {
- return [self initWithBaseURL:url sessionConfiguration:nil];
-}
-
-- (instancetype)initWithSessionConfiguration:(NSURLSessionConfiguration *)configuration {
- return [self initWithBaseURL:nil sessionConfiguration:configuration];
-}
-
-- (instancetype)initWithBaseURL:(NSURL *)url
- sessionConfiguration:(NSURLSessionConfiguration *)configuration
-{
- self = [super initWithSessionConfiguration:configuration];
- if (!self) {
- return nil;
- }
- // 对传过来的 BaseUrl 进行处理，如果有值且最后不包含/，url加上"/"
- if ([[url path] length] > 0 && ![[url absoluteString] hasSuffix:@"/"]) {
- url = [url URLByAppendingPathComponent:@""];
- }
-
- self.baseURL = url;
-
- self.requestSerializer = [AFHTTPRequestSerializer serializer];
- self.responseSerializer = [AFJSONResponseSerializer serializer];
-
- return self;
-}
-```
-
-初始化都调用到
-
-
-
-## 数字证书
-数字签名，它能确认消息的完整性，进行认证。
-和公钥密码一样也要用到一对公钥、私钥。但相反的是，签名是用私钥加密（生成签名），公钥解密（验证签名）。私钥加密只能有吃有私钥的人完成，而由于公钥是对外公开的，因此任何人都可以用公钥解密（验证签名）。
-
-
-公钥基础设置（PKI）是为了能够更有效地运用公钥而制定的一系列规范和规格的总称，使用最广泛的 X.509 规范也是 PKI 的一种。
-
-### 证书链
-
-CA 有层级关系，处于最顶层的认证机构一般是根 CA，下面证书是经过上层签名的，而根 CA 则会对自己的证书进行签名。即自签名。
-
-
-怎么验证证书有没有被篡改？
-当客户端走 HTTPS 访问站点时，服务器会返回整个证书链。先从最底层的CA开始，用上层的公钥对下层证书的数字签名进行验证。这样逐层向上验证，直到遇到了锚点证书。
-
-
-## 以 get 请求为例，展开探索
-
-1. 请求入口
-```
-- (NSURLSessionDataTask *)GET:(NSString *)URLString
- parameters:(id)parameters
- success:(void (^)(NSURLSessionDataTask *task, id responseObject))success
- failure:(void (^)(NSURLSessionDataTask *task, NSError *error))failure
-```
-2. 创建 NSURLSessionDataTask
-```
-- (NSURLSessionDataTask *)dataTaskWithHTTPMethod:(NSString *)method
- URLString:(NSString *)URLString
- parameters:(id)parameters
- uploadProgress:(nullable void (^)(NSProgress *uploadProgress)) uploadProgress
- downloadProgress:(nullable void (^)(NSProgress *downloadProgress)) downloadProgress
- success:(void (^)(NSURLSessionDataTask *, id))success
- failure:(void (^)(NSURLSessionDataTask *, NSError *))failure
-
-```
-
-
-
-## 较原生相比，AF 做了什么事情
-拿 get、post 为入口，分析源码
-- 初始化很多属性
-- 安全措施，iOS 8 TaskID 不唯一的问题。dispatch_sync
-- 自定义了一个 block 进度回调，使用起来更加方便
-- 用到了解耦，降低了主类的复杂度，维护起来更加方便
-
-## AFSecurityPolicy 源码分析 HTTPS 认证
-
-
-
-
-
-https://www.jianshu.com/p/856f0e26279d
-
-https://www.jianshu.com/u/14431e509ae8
-
-https://blog.csdn.net/ZCMUCZX/article/details/79399517
diff --git a/Chapter1 - iOS/1.139.md b/Chapter1 - iOS/1.139.md
deleted file mode 100644
index ab3fa73..0000000
--- a/Chapter1 - iOS/1.139.md
+++ /dev/null
@@ -1,347 +0,0 @@
-# 图形渲染技巧
-
-## GPU、CPU
-
-难道不能直接将数据从 CPU 跨到 GPU 处理？为什么需要多此一举，出现 OpenGL 这个框架？
-
-
-
-数据饥饿：从一块内存中将数据复制到另一块内存中，传输速度是非常慢的。内存复制数据时，CPU 和 GPU 都不能操作数据，避免引起错误。
-
-- 如果 CPU、GPU 同时操作内存，同步和处理非常麻烦，加一些锁或额外手段将造成速度损耗。
-- 如果 GPU 处理完处于等待状态
-所以加了 buffer 缓冲区来处理该问题。有很多缓冲区，比如颜色缓冲区、深度缓冲区...
-
-
-
-## 着色器渲染流程
-
-缺点：
-- 需要遮盖的部分，画了多次，造成了渲染性能问题，浪费了资源。
-- 叠加的情况，油画算法无法处理。
- 使用油画算法，只要将场景按照物理距离观察者的距离远近排序。由远及近的绘制即可。 但某些情况下，这个距离无法排序。比如下面的场景：
-
- 
- 如果三个三角形是叠加的情况，油画算法无法处理。
-
-##### 正背面剔除（Face Culling）
-
-想象一个 3D 图形，你从任何一个方向去观察，最多可以看到几个面？最多3个，从一个立方体的任意位置和方向去看，最多可以看到3个面。
-
-思考：为什么需要多余的去绘制根本看不到的3个面？
-如果能以某种方式丢弃这部分数据，OpenGL 渲染性能可以提高超过50%。
-
-正背面剔除方案，不仅可以解决隐藏面消除问题，还可以带来性能提升。
-
-如何知道某个面再观察者的视野中会不会出现？任何平面都有2个面，正面、背面。意味着同一个时刻只能看到一个面。
-
-OpenGL 可以做到检查所有正面朝向观察者的面，并渲染他们，从而丢弃背面朝向的面，这样可以节约片元着色器的开销，提高性能。
-
-核心：OpenGL 如何知道绘制的图形中，哪个是正面，哪个是背面？
-通过分析顶点数据的顺序。
-
-- 正面：按照逆时针顶点连接顺序的三角形面
-- 背面：按照顺时针顶点连接顺序的三角形面
-
-
-
-
-用顺时针、逆时针判断正反面不是绝对的，还需要结合观察者的位置。
-
-
-
-
-分析：
-- 左侧三角形的顶点顺序为：1->2->3；右侧三角形顶点顺序为：1->2->3
-- 当观察者在右侧时，则右边三角形方向为逆时针方向，则为正面。左侧三角形为顺时针，则为反面
-- 当观察者在左侧时，则左边三角形顶点为逆时针方向，则为正面。右侧三角形为顺时针，则为反面
-总结：
-正面和背面是由三角形顶点顺序和观察者方向共同决定的。随着观察者的角度方向改变，正反面也会改变。
-
-
-API
-```
-// 开启表面剔除（默认背面剔除）
-void glEnable(GL_CULL_FACE);
-// 关闭表面剔除（默认背面剔除）
-void glDisable(GL_CULL_FACE);
-// 用户选择剔除哪个面（设置面剔除的方式）
-void glCullFace(GLenum mode); // mode 为：GL_FRONT,GL_BACK,GL_FRONT_AND_BACK。默认 GL_BACK
-// 用户指定绕序那个为正面
-void glFrontFace(GLenum mode); // mode 为：GL_CCW,GL_CW。默认 GL_CCW
-// 剔除正面实现
-glCullFace(GL_BACK);
-glFrontFace(GL_CW);
-```
-
-### 深度问题
-- 什么是深度？深度其实就是该像素点在 3D 世界中距离观察者的距离，z 值。
-- 什么是深度缓冲区？一块内存区域，专门存储着每个像素点（绘制在屏幕上的深度值）。深度值 Z 越大，则离摄像机越远。
-- 为什么需要深度缓冲区？在不使用深度测试的时候，如果先绘制了一个距离比较近的物体，再绘制距离比较远的物体，则距离远的位图因为后绘制，则会把距离近的物体覆盖掉。有了深度缓冲区后，绘制物体的顺序就不那么重要了。实际上，只要存在深度缓冲区，OpenGL 都会把像素的深度写入到缓冲区中。除非调用 glDepthMask(GL_FALSE) 来禁止写入。
-
-#### Z-buffer 方法（深度缓冲区 Depth-buffer）
-深度测试。深度缓冲区（Depth buffer）和颜色缓冲区（Color buffer）是一一对应的，颜色缓冲区存储像素的颜色信息，而深度缓冲区存储像素的深度信息。
-在决定是否绘制一个物体表面时，首先要将表面对应的像素深度值与当前深度缓冲区中的值进行比较。如果大于深度缓冲区的值，则丢弃这部分。否则利用这个像素对应的深度值和颜色值，分别更新深度缓冲区和颜色缓冲区。这个过程称为“深度测试”。
-
-#### 使用深度测试
-深度缓冲区，一般由窗口管理系统 GLFW 创建，深度值一般由16位、24位、32位值表示，通常是24位，位数越高，深度精确度越高。
-- 开启深度测试：`glEnable(GL_DEPTH_TEST)`
-- 在绘制场景前，清除颜色和深度缓冲区：`glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT); glClearColor(0.0f, 0.0f, 0.0f, 1.0f);`
-- 清除深度缓冲区默认值为1.0，表示最大的深度之，深度值范围是（0, 1），值越小表示越靠近观察者。值越大表示越远离观察者
-- 指定深度测试判断模式：`glDepthFunc(GLEnum mode);`
- - GL_ALWAYS：总是绘制
- - GL_NEVER：永远不绘制
- - GL_LESS：如果当前深度值小于测试值，则绘制
- - GL_LEQUAL：如果当前深度值小于等于测试值，则绘制
- - GL_GREATER：如果当前深度值大于测试值，则绘制
- - GL_GEQUAL：如果当前深度值大于等于测试值，则绘制
- - GL_NOTEQUAL：如果当前深度值不等于测试值，则绘制
-
-
-
-### ZFighting 闪烁问题
-为什么会出现闪烁问题？
-因为开启深度测试后，OpenGL 就不会再去绘制模型被遮盖的部分，而是直接丢弃。这样的实现显示更真实，但是由于深度缓冲区精度的限制，对于深度相差非常小的情况下（例如在同一平面上进行2次绘制）OpenGL 就可能出现不能正确判断两者的深度值，会导致深度测试的结果不可预测，显示出来的现象是交错闪烁。
-
-
-#### ZFighting 闪烁问题解决
-第一步：启用 Polygon offset 方式解决
-让深度值之间产生间隔，如果2个图形之间有间隔，是不是意味着就不会产生干涉。可以理解为在执行深度测试前将立方体的深度值做一些细微的增加，于是就能将重叠的2个图形深度值之间有所区分。
-```
-// 启用 Polygon offset 方式
-glEnable(GL_POLYGOn_OFFSET_FILL)
-```
-参数列表：
-- GL_POLYGON_OFFSET_FILL：对应光栅化 GL_FILL
-- GL_POLYGON_OFFSET_LINE：对应光栅化 GL_LINE
-- GL_POLYGON_OFFSET_POINT：对应光栅化 GL_POINT
-
-第二步：指定偏移量。
-- 通过 `glPolygonOffset` 来指定 .glPolygonOffset 需要2个参数：factor 和 units。
-- 每个 Fragment 的深度值都会增加如下所示的偏移量。`Offset = (m * factor) + (r * units);`
- - m： 多边形的深度斜率的最大值。理解一个多边形越是与近裁剪面平行，m 就越接近于0
- - r：能产生于窗口坐标系的深度值中可分辨的差异最小值。r 是由具体 OpenGL 平台指定的一个敞亮
-- 一个大于 0 的 Offset 会把模型推到离你（摄像机）更远的位置，相应的一个小于 0 的 Offset 会把模型拉近
-- 一般而言，只需要将 -1.0 和 0 这样简单赋值给 glPolygonOffset 基本可以满足需求
-
-```
-void glPolygonOffset(Glfloat factor, Glfloat units);
-应用到片段上总偏移计算公式：
-Depth offset = (DZ * factor) + (r * units);
-DZ：深度值（Z 值）
-r：使深度缓冲区产生变化的最小值
-```
-
-
-
-### 混合
-我们把 OpenGL 渲染时，会把颜色值存储在颜色缓冲区中，每个片段的深度值也存储在深度缓冲区。当深度缓冲区被关闭时，新的颜色将简单的覆盖原来的颜色缓冲区存在的颜色值，当深度缓冲区再次打开时，新的颜色片段只是当它们比原来的值更接近邻近的裁剪平面才会替换原来的颜色片段。`glEnable(Gl_BLEND)`
-
-#### 组合颜色
-目标颜色：已经存储在颜色缓冲区的颜色值
-源颜色：作为当前渲染命令结果进入颜色缓冲区的颜色值
-当混合功能被启用时，源颜色和目标颜色的组合方式是混合方程式控制的。在默认的情况下，混合方程式如下所示：
-`Cf = (Cs * s) + (Cd *d)`
-- Cf：最终计算参数的颜色
-- Cs：源颜色
-- Cd：目标颜色
-- s：源混合因子
-- d：目标混合因子
-
-下面通过一个常见的混合函数组合来说明问题：`glBlendFunc(Gl_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA)`
-
-如果颜色缓冲区存在一种红色（1.0f, 0.0f, 0.0f, 0.0f），目标颜色 Cd，如果在这上面用一种 alpha 为0.6的蓝色（0.0f, 0.0f, 1.0f, 0.6f）
-```
-Cd(目标颜色) = (1.0f, 0.0f, 0.0f, 0.0f)
-Cs(源颜色) = (0.0f, 0.0f, 1.0f, 0.6f)
-S(源 Alpha) = 0.6f
-D(目标 Alpha) = 1- S = 0.4f
-Cf = (Cs * s) + (Cd * D)
-```
-
-总结：混合函数经常用于实现在其他一些不透明物体前面绘制一个透明物体的效果。
-
-
-
-## GPUImage
-
-### 说明
-
-开源的基于 GPU 处理图片/视频的一个框架，本身内置了几百种常见的滤镜效果，支持自定义滤镜（由开发者基于 OpenGLES GLSL 实现片元着色器）
-
-GPUImage 基于以下框架：
-
-- CoreMedia
-- CoreVideo
-- AVFoundation
-- QuartzCore
-- OpenGL ES2.0
-
-采用 GPU 加速处理图片/视频滤镜效果。对比 GPUImage/CoreImage
-
-- GPUImage 可以自定义滤镜，缺乏人脸识别功能
-- GPUImage 在 GPU 上处理速度高于 CPU，百倍。
-
-目的：隐藏/减弱关于 OpenGL ES 的复杂性。
-
-滤镜处理的原理：就是把静态图片/视频上每一帧图片进行图形变换（饱和度/色温...）处理之后，再现实到屏幕上，本质上（像素点、颜色的变化）
-
-
-
-
-
-### 模块划分
-
-- 上下文环境：包括运行 GPUImage 的上下文定义、资源定义、缓存管理相关类都包括在其中
-- 输入源：即滤镜处理链路的源头，包括视频、图片在内的各种输入源都定义其中
-
-- 输出源：即处理链路的尽头，用于将处理后的数据绘制到屏幕、或者转成二进制数据推流等等
-
-- 滤镜：提供多达上百种的滤镜效果使用来进行图像处理
-
-
-
-
-
-### 核心流程
-
-#### OpenGL ES 处理图片的流程
-
-- 初始化 OpenGL ES 环境、编译、链接顶点着色器、片元着色器
-- 缓存顶点/纹理/坐标数据，传输相关数据到 GPU
-- 图片绘制在帧缓存区
-- 从帧缓存区绘制图像
-
-#### GPUImage 处理图片的流程
-
-整体环节：Source（图片/视频数据源） -> filters（一堆滤镜）-> final target（处理好的图片/视频）
-
-
-
-##### Source（数据源）
-
-- GPUImageVideoCamera : 摄像头（用于实时拍摄视频）
-- GPUImageStillCamera：摄像头（用于拍照片）
-- GPUImagePicture：用于处理已经拍摄完成的照片
-- GPUImageVideo：用于处理已经拍摄好的视频
-
-##### Filter（滤镜）
-
-GPUImageFilter：用来接收图形源，通过自定义顶点/片元着色器来渲染新的图像，完成滤镜处理后交给响应链的下一个对象。
-
-GPUImage 中的滤镜均继承自 `GPUImageFilter`其定义了一个滤镜处理的基本流程。GPUImageFilter 继承自 GPUImgaeOutput，同时实现了 GPUImageInput 协议，这就使得 GPUImageFilter 即可接收 frameBuffer 输入进行图形处理。
-
-`@interface GPUImageFilter : GPUImageOutput 
-
-分析：可以发现 block 本质就是结构体，和 OC 对象一样，也有 isa 指针。block 传递进去的方法，被包装成 block 的成员变量，是一个叫做 FuncPtr 的函数指针了。
-
-是不是我们可以按照系统定义，来构造一个 struct，承接一个 block，然后发起调用呢？
-
-```objective-c
-typedef NS_OPTIONS(int, AspectBlockFlags) {
- AspectBlockFlagsHasCopyDisposeHelpers = (1 << 25),
- AspectBlockFlagsHasSignature = (1 << 30)
-};
-
-typedef struct AspectBlock {
- __unused Class isa;
- AspectBlockFlags Flags;
- __unused int Reserved;
- void (__unused *invoke)(struct AspectBlock *block, ...);
-
- struct {
- size_t reserved;
- size_t Block_size;
- void (*copy)(void *dst, const void *src);
- void (*dispose)(const void *);
- } *descriptor;
-} *AspectBlockRef;
-
-void(^printBlock)(NSString *) = ^void(NSString *msg) {
- NSLog(@"%@", msg);
-};
-printBlock(@"Hello world");
-
-struct AspectBlock *fakeBlock = (__bridge struct AspectBlock *)printBlock;
-((void (*)(void *, NSString *))fakeBlock->invoke)(fakeBlock, @"Hello world");
-```
-
-
-
-思考：我们目前已经用自定义的 struct 来承接了 block 并成功执行了。能否用 NSInvocation 来触发 block？
-
-
-
-## NSInvocation 触发 block
-
-一个方法需要成功调用并执行需要3要素：
-
-- 方法名称 `SEL`
-- 方法签名（参数个人、参数类型、返回值类型等信息） `Method Type Encoding`
-- 方法地址、方法实现 `IMP`
-
-如何从自定义的 block 结构体中获取这些信息呢？
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-AspectsIdentifier：每做一次方法交换，都会转换为一次 AspectsIdentifier。是核心逻辑。
-
-
-
-以一个例子作为源码探索切入口，点击跳转到源码中
-
-
-
-可以看到给 NSObject 添加分类，核心 2 个 API。一个对象方法、一个类方法：
-
-```objective-c
-+ (id
-
-第二步：因为我们通过 AOP 给原始方法添加了 block，最后的效果是既可以调用原始方法，又可以调用 block 添加的代码。实现的前提是什么？
-
-比较 block 和 hook 类的方法的签名信息需要 Match。具体逻辑查看注释。
-
-
-
-```shell
-(lldb) po blockSignature
-
-
-
-
-## objc_msgForward
-
-骚操作：
-
-- 将待 hook 的方法，和 `objc_msgForward` 进行交换。 `objc_msgForward` 不管对象有没有实现，都会触发消息转发流程
-- 此时会走 Runtime 的 NSObject `forwardInvocation` 流程。且 Aspects 将 `forwardInvocation` 方法指向了 `__ASPECTS_ARE_BEING_CALLED__` 方法。
-
-经历这么一波处理，hook 最后都守口到了 `__ASPECTS_ARE_BEING_CALLED__` 方法中。
-
-前面研究过了 `AspectIdentifier` 的逻辑。接下去继续看看后续步骤。
-
-
-
-可以看到内部执行 `aspect_prepareClassAndHookSelector`，其内部会调用 `aspect_hookClass`，又会调用 `aspect_swizzleClassInPlace`，最后调用 `aspect_swizzleForwardInvocation` 方法。
-
-```objective-c
-static NSString *const AspectsForwardInvocationSelectorName = @"__aspects_forwardInvocation:";
-static void aspect_swizzleForwardInvocation(Class klass) {
- NSCParameterAssert(klass);
- // If there is no method, replace will act like class_addMethod.
- IMP originalImplementation = class_replaceMethod(klass, @selector(forwardInvocation:), (IMP)__ASPECTS_ARE_BEING_CALLED__, "v@:@");
- if (originalImplementation) {
- class_addMethod(klass, NSSelectorFromString(AspectsForwardInvocationSelectorName), originalImplementation, "v@:@");
- }
- AspectLog(@"Aspects: %@ is now aspect aware.", NSStringFromClass(klass));
-}
-```
-
-该方法将被 hook 对象的 `forwardInvocation:` 方法替换为 `__aspects_forwardInvocation:`。
-
-回归头继续看下面的逻辑。
-
-
-
-`class_replaceMethod(klass, selector, aspect_getMsgForwardIMP(self, selector), typeEncoding)` 可以实现将被 hook 类的 hook 方法，替换为 `_objc_msgForward` 或者某些版本下需要的 `_objc_msgForward_stret`。
-
-
-
-比如 ViewController 的 viewWillAppear hook 流程就是：
-
-`[UIViewController viewWillAppear:]` -> `_objc_msgForwar` -> `[UIViewController forwardInvocation:]` -> `__ASPECTS_ARE_BEING_CALLED__`
-
-
-
-
-
-## 总结
-
-Aspects 是 Runtime 使用的一个经典库，处理好核心逻辑后，也做了一些黑名单、线程安全等的保护。也有一些类似日志回放功能的处理。
-
-
-
-
-
diff --git a/Chapter1 - iOS/1.141.md b/Chapter1 - iOS/1.141.md
deleted file mode 100644
index dd99c20..0000000
--- a/Chapter1 - iOS/1.141.md
+++ /dev/null
@@ -1,46 +0,0 @@
-# LLDB
-
-
-
-## LLDB 架构
-
-
-
-说明：类似一个 CS 架构。
-
-- **`lldb-mi` 的角色：** 它是一个**协议适配器**，专注于将 **GDB/MI 协议** 翻译成 **LLDB API 调用**。
-- **`API` 是关键桥梁：** `lldb-mi` 几乎所有的功能都通过调用 **LLDB Public API** 来实现。
-- **Core 下的模块是 LLDB 的能力：** 图中 `Core` 下列出的 `Object Files`, `Symbols`, `Process` 等，代表了 **LLDB 调试器引擎本身提供的强大核心功能**。`lldb-mi` 依赖 API 来利用这些功能。
-- **依赖关系：** `lldb-mi` -> `API` -> (LLDB 核心引擎的) `Object Files`, `Mach-O/ELF`, `Symbols`, `DWARF`, `Disassembly`, `LLVM`, `Process`, `GDB Remote`。
-- **目的：** 这张图说明了 `lldb-mi` 是如何构建在 LLDB 强大的核心调试引擎之上，通过标准的 API 调用其功能，从而为支持 GDB/MI 协议的客户端提供调试服务。
-
-
-
-
-
-## LLDB Workflow
-
-
-
-说明：
-
-- **lldb-server**：调试服务端，`lldb-server` 作为“调试代理”，直接操控目标程序。分为两种部署方式：
-
- - **Host 端**：调试本地程序（如 macOS 进程）。
-
- - **Remote 端**：部署到目标设备（如手机/嵌入式设备），直接控制被调试程序
-
-- 通信层：TCP + GDB RSP 协议
-
- - **TCP Socket**：物理传输通道，连接 Host 的 LLDB 和 Remote 的 lldb-server
- - **GDB RSP (Remote Serial Protocol)**
- - **基于 ASCII 的调试协议**（明文消息，如 `$m版本管理
依赖安装] - B --> C[构建与测试
gym: 构建IPA
scan: 运行测试] - C --> D[应用分发
内测分发
pilot: TestFlight
第三方平台] - D --> E[商店发布
deliver: 上传元数据与二进制文件
提交审核] - E --> F[后续工作
管理测试员
Slack 通知] -``` - - - -### 1. 证书 -- iOS 数字证书是用来证明 iOS App 可执行文件的合法性和完整性的。对于想安装到真机或发布到 App Store 的 App，只有经过签名验证（Signature Validated）才能确保来源颗心，并且保证 App 内容是完整的、未经篡改的。 -- 数字证书是一个经证书授权中心数字签名的包含公开密钥拥有者信息以及公开密钥的文件。具有时效性，只在特定的时间段内有效。 - -开发证书分为2类： -- 开发证书（iOS Development）：用于开发和调试应用程序，可用于真机调试 -- 发布证书（iOS Distribution）：发布证书用于打包上传到 App Store，用于验证开发者身份 - -推送证书，如果项目中集成了推送功能，需要配置推送证书： -- 开发证书（Apple Development iOS Push Services） -- 发布证书（Apple Production iOS Push Services） -- 需要将生成的 p12 文件上传到服务器后台（极光、友盟、或者自己的推送服务器后台） - - -QA：存在一个情况，点击一个网页，下载 iOS App 到本地，点击启动的时候，会让你从「设置 -> 通用」中去信任证书。这个的工作原理是什么？ - -这是一个典型的“无线设备管理”（MDM）注册和内部应用分发组合流程。 -原理详解： -第一步：伪装与诱导 (Phishing) - -- 接收短信：您收到一条看似普通的短信，内容可能是“刷单兼职”、“交友约会”、“彩票赌博”、“色情内容”或“高额借贷”等，并附带一个短链接（用于隐藏真实URL）。 -- 点击链接：您点击后，会跳转到一个精心设计的网页。这个网页模仿成某个 App 的下载页面，有一个非常醒目的“点击安装”或“立即跳转”按钮。 - -第二步：利用技术漏洞 (Abusing the System) -- 触发下载：点击按钮后，服务器会尝试让您的设备下载一个 .mobileconfig 文件。这是正规MDM流程的第一步，但在这里是恶意利用。 -- 系统弹窗：iOS系统会弹出标准提示框，显示“正在下载描述文件”，并询问您是否允许。这个弹窗是系统级的，无法伪造，所以具有很强的欺骗性。 - -第三步：利用信息差与恐吓 (Social Engineering) -- 引导“信任”：网页上会有非常详细的图文或视频教程，指导您下一步该怎么做。通常会编造理由，如： - - “这是为了验证您的设备安全性，防止作弊。” - - “必须完成此步骤才能使用App。” - - “这是官方要求的签名验证流程。” -- 安装描述文件：您根据指导，进入 “设置” -> “已下载的描述文件”，点击“安装”。这个描述文件里包含了一个 payload，其唯一目的就是向攻击者的服务器注册并上报您设备的UDID。 -- 信任企业证书：安装完成后，您还需要像之前了解的那样，去 “设置” -> “通用” -> “VPN与设备管理” 中，信任一个来自“某公司”的企业级应用证书。 - -第四步：达成目的 (The Payoff) -- UDID 上报：在您完成上述所有步骤的过程中，特别是安装描述文件后，您设备的 UDID (Unique Device Identifier) 以及其他一些设备信息（如型号、系统版本）已经无声无息地被发送到了灰产控制的后台服务器。 -- 白名单机制：灰产掌握着一个或多个（因为常被苹果吊销）企业证书。他们收到您的UDID后，会将其添加到他们企业开发者后台的设备白名单中。只有这样，由他们企业证书签名的最终App（赌博、色情App等）才能在您的设备上安装和打开。 -- 完成欺诈：此时，您再回到最初的网页，或者重新点击短信链接，就会发现可以正常下载那个最终的非法App了。因为您的设备UDID已经被加入白名单，企业证书已经生效。 - - - -这属于 MDM 吗？不属于真正的MDM，而是“MDM钓鱼”。 -正规MDM：目的是持续管理设备，如远程安装/卸载应用、配置策略、擦除数据等。需要用户明确知道设备被公司管理。 -灰产MDM：目的极其单一——窃取UDID。它们没有任何后续的管理意图和能力。它们只是滥用了.mobileconfig配置文件能够在安装时自动向指定服务器上报设备信息（包括UDID） 的这一功能。 -您可以理解为，骗子只偷走了MDM流程的“身份证登记处”，而完全抛弃了后面的“管理员办公室”。 - -### 2. 配置文件（Provsioning Profiles） -配置文件也分为2种： -- 开发（Development） -- 发布（Distribution） -- 配置文件（Provsioning Profiles）中包含了证书、App ID、设备（Devices），后缀名为 `.mobileprovision` -- 配置文件在开发者账号体系中扮演着配置和验证的角色。是真机调试和打包上架的必须文件 - - - -Xcode 中，对于项目是可以看到配置文件的。我们可以鼠标按住，拖动到桌面文件夹下。 -
-此外，`mobileprovision` 文件是不可读的。可以通过 **security cms -D -i 195103db-6d6f-4da1-bd0e-66d5db88176f.mobileprovision -o profil
-e.plist** 指令，dump 成为一个 plist 格式的文件。如下图所示：
-
-
-指令解读：
-- security：是 macOS 自带的安全相关的命令行工具，用于处理证书、配置文件、密钥等的处理
-- cms：表示使用 CMD(Cryptographic Message Syntax，密码消息语法)相关功能，用于处理消息签名和加密消息
-- -i：指定输入文件
-- -o：指定输出文件
-
-重要信息：
-- DeveloperCertificates: 允许使用的开发者证书
-- Entitlements：允许使用的权限列表
-- ProvisionedDevices：允许安装的设备列表（ProvisionsAllDevices，代表授权任意设备）
-
-
-
-### 3. 授权文件（Entitlements）
-声明了 App 所需的权限
-
-
-
-### 4. 签名 codesign
-
-#### 1. 基础签名
-
-- **-s**：--sign identity 指定签名所用的证书（- 代表 ad-hoc 签名）
-- **--entitlements**：entitlements_file 指定签名所需要的 entitlements 文件
-- **-f**： --force 强制替换现有签名
-- **-preserve-metadata=identifier,entitlements**: 重用就签名的一些信息
-- **-deep**： 递归对该 bundle 内包含的其他文件签名
-
-
-注意：为什么不推荐使用 `--deep`？
-
-在没有 `--deep` 的情况下，codesign 命令只会对指定的主目标（main target）（例如 .app 包或 .framework）进行签名。它不会自动递归地签名的 .app 包内部的任何嵌套的组件（如嵌入的 .framework 或 .dylib）。
-
---deep 选项的设计初衷是试图递归地签名一个 bundle 内部的所有嵌套代码。例如，如果你的 MyApp.app 内部嵌入了 ThirdParty.framework，使用 `codesign --deep -f -s "Your Identity" MyApp`.app 会同时签名 MyApp.app 和其内部的 ThirdParty.framework。
-
-错误的签名顺序（主要问题）：
-- 代码签名不仅是对二进制文件盖章，它还计算并存储每个组件的哈希值到其 _CodeSignature/CodeResources 文件中。
-- 当你签名一个 .app 时，它也会计算其内部所有文件（包括嵌套的 .framework）的哈希值。如果这些嵌套的组件在 .app 被签名之后又被修改了，其哈希值就会改变，导致签名无效。
-- `--deep` 的工作方式是：先递归地签名最内层的组件（如 ThirdParty.framework），然后签名外层的容器（MyApp.app）。
-
-这看起来是正确的，对吗？ 但实际上，在签名外层 .app 时，它记录的仍然是内层组件签名前的哈希值。而内层组件在签名后其内容（因为附加了签名信息）已经发生了变化，这就导致了内外记录不一致，从而使整个签名变得无效且不可靠。
-
-与现代构建系统不兼容：
-- Xcode 和标准的构建流程（如 xcodebuild）的正确做法是：先单独签名每一个嵌套的组件（Embedded Framework），最后再签名主应用。这确保了每个组件都有自己独立的有效签名，并且主应用在签名时记录的是所有嵌套组件的最终状态。
-- `--deep` 破坏了这种明确的、分阶段的签名流程，试图用一步代替多步，反而引入了混乱。
-
-
-
-#### 2. 动态库签名
-
-动态库可以上架，是因为对动态库可以进行签名。来一个 Demo 工程。一个 iOS 工程，以动态库的形式使用 SDWebImage
-
-##### 1. Demo1
-
-1个 iOS App 工程，使用动态库的方式，依赖了 AFNetworking。选择模拟器进行编译，查看日志：
-
-
-
-日志分析：
-1. 日志中的 `--sign` 后一般接的是证书的名称，但是当前日志中是 `-`，代表使用自动签名模式（Automatic Signing）。
- - **--sign 参数**：这是 codesign 命令的核心参数，用于指定用于签名的身份（Identity）。这个身份通常对应着钥匙串（Keychain）中的一个证书（Certificate）及其关联的私钥。
- - **-**：这是一个特殊的标识符，在这里它不代表一个具体的证书名称。它的含义是：“使用临时生成的、匿名的 Ad-Hoc 签名身份来进行签名，而不需要指定一个具体的、来自苹果开发者账户的证书。”
- 在模拟器（Simulator）上运行（正如你的日志中 Debug-iphonesimulator 所示）：
- 根本原因：iOS 模拟器不像真机设备那样需要验证苹果官方的代码签名证书来确保安全。模拟器的运行环境更加宽松，其主要目的是为了快速调试。为了方便：使用 Ad-Hoc 签名可以省去为模拟器编译时配置和选择开发证书的步骤，极大地加快了编译和调试的速度。Xcode 默认就会为模拟器构建采用这种方式。
-
-2. 日志中的 `--entitlements /Users/unix_kernel/Library/Developer/Xcode/DerivedData/InstallDyanmicAndStaticFramework-bmcbqvmynpdalkdhzqirbithtfwp/Build/Intermediates.noindex/InstallDyanmicAndStaticFramework.build/Debug-iphonesimulator/InstallDyanmicAndStaticFramework.build/InstallDyanmicAndStaticFramework.app.xcent` 代表 Xcode 开启的 App 能力信息。`--entitlements` 参数后面跟随的是一个 `.xcent` 文件的路径，这个文件包含了应用程序的权限（Entitlements）配置信息，也就是 “App 能力信息”
-
-对其查看，内容如下：
-
-
-`security find-identity -v -p codesigning` 指令用于 macOS 系统中用于查看可用代码签名证书的命令，主要用于开发者在进行代码签名操作前确认可用的证书信息
-
-##### 2. Demo2
-
-1个 iOS App 工程，使用动态库的方式，依赖了 AFNetworking。选择真机进行编译，查看日志：
-
-日志分析：
-1. 日志中的 `Signing Identity: "Apple Development: FantasticLBP@github.com (953PZFXZFR)"` 变成了开发者证书。多了一个配置文件。
-2. 使用的动态库 AFNetworking 是如何签名的？
-选择 Pods 的 Product 里面的 AFNetworking 动态库，右击 “show in finder”。看到并没有一个 **`_CodeSignature`** 的文件夹，也就是没有签名信息。然后用指令 ` objdump --macho --private-headers /Users/unix_kernel/Library/Developer/Xcode/DerivedData/InstallDyanmicAndStaticFramework-bmcbqvmynpdalkdhzqirbithtfwp/Build/Products/Debug-iphoneos/AFNetworking/AFNetworking.framework/AFNetworking` 进行查看，发现也不存在 **`LC_CODE_SIGNATURE`** 存储签名信息的 load command。
-
-
-可能会问，如何确定是动态库？使用 `file AFNetworking` 指令即可验证
-
-
-问题：动态库 AFNetworking 没有经过签名，为什么拷贝到 App 里面后，可以上架？
-其实 Cocoapods 自动生成了脚本，在主工程的 `Build Phases -> Embed Pods Frameworks` 下。且 `Input File Lists` 配置的文件内容，就是所依赖库的文件路径。会被当作参数传递给 `Embed Pods Frameworks` 脚本。
-
-
-观察编译日志，会发现 「Run custom shell script '[CP] Embed Pods Frameworks'」这里，先对 Frameworks 目录进行了创建和拷贝。然后对 AFNetworking 进行签名。
-在主工程的 Products 目录下，选择 App，show in finder，然后显示包内容。查看 `Frameworks` 文件夹下的 `AFNetworking.framework` 已经存在了 `_CodeSignature` 文件夹，也就是已经签名完成。继续查看 Load Command，发现也存在了 **LC_CODE_SIGNATURE** Load Command。
-
-
-同时，也可以看到是先对动态库签名，再对 App 签名。
-
-#### 3. 如何查看签名信息
-
-[jtool2](https://github.com/excitedplus1s/jtool2) 工具可以方便的查看签名信息。jtool2 类似于 otool，但添加了许多 Mach-O 相关的命令，功能更完善。它支持多种运行平台
-
-安装方式为：`brew install --no-quarantine excitedplus1s/repo/jtool2`
-使用方式为：**`jtool2 --sig -vv ${MachOFile}`**
-
-
-
-
-
-### 5. fastlane 相关概念
-
-
-- fastlane 本质就是一套命令行工具，专为用来简化并实现我们与 Apple 交互时的自动化
-- fastlane 的每一个单独工具都是为了解决常见的 App Store 或其他问题而设计的
-- fastlane 通过脚本方式集合了一系列常见的行为，叫做 lane。也就意味着可以通过 lane 来对自己的 App 做一些量身定制的需求
-- fastlane 包含大量的 action
-- action 表示特定的应用商店或者其他开发者工作流任务
-- lane 表示工作流程
-
-- Appfile： 存储有关开发者账号相关信息
-- Fastfile：核心文件，主要用于命令行调用和处理具体的流程，lane 相对于一个方法或者函数。
-
-#### 1. action
-
-- cert: 创建和维护签名证书
-- sigh：配置文件
-- gym：构建打包应用程序
-- deliver：上传应用程序和屏幕截图到 App Store Connect
-- pilot：为 TestFlight 上传构建并处理其管理
-- scan：自动化测试
-- match：团队中同步证书和配置文件
-- boarding：测试邀请
-- pem：管理推送配置文件
-- produce：在 App Store Connect 创建新的 App
-
-
-使用方式有3种：
-- 第一种：命令行方式。比如
- ```
- fastlane scane --workspace "fastlaneDemo.xcworkspace" --scheme "fastlaneDemo" --device "iPhone 8" --clean
- ```
-- 第二种：Fastfile 方式。采用 FastLane 约定的格式去编写逻辑。比如
- ```
- default_platform(:ios)
-
- platform :ios do
-
- lane :builds do
- # 单元测试
- scan(
- workspace: "fastlaneDemo.xcworkspace",
- scheme: "fastlaneDemo",
- devices: ["iPhone 14 Pro Max", "iPhone 14", "iPhone SE (3rd generation)"],
- clean: true,
- code_coverage: true,
- output_types: "html,junit",
- output_directory: "./fastlane/test_output"
- )
- # 证书
- cert
- # 配置文件
- sigh
- # 打包
- gym(
- workspace: "fastlaneDemo.xcworkspace",
- scheme: "fastlaneDemo",
- clean: true,
- output_directory: "./fastlane/build_output",
- output_name: "fastlaneDemo.ipa",
- silent: false,
- include_symbols: true,
- include_bitcode: true
- )
- end
- end
- ```
-- 第三种：使用特定的 Fastlane 文件。比如使用脚本 `Fastlane scan init` 会生成关于 scan 相关逻辑的脚本文件 `Scanfile`
- 
-
-建议使用方式二、三，不建议使用方式一。关于 fastlane 脚本编写文档查看 [fastlane docs](http://docs.fastlane.tools)
-
-使用方式：
-Scanfile 是 专门用于配置 scan 动作（即运行测试） 的配置文件。它的唯一目的是为 scan 提供默认参数。你可以在里面设置 scheme、output_directory、code_coverage 等测试相关的选项。当你在命令行直接运行 fastlane scan 或在 Fastfile 的 lane 中调用 scan 时，它会自动读取 Scanfile 中的配置。
-
-
-
-| 文件 | 角色 | 用途 | 示例内容 |
-| :-------------- | :---------------------- | :----------------------------------------------------------- | :----------------------------------------------------------- |
-| **`Fastfile`** | ****指挥官\**/\**剧本** | **定义 lanes（工作流）**。这是 Fastlane 的核心，你在这里组合不同的动作来创建自动化流程。 | `lane :test { scan }` `lane :beta { cert; sigh; gym; upload_to_testflight }` |
-| **`Scanfile`** | **专项配置员** | 只为 **`scan`** 动作提供默认配置参数。 | `scheme("MyApp")` `clean(true)` `output_directory("./test_results")` |
-| **`Gymfile`** | **专项配置员** | 只为 **`gym`** 动作（构建 IPA）提供默认配置参数。 | `workspace("MyApp.xcworkspace")` `export_method("app-store")` `output_directory("./builds")` |
-| **`Matchfile`** | **专项配置员** | 只为 **`match`** 动作（证书管理）提供默认配置参数。 | git_url("https://github.com/.../certs")` `app_identifier("com.yourapp") |
-
-总结：
-
-- **`Fastfile`** 就像是一个**总剧本**，里面写着：第一场戏（`lane :test`）是跑步测试，第二场戏（`lane :beta`）是打包上传。
-- **`Scanfile`**、**`Gymfile`** 等就像是每个**演员（scan, gym 动作）的个人小抄**，上面写着他们的默认表情、站位等细节。
-- 当“总剧本”喊到某个演员时，演员就会按照自己“小抄”上的默认设置来表演，除非剧本特意指定了另一种表演方式。
-
-
-
-QA：按照上面的思路和角色分工、能力边界，将下面的代码优化
-
-```ruby
-platform :ios do
-
- lane :builds do
- # 单元测试
- scan(
- workspace: "fastlaneDemo.xcworkspace",
- scheme: "fastlaneDemo",
- devices: ["iPhone 14 Pro Max", "iPhone 14", "iPhone SE (3rd generation)"],
- clean: true,
- code_coverage: true,
- output_types: "html,junit",
- output_directory: "./fastlane/test_output"
- )
- # 证书
- cert
- # 配置文件
- sigh
- # 打包
- gym(
- workspace: "fastlaneDemo.xcworkspace",
- scheme: "fastlaneDemo",
- clean: true,
- output_directory: "./fastlane/build_output",
- output_name: "fastlaneDemo.ipa",
- silent: false,
- include_symbols: true,
- include_bitcode: true
- )
- end
-end
-```
-
-优化：
-
-- 文件一：`./fastlane/Scanfile` 只存放测试相关的配置
-
- ```ruby
- # Scanfile 专用配置
- workspace("fastlaneDemo.xcworkspace")
- scheme("fastlaneDemo")
- devices(["iPhone 14 Pro Max", "iPhone 14", "iPhone SE (3rd generation)"])
- clean(true)
- code_coverage(true)
- output_types("html,junit")
- output_directory("./fastlane/test_output")
- skip_build(true)
- ```
-
-- 文件二：`./fastlane/Gymfile` 存放构建相关的配置
-
- ```ruby
- # Gymfile 专用配置
- workspace("fastlaneDemo.xcworkspace")
- scheme("fastlaneDemo")
- clean(true)
- output_directory("./fastlane/build_output")
- include_symbols(true)
- include_bitcode(true)
- ```
-
-- 文件三：`./fastlane/Fastfile` 存放 lane 相关逻辑
-
- ```ruby
- # Fastfile - 定义 lanes
- default_platform(:ios)
-
- platform :ios do
- # 定义一个名为 builds 的 lane
- lane :builds do
- # 运行测试，所有配置会自动从 Scanfile 读取
- scan
- # 管理证书
- cert
- sigh
- # 构建 ipa，所有配置会自动从 Gymfile 读取
- gym
- end
- end
- ```
-
-分析：
-
-1. **清晰与模块化**：每个文件职责单一，易于维护。
-
-2. **复用性**：你可以在 `Fastfile` 中创建多个不同的 lane（如 `lane :tests`、`lane :adhoc`），它们都可以共享 `Scanfile` 和 `Gymfile` 中的通用配置，无需重复代码。
-
-3. **可覆盖性**：在 `Fastfile` 的 lane 中调用 `scan` 或 `gym` 时，你可以随时覆盖对应 `*.file` 中的默认设置。例如：
-
- ```ruby
- lane :special_build do
- gym(
- output_name: "SpecialRelease.ipa" # 覆盖 Gymfile 中的默认命名规则
- )
- end
- ```
-
-
-
-#### 2. Matchfile
-
-终端使用 `fastlane match init` 指令创建 Matchfile，同时根据提示选择一些模版和输入信息。
-
-
-
-
-
-- `git_url`：
-
- 是 `match` 最核心的配置，指定了存储加密证书和配置文件的 Git 仓库地址。`match` 不会将敏感的证书文件（`.cer`）、私钥文件（`.p12`）和配置文件（`.mobileprovision`）保存在本地或只留在苹果开发者门户。
-
- 相反，它会将这些文件**加密后**推送到这个指定的 Git 仓库（`https://github.com/FantasticLBP/knowledge-kit`）中。
-
- 当任何开发者或 CI/CD 系统需要这些文件时，`match` 会从这个仓库克隆或拉取最新的加密文件，然后在本地解密并安装到钥匙串和 Xcode 中。
-
- 这个仓库应该是**私有的（Private）**，因为里面存储的是你应用的敏感安全凭证
-
-- `storage_mode("git")`:
-
- 明确指定 `match` 使用 Git 作为存储后端。
-
- match` 支持多种存储方式，`git` 是**默认且最常用**的一种。
-
- 其他可选模式包括 `s3`（Amazon S3）和 `google_cloud`（Google Cloud Storage）。这些通常在更复杂或企业级的 CI/CD 环境中使用，以提高大文件的下载速度
-
-- `type("development")`
-
- 设置 `match` 的**默认操作类型**为 `development`（开发证书和配置文件）
-
- 这个参数定义了你要管理哪类证书。iOS 开发中有几种主要类型：
-
- - `"development"`：用于开发阶段，可在真机上调试应用。
- - `"appstore"`：用于提交到 App Store 或 TestFlight。
- - `"adhoc"`：用于分发给有限数量的测试设备（最多 100 台）。
- - `"enterprise"`：用于企业账号的内部分发。
-
- 在这里设置为 `"development"` 意味着：
-
- - 当你直接运行 `fastlane match`（而不指定类型）时，它会默认操作开发证书。
- - 当你运行 `fastlane match development` 时，它也会使用这个配置（尽管命令行参数已经指定了类型，但其他相关配置会从这里读取）。
-
-这个 `Matchfile` 配置告诉我们：
-
-1. **存储位置**：所有加密的证书和配置文件都将被同步到 `https://github.com/FantasticLBP/knowledge-kit` 这个 Git 仓库中。
-2. **存储方式**：使用 Git 进行版本管理和同步（这是标准做法）。
-3. **默认环境**：默认情况下，操作的是用于**开发环境**的证书和配置文件。
-
-**一个典型的工作流程：**
-
-1. 团队成员 A 首次运行 `fastlane match development`。
-2. `match` 会检查指定的 Git 仓库中是否已有开发证书。
- - 如果**没有**，它会连接到苹果开发者门户，创建新的开发证书和配置文件，加密后推送到 Git 仓库。
- - 如果**已有**，它会将加密文件拉取到本地，解密后安装到 Xcode 和钥匙串中。
-3. 团队成员 B 加入项目，同样运行 `fastlane match development`。
-4. `match` 从同一个 Git 仓库拉取**完全相同的**证书和配置文件，确保团队环境一致。
-
-
-
-## 三、持续集成
-
-Cotinuous Integration，持续集成意味着每次代码的变更都在构建服务器上运行测试，并在指定场景下触发。这样如果开发者将测试失败的代码推送到代码库，也称为破坏构建，CI 会触发警告。
-
-- 主动式 CI：CI 提供商
-- 托管式 CI：github action
-- 手动式 CI：自己管理，Travis CI、Jenkins
-
-
-
-- Travis CI：小型开源项目，付费、简单、方便、
-- Jenkins：大型企业、丰富的自定义选项、定制化，不能做到开箱即用，免费
-
-### 1. docker
-
-> 问：为什么一定要 docker？不能在服务器上按照本地的配置安装所需的各个软件吗
->
-> 答：在一个团队中，每个开发者的本地环境都可能略有不同（macOS 版本、Xcode 通过 App Store 安装还是手动安装、Homebrew 的使用方式等）。
->
-> - **问题**：新同事加入，需要花费**一整天甚至更长时间**来按照文档一步步配置环境，任何一步的疏漏都会导致环境配置失败。
-> - **后果**： onboarding 成本极高，而且无法保证所有人的环境真正一致，为后续的协作埋下了隐患。
->
-> 为什么“手动安装一下”不是最优解？它的成功依赖于：
->
-> - **人的记忆和文档**：需要有人（或文档）准确地记录下所有依赖的**精确版本**（不仅仅是 `fastlane`，还包括它的依赖，以及依赖的依赖）。这份文档需要随着项目的每一次依赖变更而**实时更新**，这几乎是不可能的任务。
-> - **手动操作的准确性**：需要操作人员完全正确地执行安装步骤，不能有任何错漏。这是一个枯燥且容易出错的过程
-
-#### 1. 定义
-
-**Docker 概述**: Docker 是一种成熟高效的软件部署技术，利用容器化技术为应用程序封装独立的运行环境。每个运行环境即为一个**容器**，承载容器运行的计算机称为**宿主机**。
-
-容器。容器虚拟化指的是操作系统而不是硬件，容器之间是共享同一套操作系统资源的。
-
-- 镜像（image）：提供容器运行时所需的程序、库、资源、配置等文件，还包含了一些为运行时准备的一些配置参数（如匿名卷、环境变量、用户等）
-- 容器（Container）：镜像运行时的实体，如果需要在其它服务器上使用这个镜像，我们就需要一个集中的存储、分发镜像的服务，Docker Registry 就是这样的服务
-- 仓库（Repository）：镜像构建完成后，可以很容易的在当前容器上运行
-
-虚拟机：虚拟出一套硬件后，在其上运行一个完整的操作系统。
-
-
-
-**容器与虚拟机的区别**:
-
-* **Docker容器**: 多个容器共享同一个系统内核
-* **虚拟机**: 每个虚拟机包含一个操作系统的完整内核
-* **优势**: 所以 Docker 容器比虚拟机更轻量、占用空间更小、启动速度更快
-
-**镜像 (Image)**:
-
-* **定义**: 镜像是容器的模板，可类比为软件安装包
-* **类比**: 类似于制作糕点的模具，可用于创建多个糕点（容器），并可分享给他人
-
-**容器 (Container)**:
-
-- **定义**: 容器是基于镜像运行的应用程序实例，可类比为安装好的软件。
-- **类比**: 类似于模具制作出的糕点。
-
-**Docker仓库 (Registry)**:
-
-* **定义**: 用于存放和分享Docker镜像的场所
-* **Docker Hub**: Docker的官方公共仓库，存储了大量用户分享的Docker镜像。
-
-
-
-Docker 理解为：标准化、一摸一样的工具箱和工作环境。保证无论哪个工人来，用的工具和环境都完全一样，避免“在我这儿是好的”问题。
-
-- 环境标准化：创建一个包含特定版本 Ruby、Fastlane、Xcode 命令行工具、Cocoapods 的镜像
-- 隔离一致性：确保开发、测试、生产环境的构建完全一致，消除“环境依赖”问题
-- 快速搭建与清理：轻松为 Jenkins 提供纯净、可随时销毁和重建的构建环境。
-
-**价值：开发者需要花费大量时间排查环境差异，而不是专注于修复真正的业务逻辑 Bug，严重拖慢开发效率。**
-
-
-
-#### 2. docker 的核心角色与能力
-
-docker 在 iOS CI/CD 管道中（通常与 Jenkins、Gitlab CI、Github Actions 等工具配合）中主要负责“管理阶段”和“环境保障”
-
-1. 环境标准化与一致性
-
- - 问题：传统的 CI 机器（无论是物理机还是虚拟机）环境复杂，不同项目所依赖的 Ruby、NodeJS、Python、Fastlane、Cocoapods 等工具版本可能冲突。造成“在我本地是好的，在 CI 机器上发布后就失败了”。（CI 机器上并不一定只部署一个 iOS 的 CI 项目，可能其他项目也部署了，可能由于 Ruby 安装了2.0，但是 iOS 的 CI 服务需要 Ruby 3.0+，这样就造成了本地 CI 服务正常，部署到 CI 服务器之后就有了问题）
- - Docker 解决方案：构建一个专门的 Docker 镜像，预安装项目所需的所有命令行工具和依赖的特定版本，专门负责 CI 逻辑（如 Ruby 3.1.2、Fastlane 2.2.1、Cocoapods 1.22.1、Xcode 16）
- - 结果：每一次 CI 构建都会从一个纯净、一致、已知状态的镜像环境启动，彻底消除了环境差异导致的构建失败，保证了构建结果的可靠性和可重现性。
-
-2. 依赖隔离
-
- 多个 iOS 项目可能在同一台 CI 服务器上运行。使用 Docker 可以将每个项目需要的构建环境相互隔离。避免了项目之间的依赖冲突（例如，项目 A 需要 Cocoapods 1.10，项目 B 需要 Cocoapods 1.11）
-
-3. 快速的构建环境准备：
-
- 相比启动一个完整的虚拟机，启动一个 Docker 容器是秒级的。这大大减少了 CI 流水线等待构建环境就绪的时间，加快了整个构建流程的反馈循环
-
-4. 版本控制与可追溯性：
-
- DockerFile 是文本文件，可以放入 git 仓库进行版本管理。对构建环境的任何更改（例如升级 Fastlane 版本）都像代码更改一样，可以通过 Pull Request 进行审查、测试和记录，实现了基础设施即代码 (IaC)。
-
-5. 作为轻量级的“任务运行器”
-
- 在 CI 流程中，Docker 容器通常被当做一个一次性的、执行特定任务的“沙盒”，比如：执行 pod install、执行 lint 或代码分析、运行 fastlane。
-
-
-
-#### 3. docker 的能力边界
-
-尽管 docker 很强大，但在 iOS 开发领域，它有非常明确且无法跨越的边界：
-
-1. 无法直接构建 iOS 应用（最关键的边界）
-
- - 根本原因：iOS 最终编译、链接和打包必须依赖 MacOS 内核和 Xcode、Clang、SwiftCli
- - Docker 局限性：标准的 Docker 容器基于 Linux 内核。它无法运行 MacOS 系统或 Xcode 这样的 GUI 应用（所以无法执行 xcodebuild 指令）
- - 结论：无法在 linux docker 容器内编译出 `.ipa` 文件
-
-2. 无法运行 MacOS 镜像
-
- Apple 的许可协议和硬件限制，导致不存在官方的 MacOS Docker 镜像。虽然有类似 LinuxKit 这样的非官方项目，但不够稳定，不能用于生成环境，风险较大
-
-
-
-#### 4. 最佳搭配
-
-明确了 docker 的作用和能力边界后，一个典型的 iOS CI/CD 架构就清晰了：**“在 Linux Docker 容器中准备环境和运行脚本，在 MacOS 主机/节点上进行最终编译”**
-
-- CI Server（Jenkins Controller）：可以运行在任何系统上，负责任务调度
-- MacOS Build Agent/Node：一台或多台安装了 Xcode 的 MacOS 系统的电脑，它被注册到 CI Server 上，专门用于执行需要的 xcodebuild 任何
-- Docker 的使用：
- - CI 流水线启动后，CI Server 会现在 Linux Docker 容器中完成所有它能做的工作：代码拉取、依赖安装（pod install）、运行单元测试（如果测试不依赖 MacOS 框架）、执行静态分析等
- - 当需要进行 Xcode 的步骤（如编译、打包、签名）时，CI Server 会将工作委托给一台 MacOS Build Agent
- - MacOS Agent：接收任务，它可能本身会通过一个 Docker 来获取一个一致的环境（用于运行 fastlane 等工具），或者直接使用本地安装的工具，然后调用 xcodebuild 和 fastlane 完成最终的构建和打包
- -
-
-
-
-
-
-### 2. fastlane
-
-fastlane 可以理解为**专业高效的“工人”**。它精通所有 iOS 打包、签名、测试、上传的具体细节，干活又快又好。
-
-是一个自动化命令工具集。
-
-### 3. jenkins
-
-统筹全局的“项目经理”，它不亲手干活，也不提供工具，但负责安排任务、监控进度、触发流程（比如代码一来就让工人工作），并向大家汇报结果。
-
-- 调度与触发：监听 git 代码推送，定时或者其他事件触发整个流水线
-- 流程编排：定义 pipeline 流水线，决定先做什么后做什么
-- 资源管理：分配和管理执行任务的服务器（成为 Agent/Node）
-- 状态监控与报告：集中展示构建结果、测试报告、日志、并发送通知
-
-
-
-### 4. 黄金搭档
-
-```mermaid
-flowchart TD
-A[开发者推送代码] --> B[Jenkins 监听到推送事件]
-
-subgraph Jenkins_Agent_Node[Jenkins 代理节点]
- direction TB
- B --> C[Jenkins 触发 Pipeline]
- C --> D[Pipeline 步骤: 准备环境]
- D --> E["执行 Docker Run启动一个预先构建好的 iOS 构建镜像"] - - subgraph Docker_Container[Docker 容器内部] - direction TB - E --> F[环境内部: 代码已挂载] - F --> G[环境内部: 执行打包脚本] - G --> H["调用 Fastlane (已安装在镜像中)"] - H --> I[Fastlane 执行具体任务] - I --> I1[match 处理证书] - I --> I2[gym 打包 IPA] - I --> I3[pilot 上传 TestFlight] - end -end - -Docker_Container --> J[任务完成, 容器销毁] -J --> K[Jenkins 收集结果并报告] -``` - -上图展示了3者的协作模式：**jenkins 是大脑，负责指挥；Docker 是隔离且一致的环境，负责提供舞台；Fastlane 是主角，在这个环境里执行具体的构建任务** - -为什么需要3者结合？ - -- 环境一致性问题（Docker 的核心价值） - - 问题：没有 Docker 时，Jenkins 所在的 Mac 服务器需要手动安装 Ruby、Fastlane、Xcode 版本等。一旦服务器需要重置或升级，环境配置会很麻烦，且难以保证与本地开发环境一致 - - 解决方案：使用 Docker 镜像来定义构建环境。`Dockerfile` 中明确指定了所有依赖的版本。无论是在开发者的笔记本上，还是在 Jenkins 服务器上，构建环境都是**完全一模一样的**，彻底杜绝了“环境问题”。 -- 专业化与高效（Fastlane 的核心价值） - - 问题：没有 Fastlane，你需要在 Jenkins 上编写复杂的 xcodebuild 脚本，处理代码签名等逻辑 - - 解决方案：Fastlane 用简洁的 Ruby 语法封装了所有复杂命令，提供了“开箱即用”的行动（action），极大简化了自动化脚本的编写和维护。 -- 调度与可视化（Jenkins 的核心价值） - - 问题：只有 Fastlane 和 Docker，你只能在本地手动执行指令，无法自动化出发，团队协作和监控 - - 解决方案：Jenkins 提供了强大的 Web 界面、流水线编排能力、权限管理和通知机制，让整个流程自动化、可视化、可协作 - - - -比如一个典型的场景： - -程序写好的代码提交到 github，提交了 MR： - -- 如果是合并到开发 feature 分支触发 pipeline 流水线任务，检查工程编译情况，编译成功则可以合并 -- 如果是合并到开发 develop 分支触发 pipeline 流水线任务，检查工程编译情况，编译成功后触发单元测试和精准测试 - -如果成功则给 merge request 的提交者和被 reviewer发送邮件，通知测试结果。并且 mr +3 后才可以合并。合并的结果也会通知 - -```shell -// Jenkinsfile -pipeline { - agent any - - environment { - DOCKER_IMAGE = 'your-custom-ios-builder-image:1.0' - PROJECT_URL = 'https://github.com/your/ios-project.git' - // 从环境变量获取GitHub相关信息 - GITHUB_REPO = 'your-org/your-repo' - GITHUB_API_URL = 'https://api.github.com' - } - - parameters { - // 添加参数用于手动触发时指定PR号 - string(name: 'PR_NUMBER', defaultValue: '', description: 'GitHub PR Number (for manual triggers)') - } - - stages { - stage('Checkout and Validate') { - steps { - script { - // 检出代码 - checkout scm - - // 获取当前分支信息 - env.BRANCH_NAME = env.BRANCH_NAME ?: sh(script: 'git rev-parse --abbrev-ref HEAD', returnStd: true).trim() - - echo "Building branch: ${env.BRANCH_NAME}" - - // 检查MR审批状态（如果是PR构建） - if (env.CHANGE_ID) { - checkMRApproval() - } else if (params.PR_NUMBER) { - env.CHANGE_ID = params.PR_NUMBER - checkMRApproval() - } - } - } - } - - stage('Build') { - steps { - script { - docker.image(env.DOCKER_IMAGE).inside { - sh 'fastlane ios build' - } - } - } - } - - stage('Test') { - when { - // 只在develop分支上运行测试 - expression { - return env.BRANCH_NAME == 'develop' || env.BRANCH_NAME.startsWith('release/') - } - } - steps { - script { - docker.image(env.DOCKER_IMAGE).inside { - // 运行单元测试 - sh 'fastlane ios run_unit_tests' - // 运行精准测试 - sh 'fastlane ios run_precision_tests' - } - } - } - } - } - - post { - always { - script { - // 记录构建结果 - currentBuild.description = "Branch: ${env.BRANCH_NAME}, Result: ${currentBuild.currentResult}" - - // 保存测试报告（如果有） - junit 'fastlane/test_output/report.xml' allowEmptyResults: true - } - } - - success { - script { - // 根据不同分支类型发送不同通知 - if (env.BRANCH_NAME == 'develop' || env.BRANCH_NAME.startsWith('release/')) { - // develop/release分支 - 发送详细测试报告 - sendTestSuccessNotification() - } else if (env.BRANCH_NAME.startsWith('feature/')) { - // feature分支 - 发送构建成功通知 - sendBuildSuccessNotification() - } - - // 如果是PR构建，更新PR状态 - if (env.CHANGE_ID) { - updateGitHubStatus('success', 'CI/CD pipeline completed successfully') - } - } - } - - failure { - script { - // 发送失败通知 - sendFailureNotification() - - // 如果是PR构建，更新PR状态 - if (env.CHANGE_ID) { - updateGitHubStatus('failure', 'CI/CD pipeline failed') - } - } - } - } -} - -// 检查MR是否已获得足够审批 -def checkMRApproval() { - echo "Checking MR approval status for PR #${env.CHANGE_ID}" - - // 使用GitHub API检查PR审批状态 - def approvalResponse = sh(script: """ - curl -s -H "Authorization: token \${GITHUB_TOKEN}" \ - -H "Accept: application/vnd.github.v3+json" \ - ${env.GITHUB_API_URL}/repos/${env.GITHUB_REPO}/pulls/${env.CHANGE_ID}/reviews - """, returnStd: true) - - def reviews = readJSON text: approvalResponse - def approvedCount = 0 - - // 计算批准的评审数量 - reviews.each { review -> - if (review.state == 'APPROVED') { - approvedCount++ - } - } - - echo "Found ${approvedCount} approvals (need at least 3)" - - // 如果审批不足，则失败构建 - if (approvedCount < 3) { - error "PR #${env.CHANGE_ID} does not have enough approvals (${approvedCount}/3)" - } -} - -// 发送测试成功通知 -def sendTestSuccessNotification() { - def changeAuthor = env.CHANGE_AUTHOR ?: "提交者" - def reviewers = env.CHANGE_TARGET ?: "评审者" - - // 获取测试覆盖率报告 - def coverageReport = sh(script: "cat fastlane/test_output/coverage.txt 2>/dev/null || echo '无覆盖率数据'", returnStd: true).trim() - - emailext ( - subject: "✅ 测试通过: ${env.JOB_NAME} #${env.BUILD_NUMBER}", - body: """ -
测试通过通知
-项目 ${env.JOB_NAME} 的测试已通过。
- -构建详情:
--
-
- 构建编号: ${env.BUILD_NUMBER} -
- 分支: ${env.BRANCH_NAME} -
- 构建结果: ${currentBuild.currentResult} -
- 构建日志: 查看详情 -
测试覆盖率:
-${coverageReport}
-
- 此MR已获得足够审批，可以合并。
- """, - to: "${changeAuthor},${reviewers}", - mimeType: 'text/html' - ) -} - -// 发送构建成功通知 -def sendBuildSuccessNotification() { - emailext ( - subject: "✅ 构建成功: ${env.JOB_NAME} #${env.BUILD_NUMBER}", - body: """ -项目 ${env.JOB_NAME} 的构建已成功完成。
-构建详情:
--
-
- 构建编号: ${env.BUILD_NUMBER} -
- 分支: ${env.BRANCH_NAME} -
- 构建结果: ${currentBuild.currentResult} -
- 构建日志: 查看详情 -
编译检查通过，可以继续代码审查流程。
- """, - to: env.CHANGE_AUTHOR ?: 'team@example.com', - mimeType: 'text/html' - ) -} - -// 发送失败通知 -def sendFailureNotification() { - def recipients = env.CHANGE_AUTHOR ? "${env.CHANGE_AUTHOR},team@example.com" : 'team@example.com' - - emailext ( - subject: "❌ 构建失败: ${env.JOB_NAME} #${env.BUILD_NUMBER}", - body: """ -项目 ${env.JOB_NAME} 的构建失败。
-构建详情:
--
-
- 构建编号: ${env.BUILD_NUMBER} -
- 分支: ${env.BRANCH_NAME} -
- 构建结果: ${currentBuild.currentResult} -
- 构建日志: 查看详情 -
确保新提交的代码能够与主线代码成功合并、正常工作 | **快速、可靠地将测试通过的代码持续交付给用户**
自动发布流程、减少手动操作带来的错误和延迟 | -| **关注点** | **构建和测试**
- 代码能否编译成功？
- 单元测试能否通过？
- UI 测试能否通过？
- 代码风格是否规范 | **分发和部署**
- 如何打包成 IPA 文件？
- 如何分发给 QA？
- 如何提交到 TestFlight 或 App Store？ | -| **典型任务** | - 触发时机：代码推送（git push）或提 PR 时
- 编译项目
- 运行单元测试
- 运行 UI 测试
- 执行 Lint 工具（如 SwiftLint）
- 生成代码覆盖率报告 | - 触发时机：CI 阶段通过后，或定时触发，或手动触发
- 生成签名证书和配置文件（`match`）
- 打包生成 IPA 文件（`gym`）
- 分发到测试平台（如 `firebase`、`testflight`）
- 提交到 App Store Connect（`deliver`） | -| **产出物** | **测试报告、精准测试覆盖率**
告诉你代码质量、工程健康度 | **可安装的 IPA 包、发布提交结果**
一个可交付给用户的产品 | -| **比喻** | **一个自动化的质量检测流水线**
每提交一个零件，就检查尺寸、规格是否合格（每一段代码） | **一个自动化的包装和物流系统**
将合格的零件包装成产品，打包、运输、分发到商店。 | - -总结：**CI 和 CD 是软件开发生命周期的2个部分。先 CI 再 CD。CI 是 CD 的基础，代码必须先经过 CI 的各类测试（编译成功、单测试覆盖率保证、精准测试覆盖率保证、Lint 成功）保证质量，才可以交给 CD 流程，进行打包和分发（实现价值）**。 - - - -### 4. CI 和 CD 的能力边界是什么？ - -用个例子来描述： - -CI 是质检车间： - -- 输入：新来的原材料（代码提交） -- 过程：自动化流水线进行一系列的质量检查（编译、测试、扫描） -- 输出：通过质检的半成品（编译通过的、测试覆盖率达标的可工作的代码）和一份质检报告 -- 边界：一旦产品贴上“质检合格”的标签，CI 阶段就结束了。不再关心这个半成品接下来的任何状态 - - - -CD 是包装与物流中心： - -- 输入：（CI 车间的输出作为输入）从 CI 车间送来的“合格半成品” -- 过程：将其打包成最终产品（签名、打包 IPA）、贴标签（版本号），然后根据指令分发到不同的目的地（TestFlight、App Store） -- 输出：交付到用户（QA、用户）手中的产品 -- 边界：假设所有的输入都是合格的。核心价值是高效、可靠、无差错地完成分发流程。 - - - -整体流程为： - -```mermaid -graph LR -A[代码提交] --> B[CI流水线] -B --> C{所有检查是否通过?} -C -- 否 --> D[反馈失败 拒绝合并] -C -- 是 --> E[生成合格产物] -E --> F[CD流水线] -F --> G[部署到测试环境] -G --> H[自动化烟雾测试] -H --> I{是否通过?} -I -- 否 --> J[自动回滚] -I -- 是 --> K[人工审批?] -K -- 是 --> L[等待批准] -L -- 批准 --> M[部署到生产环境] -K -- 否 --> M -M --> N[完成交付/部署] -``` - -总结： - -**CI 和 CD 是软件开发生命周期的2个部分。先 CI 再 CD。CI 是 CD 的基础，代码必须先经过 CI 的各类测试（编译成功、单测试覆盖率保证、精准测试覆盖率保证、Lint 成功）保证质量，才可以交给 CD 流程，进行打包和分发（实现价值）** - -**CI 是质量的守门员，其边界在于代码集成阶段的验证和保证；CD 是价值的输送带，其边界在于发布流程的自动化。2者职责分明，先后衔接，各司其职。共同构建了现代软件工程的敏捷、高效的交付流程** - - - - - - - - - - - - - - - diff --git a/Chapter1 - iOS/1.143.md b/Chapter1 - iOS/1.143.md deleted file mode 100644 index 87a92a7..0000000 --- a/Chapter1 - iOS/1.143.md +++ /dev/null @@ -1,461 +0,0 @@ -# AI 对端上的赋能 - - -## 一、实时特征回流 -传统智能的问题、弊端是什么？ - - -- 推荐系统需要收集用户的行为，将这些行为作为用户的意图表征，表征他的偏好，回流到服务端。 -- 服务端拿到这个数据，在发起一次实时请求的时候，会根据用户的行为特征，去商品池里面召回一批用户喜欢的商品，再返回给端上，给用户做展示 -- 同时，这个用户的行为数据，还会作为训练模型的一个样本 - - - -可以发现传统的推荐系统存在一些瓶颈： -- 实时性不足 - 行为数据回流的时效性，会影响算法对于用户意图变化的感知，会影响推荐的准确性。 - 现有的系统，在手淘这种亿级用户体量下面，想要做到用户数据的实时回流，技术上面挑战很大。 - 另外涉及到用户隐私方面的风险考虑，以及在服务端的存储瓶颈相关的考虑，是不能把用户所有的行为都回流到云端 -- 数据丰富度有限 - 在服务端，整个用户行为数据的丰富度非常有限的。 - 同时我们的一次推荐内容的更新，也是受限于一次新的请求时机的发起。 - 即使我们发现用户的意图，通过数据发现了意图的变化，但是也很难实时对用户的前台界面去做一次干预，去及时调整推荐的内容 -- 但用户算力/存储瓶颈 -- 千人一面的模型 - 目前服务端的算法模型更多的还是千人一面。受到算力和存储的瓶颈，很难针对每一个用户去建立一个属于他自己的模型。 - 去做更加精准的预测。 - -针对上面的这些问题，就是端上的智能可以去发挥的空间所在。 - - - -前面说过，用户的数据回流时效性会影响推荐的准确度。那么是不是可以把用户的特征、用户的数据，做到最实时的回流？ -这里，我们做了一些这样的尝试： - - -- 首先可以把用户的最原始的行为数据回流。比如用户在逛手淘的过程中产生的一些浏览、点击等行为回流到服务端 -- 同时，也可以把用户的这些原始行为数据做一定的聚合，生成一个信息量含量更高，但是数据量更小的用户特征数据（数据聚合） -比如把用户在商品详情页的一系列的特征，聚合成用户对商品详情的更精炼的一些数据，比如用户有没有对商品点击过收藏、有没有点击过加购，聚合成 -一条商品详情的浏览特征 -- 也可以对这个特征继续做精加工处理，变成一个算法模型可直接使用的特征向量。当然了，它也可以表征用户的行为和意图 -- 还可以把这个向量做进一步精加工处理，生成一些用户的意图打分。比如用户对于某个商品详情的意图分，是强还是弱，用分数去表明。 - -比如用户在手淘里面浏览的过程当中，用户逛着逛着是不是不感兴趣了？是不是疲劳了？这也可以用来表征用户的一个“跳失意图”。 - -这几种数据都可以回流到服务端的，图上数据可以看到： -- 从左往右：数据的加工度越来越高的、数据量是越来越少的 -- 从右往左：数据量大，信息密度低 - -回流到服务端的时候，对于这4种不同类型的数据，一一做过尝试： -- 首先，如果直接回流用户的原始数据，那么这个数据量会非常大，服务端的存储存在压力。另一方面也会涉及到用户的隐私风险 -- 其次，我们也尝试过，将用户的行为数据聚合成一条向量直接回流到服务端，数据量虽然小了，但是会丢失一些信息。另外向量这种数据格式，通用性会非常的受限。智能针对特定的模型去回流特定的向量。 -- 另外，也尝试过直接回流用户的意图分，比如回流一条对于商品详情页的意图分，在整个手淘的流失的意图，这个数据是有效的，但是它丢失的信息也是非常多的 - -所以最后选择的是将用户的数据在端上做一定的标准的加工化处理，聚合成特征回流到服务端，这是实践过比较好的，既能保证数据的有效性又能保证实时性的一种方式。 - - -### 1. 实时特征回流 - -- 数据本地加工，做标准化处理，然后按照需要将需要的那部分数据回传到服务端 - -解决了什么问题？ -- 提升了数据的丰富度，能够在服务端拿到用户更多的、更细粒度的一些行为数据。能够让服务端的数据输入变得更丰富 -- 通过对数据加工之后，建立一条实时的特征回流通道，保证了从端到云上的数据实时性 - -遗留了什么问题？ -- 通过实时的回流方式，解决了用户实时感知的在实时性方面的问题 -- 但即使感知到了用户意图发生了变化，，也缺少一个实时在前台去干预用户的方式 - - -### 2. 信息流的“回退推荐” -针对实时特征无法具备实时干预能力的问题，在信息流方面做了一种叫“回退推荐的策略” - -想象这样一个场景：用户在商品列表页，对某个商品感兴趣，点击某个商品到达详情页，在详情页看了一番之后，用户点击了收藏或者加入到购物车了。有收藏、加购行为表示用户对这个商品是很感兴趣的。 - -此时，从商品详情页到回退到外面这个商品列表页的时候，会根据用户刚刚的浏览、加购行为，推荐一个相似的商品。 - - - -会根据用户刚刚浏览的这些行为，去给他推荐一个相似的商品。这个过程会发生很多行为，通过滚动、曝光等行为可以推测用户在信息流的浏览意图是逐渐从逛切换到了买。 - -如果页面回退，我们不做干预的情况下，他可能继续往下去浏览，购买这个行为的意图差“临门一脚”就可以转换为一次成交购买。如果不加以干预，可能逛着逛着就丧失购买意愿了，流失一笔潜在交易。 - -选择的策略是：在页面回退的时候，在原来的商品卡片周围，立即推荐一个相似的商品，希望能继续促成，希望能够留住他刚刚这次对商品购买的强意图。这个就是回退推荐。 - -本质上就是抓住了用户从逛到买的这个强意图聚焦。针对强意图的聚焦，做了一次成交转换的促成。 - -商品卡片的回退推荐策略落地上线后，效果是非常好的。比普通商品卡片的转换率高五六倍左右。 - - - - -存在什么问题？ -类似程序员和产品设计沟通出的一种机制，可以理解为命令式编程，是人为先验地找到了一个能够代表用户意图的时机，也就是在回退时机。这种时机靠人去发现梳理，往往是很难覆盖全面的。依赖于对于用户强意图的梳理、选择。那么有没有一种方式可以自动的去预测用户意图的变化？ - - - -## 二、应用场景 - -### 1. 信息流的端侧重排 - -在信息流上面做了另外一个尝试：在本地进行了一次端上的重排。 - - - - -一个用户在逛信息流的过程中，会产生滚动、曝光、点击、加购、收藏、停留、回退、滚动这些行为。从用户的实时的行为序列中，其实是表征了用户背后的一个隐式的意图表达。 - -可以把用户的实时行为序列去输入到一个意图的模型当中，去计算用户当前的意图是什么？他偏好哪些、不喜欢哪些？得到用户的正负一些意图反馈。去判断用户当前是不是正在一个疲劳的状态，去计算他即将要跳失的可能性。 - -然后将这些用户意图，输入到一个本地的实时决策模型中去，去决定接下去要给这个用户去做什么事情。例如用户是不是对于接下来要滚动浏览的商品兴趣是不是发生了变化的时候，能够根据用户的实时意图，去做一次实时的调整，永远把用户最喜欢的内容放在他排序更靠前的位置。 - -或者当发现对这批商品都不感兴趣的时候，就理解去重新更新一次商品。或者当发现用户即将跳失之前，去做一些强干预，去挽留他继续留在这个页面上。比如通过一些权益去做挽留。 - -做完决策后，就可以将这个决策结果通知到前台，去做相应的响应。 - -还存在一些问题： - - -决策选择还是受限于产品策略。程序员还需要和产品去约定设计产品策略。开发和产品共同约定，在用户的某一时机之下，接下来对应的一个处理是什么。它的整个呈现形式和所处业务域还是存在紧密关系的。 - -这种应用形式，应用在信息流上是非常好的，但是很难迁移到其他业务域。 - -### 2. 智能 Push - -在这样的背景之下，接下来开始下一个尝试，去做一个更加通用的、端上的智能应用。去 Push 业务。 - -传统业务上，Push 是服务端发起的。服务端存在一个任务，不断计算：我需要给什么样的一批用户、推送一批什么内容。服务端跑了这个任务后，会圈选一批人群，定一个任务，给这些人要去发一个推送。客户端收到这个推送，展示这个推送的消息内容。 - -服务端发起的 Push 有啥问题？ -- 缺乏感知能力，难以精细化运营 - 服务端不知道用户当前 App 的状态，用户在手淘内还是不在。没有办法知道用户的实时状态，很难针对用户的实时状态去做精细化运营。 -- 被动触达，错失最佳营销时机 - 更希望的是针对用户的某一个精细化行为，去做一次响应的时候，服务端 Push 是做不到的。 - - -完整流程： - - -用户进入手淘后，会不断收集端上的行为（滚动、曝光、点击、加购、收藏、停留）数据，然后会把行为数据输入到另一个意图模型中，去判断他当前的一些实时意图。不断的根据行为做分析。也会输入到另一个决策模型中去，但这个（智能 Push）场景下的决策模型和前面的端上重排场景的决策模型是不一样的。这个决策模型会**判断用户当前的状态适不适合接受一次干预**，或者适不适合接受某一次营销的推荐。当我们发现用户当前处于一个相对空闲的状态，这个时机更适合接受一条干预的时候，我们就会把这个信号通知到服务端。这时候服务端在海量的内容中去筛选出一条对应着用户当前的意图，有效的一条信息，再推送给客户端。 - -这种从客户端发起的 Push 推送相比于服务端推送来说，对于用户当前的实时状态有着非常强的感知的，用户发生的任何一个行为在端上的决策模型中，可以以毫秒级的速度获取到，当我们真的需要去对用户做一次精准的干预的时候，这种方式相比于服务端推送来说，是有着非常大的优势的。 - -- 从“平台视角”向“用户视角”的转变 - 传统的服务端推送是站在平台视角，来去筛选内容、筛选用户去发送消息的。而“端智能 Push”更多站在用户视角，去分析用户在什么时机下适合接受干预。 -- 解决了什么问题 - 对端上单用户的算力空间的充分利用；同时智能 Push 分离了用户的感知决策。用户的感知可以作为一个独立的模块存在。用户的决策：接下来要做什么响应。也是一个比较独立的模块。在应用性上具备初步的可移植性。可以在多个应用场景，不只是信息流这样一个较为垂直的业务域上去使用。 -- 没有解决什么问题？ - 决策依然需要先验制定。 - -我们对于 AI 的期待是美好的，期望 AI 可以帮助我们决定下一步做什么。然而通过这些案例可以发现，现阶段，我们还是只能做到在一个已经决策好的产品框架下面去做。是需要先有一系列的决定（在什么样的情况下面，可以有哪些响应），那么 AI 是帮助这样一个决策的结果更加精准。 - -### 3. 智能预加载 - -根据用户身份、角色、常见行为路径，预测接下去要使用的功能，对可能要进入的页面进行预热、预加载，在用户访问这个页面之前，把页面准备好，来做到秒开的效果。 - -也就是说，如果能精准预测用户下一步将要去往哪里，对于性能来说，提升是会非常明显的。 - -那么最关键问题就是：**如何预测用户下一步将要去往哪里**？ - -### 4. 手势热点识别 - -判断用户热点的操作区域是什么？针对这块区域来做一些定制化的特定推荐。 - -### 5.智能营销投放 - -用算法的更加精准的预测，去替代 以往的业务规则的人群圈选。 - - -对于端智能来时，它属于基础能力。它用在哪里，才是能不能用好的一个关键，也就是业务价值能不能提升。 - -从过去的应用来说，我们认为端智能对于客户端的改变主要体现在： - -- 更多的数据 - 在端上做算法模型的预测，可以拿到用户在端上更富丰富、更细粒度的数据，去避免在服务端取不到这样丰富数据的缺陷。 -- 更实时的响应 - 相比于服务端，很多系统称具有小时、分钟、秒级别的实时响应，在端上的实时性是带来本质性的变化。 -- 更低的消耗 - 闲置算力去运算和存储资源，带来本质上的实时性的提升。同时也节约了服务端资源的消耗。 - - -## 三、端智能整体架构 -要素：算法、数据、调度框架、运行环境 -架构如下： - - -1. 围绕着端上的算法分为2种模型： -- 用户意图计算模型：不断分析用户当前所处状态 -- 决策模型：会根据用户意图计算的结果，去判断下一步要做什么样的处理。比如一次本地重排、还是去做一次数据的重新刷新 - -2. 作为端上的算法输入，建立了一个端上的特征中心，用来提供给端上的算法使用：提供标准的用户行为数据、以及一些特征服务。 - -3. 还建立了端上的用户决策框架：接受用户的每条行为数据，然后根据这些行为去决定接下来什么时机要去唤起一个什么样的模型。拿到这个模型的响应结果后再一路回传到我们的客户端应用层。应用层根据这个结果来做前台界面上的渲染。 - -4. 围绕着端上的算法所在的执行环境，是在底层有一个端计算的容器，提供 Python 的运行环境以及 MNN 轻量级的推理引擎 - -5. 对于整个算法研发的 workflow，配套的做了一个端计算的一体化研发平台。算法同学在这个平台完成开发到发布、再到 AB 实验以及模型训练的一系列工作。 - -模型从这个平台发布后，是会下发到客户端，然后在端上跑。 - -### 1. 端上算法方案 - - - -- Algorhitms Solution On Edge： - - 提供了模型、特征和样本这三大机器学习算法基础组件的端上通用方案 -- Business Solution On Edge： - - 端上推荐算法解决方案，提供了端上实时用户感知和端上智能决策2大模块 - - 通过多任务学习，端上智能决策支持了端上重排、端上智能刷新、端上会话式推荐和端上跳失点预测等任务 -- 千人千模： - - 每个用户训练和部署自己的个人化模型 - - Meta-learning + Federated Learning - -### 2. 端上特征中心 -为端智能应用而设计，提供端侧算法所使用的标准化的全域用户行为数据和特征服务 - -- 定义端侧用户行为标准 - 该特征中心会定义端上用户的行为标准，产生什么样的用户行为，比如用户的浏览行为。这个浏览行为会有一些我的浏览区域、浏览停留时长等等标准化属性。其次，也会有一些像用户手势行为。比如滚动、点击等等。 -- 建立行为数据图化索引 - 具体的实现上，为用户的每个行为，去建立了一个行为的图画的索引，将用户的行动点当作一个节点，并且把节点和节点之间建立了一种关联。这样子能够在端上，让算法可以快速拿到这个数据。 -- 数据标准化 - 同时，采集到这个数据之后。也会对数据做标准化处理。把它经过标准化的字段解析和我们的特征加工，给算法提供简单、易用、可用的数据 -- 通用特征接口服务 - - - -数据分层架构： - - -- 存储层：将采集到的用户行为数据按照约定的标准，在客户端本地做持久化存储。同时对用户数据进行一次加工处理，生成一份信息密度比较高的基础特征表。比如对详情页的浏览行为、App 页面间操作路径的数据、页面浏览的时序特征，这些数据都会存储在客户端本地。 -- 接口层：实时接口层，提供了 Python 层面的接口服务，给算法侧使用。可以做到数据的实时查询，将下层的通用数据、用户行为数据、环境信息等打包好给算法侧使用。 - 这个数据一部分存在端上，一部分存储在云端，和云端有个数据同步需求的： - - 从端同步到云，将一些必要的基础特征同步到服务端，让服务端可以拿到用户实时的聚合好的特征。 - - 从云到端，也可以把云端特有，客户端没有的数据（比如用户画像、历史行为等等）下发下来，这样子可以让端上的算法也能拿到这部分数据，做出更精准的预测。 - - -### 3. 端上的决策中心 - -比如：用户在：我的淘宝 -> 我的订单 -> 订单详情页查看了某个订单详情，然后回退到“我的淘宝”页，这时候会对用户的意图进行分析，判断当前是不是处于一个空闲的状态。如果发现是空闲状态，则给他发送一条 Push 消息，引导进入双11主会场。这个就是一个智能 Push 的案例。 - -还有其他的需求： -- 用户打开 App 直接进入“我的淘宝”查看订单信息，1分钟内未打开商品详情页，回退到“我的淘宝”页面，推送弹窗，可以是红包等权益或者低价商品 -- 用户从搜索/导购产品页面进入商品详情页后停留超过2分钟，且有收藏/加购行为，回退到搜索/导购产品页面后会推荐相似商品 - -这些需求，纯客户端视角下很难完成。所以基于用户行为的端侧事件引擎，提供面向全域用户行为的切面开发模式，打破业务间的隔离，实现以用户为中心的跨业务域的决策能力。 - -这样一个切面能力的好处就是： -- 业务开发同学不需要去关心前面的这一串行为是啥时候触发的、怎么发生的。这个行为的匹配由端上的决策框架去做。 -- 实际的开发同学，只需要去关注在切面发生的时候，我需要去做哪些处理。比如：弹层 - - -这种面向用户行为的切面的编程方式，既可以用在运营规则上，也可以用在算法模型上。后续的响应，可以是弹出弹层、发送 Push、发送1次请求等。 - -### 4. 端计算容器 - -端上的算法模型需要跑在容器里，手淘用的是一个轻量级的推理引擎 MNN。MNN 提供了算法在端上跑模型所需要的算子。 - -## 四、云端一体协同 - -上图是端计算的优势和云计算的劣势。 -未来的端计算并不是完全割裂的。端和云协同才可以迸发最大的效果。 - - -可以看到端和云拥有各自擅长的领域。 - -在做云端协同的过程中，会遇到不少问题。比如在端上触发一次重排的时候，会发现端上的数据量是不够的，如果想要提升端上的重排效果，就要扩大候选池，所以增加了**端上的缓存池**。在端上的模型在本地运行过程中，由于模型本身是在服务端训练的，它的模型和特征向量的同步一致性是需要细节方面处理好的。 -同时由于在端上选择用户时机去做一些干预，实际上对于服务端是带来一些 QPS 增量，如何解决处理使其不是负担也需要处理。 - -这些问题处理好，最后需要回答价值多大问题的时候，就需要做实验验证端计算是否真的有效的时候，在实验的设计、以及后续数据分析、结果归因上，也耗费了大量的精力去论证它的有效性。这些是踩坑之处。 - - - -QA: 决策框架与 MNN 推理引擎的区别是什么？ - -| 维度 | MNN (推理引擎) | 决策框架 | -| :----------- | :-------------------------------------------------------- | :----------------------------------------------------------- | -| **技术定位** | **底层计算基础设施** | **上层业务调度与编排系统** | -| **核心职能** | **“算”** - 高效执行模型计算，输出预测结果（如用户意图分） | **“判”与“调”** - 判断在什么时机、调用哪个模型、并根据结果执行哪个业务动作 | -| **类比** | **笔墨和运笔技法**（负责把字写出来） | **书法家的头脑和章法**（决定何时写、写什么字、怎么写布局） | -| **关注点** | 计算性能、算子支持、模型兼容性、功耗 | 业务逻辑、决策流程、时机控制、动作执行 | -| **输出物** | 模型的数值化输出（如分数、概率） | 一个具体的业务指令（如：重排、刷新、弹窗） | - -为了更好地理解，我们可以看一个它们如何协同工作的例子，比如“端侧重排”： - -1. **决策框架感知时机**：决策框架监控到用户发生了一系列行为（滑动、点击、停留），判断**此时需要重新计算用户意图**。 -2. **决策框架调用MNN**：决策框架**调度**“用户意图计算模型”开始工作，并将必要的特征数据准备好。 -3. **MNN执行计算**：**MNN引擎**加载并运行该模型，进行高速数学计算，最终输出一个**用户当前的意图分数**。 -4. **决策框架做出决策**：决策框架**接收**MNN返回的意图分数，再结合预设的业务规则（例如：分数高于X则触发重排），**判断**下一步应该执行“本地重排”动作。 -5. **决策框架执行响应**：决策框架**通知**前端的渲染模块，对商品列表进行重新排序。 - - - -## 五、AI 在有赞落地了什么场景 - -### 1. 云打印机秒连接 -云打印机接入 OCR + LLM 技术实现 AI 拍照秒识别，秒连打印机，一拍即用，操作简单 -门店商家很多都会去连接打印机，连接过程中成功率只有54%左右。分析了相关原因，发现有2个主要原因： -- 商家找不到打印机的连接入口 -- 打印机的配置过程中需要输入相关的编号和密钥。很容易输错 - -正好 AI 来了，AI 可以结合到打印机的铭牌，做一些智能识别跟参数的推理，然后拿到相关的结果，就可以智能的去调云打印机相关服务厂商的接口，就可以非常完美的解决这个问题。 - -我们对接了非常多的云打印机的品牌厂商，通过 AI 能力，去设计一些提示词，针对这些不同厂商的差异要做一些不同场景的兼容设计，过程中其实踩了不少的坑，不断的调优，让所有的硬件识别准确率提升了非常多。 - -我们的产品改造完之后，在商家平台网页端，硬件添加入口，让商家上传铭牌照片就可以了。原来的十步变成1步。连接成功率也从原来的不到70%提升到97%。 -思路，以后的业务需求，可以尝试跳出 Web 前端能力、Native 能力，从 AI 侧看看有没有更多的可能和思路。 - - -### 2. 基于图像识别算法的零售移动智能收银方案 - -#### 1. 背景 -生鲜果蔬行业在零售行业中是一个较大且比较有特征性的行业，同时在生鲜果蔬行业中，称重秤为经营的刚需类设备。目前商家主要使用条码秤，通过 PLU（Price Lookup Code） 码进行商品的管理，每个 PLU 码对应一个商品，我们可以想象下在超市购买水果的时候会碰到下面这个流程： - - - -所以在门店商品种类比较多时（一个典型生鲜果蔬类商家商品种类大多超过 200 个，随机调研了 5 家有赞果蔬商家，平均 SKU 数量 500+），PLU 码较难记忆清楚，在打秤时需临时查询，称重耗时比较长，为了避免高峰时期排队现象，需在门店增加秤台和打称员，导致商家人力成本较高。 - -因此就前面所提到的场景，我们需要通过更加智能的方式帮助商家加购，那么基于机器学习的图像识别能力就被提上了议程。我们通过条码秤关联的摄像头进行实时拍摄，基于机器学习技术和图像识别技术，将店员放置在秤盘上的商品进行识别，并给出相关商品的列表，减少收银员收银场景中的操作次数，减少商家对新收银员的PLU码的培训并降低熟悉相关商品的培训成本，从而在整体上降低收银员的门槛以及商家的人力成本。所以我们可以得到我们期望的购买流程： - - - -#### 2. 架构设计 -我们针对于商家的痛点和可行的解决方案绘制了下面的流程图： - - -整个流程中的基础能力： -- 实现摄像头对于商品的拍摄 -- 针对于拍摄能力支持图像转换成为商品的能力 -- 将识别结果进行列表化展示 -- 将用户点击之后的结果进行上报，用于商家个性化画像的绘制，以及机器学习模型的加深 -- 支持机器学习模型的动态下发 - - -#### 3. 框架选择 -首先是整个环节的核心点，对于商家商品的关联以及数据模型进行机器学习并完成定时的增量更新流程。通过对比市面上已有的框架，因为 TensorFlow 有 lite 版本单独支持移动端能力，同时结合有赞算法团队已有的技术沉淀，所以敲定使用 TensorFlow 作为机器学习的基础框架。完成了框架的确定，就需要考虑业务场景上的实现了。 - - -#### 4. PLU 码是什么 -PLU 码是生鲜零售行业的 “商品价格查询码”，核心是用一串数字唯一标识一种散装生鲜商品，方便打秤时快速调取价格 -特点： -- 本质是 “商品与价格的关联码”，替代人工记忆商品价格的繁琐操作。 -- 通常由 4-5 位数字组成，可分为行业通用码和商家自定义码。 -- 仅用于散装生鲜（如蔬菜水果、散装零食），预包装商品多用地条码。 - -比如我买了10斤红富士苹果，怎么体现？PLU码会携带重量、价格信息吗？收银员拿到这个 PLU 码之后的处理流程是什么样的？ -PLU 码不只为生鲜类目（主要服务散装非标品），本身不携带重量/价格信息，仅关联 “商品 + 单价”信息。10 斤红富士需通过 PLU 码调单价 + 秤称重算总价，收银员核心流程是 “输码 - 调价 - 称重 - 结算”。 - -##### 1. PLU 码的适用范围：不止生鲜，但聚焦 “散装非标品” -核心适用场景：散装生鲜果蔬（如苹果、生菜）、散装干货（如核桃、枸杞）、散装零食（如糖果、饼干），这些商品无固定包装、需按重量计价。 -非适用场景：预包装商品（如盒装牛奶、袋装面包），这类商品有固定重量 / 价格，用地条码（EAN 码）而非 PLU 码。 -简单说：PLU 码是 “散装称重商品的专属身份码”，生鲜是主要使用场景，但不是唯一场景。 - -##### 2. 10 斤红富士的 PLU 码使用逻辑：重量靠秤、价格靠计算 -PLU 码的核心作用是 “快速调取商品单价”，重量和总价需结合秤的功能实现： -第一步：红富士对应 PLU 码（如通用码 4133），商家已在秤中录入 “4133 = 红富士，单价 8 元 / 斤”。 -第二步：你买 10 斤红富士，打秤员将苹果放在秤上，输入 PLU 码 4133。 -第三步：秤自动读取 “10 斤” 重量，按 “单价 8 元 / 斤 ×10 斤” 算出总价 80 元。 - -关键：PLU 码只负责 “告诉秤这是什么商品、多少钱一斤”，重量是秤测量的，总价是系统实时计算的，三者独立但联动。 - -##### 3. 收银员拿到 PLU 码后的完整流程 -以超市购买 10 斤红富士为例，流程分 5 步： -- 商品上秤：将散装红富士放在条码秤的秤盘上，秤实时显示重量（10 斤）。 -- 输入 PLU 码：收银员手动输入 4133（红富士 PLU 码），或通过扫码枪扫预存的 PLU 码贴纸。 -- 系统调参计算：秤通过 PLU 码调取预设单价（8 元 / 斤），自动计算总价（8×10=80 元）。 -- 打印价签：秤打印含 “PLU 码、商品名、重量、单价、总价、日期” 的价签，贴在商品上。 -- 收银结算：你拿着贴有价签的商品到收银台，收银员扫价签上的条码（或手动输入 PLU 码），收银系统确认价格后完成支付。 - -#### 5. 商品关联 -完成了框架选择，接下来就需要确定如何将商品关联到数据模型上了。 - -有赞的商品有很多的字段，比如说：编码、条码、规格、属性等等。“有赞商品的编码、条码等唯一标识字段，零售场景已支持识别，但这类标识仍需人工关联 PLU 码才能完成称重结算，未能解决‘PLU 码难记忆、打秤查询耗时’的核心痛点。本次 AI 图像识别的核心目标，是通过商品视觉特征直接匹配类目，替代人工查询 PLU 码的操作，实现‘称重 - 识别 - 收银’一体化，而非替代已有条码识别能力 - -我们选择能够区分商品本身存在的差异化的方案——商品类目。 - -有赞的商品类目最大为 4 级，最后基本上已经能够细分到水果的某一个种类中。举个例子：一个苹果，在有赞类目中的选择需要被选择成为 `食品酒水 > 水产肉类/新鲜蔬果/熟食/现做食品 > 新鲜水果 > 苹果`，同时考虑到苹果中仍然存在不同的品种。所以我们在商品类目中追加了水果种类用于区分不同的苹果品种，比如说：金帅、国光、冰糖心…… - - -#### 6. 反馈闭环 -在确定了核心能力的解决方案后，接下来需要解决的是如何将商家本地的数据进行上传，并对于已有模型进行强化。为了更加及时的获得用户本地的选择情况，我们选择了有赞埋点平台作为技术支撑，通过离线缓存，并结合闲时上报的能力，将用户选择图片的整体筛选情况，基于店铺/角色等维护进行拆分，并将最终的选择数据导入 ODS 库中。并在算法前结合用户选择时机的拍摄图片上传 + 用户选择商品情况进行结合，进一步针对于对应店铺的模型进行加强。从而在不断的强化商家模型，从而提高用户准确性。 - - - -#### 7. 流程优化 -要达到好用的程度。所以我们需要对于数据统计流程/用户交互流程进行更加深入的优化 - -##### 1. 自动化类目关联 -考虑到许多商家在使用零售的过程中，如果需要挂载到对应的类目中成本较高，为了减少商家的操作成本。我们基于商家的商品标题 + 图片提供了默认类目和种类的选择。极大程度上降低了用户的操作成本。 - - -##### 2. 图片上传/优化 -根据分析商家的实际使用场景，我们发现部分商家在售卖生鲜果蔬的同时，仍然会同时售卖一些标品，比如说日常的柴米油盐酱醋茶。所以导致商家在正常选择商品时候，设备相机仍然会采集相关照片。从而导致商家返回中会存在一部分无效图片，从而影响后续的数据分析，所以我们需要在进行机器学习算法前进行空盘图片的判断，从而避免无效数据对于数据集的影响。 - -同时由于电子秤的硬件特性：当物品放置到称上的时候，电子秤中的读数从 0 变化到物品实际重量的流程是非线形的，这就导致了，如果我们在这过程中进行数据采集，可能会采集物品非稳定的状态。所以我们约定在电子秤的读数停止变化的时候才进行数据采集，从而保证数据的有效性。 - -除此之外，由于设备的服务商的不同，导致不同服务商对于设备摄像头的调校结果也不相同。有的厂商为了能够更好地将商品拍摄完全，通过广角镜头在较短的视距内获得更好的视野；有的厂商使用了分辨率较低的摄像头导致图像的精细程度没有那么高；有的商家设备由于在运输过程中的震动，导致摄像头拍摄位置发生了偏移。以上种种问题，我们都需要通过一些图形学的解法，将所有的逻辑处理成为统一的结果。所以在最终进入机器学习的算法前，我们需要通过图像处理，对图片进行裁切、锐化、畸变矫正。从而保证了不同设备的数据一致性。当然为了能实现这些细节，我们需要在用户上报信息的过程中追加设备信息，方便后续处理图片针对于不同的商家的设备进行区分，从而保证结果的稳定输出。 - -##### 3. 离线能力支持 -考虑到零售本身的特殊性，很多商家在真实收银的场景当中的网络环境较差，完全的离线的机器学习可能会影响商家的收银流程。所以我们在本地建立了索引，并在用户点选商品后，优先将商品的图像信息转换成为数据与商品关联后在索引中进行插入，并在下一次识别结果中优先展示，从而既保证了商家在第一次使用的时候，基于有赞类目体系有一个基准模型进行下发，也可以在后续不断收银的过程中进行不断优化机器学习的结果，逐步提高机器学习的准确率。 - - - -## 六、QA - -### 1. 什么是索引？ - -#### 通俗化解释 - -想象一下，你是一个新店员，老板给你做培训： - -1. 老板指着一个苹果说：“这个叫‘红富士’，PLU码是4133。” -2. 你的大脑：并不会像相机一样存下苹果的完整图片，而是会提取关键特征——“圆圆的、红色带黄条纹、有个把儿”。你把这些特征和“红富士/4133”这个信息关联起来，记在脑子里。 -这个过程就是 “将商品的图像信息转换成为数据与商品关联”。 -- 商品的图像信息：一张苹果的彩色图片（原始数据，体积大，难以直接比较）。 -- 转换成为数据：通过一个复杂的AI模型（通常是卷积神经网络），从图片中提取出最能代表这个苹果的、最本质的特征向量。这个向量就是一长串数字（比如128或256个数字组成的一个列表），可以理解为这个苹果的 “数字指纹” 或 “特征DNA”。 -- 与商品关联：将这个“数字指纹”（特征向量）与商品信息（如PLU码“4133”、商品名“红富士”）绑定在一起。 -所以，简单来说：它不是存储图片本身，而是存储从图片中提取的、机器可理解的“本质特征”，并把这个特征和商品身份挂钩。 - -#### 索引是什么？为什么是核心？ - -现在，你大脑里已经记住了好几种商品的特征。当顾客又拿来一个水果时，你需要快速判断它是什么。 - -**“索引”就是你所记忆的、所有商品的“特征-DNA -> 商品信息”的快速查询表。** - -在计算机中，**它就是一个专门为"相似性搜索"优化的特殊数据库表。** - -| ID | 商品名称 | PLU码 | 特征向量 | -| :--- | :--------- | :---- | :------------------------- | -| 1 | 红富士苹果 | 4133 | [0.12, 0.95, -0.43, 0.67] | -| 2 | 香蕉 | 4017 | [-0.34, 0.21, 0.88, -0.12] | -| 3 | 西兰花 | 4620 | [0.76, -0.55, 0.09, 0.33] | - -**这个表格本身就是"索引"**——它把商品和它们的"数字指纹"（特征向量）关联起来了。 - -### 关键问题：如何快速查找？ - -您完全正确——**就是通过计算距离，距离越近越匹配！** - -#### 距离计算的直观理解 - -把特征向量想象成在多维空间中的"坐标点"： - -- 红富士苹果：坐标 `[0.12, 0.95, -0.43, 0.67]` -- 香蕉：坐标 `[-0.34, 0.21, 0.88, -0.12]` -- 西兰花：坐标 `[0.76, -0.55, 0.09, 0.33]` - -当新来一个水果，AI也把它转换成一个坐标，比如 `[0.15, 0.89, -0.38, 0.71]`。 - -**系统会计算这个新坐标与索引中所有商品坐标的"距离"**： - -```shell -新水果 vs 红富士苹果：距离 = 0.08 (很近！) -新水果 vs 香蕉：距离 = 1.42 (很远) -新水果 vs 西兰花：距离 = 1.15 (较远) -``` - -#### 实际的查找过程 - -1. **遍历计算**：系统会遍历索引中的每一条记录，计算新向量与该记录特征向量的距离 -2. **排序**：按距离从近到远排序所有商品 -3. **返回Top K**：返回距离最近的3-5个商品作为候选结果 - diff --git a/Chapter1 - iOS/1.144.md b/Chapter1 - iOS/1.144.md deleted file mode 100644 index f39667f..0000000 --- a/Chapter1 - iOS/1.144.md +++ /dev/null @@ -1,325 +0,0 @@ -# Weex 底层原理 - -## Weex 三线程模型 -在查看 Weex 的文章时看到一段文字：JSThread过于繁忙，导致DOM线程和UI线程的堵塞（三者类似于串行的机制运行」该怎么理解？一段跨端引擎不是双线程的吗？UI线程和逻辑线程。为什么这里看上去除了 DOM 线程、还有 UI线程和 js 逻辑线程？ - -文章地址：https://developer.aliyun.com/article/69005 - -要理解Weex中“JSThread、DOM线程、UI线程”的关系，需要结合Weex的架构设计和线程分工来分析。虽然多数跨端引擎（如React Native）采用“逻辑线程（JS）+ UI线程（原生）”的双线程模型，但Weex的早期设计中引入了**DOM线程作为中间层**，形成了独特的三线程协作模式，这也是其与其他引擎的核心差异之一。 - - -先明确三个线程的核心分工 -1. **JSThread（JavaScript线程）**： - 负责执行开发者编写的JavaScript业务逻辑（如数据处理、事件响应、生命周期函数等），是业务逻辑的“计算中心”。 - - -2. **DOM线程**： - Weex的设计中保留了“类浏览器DOM”的抽象层（虽然最终渲染的是原生控件，但中间需要通过DOM树来描述界面结构）。DOM线程的核心作用是： - - 维护虚拟DOM树的状态（比如节点增删、属性更新）； - - 处理布局计算（如通过CSS样式计算节点位置、大小）； - - 将JSThread传来的界面更新指令（如`appendChild`、`setStyle`）转换为可被UI线程理解的“原生渲染指令”。 - - -3. **UI线程（原生主线程）**： - 负责最终的原生控件渲染（如Android的`MainThread`、iOS的`Main Thread`），直接操作原生视图（如`TextView`、`UIView`），是界面真正“可见”的执行者。 - - -### 为什么三者类似“串行机制”？ -Weex中三个线程的协作并非完全并行，而是存在**依赖关系的串行流转**： -JSThread的逻辑执行结果（如“更新某个按钮的文本”）需要先传递给DOM线程，由DOM线程处理DOM树更新和布局计算，再将计算后的“原生渲染指令”（如“修改原生Button的text属性”）传递给UI线程，最终由UI线程执行渲染。 - -这个流程可以简化为： -`JSThread处理逻辑 → DOM线程处理DOM/布局 → UI线程执行渲染` - -如果JSThread过于繁忙（比如执行复杂循环、同步计算），会导致它无法及时将更新指令传递给DOM线程，后续的DOM线程和UI线程就会“等米下锅”，陷入阻塞状态——这就是“JSThread繁忙导致DOM和UI线程堵塞”的原因。 - - -### 为什么Weex需要单独的DOM线程？ -这与Weex的设计初衷有关：早期Weex希望尽可能复用Web前端的开发习惯（如基于DOM的界面描述、CSS布局），因此保留了DOM层作为“桥接层”。DOM线程的存在是为了隔离JS逻辑与原生渲染，专门处理“Web风格的界面描述”到“原生渲染指令”的转换，降低前端开发者的迁移成本。 - -而像React Native这类引擎则更彻底地抛弃了DOM层，直接通过JS线程生成“虚拟组件树”，再传递给UI线程渲染，因此不需要单独的DOM线程，形成了双线程模型。 - - -### 总结 -Weex的三线程模型是其“兼容Web开发习惯”设计的产物：JSThread负责逻辑，DOM线程负责DOM/布局转换，UI线程负责原生渲染。三者因指令流转的依赖关系呈现串行特性，因此JSThread的阻塞会直接导致后续环节停滞，最终表现为界面卡顿。这与其他双线程跨端引擎的核心差异，本质上是架构设计（是否保留DOM层）导致的。 - - -## 「将 JSThread 传来的界面更新指令（如appendChild、setStyle）转换为可被 UI 线程理解的 “原生渲染指令”」这段逻辑在 Weex 最新源码中是哪个文件哪段代码？ - -1. JS 线程指令接收与初步处理（桥接层） - -JS 线程的 appendChild、setStyle 等指令首先通过 WXDomModule 接收（JS 与原生的桥接模块），该类直接对接 JS 调用并解析参数。 -文件：ios/sdk/WeexSDK/Modules/WXDomModule.m -```Objective-C -@implementation WXDomModule - -// 处理 JS 层的 "appendChild" 指令（添加子元素） -- (void)addElement:(NSDictionary *)params callback:(WXModuleCallback)callback { - NSString *pageId = params[@"pageId"]; - NSString *parentRef = params[@"parentRef"]; - NSDictionary *elementData = params[@"element"]; - - // 转发指令到 DOM 处理核心（原 WXDomManager 功能迁移至此） - [[WXSDKManager sharedInstance].domService addElement:elementData - toParentRef:parentRef - pageId:pageId]; - - if (callback) { - callback(@{@"result": @"success"}); - } -} - -// 处理 JS 层的 "setStyle" 指令（更新样式） -- (void)updateStyle:(NSDictionary *)params callback:(WXModuleCallback)callback { - NSString *pageId = params[@"pageId"]; - NSString *ref = params[@"ref"]; - NSDictionary *style = params[@"style"]; - - // 转发样式更新指令到 DOM 处理核心 - [[WXSDKManager sharedInstance].domService updateStyle:style - forRef:ref - pageId:pageId]; - - if (callback) { - callback(@{@"result": @"success"}); - } -} - -@end -``` - -2. DOM 层处理与渲染指令生成（核心转换逻辑） - -JS 指令经 WXDomModule 转发后，由 WXDomService（DOM 服务核心）处理：解析参数、更新虚拟 DOM 树，并生成原生渲染指令（如 “创建视图”“更新样式”）。 -文件：ios/sdk/WeexSDK/DOM/WXDomService.m -```Objective-C -@implementation WXDomService - -// 处理 "添加子元素" 指令，生成原生渲染指令 -- (void)addElement:(NSDictionary *)elementData toParentRef:(NSString *)parentRef pageId:(NSString *)pageId { - // 1. 获取页面上下文的虚拟 DOM 树 - WXDOMTree *domTree = [self _domTreeForPageId:pageId]; - if (!domTree) return; - - // 2. 创建虚拟 DOM 节点（映射 JS 元素） - WXDOMNode *childNode = [WXDOMNode nodeWithData:elementData]; - childNode.ref = elementData[@"ref"]; - - // 3. 更新虚拟 DOM 树（添加子节点） - [domTree addNode:childNode toParentWithRef:parentRef]; - - // 4. 计算布局（转换为原生视图的位置/大小） - [domTree layoutIfNeeded]; - - // 5. 生成原生渲染指令：通知渲染服务创建并添加视图 - [self _renderService createView:childNode - parentRef:parentRef - pageId:pageId]; -} - -// 处理 "更新样式" 指令，生成原生渲染指令 -- (void)updateStyle:(NSDictionary *)style forRef:(NSString *)ref pageId:(NSString *)pageId { - WXDOMTree *domTree = [self _domTreeForPageId:pageId]; - if (!domTree) return; - - // 1. 更新虚拟 DOM 节点的样式 - WXDOMNode *node = [domTree nodeForRef:ref]; - [node updateStyle:style]; - - // 2. 重新计算布局 - [domTree layoutIfNeeded]; - - // 3. 生成原生渲染指令：通知渲染服务更新视图样式 - [self _renderService updateViewStyle:node.computedStyle - forRef:ref - pageId:pageId]; -} - -@end -``` -3. 渲染指令调度到 UI 线程（执行层） - -生成的原生渲染指令由 WXRenderService 接收，并通过 iOS 主线程队列（UI 线程）调度执行，最终转换为 UIView 的操作。 -文件：ios/sdk/WeexSDK/Render/WXRenderService.m -```Objective-C -@implementation WXRenderService - -// 调度 "创建视图" 指令到 UI 线程 -- (void)createView:(WXDOMNode *)node parentRef:(NSString *)parentRef pageId:(NSString *)pageId { - // 封装原生渲染任务（包含 UI 线程所需的视图类型、样式、父节点等信息） - WXRenderTask *task = [[WXRenderTask alloc] init]; - task.action = ^{ - // 获取父组件（原生视图容器） - WXComponent *parentComponent = [self _componentForRef:parentRef pageId:pageId]; - if (!parentComponent) return; - - // 创建原生组件（对应 UIView 实例） - WXComponent *childComponent = [WXComponentFactory componentWithType:node.type - ref:node.ref - style:node.computedStyle - parent:parentComponent - pageId:pageId]; - - // 执行原生视图操作：添加子视图（UI 线程直接调用） - [parentComponent.view addSubview:childComponent.view]; - }; - - // 提交任务到 UI 线程（主线程） - [self _dispatchToMainThread:task]; -} - -// 调度 "更新样式" 指令到 UI 线程 -- (void)updateViewStyle:(NSDictionary *)style forRef:(NSString *)ref pageId:(NSString *)pageId { - WXRenderTask *task = [[WXRenderTask alloc] init]; - task.action = ^{ - // 获取目标原生组件（对应 UIView） - WXComponent *component = [self _componentForRef:ref pageId:pageId]; - if (!component) return; - - // 执行原生样式更新（直接修改 UIView 属性） - component.view.backgroundColor = [WXConvert UIColor:style[@"backgroundColor"]]; - component.view.frame = CGRectMake( - [WXConvert CGFloat:style[@"left"]], - [WXConvert CGFloat:style[@"top"]], - [WXConvert CGFloat:style[@"width"]], - [WXConvert CGFloat:style[@"height"]] - ); - // 其他样式属性（如字体、边框等）的转换... - }; - - // 提交任务到 UI 线程 - [self _dispatchToMainThread:task]; -} - -// 确保任务在 UI 线程执行 -- (void)_dispatchToMainThread:(WXRenderTask *)task { - if ([NSThread isMainThread]) { - task.action(); - } else { - dispatch_async(dispatch_get_main_queue(), task.action); - } -} - -@end -``` -总结：最新代码中，原 WXDomManager 的功能被拆分为： -- WXDomModule：接收 JS 指令并转发； -- WXDomService：处理 DOM 逻辑并生成原生渲染指令； -- WXRenderService：调度指令到 UI 线程并执行原生视图操作。 -这三个文件共同完成了从 JS 线程指令到 UI 线程原生渲染指令的转换，核心逻辑集中在 WXDomService.m（指令转换）和 WXRenderService.m（UI 线程执行）中。 - - -## 为什么 core_side_in_multi_process.cpp 只有 Android 有？按理说 c++ 实现的逻辑 iOS 和 Android 通用的，为什么 Android 侧用 c++，iOS 侧相关逻辑还是 OC 代码实现的。为什么 Weex 团队没有做成共用的，阿里的工程师的水平是够的，为什么这么做 - -Weex 中 Android 侧用 C++ 实现 `core_side_in_multi_process.cpp` 这类核心逻辑，而 iOS 侧仍以 OC 为主，并非“技术能力不足”，而是基于 **平台特性差异、历史演进路径、性能开销权衡、原生生态兼容性** 四大核心因素的理性选择——阿里工程师的技术选型，本质是“优先适配平台最优解”，而非单纯追求“跨平台代码统一”。 - - -### 一、核心前提：Weex 的“跨平台”≠“全平台代码完全一致” -跨平台框架的核心目标是“一次编写、多端运行”，但**底层实现是否用统一语言**，取决于“平台特性是否允许”和“统一后的收益是否大于成本”。Weex 早期设计时，Android 和 iOS 团队是并行推进的，初期更追求“快速落地”而非“底层完全统一”，后续的差异则是“基于平台特性的持续优化”，而非“技术断层”。 - - -### 二、为什么 Android 侧优先用 C++ 实现核心逻辑？ -Android 侧选择 C++（尤其是多进程/线程相关逻辑），本质是为了解决 **Android 平台特有的痛点**： -#### 1. Android 对“多进程”的依赖远高于 iOS -早期 Android 设备普遍存在 **单进程内存限制**（如 4.4 之前单进程内存上限仅 128MB），而 Weex 加载复杂页面时（如包含大量图片、列表），JS 引擎（如 V8）和 DOM 计算会占用大量内存，容易触发 OOM。因此 Weex Android 侧必须支持 **“JS 进程与 UI 进程分离”**（多进程模式），而： -- 多进程通信需要高效的 **序列化/反序列化**（如传递 JS 指令、DOM 数据），C++ 的内存操控能力和二进制序列化效率（如 Protobuf 底层）远高于 Java； -- `core_side_in_multi_process.cpp` 本质是“多进程通信的 C++ 抽象层”，负责 JS 进程与核心进程（DOM 线程）的指令转发，这是 Android 多进程模式的刚需，而 iOS 几乎用不到。 - -#### 2. Android NDK 生态更适合“C++ 与 Java 混合开发” -Android 的 NDK（原生开发工具包）对 C++ 的支持非常成熟： -- 通过 JNI（Java Native Interface），C++ 可以高效调用 Java 层 API（如 UI 线程调度、原生视图创建），且 Android 团队对 JNI 优化多年，桥接开销可控； -- 早期 Android 上的 JS 引擎（如 V8）是 C++ 实现的，用 C++ 写核心逻辑可以直接对接 V8 的 C++ 接口，避免“Java → JNI → C++”的多层桥接损耗（如果用 Java 写核心逻辑，调用 V8 反而需要额外 JNI 开销）。 - -#### 3. Android 对“性能极致优化”的需求更迫切 -早期 Android 设备硬件性能差异极大（从低端机到旗舰机），而 DOM 计算、布局排版（如 Flex 布局）是高频耗时操作： -- C++ 是编译型语言，执行效率比 Java 高 30%~50%（尤其是循环计算、内存密集型操作），用 C++ 实现 DOM 树维护、布局计算，可以缓解低端机的卡顿； -- Android 侧的“核心线程”（DOM 线程）需要处理大量并发任务，C++ 的线程库（如 `std::thread`）比 Java 的 `Thread` 更轻量，调度开销更小。 - - -### 三、为什么 iOS 侧仍用 OC 实现核心逻辑？ -iOS 侧不依赖 C++ 做核心逻辑，是因为 **iOS 平台特性完全不需要，且 OC 更适配 iOS 原生生态**： -#### 1. iOS 几乎不需要“多进程模式”，C++ 多进程逻辑无意义 -iOS 有两大特性决定了 Weex 无需多进程： -- **单进程内存限制宽松**：iOS 对单进程内存的限制远高于同期 Android（如 iPhone 6 单进程内存上限达 1GB），Weex 单进程运行（JS 线程+UI 线程）完全足够，无需拆分多进程； -- **多进程限制严格**：iOS 的沙盒机制和后台进程管理极严，除了系统应用（如 Safari、微信），第三方框架启用多进程会面临“审核不通过”“后台进程被强杀”等问题，Weex 作为嵌入框架，根本无法使用多进程模式——因此 `core_side_in_multi_process.cpp` 这类多进程相关的 C++ 代码，在 iOS 上完全是“无用代码”。 - -#### 2. OC 与 iOS 原生生态的“零成本对接”，C++ 反而增加开销 -iOS 的 UI 框架（UIKit）、JS 引擎（JavaScriptCore）都是 OC 原生支持的： -- **UIKit 是 OC 接口**：如果用 C++ 写渲染逻辑，需要通过“C++ → OC 桥接”（如 `extern "C"` 封装）才能调用 `UIView`、`AutoLayout` 等 API，桥接过程会产生额外的内存拷贝和类型转换开销（高频 UI 更新时，这种开销会被放大）；而用 OC 写，能直接调用 UIKit API，零桥接损耗； -- **JavaScriptCore 与 OC 无缝交互**：iOS 的 JS 引擎（JavaScriptCore）原生提供 OC 接口（如 `JSContext`、`JSValue`），JS 线程的指令可以直接通过 OC 传递到 DOM 层，无需 C++ 中转——如果强行用 C++，反而需要“JS → C++ → OC”的多层转换，效率更低。 - -#### 3. iOS 硬件性能更均匀，OC 性能完全够用 -iOS 设备的硬件生态高度统一（仅苹果自研芯片），性能差异远小于 Android： -- 即使是低端 iOS 设备（如 iPhone SE 第一代），OC 处理 DOM 计算、布局排版也能满足流畅度需求（OC 是编译型语言，性能接近 C++，且苹果对 Clang 编译器优化极深）； -- 阿里工程师曾做过测试：iOS 侧用 OC 实现 DOM 核心逻辑，比用 C++ 少了 15% 的桥接开销，反而更流畅——既然 OC 能满足性能需求，且开发效率更高，就没必要强行用 C++。 - - -### 四、为什么不做成“C++ 统一核心”？—— 统一的成本远大于收益 -阿里工程师并非没能力做 C++ 统一核心，而是“做了反而亏”： -#### 1. 跨平台适配成本极高 -iOS 和 Android 的底层差异太大： -- **线程模型不同**：Android 用 Looper/Handler 调度线程，iOS 用 GCD/RunLoop，C++ 统一线程调度需要封装两层适配（如 C++ Thread → Android Looper / iOS GCD），反而增加复杂度； -- **UI 调用方式不同**：Android 的 View 可以通过 JNI 从 C++ 调用，iOS 的 UIKit 必须在主线程用 OC 调用，C++ 统一渲染逻辑需要额外写“C++ → OC”的桥接层，代码量比单独用 OC 还多。 - -#### 2. 开发与调试效率下降 -- **iOS 开发者更熟悉 OC/Swift**：Weex iOS 团队早期以 OC 开发者为主，用 OC 写核心逻辑能快速迭代，而用 C++ 会增加学习成本和调试难度（如 Xcode 对 C++ 的调试支持不如 OC，内存泄漏排查更复杂）； -- **C++ 与 OC 的混合开发坑多**：比如 C++ 的异常机制与 OC 的 `@try/@catch` 不兼容，内存管理（C++ 的 `new/delete` 与 OC 的 ARC）容易出现野指针，反而增加 Bug 率。 - -#### 3. 性能收益为负 -如前所述，iOS 侧用 C++ 会增加“C++ → OC”的桥接开销，而 OC 本身的性能已足够支撑 Weex 的需求——统一成 C++ 不仅没提升性能，反而可能导致界面卡顿（尤其是高频更新场景，如列表滚动）。 - - -### 五、本质：阿里工程师的“技术选型理性”—— 不唯技术，只唯场景 -Weex 作为阿里内部孵化的框架，核心目标是“服务业务”（如淘宝、支付宝的移动端页面），而非“做技术标杆”。技术选型的唯一标准是： -- **能否解决平台痛点**（Android 用 C++ 解决多进程和性能问题）； -- **能否降低开发成本**（iOS 用 OC 适配原生生态，减少调试成本）； -- **能否保证业务稳定**（不强行重构成熟的 OC 逻辑，避免线上 Bug）。 - -这种“不追求形式上的统一，只追求场景下的最优”，恰恰是阿里工程师技术成熟的体现——跨平台的核心是“体验统一”，而非“代码统一”。 - - -### 总结 -Weex Android 侧用 C++、iOS 侧用 OC 的差异，是： -- **Android 为解决多进程、性能痛点，选择 C++**； -- **iOS 为适配原生生态、降低开销，选择 OC**； -- 并非“技术能力不足”，而是“基于平台特性的最优解”。 - -如果强行将 iOS 侧核心逻辑改成 C++，只会导致“开发效率下降、性能损耗增加、Bug 率上升”，完全不符合业务需求——这才是阿里工程师不做统一的根本原因。 - - - -## 增强并发 - - - - -上图左侧是未经优化前JS&Native通信流程，可以看出，每当JS发送一个callNative时，Native都会有一个callJS回调，这种方式更类似于JS同Native握手的方式，这种设计方式保证了页面渲染时所需的时序性。 - -图中右侧的通信流程之所以比左侧少很多callJS，是因为在JS Render中进行简单的队列维护既可以满足时序要求。针对特殊的渲染指令，如同步依赖上一渲染完成事件才能开始下一个渲染指令的情况，再对其进行callJS的强制回调；但大部分的渲染指令无需同步的callJS回调约束。 - - -思考：为什么从 native 回调给 js 需要用一个队列去做，但是从 js call native 不用一个队列去做？这样做不是可以起到防抖的目的吗？为什么设计上不对称 - - -js call native 后，对每个方法都进行编号，执行完成后也设计为类似一个 map 的效果，key 为 methodId， value 为回调函数，回调函数携带 methodID，JS 根据 methodID 决定处理哪段逻辑不行吗？ - -不行。用 methodId + map 匹配回调）确实能解决 “回调与原始调用的归属匹配” 问题（即 “哪个回调对应哪个 callNative”），但无法解决 “回调执行的时序一致性” 问题。这两者的核心区别在于：methodId 解决的是 “谁的回调”，而队列解决的是 “按什么顺序执行回调”。 - - -不能解决的问题：“执行时序”。methodId 只能保证 “回调被正确匹配到原始调用”，但无法保证 “回调的执行顺序与业务预期的时序一致”。这一点在 Native→JS 回调 中尤为明显，因为 Native 是多线程模型，可能出现 “先触发的回调后到达 JS，后触发的回调先到达 JS” 的情况。 - - -### 为什么 Native→JS 必须用队列保证时序？ -假设一个场景：Native 中两个回调需要按顺序执行（业务依赖时序）： -- 线程 A 触发回调 A（如 “列表第 1 项渲染完成”）； -- 线程 B 触发回调 B（如 “列表第 2 项渲染完成”）。 -业务预期是 A 先执行，B 后执行（保证列表渲染顺序正确）。但由于 Native 多线程并行，可能出现： -- 线程 B 的回调 B 先通过 callJS 发送到 JS； -- 线程 A 的回调 A 后发送到 JS。 -此时，即使 A 和 B 都有 methodId，JS 会先执行 B 再执行 A，导致业务逻辑错误（列表渲染顺序颠倒）。 -队列的作用正是强制让 JS 按 “Native 触发回调的顺序” 执行： -无论 Native 多线程如何并发触发，所有回调先进入 JS 端的队列； -JS 单线程按 “入队顺序” 依次执行（先入队的 A 先执行，后入队的 B 后执行），保证时序与业务预期一致。 - - - diff --git a/Chapter1 - iOS/1.145.md b/Chapter1 - iOS/1.145.md deleted file mode 100644 index e69de29..0000000 diff --git a/Chapter1 - iOS/1.146.md b/Chapter1 - iOS/1.146.md deleted file mode 100644 index 75976e6..0000000 --- a/Chapter1 - iOS/1.146.md +++ /dev/null @@ -1,1898 +0,0 @@ -# Weex 底层原理与 APM - -> 从 Vue 组件库（Vue Lib）到 Weex 渲染为 iOS 原生 UIKit 元素，核心是 “Virtual DOM → 跨线程通信 → Native DOM 构建 → 布局计算 → 原生 View 渲染 → 事件反向绑定” 的完整链路。Weex 作为中间层，主要完成 7 大核心工作。 -> -> Weex 是诸多年前的产物，部分业务线用 Weex 写了部分功能模块，或者是某几个页面，或者是某个二级、三级业务 SDK 的页面。但可以确定的是：新业务的实现只会在 Native 和 Flutter 上考虑；Weex 业务代码基本上是存量的；所以像 Native 一样去全面监控性能、网络、crash、异常、白屏、页面加载耗时等维度的话，ROI 是很低的。那么就需要制定一些策略去有针对性的监控高优问题。这时候就需要摒弃程序员视角（不然会陷入啥数据都想统计，可能是洁癖、可能是追求），但从 ROI 角度出发，我们就需要切换到用户视角。 -> -> 按照异常等级，可以划分为影响业务和不影响业务。什么叫“影响业务”？这是我们自己定义的标准，影响用户是否正常操作 App。比如：页面白屏（页面全部白屏、页面部分白屏）、点击某个按钮无响应，这些叫做“影响业务”，属于 Error 级别。其他的一些轻微异常，不影响用户使用 App 功能，不影响业务，属于 Warning 级别。 -> -> 关于异常的一些北极星指标的定义，以及 Weex 侧的稳定性与异常监控怎么做？请带着问题看文章 - -## 一、核心步骤 - -从 Vue Lib 到 Weex 原生 UIKit 元素的完整流程。 - -首先，用户的需求是 “列举 Weex 做的事情” 并 “结合最新源码标位置”，所以思考过程要先拆解流程：从 Vue 编译产物处理、JS-Native 通信、Virtual DOM 解析、DOM 构建与布局计算、渲染指令生成、原生 View 创建与更新，这几个核心步骤。每个步骤都要对应 Weex 的具体工作，还要找到最新源码中的对应类和方法。 - -第一步，应该是 Vue 编译产物的适配。因为 Vue 写的代码要被 Weex 识别，Weex 需要处理 Vue 的模板编译结果（比如 render 函数生成的 Virtual DOM），还要注入 Weex 的 JS Runtime API。这里要找最新源码中 JS Runtime 的初始化类，比如 WXJSContext 或 WXBridgeCore，因为 JS 环境的搭建是第一步。 - -第二步，JS-Native 通信的建立。Vue 的 Virtual DOM 变化需要传递给 Native，所以 Weex 的 Bridge 核心要注册通信方法（比如 callNative），这里对应 WXBridgeCore 的 invokeNative 方法，之前讨论过 bridge 队列，这里要结合最新源码中通信任务的调度。 - -第三步，Virtual DOM 的解析与 DOM 树构建。Weex 需要把 Vue 的 Virtual DOM（JSON 结构）解析成 Native 侧的 DOM 节点（WXDOMNode），这部分现在在 WXDOMCore 中，比如 createNode 方法，处理节点创建、属性更新，还要维护 DOM 树结构。 - -第四步，样式解析与 Yoga 布局计算。Vue 的样式（比如 flex）要被 Weex 解析，转换为 Yoga 的布局属性，然后在 dom 线程计算布局，这部分在 WXDOMCore 的_scheduleLayout 方法，调用 Yoga 的 calculateLayout。 - -第五步，渲染指令生成与传递。DOM 和布局计算完成后，要把结果封装成渲染指令（节点 ID、frame、类型等），通过主线程传递给渲染核心，这里是 WXDOMCore 的_notifyRender 方法，切换到 main queue。 - -第六步，原生 UIKit 元素的创建与更新。渲染核心（WXRenderCore）接收指令，创建对应 UIKit 控件（UILabel、UIImageView 等），或复用已有 View，更新 frame 和样式，这部分在 WXRenderCore 的 render 方法，还有具体的 View 工厂类（比如 WXViewFactory）。 - -第七步，事件绑定与反向通信。原生 UI 的事件（比如点击）要传递回 Vue，Weex 需要注册 Native 事件，通过 Bridge 回调 JS，这里对应 WXEventDispatcher 和 WXBridgeCore 的 callbackJS 方法。 - -具体的逻辑不做深入探讨，可以查看源码研究。 - - - -## 二、Yoga - -### 1. 支持"增量布局更新" - -当组件样式变化时，Yoga 仅重新计算受影响的组件树分支，而非全量重算，大幅减少 RN 应用的布局耗时和卡顿』Yoga 是如何实现仅计算受影响的组件树分支的？类似有个打标记，标记为 dirty？ - -Yoga 实现增量布局的核心就是 「Dirty 标记机制」+「组件树依赖传播」—— 通过标记 “受影响的节点”，并仅处理这些节点及其关联分支，避免全量重算。 - -#### 1. YogaNode 与 Dirty 状态标识 -Yoga 中每个组件对应一个 YogaNode（布局计算的最小单元），每个节点都包含 3 个关键状态标记（用于判断是否需要重算）： -- dirtyFlags（核心标记）：记录节点的 “脏状态类型”，主要分两类： - - LAYOUT_DIRTY：节点自身样式（如 width、flex）或子节点布局变化，需要重新计算自身布局； - - MEASURE_DIRTY：节点的测量相关属性（如 measureFunction 自定义测量逻辑）变化，需要先重新测量尺寸，再计算布局。 -- isLayoutClean：布尔值，快速判断节点是否 “干净”（无脏状态），避免重复检查 dirtyFlags； -- childCount + children 指针：维护子节点列表，用于后续遍历依赖分支。 - - -#### 2. 脏状态触发与传播：从 “变化节点” 到 “根节点” 的冒泡 -当组件样式变化时（如 RN 中修改 style={{ flex: 2 }}），Yoga 会触发以下流程： - -- 步骤 1：标记自身为 Dirty -直接修改变化节点的 dirtyFlags |= LAYOUT_DIRTY（或 MEASURE_DIRTY），同时设置 isLayoutClean = false。 - -- 步骤 2：向上冒泡通知父节点 -由于父节点的布局（如尺寸、位置）依赖子节点的布局结果（比如父节点是 flex:1，子节点尺寸变化会影响父节点的剩余空间分配），因此会递归向上遍历父节点，直到根节点，将所有 “依赖节点” 都标记为 LAYOUT_DIRTY。 -关键优化：父节点仅标记 “需要重算”，但不会立即计算，避免中途重复触发计算。 - -- 步骤 3：跳过已标记的节点 -若某个节点已被标记为 Dirty，后续重复触发时会直接跳过（避免重复冒泡），提升效率。 - -#### 3. 布局计算阶段：只处理 Dirty 分支，跳过干净节点（DFS） -当 Yoga 触发布局计算（如 RN 渲染帧触发、组件挂载完成）时，会从根节点开始遍历组件树，但仅处理 “Dirty 节点及其子树”： - -- 步骤 1：根节点判断状态 -若根节点是干净的（isLayoutClean = true），直接终止计算（全量跳过）；若为 Dirty，进入分支处理。 - -- 步骤 2：递归处理 Dirty 分支 -对每个节点，先检查自身状态： -- 若干净：直接复用上次缓存的布局结果（x/y/width/height），不重算； -- 若 Dirty： - - 先处理子节点：如果子节点是 Dirty，先递归计算子节点布局（保证父节点计算时依赖的子节点数据是最新的）； - - 再计算自身布局：根据 Flex 规则（如 flexDirection、justifyContent）和子节点布局结果，计算自身的最终尺寸和位置； - - 清除 Dirty 标记：计算完成后，设置 dirtyFlags = 0、isLayoutClean = true，标记为干净。 - -- 步骤 3：增量更新的核心效果 -比如修改一个列表项的 margin，只会标记该列表项 → 父列表容器 → 根节点为 Dirty，其他列表项、页面其他组件均为干净，会直接跳过计算，仅重算 “列表项→父容器” 这一小分支。 - -### 2. Flex 布局逻辑如何到 Native 系统 - -Flex 布局逻辑，或者说 DSL，是如何翻译为 iOS 的 AutoLayout 和 Android 的 LayoutParams 的？ - -Yoga 先将 Flex DSL 解析为统一的「布局计算结果」（节点的 x/y/width/height、间距、对齐方式等），再根据平台差异，将计算结果 “映射” 为对应平台的原生布局规则——iOS 映射为 AutoLayout 约束，Android 映射为 LayoutParams + 原生布局容器属性。 - -#### 1. 第一步：通用前置流程（跨平台统一） -无论 iOS 还是 Android，Yoga 都会先完成以下步骤，屏蔽 Flex DSL 的解析差异： -1. 解析 Flex 样式：将上层框架的 Flex 配置（如 RN 的 StyleSheet、Weex 的模板样式）解析为 YogaNode 的属性（如 flexDirection、justifyContent、margin、padding 等）； -2. 执行布局计算：通过 Flexbox 算法（基于 Web 标准），计算出每个 YogaNode 的最终布局数据： -- 固定属性：width/height（含 auto/flex 计算后的具体数值）、x/y（相对父节点的坐标）； -- 间距属性：marginLeft/Top/Right/Bottom、paddingLeft/Top/Right/Bottom； -- 对齐属性：alignItems、justifyContent 对应的节点相对位置关系； -3. 输出标准化布局数据：将上述结果封装为平台无关的结构体，供后续平台映射使用。 - -#### 2. 第二步：iOS 端：映射为 AutoLayout 约束（NSLayoutConstraint） -AutoLayout 的核心是「基于约束的关系描述」（而非直接设置坐标），因此 Yoga 会将 “计算出的具体尺寸 / 位置” 转化为 UIView 的约束（NSLayoutConstraint），核心映射规则如下：一一翻译 css 规则到 iOS AutoLayout 写法： - -| Flex 核心属性 | 对应的 AutoLayout 约束逻辑 | -| ----------------------------------------------------- | ------------------------------------------------------------ | -| `width: 100` | 映射为 `view.widthAnchor.constraint(equalToConstant: 100)` | -| `height: auto` | 先通过 Yoga 计算出具体高度（如文字高度、子节点包裹高度），再映射为 `heightAnchor` 约束；若为 `flex:1`，则映射为 `heightAnchor.constraint(equalTo: superview.heightAnchor, multiplier: 1)`（占满父容器剩余高度） | -| `marginLeft: 20` | 映射为 `view.leadingAnchor.constraint(equalTo: superview.leadingAnchor, constant: 20)` | -| `marginTop: 15` | 映射为 `view.topAnchor.constraint(equalTo: superview.topAnchor, constant: 15)` | -| `justifyContent: center`（父节点 flexDirection: row） | 父节点约束：`view.centerXAnchor.constraint(equalTo: superview.centerXAnchor)`；若有多个子节点，通过调整子节点间的 `spacing` 约束实现均匀分布 | -| `alignItems: center`（父节点 flexDirection: column） | 子节点约束：`view.centerYAnchor.constraint(equalTo: superview.centerYAnchor)` | -| `flex: 1`（子节点） | 映射为 `view.widthAnchor.constraint(equalTo: superview.widthAnchor, multiplier: 1)`（横向占满）+ 父节点的 `distribution` 约束（分配剩余空间） | - -补充信息： - -- Yoga 会为每个 `UIView` 关联一个 `YogaNode`，布局计算完成后，通过 `YogaKit`（或上层框架如 RN 的原生层）自动生成约束； -- 支持 “约束优先级” 适配：比如 `flex:1` 对应的约束优先级会高于固定尺寸约束，确保 Flex 规则优先生效； -- 混合布局兼容：若原生视图已有部分 AutoLayout 约束，Yoga 会生成 “补充约束”，避免冲突（通过 `active`属性控制约束启用 / 禁用）。 - - - -## 三、Weex 剖析 - -```mermaid -sequenceDiagram - participant V as Vue组件 - participant J as JS Framework - participant B as JS-Native Bridge - participant N as Native引擎 - participant P as 原生UI - - V->>J: .vue单文件 (template/style/script) - Note right of J: 编译阶段
weex-loader编译Vue组件 - J->>J: 生成Virtual DOM树 - Note right of J: 运行阶段
JS Framework管理VNode生命周期 - J->>B: 通过callNative发送
渲染指令JSON - Note right of B: 通信层
将JS调用转为原生模块调用 - B->>N: 传递渲染指令 - Note right of N: 原生渲染引擎
WXRenderManager (Android)
WXComponent (iOS) - N->>N: 解析指令，创建/更新组件树 - N->>P: 调用原生API渲染
（e.g., UIView, TextView） - P->>P: 最终原生视图 -``` - -下面针对核心机制详解与源码定位 - -### 1. 编译阶段：从 Vue 到 Virtual DOM - -- 处理 Vue 单文件：开发者的`.vue`文件通过 Webpack 和 `weex-loader` 编译成 JavaScript Bundle。这个 Bundle 包含了渲染页面所需的所有信息 -- 生成Virtual DOM：在JS运行时，Vue.js（或 Rax）的渲染函数会生成一棵 Virtual DOM树（VNode）。Weex 的 JS Framework 会拦截常规的 DOM 操作，将其导向 Weex 的渲染管道 - -源码相关：编译过程主要涉及 `weex-loader` (在 `weex-toolkit` 项目中)，而 JS Framework 对 VNode 的处理在 `js-framework` 目录下。重点关注 `src/framework.js` 中的 `Document` 和 `Element` 类，它们模拟了 DOM 结构 - -### 2. 指令生成与通信 - -- 序列化为渲染指令（json 数据）：JS-Framework 不会直接操作 Dom，而是把对 Dom 的操作，描述成对 VNode 对象的创建、更新、删除等，序列化成一种特殊的 JSON 格式的渲染指令。比如 - - ```json - { - "module": "dom", - "method": "createBody", - "args": [{"ref": "1", "type": "div", "style": {...}}] - } - ``` - -- JS-Native 桥接：这些指令通过 callNative 方法，从 JS 端发送到 Native 端，同时 Native 端也可以通过 callJS 方法向 JS 端发送事件（比如用户点击） - -### 3. 原生端渲染 - -- 指令解析与组件渲染：Native 端的渲染引擎（如 Android 的 WXRenderManger 和 iOS 的 WXComponentManager）接收并解析 JS 指令。Weex 维护了一个从 JS 组件到原生 UI 组件的映射表。（例如
` 根节点），绑定到页面根视图；
- - 子组件创建（`addComponent:type:parentRef:`）：根据 JS 端指令，创建子组件并关联父组件，存入 `_indexDict`（组件 ref → 实例映射，快速查找）。
-- 更新组件关系
- - 移动组件（`moveComponent:toSuper:atIndex:`）：调整组件在组件树中的位置，同步更新视图层级；
- - 删除组件（`removeComponent:`）：从组件树和索引字典中移除组件，递归删除子组件，释放视图资源。
-- 组件查询与遍历
- - 按 ref 查找组件（`componentForRef:`）：供 JS 端 `this.$refs` 访问原生组件实例；
- - 遍历组件树（`enumerateComponentsUsingBlock:`）：支持递归遍历所有组件（如性能统计、全局样式更新）
-
-#### 3. 数据绑定辅助：绑定规则的提取与存储
-
-配合 `WXComponent+DataBinding` 模块，`WXComponentManager` 在组件创建时，从 JS 端传递的 `props`/`styles`/`attributes` 中提取「绑定表达式配置」，为响应式更新铺路。核心工作：
-
-- 提取绑定规则：
- - `_extractBindings:`：从样式 / 属性中提取 `[[repeat]]`/`{"@binding": "expr"}` 等绑定配置，移除原始字典中的绑定字段（避免干扰普通属性处理）
- - `_extractBindingEvents:`：从事件数组中提取绑定参数（如 `onClick` 的回调表达式）；
- - `_extractBindingProps:`：提取组件自定义 props 绑定（`@componentProps`）。
-- 存储绑定规则：调用组件的 `_storeBindingsWithProps:styles:attributes:events:`，将提取的绑定配置存入组件实例，后续数据变化时触发表达式计算。
-
-#### 4. 组件更新调度：样式 / 属性 / 事件的 “同步与执行”
-
-当 JS 端触发组件更新（如修改样式、属性、绑定事件）时，`WXComponentManager` 负责「跨线程调度、数据预处理、UI 同步」，确保更新流程高效且安全。
-
-- 样式更新（`updateStyles:forComponent:`）
- - 组件线程：过滤无效样式（如空值），更新组件实例的样式数据，触发布局计算；
- - 主线程：通过 `_addUITask` 将样式更新任务（如设置 `CALayer.backgroundColor`、`UILabel.font`）批量调度到主线程执行。
-- **属性更新（`updateAttributes:forComponent:`）**：类似样式更新，组件线程处理数据逻辑，主线程更新原生组件属性（如 `UIImageView.image`、`UIScrollView.contentOffset`）。
-- 事件绑定 / 解绑
- - 组件线程：维护组件的事件列表（如 `click`/`scroll`）；
- - 主线程：绑定 / 移除原生手势识别器（如 `UITapGestureRecognizer`），捕获用户交互。
-- **批量更新优化**：通过 `performBatchBegin`/`performBatchEnd` 标记批量更新范围，合并多个 UI 任务，减少主线程调度次数（提升性能）。
-
-#### 5. 布局调度与 UI 同步：从布局计算到 UI 渲染
-
-Weex 采用 Flex 布局引擎（Yoga），`WXComponentManager` 负责布局计算的触发、组件 frame 分配、UI 任务批量执行，确保组件按预期位置渲染。
-
-- 触发布局计算：组件更新、根视图尺寸变化（`rootViewFrameDidChange:`）时，调用 `_layoutAndSyncUI` 触发 `WXCoreBridge` 执行 Yoga 布局计算，得到所有组件的 frame。
-- 分配组件 frame：`layoutComponent:frame:isRTL:innerMainSize:` 将计算后的 frame 分配给组件，若为根组件，同步更新页面根视图尺寸（适配 `wrap_content` 模式）。
-- UI 任务同步：`_syncUITasks` 批量执行 `_uiTaskQueue` 中的 UI 任务（如 `addSubview`、`setFrame`），异步调度到主线程，避免频繁主线程切换导致掉帧。
-- 帧率同步：通过 `WXDisplayLinkManager` 监听屏幕刷新率（60fps），确保布局更新与帧率同步，提升渲染流畅度。
-
-
-
-#### 6. 生命周期与资源释放：页面卸载时的 “清理工作”
-
-当 Weex 页面销毁（`WXSDKInstance` 卸载）时，`WXComponentManager` 负责清理组件资源，避免内存泄漏。
-
-核心工作（`unload` 方法）：
-
-- 停止布局调度：调用 `_stopDisplayLink`，停止帧率监听和布局计算；
-- 解绑渲染资源：遍历所有组件，解除与底层渲染对象（`RenderObject`）的绑定；
-- 释放 UI 资源：调度到主线程，销毁所有组件的原生视图（`_unloadViewWithReusing:`）；
-- 清空状态：清空 `_indexDict`、`_uiTaskQueue`、`_fixedComponents` 等容器，解除与 `WXSDKInstance`的绑定。
-- 清除事件绑定：清除所有的事件、手势等逻辑
-
-
-
-## 七、WXModule 的注册机制及其调用流程
-
-```mermaid
-sequenceDiagram
- participant JS as JS环境
- participant B as WXBridge
- participant MF as WXModuleFactory
- participant MM as WXModuleManager
- participant MI as Module实例
- participant MC as 自定义Module
-
- Note over JS,MC: 注册阶段
- MC->>+MF: registerModule("customModule", MyModule.class)
- MF->>MF: 生成ModuleFactory并缓存
- MF->>MF: 反射解析@JSMethod方法
- MF->>B: 将模块&方法信息传递给JS
-
- Note over JS,MC: 调用阶段
- JS->>+B: weex.requireModule('customModule').myMethod(args)
- B->>+MM: 调用 invokeModuleMethod
- MM->>+MF: 获取Module实例和方法Invoker
- MF->>MF: 查找/创建Module实例
- MF->>MF: 获取方法Invoker
- MF->>MM: 返回实例和Invoker
- MM->>+MI: 通过Invoker.invoke调用
- MI->>+MC: 执行原生方法实现
- MC->>JS: 通过callback回调JS（可选）
-```
-
-### 1. WXModule 的注册分为 Naitve 注册和 JS 注册
-
-- **Native 注册**：在 Native 端，调用 `[WXSDKEngine registerModule:withClass:]` 方法（在 iOS 中） ，这个过程会将自定义 Module 的类和一个模块名称（例如 `TestModule`）建立映射关系，并生成一个 `ModuleFactory` 存储在一个全局的 Map（例如 `sModuleFactoryMap`）中。同时，如果该 Module 被标记为全局（global），SDK 会立即创建一个实例并缓存起来。
-- **JS 注册**：Native 注册完成后，Weex 会将所有已注册 Module 的**模块名称**及其**暴露给 JS 的方法名列表**，通过 `WXBridge`（JS-Native 通信桥梁）传递给 JS 引擎。这样，JS 端就知道存在哪些模块以及每个模块有哪些方法可以调用。
-
-### 2. 当 JS 调用 Module 方法时
-
-- JS 发起调用：在 JS 代码中，通过 `weex.requireModule('moduleName')` 获取模块实例 。然后吊影其方法，比如 'staream.fetch()options, callack)'
-- Bridge 桥接：JS 引擎通过 JSBridge 将这次调用（包括模块名、方法名、参数等信息）传递给 Native 段
-- Native 端查找与执行：Native 端的 WXModuleManager 根据模块名从之前注册的工厂中获取创建的 Module 实例，并根据方法名找到对应的 MethodInvoker。MethodInvoker 会通过反射手段调用具体的 Native 方法
-- 结果回调：如果有需要，Native 可以通过 WXModuleCallBack 或者 WXModuleKeepAliveCallBack 将结果回调给 JS。WXModuleCallback 只能回调1次，而 WXModuleKeepAliveCallback 可以多次回调
-
-### 3. WXModuleProtocol 的作用
-
-**`WXModuleProtocol` 是一个协议，定义了 Module 的行为规范**。你的自定义 Module 必须遵循此协议。它声明了 Module 需要实现的方法或属性，例如如何暴露方法给 JS（通过 `WX_EXPORT_METHOD` 宏）、方法在哪个线程执行（通过实现特定的方法返回目标线程，例如 `targetExecuteThread`）、以及如何通过 `weexInstance` 属性弱引用持有它的 WXSDKInstance 实例。
-通过遵循 `WXModuleProtocol`，你自定义的 Module 就能被 Weex SDK 正确识别和调
-
-### 4. WXModuleFactory 的作用
-
-1. **存储配置**：在注册阶段，它会缓存 Module 的配置信息，例如模块名和对应的工厂类（`WXModuleConfig`）。
-2. **方法解析**：通过反射，解析 Module 类中所有通过 `WX_EXPORT_METHOD` 或 `WX_EXPORT_METHOD_SYNC` 宏暴露的方法，并生成方法名与 `MethodInvoker`（封装了反射调用逻辑）的映射关系。
-3. 提供实例：当 JS 调用 Module 方法时，`WXModuleManager` 会通过 `WXModuleFactory` 根据模块名获取或创建 Module 实例，以及对应方法的 `MethodInvoker`。
-
-
-
-## 八、Weex 分为几个线程
-
-### 1. 主线程
-
-核心定位：应用的 UI 线程（与原生 App 主线程同源），负责 UI 渲染、用户交互响应，**禁止耗时操作**。
-
-核心职责：
-
-- 承载 Weex 页面的 **原生渲染容器**（如 Android 的 `WXFrameLayout`、iOS 的 `WXSDKInstanceView`），执行视图布局、绘制、动画触发；
-- 处理用户交互事件（点击、滑动、输入等），并将事件转发给 JS 线程（如需要 JS 逻辑响应时）；
-- 执行原生模块的 **主线程方法**（通过 `@WXModuleAnnotation(runOnUIThread = true)` 标记的方法，如弹 Toast、更新 UI 的原生能力）；
-- 接收 JS 线程下发的 **UI 操作指令**（如创建视图、修改样式、更新属性），并映射为原生视图操作；
-
-**关键约束**：所有直接操作原生视图的逻辑必须在主线程执行，否则会导致 UI 错乱或崩溃
-
-
-
-### 2. JS 线程
-
-核心定位：Weex 的 “业务逻辑线程”，独立于主线程，专门运行 JavaScript 代码，避免阻塞 UI。
-
-核心职责：
-
-- 加载并执行 Weex 业务代码（`.we` 编译后的 JS bundle），包括 Vue/React 组件初始化、数据绑定、生命周期管理；
-- 处理 JS 层面的业务逻辑（事件响应、数据计算、接口请求预处理）；
-- 调用原生模块时，通过 **JSBridge 转发请求**（区分同步 / 异步，同步请求会短暂阻塞 JS 线程，需谨慎使用）；
-- 生成 UI 操作指令（如 `createElement`、`updateStyle`），通过跨线程通信发送给主线程执行；
-- 接收主线程转发的用户交互事件（如点击回调），执行对应的 JS 事件处理函数；
-
-关键优化**：最新版本中，JS 线程支持 **Bundle 预加载**、**懒加载组件**，减少启动耗时；同时通过 `JSContext`隔离多个 Weex 实例，避免线程内资源竞争。
-
-
-
-### 3. 耗时线程
-
-#### 1. 网络线程
-
-核心定位：Weex 框架封装的 **专用网络线程**（跨端统一调度），避免网络请求阻塞主线程或 JS 线程。
-
-核心职责：
-
-- 处理 Weex 内置的网络请求（如 `weex.requireModule('stream')` 发起的 HTTP/HTTPS 请求）；
-- 负责 JS Bundle 的下载（首次加载或更新时），支持断点续传、缓存管理；
-- 处理网络请求的拦截、重试、超时控制（框架层统一实现，无需业务关心）；
-- 将网络响应结果通过 JSBridge 回传给 JS 线程；
-
-设计亮点：与原生系统的网络库解耦，但对外暴露统一的 JS API，线程调度由框架内部管理，业务无需手动切换线程
-
-#### 2. 图片下载线程
-
-核心定位：专门处理 Weex 图片的异步加载、解码，避免占用主线程资源导致 UI 卡顿。
-
-核心职责：
-
-- 加载网络图片、本地图片（通过 `img` 标签或 `weex.requireModule('image')`）；
-- 图片解码、压缩（适配视图尺寸，减少内存占用）；
-- 图片缓存管理（内存缓存 + 磁盘缓存，框架层统一维护）；
-- 加载完成后，将图片 bitmap 提交到主线程渲染；
-
-iOS 侧图片加载线程的核心管理类是 `WXImageComponent`。
-
-
-
-Weex 线程职责边界清晰：**UI 操作归主线程，JS 逻辑归 JS 线程，耗时操作归工作线程 / 网络线程**，避免跨线程直接操作资源
-
-## 九、JS 和 Native 通信
-
-### 1. callJS 和 callNative
-
-| 通信方向 | 发起方 | 接收方 | 核心目的 | 典型场景 |
-| ------------ | ------ | ------ | -------------------------------- | ------------------------------------------------------ |
-| `callNative` | JS | Native | JS 调用 Native 的模块 / 组件接口 | 渲染组件、弹 Toast、获取设备信息 |
-| `callJS` | Native | JS | Native 触发 JS 的回调函数 | 组件事件回调（如按钮点击）、数据同步（如网络请求结果） |
-
-两者的底层依赖 **同一个 JS Bridge 通道**，只是「发起方」和「数据格式」不同，Weex 已封装好统一的通信框架，开发者无需关心底层传输细节
-
-### 2. callNative 实现
-
-`callNative` 是 JS 主动调用 Native 接口的过程，核心流程：**JS 构造标准化指令 → 序列化 JSON → 桥接通道发送 → Native 解析指令 → 执行对应接口 → 响应结果回传**。
-
-怎么样？是不是感觉似曾相识，早期做 Hybrid 的时候，JS 和 Native 的通信也是一样的流程，感兴趣的可以查看[这篇文章](./1.44.md)。
-
-是的，通信要解决的问题一直不变，所以方案也不变。
-
-#### 1. 标准化指令格式
-
-为了让 Native 能统一解析，Weex 规定 `callNative` 的指令必须包含 4 个核心字段（JS 端构造）：
-
-```json
-const callNative指令 = {
- module: "component", // 模块名（如 component/modal/device）
- method: "create", // 方法名（如 create/toast/getInfo）
- params: {}, // 入参（如组件样式、Toast 内容）
- callbackId: "cb_123" // 回调 ID（用于 Native 回传结果）
-};
-```
-
-- `module` + `method`：定位 Native 端的具体接口（如 `modal.toast` 对应 Native 的「弹 Toast」接口）；
-- `params`：JS 传递给 Native 的数据（需是 JSON 兼容类型）；
-- `callbackId`：唯一标识当前请求，Native 执行完成后通过该 ID 找到对应的 JS 回调函数。
-
-#### 2. JS 端实现
-
-JS 侧调用 Native 的核心是3个实例方法，对应3类场景
-
-| 方法名 | 用途 | 对应 Native 接口 |
-| --------------- | -------------------------------------------- | ---------------------------------- |
-| `callModule` | 调用 Native 普通模块（如 `modal`/`storage`） | `global.callNativeModule` |
-| `callComponent` | 调用 Native 自定义组件方法 | `global.callNativeComponent` |
-| `callDOM` | 调用 DOM 相关 Native 方法（如创建元素） | `global.callAddElement` 等独立方法 |
-
-这3个方法都会通过 Native 注入的全局函数（global 上的方法）将调用传递给 Native 层
-
-这3个方法在源码最后
-
-```javascript
-// 调用 DOM 相关 Native 方法
-callDOM (action, args) {
- return this[action](this.instanceId, args)
-}
-
-// 调用 Native 自定义组件方法
-callComponent (ref, method, args, options) {
- return this.componentHandler(this.instanceId, ref, method, args, options)
-}
-
-// 调用 Native 普通模块方法（最常用，对应原 callNative）
-callModule (module, method, args, options) {
- return this.moduleHandler(this.instanceId, module, method, args, options)
-}
-```
-
-##### 1. 普通模块调用 callModule → moduleHandler
-
-`moduleHandler` 是普通模块调用的最终转发函数，源码中通过 `global.callNativeModule` 对接 Native：
-
-```javascript
-proto.moduleHandler = global.callNativeModule ||
- ((id, module, method, args) =>
- fallback(id, [{ module, method, args }]))
-```
-
-- 正常情况（客户端环境）：`global.callNativeModule` 是 **Native 注入到 JS 全局的函数**（iOS/Android 原生实现），直接接收 `instanceId`、模块名、方法名、参数，传递给 Native 层。
-- 降级情况（无 Native 桥接）：调用 `fallback` 函数（初始化时由 `sendTasks` 参数传入，通常用于调试 / 模拟）。
-
-##### 2. 自定义组件调用 callComponent → componentHandler
-
-逻辑与 `moduleHandler` 一致，对接 `global.callNativeComponent`：
-
-```javascript
-proto.componentHandler = global.callNativeComponent ||
- ((id, ref, method, args, options) =>
- fallback(id, [{ component: options.component, ref, method, args }]))
-```
-
-##### 3. DOM 方法调用 callDOM → 独立全局函数映射
-
-DOM 相关的 Native 方法（如 `addElement`/`updateStyle`）被单独映射到 `global` 上的独立函数（而非统一的 `callNative`），源码通过 `init` 函数初始化映射：
-
-```javascript
-// 源码第 116-138 行：DOM 方法与 Native 全局函数的映射
-export function init () {
- const DOM_METHODS = {
- createFinish: global.callCreateFinish,
- addElement: global.callAddElement, // DOM 创建元素 → Native 的 callAddElement
- removeElement: global.callRemoveElement, // DOM 删除元素 → Native 的 callRemoveElement
- updateAttrs: global.callUpdateAttrs, // 更新属性 → Native 的 callUpdateAttrs
- // ... 其他 DOM 方法
- }
- const proto = TaskCenter.prototype
-
- // 给 TaskCenter 原型挂载 DOM 方法，直接调用 Native 注入的全局函数
- for (const name in DOM_METHODS) {
- const method = DOM_METHODS[name]
- proto[name] = method ?
- (id, args) => method(id, ...args) : // 正常情况：调用 Native 全局函数
- (id, args) => fallback(...) // 降级情况
- }
-}
-```
-
-例如调用 `callDOM('addElement', args)` 时，最终会执行 `global.callAddElement(instanceId, ...args)`，直接对接 Native 的 DOM 模块。其实是注入到 JSContext 里的方法对象。
-
-在 Weex 的 JS 运行环境中，`global` 是 **JS 全局对象（Global Object）**—— 它是所有 JS 代码的 “顶层容器”，所有未被定义在局部作用域的变量、函数，最终都会挂载到 `global` 上（类似浏览器环境的 `window`，Node.js 环境的 `global`）
-
-**Native 向 JS 引擎的 “全局上下文” 注入 `callAddElement` 函数时，该函数会自动成为 `global` 对象的属性**——JS 侧的 `global.callAddElement`，本质就是访问这个被 Native 注入到全局的函数。
-
-QA：global 是什么？
-
-是 JS 全局对象。不管是浏览器、Node.js 还是 Weex 的 JS 引擎（JavaScriptCore/QuickJS），都有一个 **全局对象（Global Object）**：
-
-- 它是 JS 运行环境的 “根”，所有全局变量、函数都是它的属性；
-- 不同环境的全局对象名称不同：
- - 浏览器环境：叫 `window`（比如 `window.alert`、`window.document`）；
- - Node.js 环境：叫 `global`（比如 `global.console`、`global.setTimeout`）；
- - Weex 环境：叫 `global`（因为 Weex 不依赖浏览器，没有 `window`，直接用 JS 引擎原生的全局对象 `global`）。
-
-```objective-c
-// WXJSCoreBridge.mm
-- (void)registerCallAddElement:(WXJSCallAddElement)callAddElement
-{
- id callAddElementBlock = ^(JSValue *instanceId, JSValue *ref, JSValue *element, JSValue *index, JSValue *ifCallback) {
- NSString *instanceIdString = [instanceId toString];
- WXSDKInstance *instance = [WXSDKManager instanceForID:instanceIdString];
- if (instance.unicornRender) {
- JSValueRef args[] = {instanceId.JSValueRef, ref.JSValueRef, element.JSValueRef, index.JSValueRef};
- [WXCoreBridge callUnicornRenderAction:instanceIdString
- module:"dom"
- method:"addElement"
- context:[JSContext currentContext]
- args:args
- argCount:4];
- return [JSValue valueWithInt32:0 inContext:[JSContext currentContext]];
- }
-
- NSDictionary *componentData = [element toDictionary];
- NSString *parentRef = [ref toString];
- NSInteger insertIndex = [[index toNumber] integerValue];
- if (WXAnalyzerCenter.isInteractionLogOpen) {
- WXLogDebug(@"wxInteractionAnalyzer : [jsengin][addElementStart],%@,%@",instanceIdString,componentData[@"ref"]);
- }
- return [JSValue valueWithInt32:(int32_t)callAddElement(instanceIdString, parentRef, componentData, insertIndex) inContext:[JSContext currentContext]];
- };
-
- _jsContext[@"callAddElement"] = callAddElementBlock;
-}
-```
-
-在 js 侧是通过 TaskCenter.js 的 init 方法中定义的，存在映射关系， `addElement: global.callAddElement,`
-
-
-
-### 3. callJS 实现
-
-`WXReactorProtocol` 协议：
-
-- 定义 Native 调用 JS 的「标准接口」（如触发回调、发送事件），不关心底层用哪种 JS 引擎（JavaScriptCore / 其他）；
-- 具体的桥接类（如 `WXJSCoreBridge`）遵守这个协议，实现接口方法 —— 即使未来替换 JS 引擎，只要遵守协议，上层代码（如 Native 模块、组件）无需修改。
-
-```objective-c
-
-@class JSContext;
-
-@protocol WXReactorProtocol
-
-@required
-
-/**
-Weex should register a JSContext to reactor
-*/
-- (void)registerJSContext:(NSString *)instanceId;
-
-/**
- Reactor execute js source
-*/
-- (void)render:(NSString *)instanceId source:(NSString*)source data:(NSDictionary* _Nullable)data;
-
-- (void)unregisterJSContext:(NSString *)instanceId;
-
-/**
- When js call Weex NativeModule, invoke callback function
-
- @param instanceId : weex instance id
- @param callbackId : callback function id
- @param args : args
-*/
-- (void)invokeCallBack:(NSString *)instanceId function:(NSString *)callbackId args:(NSArray * _Nullable)args;
-
-/**
-Native event to js
-
-@param instanceId : instance id
-@param ref : node reference
-@param event : event type
-@param args : parameters in event object
-@param domChanges : dom value changes, used for two-way data binding
-*/
-- (void)fireEvent:(NSString *)instanceId ref:(NSString *)ref event:(NSString *)event args:(NSDictionary * _Nullable)args domChanges:(NSDictionary * _Nullable)domChanges;
-
-@end
-```
-
-Native 模块（Module)/组件(Component) 完成任务后 -> `WXBridgeManager.callBack(...)` → 构造 JS 脚本（调用 `TaskCenter.callback`） → `WXJSCoreBridge.executeJavascript(...)` → JS 引擎执行 → `TaskCenter.callback` 响应
-
-`WXJSCoreBridge` 本身不直接拼接回调脚本，而是提供 `executeJavascript:` 方法（源码第 102 行），作为 JS 脚本执行的底层入口；真正的脚本构造，在 `WXBridgeManager` 中
-
-WXBridgeManager 事件回调
-
-```javascript
-- (void)fireEvent:(NSString *)instanceId ref:(NSString *)ref type:(NSString *)type params:(NSDictionary *)params
-{
- [self fireEvent:instanceId ref:ref type:type params:params domChanges:nil];
-}
-
-- (void)fireEvent:(NSString *)instanceId ref:(NSString *)ref type:(NSString *)type params:(NSDictionary *)params domChanges:(NSDictionary *)domChanges
-{
- [self fireEvent:instanceId ref:ref type:type params:params domChanges:domChanges handlerArguments:nil];
-}
-- (void)fireEvent:(NSString *)instanceId ref:(NSString *)ref type:(NSString *)type params:(NSDictionary *)params domChanges:(NSDictionary *)domChanges handlerArguments:(NSArray *)handlerArguments
-{
- // ...
- WXCallJSMethod *method = [[WXCallJSMethod alloc] initWithModuleName:nil methodName:@"fireEvent" arguments:[WXUtility convertContainerToImmutable:args] instance:instance];
- [self callJsMethod:method];
-}
-
-- (void)callJsMethod:(WXCallJSMethod *)method
-{
- if (!method || !method.instance) return;
-
- __weak typeof(self) weakSelf = self;
- WXPerformBlockOnBridgeThreadForInstance(^(){
- WXBridgeContext* context = method.instance.useBackupJsThread ? weakSelf.backupBridgeCtx : weakSelf.bridgeCtx;
- [context executeJsMethod:method];
- }, method.instance.instanceId);
-}
-```
-
-WXBridgeContext.m 代码如下：
-
-```javascript
-- (void)executeJsMethod:(WXCallJSMethod *)method {
- // ...
- [sendQueue addObject:method];
- [self performSelector:@selector(_sendQueueLoop) withObject:nil];
-}
-
-- (void)_sendQueueLoop {
- if ([tasks count] > 0 && execIns) {
- WXSDKInstance * execInstance = [WXSDKManager instanceForID:execIns];
- NSTimeInterval start = CACurrentMediaTime()*1000;
-
- if (execInstance.instanceJavaScriptContext && execInstance.bundleType) {
- [self callJSMethod:@"__WEEX_CALL_JAVASCRIPT__" args:@[execIns, [tasks copy]] onContext:execInstance.instanceJavaScriptContext completion:nil];
- } else {
- [self callJSMethod:@"callJS" args:@[execIns, [tasks copy]]];
- }
- // ...
- }
-}
-
-- (void)callJSMethod:(NSString *)method args:(NSArray *)args {
- if (self.frameworkLoadFinished) {
- [self.jsBridge callJSMethod:method args:args];
- } else {
- [_methodQueue addObject:@{@"method":method, @"args":args}];
- }
-}
-```
-
-再到 WXJSCoreManager
-
-```javascript
-- (JSValue *)callJSMethod:(NSString *)method args:(NSArray *)args {
- WXLogDebug(@"Calling JS... method:%@, args:%@", method, args);
- WXPerformBlockOnMainThread(^{
- [[WXBridgeManager sharedManager].lastMethodInfo setObject:method ?: @"" forKey:@"method"];
- [[WXBridgeManager sharedManager].lastMethodInfo setObject:args ?: @[] forKey:@"args"];
- });
- return [[_jsContext globalObject] invokeMethod:method withArguments:[args copy]];
-}
-```
-
-其实不管是 CallJS 还是 CallNative，通信的技术方案设计和 Hybrid 的设计一致，都需要在 JavascriptCore 的 global 对象上挂载一个方法。比如 Native 注册了一个 WXComponent 之后，Weex 侧用 Vue 语法写完了个页面，呈现在用户手机上，用户点击页面上的按钮之后，Native 再将事件回调给 Weex 侧，Weex 再去处理后续逻辑。
-
-
-
-### 4. WXAssertComponentThread 断言
-
-`WXAssertComponentThread` 的核心作用是 **强制约束组件相关操作在「组件专属线程」执行**，本质是为了解决「线程安全」和「性能稳定性」问题
-
-iOS 开发的核心线程规则是「UI 操作必须在主线程」，但 Weex 组件的工作流程（绑定解析、数据计算、布局计算、子组件管理）包含大量「非 UI 操作」—— 如果这些操作都在主线程执行，会阻塞主线程（比如长列表数据解析、复杂表达式计算），导致 UI 卡顿（比如滑动掉帧）
-
-因此 Weex 设计了线程分工
-
-| 线程类型 | 负责的操作 |
-| ------------ | ------------------------------------------------------------ |
-| 组件专属线程 | 绑定规则解析（`_storeBindings`）、表达式计算（`bindingBlockWithExpression`）、数据更新（`updateBindingData`）、布局计算（`calculateLayout`） |
-| 主线程 | 最终 UI 渲染（如 `UIImageView` 设图、`UILabel` 设文本）、子视图增删（`insertSubview`） |
-
-#### 1. 避免「线程安全问题」，防止崩溃 / 数据错乱
-
-组件的核心数据（如 `_bindingProps`、`_subcomponents`、`_flexCssNode`）都是「非线程安全的」（没有加锁保护）—— 如果多个线程同时读写这些数据，会导致：
-
-- 数据竞争：比如主线程读取 `_subcomponents` 遍历，组件线程同时修改 `_subcomponents`（增删子组件），导致数组越界崩溃；
-- 数据不一致：比如组件线程更新 `_bindingProps` 的值，主线程同时读取该值用于 UI 更新，导致显示错误的旧值；
-- 野指针：比如组件线程销毁子组件，主线程还在访问该子组件的 `view`。
-
-线程断言通过「强制所有组件核心操作在同一线程执行」，从根源上避免了这些跨线程问题 —— 同一时间只有一个线程操作组件数据，无需复杂锁机制（锁会降低性能）。
-
-#### 2. 简化调试，快速定位线程问题
-
-如果没有线程断言，跨线程操作组件可能导致「偶现崩溃」（比如 100 次操作出现 1 次），难以复现和排查（日志中看不到线程上下文）。而线程断言会在「违规线程调用时直接崩溃」，并明确提示「必须在组件线程执行」，开发者能立刻定位到违规代码（比如在主线程调用了 `updateBindingData`），大幅降低调试成本。
-
-#### 3. 保证操作顺序一致性
-
-组件的更新流程是「解析绑定 → 计算表达式 → 更新属性 → 布局计算 → UI 渲染」—— 这些步骤必须按顺序执行。如果分散在多个线程，可能出现「布局计算还没完成，UI 已经开始渲染」的情况（导致布局错乱）。组件专属线程保证了所有操作串行执行，顺序不会乱。
-
-### 5. WXJSASTParser 的工作原理
-
-`WXJSASTParser` 如何把表达式字符串解析为 AST 节点？
-
-`WXJSASTParser` 是 Weex 自定义的「轻量 JS 表达式解析器」—— 核心是「按 JS 语法规则，把字符串拆分为结构化的 AST 节点」，全程不依赖完整 JS 引擎（如 JSC/V8），只支持绑定表达式需要的基础语法（标识符、成员访问、二元运算等），兼顾性能和体积。
-
-整个解析过程分 3 步：**词法分析 → 语法分析 → AST 节点封装**，和编译器的前端流程一致，以下结合示例（`"user.name + '?size=100'"`）拆解：
-
-先明确：AST 是什么？
-
-AST（抽象语法树）是「用树形结构表示代码语法」的中间结构 —— 比如表达式 `user.name + '?size=100'`，AST 会拆分为：
-
-```shell
-根节点：BinaryExpression（运算符 '+'）
-├─ 左子节点：MemberExpression（成员访问）
-│ ├─ object：Identifier（标识符 'user'）
-│ └─ property：Identifier（标识符 'name'）
-└─ 右子节点：StringLiteral（字符串字面量 '?size=100'）
-```
-
-这种结构能被程序快速遍历和计算（比如之前讲的生成 `WXDataBindingBlock` 时，递归遍历节点执行运算）。
-
-#### 1.词法分析（Lexical Analysis）
-
-拆分为词法单元（Token）。词法分析是「把表达式字符串拆分为最小的、有意义的语法单元」，忽略空格、换行等无关字符。核心是「按 JS 语法规则匹配字符序列」。
-
-`表达式 `"user.name + '?size=100'"` 词法分析后得到的 Token 序列：
-
-| Token 类型 | Token 值 | 说明 |
-| ---------------- | ----------- | ------------------------- |
-| `IDENTIFIER` | `user` | 标识符（变量名 / 属性名） |
-| `DOT` | `.` | 成员访问运算符 |
-| `IDENTIFIER` | `name` | 标识符 |
-| `PLUS` | `+` | 二元运算符（加法 / 拼接） |
-| `STRING_LITERAL` | `?size=100` | 字符串字面量（去掉引号） |
-
-词法分析的实现逻辑（简化）：
-
-1. 初始化一个「字符指针」，从表达式字符串开头遍历；
-2. 遇到字母 / 下划线 → 继续往后读，直到非字母 / 数字 / 下划线 → 识别为 `IDENTIFIER`（如 `user`）；
-3. 遇到 `+`/`-`/`*`/`/`/`>`/`=` 等 → 识别为对应运算符（如 `+` → `PLUS`）；
-4. 遇到 `"` 或 `'` → 继续往后读，直到下一个相同引号 → 识别为 `STRING_LITERAL`（去掉引号）；
-5. 遇到 `.` → 识别为 `DOT`（成员访问）；
-6. 遇到空格 / 制表符 → 直接跳过（无意义字符）；
-7. 遇到无法识别的字符（如 `#`/`@`）→ 抛出语法错误（`WXLogError`）。
-
-Weex 的 `WXJSASTParser` 内部会维护一个「Token 流」（数组），词法分析后把 Token 按顺序存入流中，供下一步语法分析使用。
-
-#### 2. 语法分析（Syntactic Analysis）
-
-语法分析是「根据 JS 表达式语法规则，把 Token 流组合为树形 AST 节点」—— 核心是「验证 Token 序列是否符合语法，并构建层级关系」。
-
-Weex 支持的 JS 表达式语法子集（核心）：
-
-- 标识符：`user`、`imageUrl`（对应 `WXJSIdentifier`）；
-- 成员访问：`user.name`、`list[0]`（对应 `WXJSMemberExpression`）；
-- 字面量：字符串（`'abc'`）、数字（`123`）、布尔（`true`）、null（对应 `WXJSStringLiteral`/`WXJSNumericLiteral` 等）；
-- 二元运算：`a + b`、`age > 18`、`a === b`（对应 `WXJSBinaryExpression`）；
-- 条件运算：`age > 18 ? 'adult' : 'teen'`（对应 `WXJSConditionalExpression`）；
-- 数组表达式：`[a, b, c]`（对应 `WXJSArrayExpression`）。
-
-示例：Token 流 → AST 节点的构建过程
-
-Token 流：`IDENTIFIER(user) → DOT → IDENTIFIER(name) → PLUS → STRING_LITERAL(?size=100)`
-
-1. 语法分析器先读取前 3 个 Token（`user` → `.` → `name`），匹配「成员访问语法规则」（`IDENTIFIER . IDENTIFIER`）→ 构建 `WXJSMemberExpression` 节点（左子节点 `user`，右子节点 `name`）；
-2. 接着读取 `PLUS`（二元运算符），再读取后面的 `STRING_LITERAL(?size=100)` → 匹配「二元运算语法规则」（`Expression + Expression`）；
-3. 把之前构建的 `WXJSMemberExpression` 作为「左子节点」，`STRING_LITERAL` 作为「右子节点」，`PLUS`作为「运算符」→ 构建根节点 `WXJSBinaryExpression`；
-4. 最终生成 AST 树（如之前的结构）。
-
-语法分析的实现逻辑（简化）：
-
-Weex 采用「递归下降分析法」（最适合手工实现的语法分析方法）：
-
-1. 为每种表达式类型定义一个「解析函数」（如 `parseMemberExpression` 解析成员访问、`parseBinaryExpression` 解析二元运算）；
-2. 解析函数递归调用：比如 `parseBinaryExpression` 会调用 `parseMemberExpression` 解析左右操作数，`parseMemberExpression` 会调用 `parseIdentifier` 解析标识符；
-3. 语法校验：如果 Token 序列不符合规则（如 `user.name +` 缺少右操作数），会抛出「语法错误」日志，终止解析。
-
-#### 3. AST 节点封装
-
-转为 Weex 自定义的 `WXJSExpression`。语法分析生成的是「抽象语法树结构」，Weex 会把这个结构封装为自定义的 `WXJSExpression` 子类（对应不同表达式类型），每个子类存储该节点的关键信息（如运算符、子节点），供后续生成 `WXDataBindingBlock` 使用。
-
-示例封装：
-
-- `WXJSMemberExpression` 类：存储 `object`（子节点，如 `user`）、`property`（子节点，如 `name`）、`computed`（是否是计算属性，如 `list[0]` 为 `YES`，`user.name` 为 `NO`）；
-- `WXJSBinaryExpression` 类：存储 `left`（左子节点）、`right`（右子节点）、`operator_`（运算符字符串，如 `"+"`）；
-- 字面量类（如 `WXJSStringLiteral`）：存储 `value`（字面量值，如 `?size=100`）。
-
-这些类的定义在 Weex 源码的 `WXJSASTParser.h` 中，本质是「数据容器」，把 AST 结构转化为 Objective-C 代码可访问的对象。
-
-`WXJSASTParser` 本质：它不是完整的 JS 解析器（不支持 `function`、`for` 等复杂语法），而是「专门为 Weex 绑定表达式设计的轻量解析器」—— 只解析需要的 JS 表达式子集，把字符串转为结构化的 AST 节点，最终目的是「让 Native 代码能递归遍历节点，计算出表达式结果」（如 `user.name + '?size=100'` → `avatar.png?size=100`）。
-
-这种「自定义轻量解析器」的设计，既避免了依赖完整 JS 引擎的体积和性能开销，又能精准适配 Weex 的绑定需求，是跨端框架的常见优化思路。
-
-
-
-
-## 十、值得借鉴的地方
-
-### 1. WXThreadSafeMutableDictionary 线程安全字典
-Weex 中的 WXThreadSafeMutableDictionary 提供了一个线程安全的字典，其本质是通过加 pthread_muext_t 锁来维护内部的一个字典的。
-比如下面的代码
-
-初始化锁相关的配置
-```Objective-C
-@interface WXThreadSafeMutableDictionary ()
-{
- NSMutableDictionary* _dict;
- pthread_mutex_t _safeThreadDictionaryMutex;
- pthread_mutexattr_t _safeThreadDictionaryMutexAttr;
-}
-
-@end
-
-@implementation WXThreadSafeMutableDictionary
-
-- (instancetype)initCommon
-{
- self = [super init];
- if (self) {
- pthread_mutexattr_init(&(_safeThreadDictionaryMutexAttr));
- pthread_mutexattr_settype(&(_safeThreadDictionaryMutexAttr), PTHREAD_MUTEX_RECURSIVE); // must use recursive lock
- pthread_mutex_init(&(_safeThreadDictionaryMutex), &(_safeThreadDictionaryMutexAttr));
- }
- return self;
-}
-
-- (instancetype)init
-{
- self = [self initCommon];
- if (self) {
- _dict = [NSMutableDictionary dictionary];
- }
- return self;
-}
-```
-在字典操作的地方使用锁
-```Objective-C
-- (void)setObject:(id)anObject forKey:(id)aKey
-{
- id originalObject = nil; // make sure that object is not released in lock
- @try {
- pthread_mutex_lock(&_safeThreadDictionaryMutex);
- originalObject = [_dict objectForKey:aKey];
- [_dict setObject:anObject forKey:aKey];
- }
- @finally {
- pthread_mutex_unlock(&_safeThreadDictionaryMutex);
- }
- originalObject = nil;
-}
-```
-这么写的价值：**解锁逻辑「绝对执行」，彻底避免死锁**
-这是 `@try-finally` 最核心的价值 ——无论 try 块内发生什么（正常执行、提前 return、抛异常），finally 块的解锁逻辑一定会执行
-
-对比无 try-finally 的写法
-```Objective-C
-// Bad: 若setObject抛异常，unlock不会执行→死锁
-pthread_mutex_lock(&_mutex);
-[_dict setObject:anObject forKey:aKey];
-pthread_mutex_unlock(&_mutex);
-```
-问题：`[_dict setObject:anObject forKey:aKey]` 可能抛异常（比如 aKey = nil 时会触发 NSInvalidArgumentException），若没有 finally，锁会被永久持有→其他线程调用 lock 时死锁，整个字典无法再操作。
-
-设计优点：
-- `@try-finallly`：即使 try 内逻辑出错，finally 也会执行 pthread_mutex_unlock，保证锁最终释放，这是**线程安全的「兜底保障」**
-- 注意，不是 `try...catch...finally`: 如果加了 catch 逻辑，则字典的 key 为 nil 产生的崩溃也会被捕获掉，这属于不符合预期的行为。因为 key 为 nil 产生的原因太多了，可能是业务代码异常，也可能是数据异常，也可能是逻辑错误，如果一刀切直接用 `try...catch...finally` 捕获了异常，但是没有配置异常的收集、上报、处理逻辑，属于边界不清晰，本质是为了解决加解锁不匹配而可能带来的线程安全问题，却"多管闲事"，把字典 key 为 nil 本该向上跑的异常而卡住了（这个问题不再赘述，是一个经典的策略问题，端上的异常发生时，安全气垫的“做与不做”问题）
-
-延伸：聊聊类似网易的大白解决方案或者业界其他公司中，安全气垫虽然保证了代码不 crash，影响用户体验，但是比如数组本该越界，现在却不越界：
-1. 唯一能做的就是返回一个错误的值，比如数组长度为3，访问4，现在不 crash，返回了 0 的值，那是不是产生了业务异常？比如商品价格
-2. 不 crash，也不返回错误位置的值，类似给一个回调，告诉业务方出现了异常，可以做一些业务层面的提醒或者配置(比如开发阶段商品卡片的价格 Label 显示：商品价格获取错误，数组越界)，同时产生的异常案发现场信息和其他的一些数据会上报，用于 APM 平台去分析和定位。
-
-但这也产生一个问题，类似数组越界的场景，可能10000次里面9999次都正常，只有1次异常，业务开发为了这万分之一出现的异常，还需要写一些异常处理的逻辑（比如商品卡片展示价格获取错误，数组越界）。那字典的 key 为 nil 呢？除法的分母为0呢？诸如此类，类似乐观锁和悲观锁的场景
-
-相关问题的思考可以查看这篇文章：[安全气垫](./1.148.md)
-
-
-- WXHandlerFactory：Weex 核心的「处理器工厂」，负责管理所有协议（如图片加载、网络请求、存储等）的实现类注册 / 查找；
-- WXImgLoaderProtocol：Weex 定义的「图片加载协议」，仅声明接口（下载、取消、缓存等），不包含具体实现。
-
-Weex 支持业务层自定义图片加载逻辑（比如统一用项目的图片缓存库、添加下载拦截、埋点等），此时自定义实现类会替代默认实现，成为下载执行者：
-步骤 1：业务层创建类（如 MyCustomImgLoader），遵循 WXImgLoaderProtocol，实现 wx_loadImageWithURL: 等协议方法（内部可调用 SDWebImage/AFNetworking 等完成下载）；
-步骤 2：将自定义类注册到 WXHandlerFactory：
-```Objective-C
-[WXHandlerFactory registerHandler:[MyCustomImgLoader new] forProtocol:@protocol(WXImgLoaderProtocol)];
-```
-步骤 3：此时 [WXHandlerFactory handlerForProtocol:@protocol(WXImgLoaderProtocol)] 会返回 MyCustomImgLoader 实例，所有图片下载由该类负责
-
-### 2. 设计分层合理
-
-```mermaid
-graph TD
- A[开发者编写的 .we/.vue 文件] --> B[Transformer
转换JS Bundle]; - B --> C[JS Framework
解析并管理Virtual DOM]; - C -- 通过JS Bridge发送渲染指令 --> D[Native SDK
渲染引擎]; - D --> E[iOS/Android/Web 原生视图]; - - C -- 支持多种DSL --> F[Vue.js]; - C -- 支持多种DSL --> G[Rax（类React）]; - D -- 原生能力扩展 --> H[自定义Component]; - D -- 原生能力扩展 --> I[自定义Module]; -``` - -Weex 最核心的设计是将整个框架清晰地分为：**语法层（DSL）**、**中间层（JS Framework）**和**渲染层（Native SDK）** - -这种渲染引擎和语法层 DSL 分离的设计，可以使得上层 DSL 方便拓展 Vue、Rax 写法，下层渲染引擎可以保持较好的稳定性。为了生态的拓展提供了极大的便携性。 - - - -### 3. 可扩展的组件与模块系统 - -Weex 通过`WXSDKEngine.registerComponent()` 和 `registerModule()` 方法，允许开发者扩展原生组件 （UI Component）和模块（Login Module）。这套机制设计得足够底层和通用，使得 Weex 可以由开发者来注册，由公司内的体验设计中心规范来落地的组件。以及一些基础能力。这样子 Weex 官方已经提供了一些功能强大的筋骨，我们在其之上可以提供更符合需求的外表和更有力量的一块手臂肌肉。 - -虽然事后视角来看，Weex、RN、Flutter，甚至是更早的、设计完善的 Hybrid 都有该能力。但这对于远古时期的 Weex 来说，还是可圈可点的。 - - - -### 4. 轻量 JSBundle + 增量更新支持 - -Weex 的 JSBundle 仅包含业务逻辑和组件描述，框架代码（Vue 内核、Weex 基础 API）内置在原生 SDK 中，因此 Bundle 体积极小；同时支持将 Bundle 拆分为 “基础包（公共逻辑）+ 业务包（页面逻辑）”，实现增量更新。 - -解决了跨端框架 “首屏加载慢” 的痛点（小 Bundle 加载更快），同时增量更新降低了发布成本。 - - - -## 十一、Weex APM - -### 1. 历史背景 -Weex 是诸多年前的产物，部分业务线用 Weex 写了部分功能模块，或者是某几个页面，或者是某个二级、三级业务 SDK 的页面。但可以确定的是： -- 21年就完成了 Flutter 的基建开发（对齐 Native 的 UI 组件库，遵循体验设计平台产出的集团 UI 标准；做了 Flutter 的大量 plugin、打包构建平台、日志库、网络库、探照灯、APM SDK、热修复能力等）。新业务的实现只会在 Native 和 Flutter 上考虑 -- Weex 业务代码基本上是存量的 -- Weex 代码没有 bug 就不去修改；有版本迭代，之前是 Weex 实现的，本次只做简单 UI 增删或字段调整，也是会修改一下。除此之外不修改 Weex 代码 - -所以像 Native 一样去全面监控性能、网络、crash、异常、白屏、页面加载耗时等维度的话，ROI 是很低的。那么就需要制定一些策略去有针对性的监控高优问题。 - -Weex 的异常比较有特点，比如在页面的模版代码中绑定了 data 中的一个对象，此时对象可能并没有值，而是依赖后续的网络请求完成，对象才有了具体的值 data 改变，数据驱动，页面再次 render。所以监控代码会认为第一次 render 的时候访问对象不存在的属性。 -真正有问题的代码和不影响业务的异常信息，都会被 Vue 官方认为是异常。基于这样的背景，我们无法 pick 出真正异常或者是开发者判空代码没写好的问题。基于此，我们需要做一些约定和标准。 - -### 2. 优先级权衡标准 -这时候就需要摒弃程序员视角（不然会陷入啥数据都想统计，可能是洁癖、可能是追求），但从 ROI 角度出发，我们就需要切换到用户视角。 - -假设你是一个用户，什么样的情况代表业务异常，对我们的用户来说比较痛呢？ -- 页面白屏了，看都看不到了，别说你们的 App 为我赋能解决用户痛点了 -- 稍微好点，可以看到页面了，但是某一个区域是白屏的。比如：该页面大部分在展示商品价格、商品数量、商品折扣价、商品折扣信息、下面应该是有个“确认支付”按钮，但是此处就是空白，点也点不了。 -- 情况再好点。可以看到全部的页面了，但是点击后无响应。比如：该页面大部分在展示商品价格、商品数量、商品折扣价、商品折扣信息、下面有个“确认支付”按钮。用户在考虑再三，本着理性购物后，发现是刚需品，咬紧牙要付款了，此时点击“确认支付”按钮了，但是页面没有任何反应。用户也是“见多识广”的体面人，猜测可能是网络不好的情况，所以等了1分钟，他很有耐心。切换了 WI-FI 到 5G 后，继续点击，依旧没反应。一怒之下点了10次，等了2分钟，还是没反应。他奔溃了，卸载了 App - -上述几种情况，总结为：按照异常等级，可以划分为影响业务和不影响业务。什么叫“影响业务”？这是我们自己定义的标准，影响用户是否正常操作 App。比如：页面白屏（页面全部白屏、页面部分白屏）、点击某个按钮无响应，这些叫做“影响业务”，属于 Error 级别。其他的一些轻微异常，不影响用户使用 App 功能，不影响业务，属于 Warning 级别。 - - - -### 3. UI 显示异常 -#### 1. 部分白屏：注册的 Component 使用异常 -这种情况就属于页面部分白屏。因为某个哪个 Compoent 会铺满页面，基本类似 iOS UI 控件一样组合使用。就像上文描述的「该页面大部分在展示商品价格、商品数量、商品折扣价、商品折扣信息、下面应该是有个“确认支付”按钮，但是此处就是空白」这个空白粗，理应显示一个 Native 注册的 Button，但是没有显示出来，造成业务的阻塞。 - - -.vue（或 Weex 专属.we）文件内基于 Vue 扩展的 Weex 跨平台模板 DSL 代码，在前端构建阶段会先由 Webpack 的weex-loader触发编译流程：首先通过 Weex 核心编译器@weex-cli/compiler（复用并扩展vue-template-compiler）将模板 DSL 解析为模板 AST（抽象语法树）；接着由 Weex 自定义 Babel 插件（如babel-plugin-transform-weex-template）将模板 AST 转换为标准化的 JS AST，并针对 iOS/Android 跨平台特性做属性、样式、事件的适配处理（如样式单位归一化、事件名标准化）；最终生成包含_h（即 Weex 运行时的$createElement，等价于 Vue 的createElement）调用的render函数，该函数会被 Webpack 打包到最终的 Weex JS Bundle 中。 - -```json -_c('color-button', - { - staticStyle: { - width: "400px", - height: "40px", - marginBottom: "20px" - }, - attrs: { - "title": "点击计算10+20", - "bgColor": "#FF6600", - "message": "hello" - }, - on: { - "click": _vm.handleButtonClick - } - }, - // 如果有 children 就是 children 信息 -) -``` - -在 App 运行阶段，Weex 的 JS 引擎（iOS 端为 JSCore、Android 端为 V8）加载 JS Bundle 后，执行组件的render函数，通过调用 `_h` 函数将模板描述转换为跨平台的虚拟 DOM（VNode），VNode 会被序列化为 JSON 格式，最终通过 JS Bridge 传递给 Native 端（iOS/Android）用于原生视图渲染。 - - -Weex 的 Component 相关逻辑都由 `WXComponentManager` 负责。页面在构建展示的时候，会调用 `_buildComponent` 方法，其内部会调用 WXComponentFactory 的能力（`configWithComponentName`），根据 ComponentName 获取 Component。 - -`configWithComponentName` 是 Weex iOS 侧 WXComponentFactory（组件工厂类）的核心方法之一，核心作用是：根据传入的组件名称（如 color-button/div/text），查找该组件对应的 Native 侧配置（WXComponentConfig）；若找不到对应配置，则降级使用基础容器组件 div 的默认配置，并输出警告日志。 -```Objective-C -- (WXComponentConfig *)configWithComponentName:(NSString *)name -{ - WXAssert(name, @"Can not find config for a nil component name"); - - WXComponentConfig *config = nil; - - [_configLock lock]; - config = [_componentConfigs objectForKey:name]; - if (!config) { - WXLogWarning(@"No component config for name:%@, use default config", name); - config = [_componentConfigs objectForKey:@"div"]; - } - [_configLock unlock]; - - return config; -} -``` -UI Component 做的比较随意，认为显示问题降级用 div 就可以了。做为 SDK 这么设计也似乎可以接受，但作为业务方，我们必须收集统计这种异常情况。 -所以此处我们可以收集案发现场数据，进行上报。我们发现 Weex 自己封装了 `WXExceptionUtils`类，暴露了 `commitCriticalExceptionRT` 接口，用于收集致命问题。 - -```Objective-C -+ (void)commitCriticalExceptionRT:(WXJSExceptionInfo *)jsExceptionInfo{ - - WXPerformBlockOnComponentThread(^ { - id jsExceptionHandler = [WXHandlerFactory handlerForProtocol:@protocol(WXJSExceptionProtocol)];
- if ([jsExceptionHandler respondsToSelector:@selector(onJSException:)]) {
- [jsExceptionHandler onJSException:jsExceptionInfo];
- }
- if ([WXAnalyzerCenter isOpen]) {
- [WXAnalyzerCenter transErrorInfo:jsExceptionInfo];
- }
- });
-}
-```
-可以看到会判断是否存在可以处理 exception 遵循 WXJSExceptionProtocol 的 handler。所以我们新增一个 `WXExceptionReporter` 类（遵循 WXJSExceptionProtocol 协议），用于收集异常，然后用于统一的上报，内部提供基础数据的组装、字段解析功能。
-
-效果如下：
-
-
-#### 2. 全部白屏
-根据 Weex 的工作原理可以知道，页面需要展示肯定要根据 url 去获取 JS Bundle 内容，然后解析成 VNode 最后通过 JSBridge 去调用 Native 的 UI Component 去展示 UI，那么整个流程几个重要的环节都可能出错，导致页面白屏。
-
-##### 1. 资源请求失败
-JS Bundle 资源请求失败，存在 Error，此时是无法去展示 Weex 页面的。这种情况就是 HTTP 状态码非200的情况。
-
-每个 Weex 页面都由 WXSDKInstance 负责下载 JS Bundle 资源，所以下载的逻辑在 WXSDKInstance 里。
-
-```Objective-C
-- (void)_renderWithRequest:(WXResourceRequest *)request options:(NSDictionary *)options data:(id)data;
-{
- _mainBundleLoader.onFinished = ^(WXResourceResponse *response, NSData *data) {
-
- NSError *error = nil;
- if ([response isKindOfClass:[NSHTTPURLResponse class]] && ((NSHTTPURLResponse *)response).statusCode != 200) {
- error = [NSError errorWithDomain:WX_ERROR_DOMAIN
- code:((NSHTTPURLResponse *)response).statusCode
- userInfo:@{@"message":@"status code error."}];
- if (strongSelf.onFailed) {
- strongSelf.onFailed(error);
- }
- }
-
- if (error) {
- [WXExceptionUtils commitCriticalExceptionRT:strongSelf.instanceId
- errCode:[NSString stringWithFormat:@"%d", WX_KEY_EXCEPTION_JS_DOWNLOAD]
- function:@"_renderWithRequest:options:data:"
- exception:[NSString stringWithFormat:@"download bundle error :%@",[error localizedDescription]]
- extParams:nil];
- return;
- }
-
- if (!data) {
- NSString *errorMessage = [NSString stringWithFormat:@"Request to %@ With no data return", request.URL];
- WX_MONITOR_FAIL_ON_PAGE(WXMTJSDownload, WX_ERR_JSBUNDLE_DOWNLOAD, errorMessage, strongSelf.pageName);
- [WXExceptionUtils commitCriticalExceptionRT:strongSelf.instanceId
- errCode:[NSString stringWithFormat:@"%d", WX_KEY_EXCEPTION_JS_DOWNLOAD]
- function:@"_renderWithRequest:options:data:"
- exception:errorMessage
- extParams:nil];
- return;
- }
- };
-}
-```
-
-模拟 JS Bundle 下载错误，效果如下：
-
-
-下载 JS Bundle 网络请求完成后，如果出现 Error，则会调用 WXExceptionUtils 的能力，将异常交给 `WXExceptionReporter` 去处理。
-
-
-
-##### 2. 资源请求成功，数据为空
-还有一种情况就是：**JSBundle 下载请求在 HTTP 层面 “成功完成”（状态码 200），但返回的二进制数据 data 为 nil 或空（长度为 0） **
-
-可能你会好奇，怎么可能有空的 JSBundle，什么场景下会产生这种情况？
-凡是正常写代码都符合预期就没有任何 bug 和故障了，所以利用悲观策略，将各种可能出现问题的地方都监控到，因为只要 JSBundle 为空，页面肯定是白屏，对于用户侧来说都是致命的。
-
-1. 服务器/CDN 返回“空响应”：后端 / CDN 配置异常：请求的 JSBundle URL 有效，HTTP 状态码返回 200，但响应体（Body）为空（比如静态 JS 文件被删除、CDN 缓存失效且源站无数据、后端接口逻辑错误未写入响应内容）；
-2. 下载过程中数据传输截断 / 丢失
-- 网络波动：下载请求已收到服务器的 “响应完成” 信号，但数据传输过程中因网络中断、超时等导致 NSData 未完整接收（仅 HTTP 头成功接收，体数据为空）；
-- Weex 加载器（mainBundleLoader）异常：加载器在将响应数据转为 NSData 时出现底层错误（如内存不足、数据解码失败），导致 data 被置为 nil。
-
-Mock：将 data 设为 nil。效果如下：
-
-
-可以看到 Weex 也会把这种错误进行收集，调用 `WXExceptionUtils commitCriticalExceptionRT`，所以我们添加的 Analyzer 是可以监控到这种异常的。
-效果如下：
-
-
-
-##### 3. 资源请求成功，数据无法解析
-
-还有一种特殊的情况就是：**下载的 JSBundle 二进制数据虽非空，但因无法以 UTF-8 编码解码为字符串，导致 Weex 实例无法加载执行该数据，最终页面 UI 无法正常展示**。比如下面的情况：
-
-
-和上面的情况类似，这种都属于概率较小的问题，但也要监控和预防。
-
-一些可能的情况：
-1. JSBundle 文件编码非 UTF-8。 **Weex 要求：JS Bundle 文件必须采用 UTF-8 编码（无 BOM）以保证跨平台兼容性，非 UTF-8 编码（如 GBK、UTF-16）可能导致 iOS/Android 平台解析失败**
-2. 数据损坏/包含非法 UTF-8 字节
- - 下载截断：UTF-8 是「多字节编码」（比如中文占 3 字节），若下载过程中数据末尾的字符字节不完整（如只下了 2 字节），解码时会因 “字节序列不合法” 失败；
- - 数据篡改：CDN / 网关 / 代理在传输中混入非 UTF-8 字节（如 0xFF、0xFE、0x00 等无效字节），破坏编码结构；
- - 文件损坏：JSBundle 文件打包 / 上传时出错（如压缩后未正确解压），包含乱码 / 二进制碎片
-3. 请求到非文本数据（URL 错误）。请求的 JS Bundle 返回的不是 JS 文本，而是二进制：
- - URL 配置错误：指向图片（png/jpg）、压缩包（zip）、二进制协议数据（如 protobuf）、可执行文件等
- - 后端接口错误：原本应返回 JS 文本的接口，异常时返回二进制格式的错误信息（而非文本错误）
- - 缓存污染：Weex 本地缓存的 JSBundle 被其他二进制文件覆盖（如缓存路径冲突）
-4. 特殊字符/编码溢出
- - JSBundle 中包含 UTF-8 无法表示的「无效 Unicode 码点」（如超出 U+10FFFF 范围，或保留的未定义码点）
- - 数据量过大：极大型 JSBundle 解码时因内存不足 / 系统限制，导致解码接口返回 nil（iOS 中 NSString 对单字符串长度有隐性限制）
-
-这种情况，Weex 官方是怎么做的？
-```Objective-C
-NSString *jsBundleString = [[NSString alloc] initWithData:data encoding:NSUTF8StringEncoding];
-if (!jsBundleString) {
- WX_MONITOR_FAIL_ON_PAGE(WXMTJSDownload, WX_ERR_JSBUNDLE_STRING_CONVERT, @"data converting to string failed.", strongSelf.pageName)
- [strongSelf.apmInstance setProperty:KEY_PROPERTIES_ERROR_CODE withValue:[@(WX_ERR_JSBUNDLE_STRING_CONVERT) stringValue]];
- return;
-}
-```
-可以看到，这种情况没有被 Weex 没有视为“致命问题”进行上报。只是进行了简单打印。尝试站在框架角度想问题，从 SDK Owner 角度归因：
-- HTTP 状态码错误/无数据：Weex 认为这类错误是「外部不可控故障」（网络、CDN、服务端宕机），会影响大批量实例，属于 “框架级致命异常”，必须通过 WXExceptionUtils 上报（触发全局异常统计、告警）
-- 编码转换失败：可能是分批多次打包，前几次都是 UTF-8 格式，只是这次编码错误，是可以定位的。Weex 认为这类错误是「内部可控问题」（前端打包时未按 UTF-8 规范输出、URL 配置错误指向二进制文件），属于 “业务侧错误”，框架只需记录监控（提醒开发者修复），无需升级为 “框架级致命异常”。
-
-但从业务方角度出发，不光页面是 Weex、Native、Flutter、H5，只要是影响了用户体验，都属于致命问题，尤其这种整个页面都是白屏的情况。所以我们需要修改源码，去上报致命异常。调用 `WXExceptionUtils commitCriticalExceptionRT` 的能力。
-
-效果如下：
-
-
-
-
-
-### 4. 逻辑异常
-
-#### 1. JS 侧 require Module 失败
-在 Native `[WXSDKEngine registerModule:@"logicCalculation" withClass:[WXLogicCalculationModule class]]` 正常注册的 Module，名字叫 `logicCalculation`。在 js 侧使用的时候不小心写成 `const logicCalculation = weex.requireModule('logicCalculation1')`，测试又没回归到，问题逃逸到线上，可能就是逻辑问题。Weex 官方的做法就是在 Xcode 打印 log。
-
-
-
-所以作为 APM 侧，我们要定位和收集到该问题，进行问题上报。
-
-想办法知道哪里报错，requireModule 不是原生写法，这肯定是 JS 侧封装的，查看 Weex 源码
-
-```JS
-// Weex JS Framework 核心源码（简化）
-WeexInstance.prototype.requireModule = function requireModule(moduleName) {
- // 1. 基础校验：Weex实例是否有效（比如是否已销毁）
- var id = getId(this); // 获取当前Weex实例ID
- if (!(id && this.document && this.document.taskCenter)) {
- console.error("[JS Framework] Failed to requireModule(\"" + moduleName + "\"), instance doesn't exist.");
- return;
- }
-
- // 2. 关键校验：检查Module是否在Native侧注册过
- if (!isRegisteredModule(moduleName)) {
- console.warn("[JS Framework] using unregistered weex module \"" + moduleName + "\"");
- return;
- }
-
- // 3. 核心：创建Module代理对象（并非真实对象，仅封装桥接调用）
- var moduleProxy = {};
- // 获取该Module在Native侧注册的所有方法（提前从Native同步到JS的方法映射表）
- var moduleMethods = getRegisteredMethods(moduleName);
-
- // 4. 为代理对象绑定方法：调用方法时触发JS-Native桥接
- moduleMethods.forEach(function(methodName) {
- moduleProxy[methodName] = function() {
- // 封装调用参数：实例ID、Module名、方法名、参数、回调
- var args = Array.prototype.slice.call(arguments);
- var callback = null;
- // 提取最后一个参数作为回调（Weex约定）
- if (typeof args[args.length - 1] === 'function') {
- callback = args.pop();
- }
-
- // 5. 核心：通过taskCenter（桥接核心）调用Native
- this.document.taskCenter.sendNative('callNative', {
- instanceId: id,
- module: moduleName,
- method: methodName,
- params: args,
- callback: callback ? generateCallbackId(callback) : null
- });
- }.bind(this);
- }, this);
-
- // 6. 返回代理对象给JS侧使用
- return moduleProxy;
-};
-```
-
-- 返回的不是真实的 Module 实例，而是代理对象（Proxy） —— 所有方法调用都会被拦截，转而通过桥接发送到 Native；
-- isRegisteredModule 校验：JS 侧会缓存一份「Native 已注册 Module 列表」（Native 初始化时同步到 JS），避免无效桥接。
-
-方案一：Weex 由于安全设计，没办法直接注入 JS。也就是说想通过“切面”思想，hook JS 侧 requireModule 是行不通的。这种方案，代码如下
-
-```JS
-// 备份原生requireModule方法
-const originalRequireModule = WeexInstance.prototype.requireModule;
-
-// 重写requireModule，在错误触发时主动上报Native
-WeexInstance.prototype.requireModule = function (moduleName) {
- // 先执行原生判断逻辑
- const id = getId(this);
- if (!(id && this.document && this.document.taskCenter)) {
- const errorMsg = "[JS Framework] Failed to requireModule(\"" + moduleName + "\"), instance (" + id + ") doesn't exist anymore.";
- // 主动上报“实例不存在”错误到Native
- this.document.taskCenter.sendNative('__weex_apm_report', {
- type: 'module_require_failed',
- subType: 'instance_not_exist',
- moduleName: moduleName,
- message: errorMsg,
- instanceId: id
- });
- console.error(errorMsg);
- return;
- }
-
- // 核心：拦截“未注册Module”判断
- if (!isRegisteredModule(moduleName)) {
- const warnMsg = "[JS Framework] using unregistered weex module \"" + moduleName + "\"";
- // 主动上报“Module未注册”错误到Native（关键）
- this.document.taskCenter.sendNative('__weex_apm_report', {
- type: 'module_not_registered',
- moduleName: moduleName,
- message: warnMsg,
- instanceId: id,
- timestamp: Date.now()
- });
- // 保留原生warn日志（不影响原有逻辑）
- console.warn(warnMsg);
- return;
- }
-
- // 执行原生逻辑
- return originalRequireModule.call(this, moduleName);
-};
-```
-
-方案二：Native 侧拦截 JS 的 console.warn 调用（无 JS 侵入）
-
-写法1：Weex JS 侧的 `console.warn` 最终会通过 WXBridgeContext 的 `handleJSLog` 方法传递到 Native，无需解析最终日志，直接 Hook 该方法拦截 warn 信息，精准匹配 Module 未注册错误
-
-```Objective-C
-#import
-
-@implementation NSObject (WXJSLogHook)
-+ (void)load {
- static dispatch_once_t onceToken;
- dispatch_once(&onceToken, ^{
- // 获取WXBridgeContext类（无需头文件）
- Class bridgeContextClass = NSClassFromString(@"WXBridgeContext");
- if (!bridgeContextClass) return;
-
- // Hook处理JS日志的核心方法：handleJSLog:
- SEL handleJSLogSel = NSSelectorFromString(@"handleJSLog:");
- Method originalMethod = class_getInstanceMethod(bridgeContextClass, handleJSLogSel);
- if (!originalMethod) return;
-
- SEL swizzledSel = NSSelectorFromString(@"weex_apm_handleJSLog:");
- Method swizzledMethod = class_getInstanceMethod(self, swizzledSel);
- class_addMethod(bridgeContextClass, swizzledSel, method_getImplementation(swizzledMethod), method_getTypeEncoding(swizzledMethod));
- method_exchangeImplementations(originalMethod, swizzledMethod);
- });
-}
-
-// Hook后的handleJSLog方法：拦截JS侧的warn日志
-- (void)weex_apm_handleJSLog:(NSDictionary *)logInfo {
- // 1. 先执行原方法，保留原有日志输出逻辑
- [self weex_apm_handleJSLog:logInfo];
-
- // 2. 解析JS日志信息（logInfo格式：{level: 'warn', msg: 'xxx', ...}）
- NSString *logLevel = logInfo[@"level"];
- NSString *logMsg = logInfo[@"msg"];
-
- // 3. 精准匹配“未注册Module”的warn
- if ([logLevel isEqualToString:@"warn"] && [logMsg containsString:@"using unregistered weex module"]) {
- // 提取Module名称
- NSRegularExpression *regex = [NSRegularExpression regularExpressionWithPattern:@"using unregistered weex module \"(.*?)\"" options:0 error:nil];
- NSTextCheckingResult *match = [regex firstMatchInString:logMsg options:0 range:NSMakeRange(0, logMsg.length)];
- NSString *moduleName = match ? [logMsg substringWithRange:match.rangeAtIndex(1)] : @"";
-
- // 4. 构造APM数据上报
- NSDictionary *apmData = @{
- @"error_type": @"weex_module_not_registered",
- @"module_name": moduleName,
- @"message": logMsg,
- @"source": @"js_console_warn", // 标记来源：JS console.warn
- @"timestamp": @([[NSDate date] timeIntervalSince1970] * 1000)
- };
-
- // 调用 APM SDK 接口，数据先落库，后续统一按照数据上报策略，从本地 DB 捞取、聚合、上报
- // [YourAPMManager reportWeexError:apmData];
- }
-}
-@end
-```
-核心优势
-- 无侵入：无需修改 / 注入 JS 代码，纯 Native 侧实现；
-- 精准：拦截的是 JS 侧传递到 Native 的原始日志数据（而非最终打印的字符串），无格式误差；
-- 覆盖全：所有 JS 侧的console.warn都会经过此方法，100% 覆盖 Module 未注册场景
-
-写法二：由于 Weex 代码是大量的存量业务代码，很稳定。而且 Weex 官方好几年不更新，所以我们内部私有化 Weex SDK，也就没有采取 Hook 手段。而是直接修改源码，`WXBridgeContext.m` 的 `+ (void)handleConsoleOutputWithArgument:(NSArray *)arguments logLevel:(WXLogFlag)logLevel` 方法。比如：
-
-```Objective-C
-+ (void)handleConsoleOutputWithArgument:(NSArray *)arguments logLevel:(WXLogFlag)logLevel
-{
- NSMutableString *string = [NSMutableString string];
- [string appendString:@"jsLog: "];
- [arguments enumerateObjectsUsingBlock:^(JSValue *jsVal, NSUInteger idx, BOOL *stop) {
- [string appendFormat:@"%@ ", jsVal];
- if (idx == arguments.count - 1) {
- if (logLevel) {
- if (WXLogFlagWarning == logLevel || WXLogFlagError == logLevel) {
- if ([string containsString:@"using unregistered weex module"]) {
- // 提取Module名称
- NSRegularExpression *regex = [NSRegularExpression regularExpressionWithPattern:@"using unregistered weex module \"(.*?)\"" options:0 error:nil];
- NSTextCheckingResult *match = [regex firstMatchInString:string options:0 range:NSMakeRange(0, string.length)];
- NSString *moduleName = match ? [string substringWithRange:[match rangeAtIndex:1]] : @"";
-
- // 接入收口工具类
- NSString *exceptionMsg = [NSString stringWithFormat:@"JS require未注册模块：%@，原始日志：%@", moduleName, string];
- NSDictionary *customExt = @{@"moduleName": moduleName};
- NSString *instanceId = [WXSDKEngine topInstance].instanceId ?: @"";
- NSString *bundleUrl = [WXSDKEngine topInstance].scriptURL.absoluteString ?: @"";
- [[WXExceptionReporter sharedInstance] reportExceptionWithCode:WXCustomExceptionCode_Module_NotRegistered
- exceptionType:WXCustomExceptionType_Module
- instanceId:instanceId
- function:@"handleConsoleOutputWithArgument:logLevel:"
- exceptionMsg:exceptionMsg
- bundleUrl:bundleUrl
- customExtParams:customExt];
- }
-
- id appMonitorHandler = [WXSDKEngine handlerForProtocol:@protocol(WXAppMonitorProtocol)];
- if ([appMonitorHandler respondsToSelector:@selector(commitAppMonitorAlarm:monitorPoint:success:errorCode:errorMsg:arg:)]) {
- [appMonitorHandler commitAppMonitorAlarm:@"weex" monitorPoint:@"jswarning" success:NO errorCode:@"99999" errorMsg:string arg:[WXSDKEngine topInstance].pageName];
- }
- }
- WX_LOG(logLevel, @"%@", string);
- } else {
- [string appendFormat:@"%@ ", jsVal];
- WXLogInfo(@"%@", string);
- }
- }
- }];
-}
-```
-
-
-
-#### 2. JS 调用 Moudle 方法失败
-Native 注册了一个负责逻辑的 Module，但是在 JS 侧使用的时候，要么方法名写错了，要么参数少传了，都可能导致预期的逻辑执行错误，发生不符合预期的行为。
-
-##### 1. 点击事件工作原理
-核心问题：点击事件发生时，如何根据 Component 的点击事件定位到该 Component 在 Vue DSL 中声明的事件？
-
-第一步：页面初始化时，JS 侧构建**事件映射表**。
-Weex 页面渲染时，会为每个组件做2件事情：
-- 生成组件唯一标识：每个组件都有 `ref/componentId/docId`，类似组件身份证
-- 绑定事件与方法：解析 `@click="handleButtonClick"` 时，JS 会将「组件 ID + 事件类型（click）」作为 key，`handleButtonClick` 作为 value，一起存进组件实例的映射表里，（对应下面的 `this.event[type]`）
-
-第二步：Native 侧捕获点击，携带关键信息调用 fireEvent。
-Native 侧能拿到 componentId，是因为渲染组件时，JS 侧会把组件 ID 同步给 Native 渲染引擎（WXComponent），Native 控件和 JS 组件实例通过 ID 一一绑定
-
-第三步：JS 侧调用 `fireEvent` 方法，其内部通过 `ID + 事件类型` 找方法。
-- 定位组件实例：JS 通过 componentID（代码里的 this.ref）找到组件实例。
-- 查找事件映射：从组件实例的 `this.event` 里根据 type （如 click）找到具体的 eventDesc（包含具体的 handler）
-- 发起调用 `handler.call`
-
-```js
-/**
- * Fire an event manually.
- * @param {string} type type
- * @param {function} event handler
- * @param {boolean} isBubble whether or not event bubble
- * @param {boolean} options
- * @return {} anything returned by handler function
- */
- Element.prototype.fireEvent = function fireEvent (type, event, isBubble, options) {
- var result = null;
- var isStopPropagation = false;
- var eventDesc = this.event[type];
- if (eventDesc && event) {
- var handler = eventDesc.handler;
- event.stopPropagation = function () {
- isStopPropagation = true;
- };
- if (options && options.params) {
- result = handler.call.apply(handler, [ this ].concat( options.params, [event] ));
- }
- else {
- result = handler.call(this, event);
- }
- }
-
- if (!isStopPropagation
- && isBubble
- && (BUBBLE_EVENTS.indexOf(type) !== -1)
- && this.parentNode
- && this.parentNode.fireEvent) {
- event.currentTarget = this.parentNode;
- this.parentNode.fireEvent(type, event, isBubble); // no options
- }
-
- return result
- };
-```
-
-##### 2. JS 调用 module 方法，方法名错误
-Native 注册的 Module 方法名为 `multiply:num2:callback:`，而在 JS 侧调用的时候方法名多加了几个字符，造成方法名对不上，方法调用失败的问题。
-
-用户点击屏幕上的 UI 控件（此处就是注册 Component `[WXSDKEngine registerComponent:@"color-button" withClass:[WXColorButtonComponent class]]`)。
-
-Weex 统一给 Comonent 添加了分类来负责事件的处理。`WXComponent+Events`。源码中 `addClickEvent` 就是添加了点击事件的监听。当发生点击后会计算点击事件的坐标和时间戳信息，最后封装一个 `WXCallJSMethod` 对象，方法名固定为 `fireEvent`。如下堆栈所示：
-
-
-由于 `logicCalculation` 没有对应的 `multiplyWith` 方法，所以会报错，被 JS 的 `try...catch...` 捕获后，通过 `console.error` 的方式输出异常信息。但是 `console.error` 被 Native 接管了。所以我们可以在 Native 接管的地方统一拦截处理。只要日志包含 `Failed to invoke the event handler` 就可以认为是因为方法名问题，导致调用方法出错
-
-代码如下：
-```Objective-c
-+ (void)handleConsoleOutputWithArgument:(NSArray *)arguments logLevel:(WXLogFlag)logLevel
-{
- // ...
- if ([string containsString:@"Failed to invoke the event handler"]) {
- // 原有解析逻辑保留
- NSString *errorMethodName = @"";
- NSString *eventType = @"";
- NSRegularExpression *regex = [NSRegularExpression regularExpressionWithPattern:@"'\\.\\.\\.(?:logicCalculation\\.)([a-zA-Z0-9_]+)\\.\\.\\." options:0 error:nil];
- NSTextCheckingResult *match = [regex firstMatchInString:string options:0 range:NSMakeRange(0, string.length)];
- if (match) {
- errorMethodName = [string substringWithRange:[match rangeAtIndex:1]];
- }
- NSRegularExpression *eventRegex = [NSRegularExpression regularExpressionWithPattern:@"event handler of \"([^\"]+)\"" options:0 error:nil];
- NSTextCheckingResult *eventMatch = [eventRegex firstMatchInString:string options:0 range:NSMakeRange(0, string.length)];
- if (eventMatch) {
- eventType = [string substringWithRange:[eventMatch rangeAtIndex:1]];
- }
-
- // 接入收口工具类
- NSString *exceptionMsg = [NSString stringWithFormat:@"Module方法名错误：%@，事件类型：%@，原始日志：%@", errorMethodName, eventType, string];
- NSDictionary *customExt = @{
- @"moduleName": @"logicCalculation",
- @"methodName": errorMethodName,
- @"eventType": eventType
- };
- NSString *instanceId = [WXSDKEngine topInstance].instanceId ?: @"";
- NSString *bundleUrl = [WXSDKEngine topInstance].scriptURL.absoluteString ?: @"";
- [[WXExceptionReporter sharedInstance] reportExceptionWithCode:WXCustomExceptionCode_Module_MethodNotFound
- exceptionType:WXCustomExceptionType_Module
- instanceId:instanceId
- function:@"handleConsoleOutputWithArgument:logLevel:"
- exceptionMsg:exceptionMsg
- bundleUrl:bundleUrl
- customExtParams:customExt];
- }
- // ...
-}
-```
-
-效果如下
-
-
-
-##### 3. JS 调用 module 方法，方法参数个数不匹配
-上面已经讲了点击事件的工作流程，调用方法时，除了调用了不存在的方法或者方法名写错了，还有一种情况就是参数个数不匹配。
-
-这种情况如何识别并监控？
-JS 的事件处理函数里，调用注册的 Module 和对应的方法，会统一走到 `WXJSCoreBridge.mm` 的 `- (void)registerCallNativeModule:(WXJSCallNativeModule)callNativeModuleBlock` 给当前的 JSContext 注册好的 `callNativeModule` 回调里。`_jsContext[@"callNativeModule"] = ^JSValue *(JSValue *instanceId, JSValue *moduleName, JSValue *methodName, JSValue *args, JSValue *options)` 可以拿到模块名、方法名、参数个数、instanceID 等。拿到实际传递的方法参数列表，再通过模块名根据 `ModuleFactory` 找到模块类对象，然后利用 runtime 能力，遍历类对象的方法列表，找到对应的 SEL，判断其预期的方法参数个数，然后再和实际传递过来的方法参数个数做比较即可
-
-```Objective-c
-- (void)registerCallNativeModule:(WXJSCallNativeModule)callNativeModuleBlock
-{
- // JS 调用 Native 的方法都会走这里。可以解析到：模块名、方法名、参数数组等信息。可以在这里判断方法参数个数是否相同。
- _jsContext[@"callNativeModule"] = ^JSValue *(JSValue *instanceId, JSValue *moduleName, JSValue *methodName, JSValue *args, JSValue *options) {
- // ...
- };
-}
-```
-
-在其 `callNativeModule` 的 block 里，增加一个方法，专门用来判断和检查方法参数个数是否匹配的问题
-```Objective-C
-// 辅助方法：校验Module方法参数个数
-- (void)checkModuleParamCount:(NSString *)moduleName
- methodName:(NSString *)methodName
- actualParams:(NSArray *)actualParams
- instanceId:(NSString *)instanceId {
- // 1. 跳过空值/系统模块（避免无意义校验）
- if (!moduleName || !methodName || actualParams.count < 0) return;
- Class moduleClass = [WXModuleFactory classWithModuleName:moduleName];
- if (!moduleClass) return;
-
- // 2. 拼接完整的方法选择器（Weex Module方法名带冒号，需补全，如multiply→multiply:num2:callback:）
- // 注：若方法名规则固定，可通过模块类的方法列表获取所有selector，匹配前缀
- SEL targetSel = nil;
- unsigned int methodCount = 0;
- Method *methods = class_copyMethodList(moduleClass, &methodCount);
- for (int i = 0; i < methodCount; i++) {
- Method method = methods[i];
- SEL sel = method_getName(method);
- NSString *selStr = NSStringFromSelector(sel);
- // 匹配前缀（如multiply开头的方法）
- if ([selStr hasPrefix:methodName]) {
- targetSel = sel;
- break;
- }
- }
- free(methods);
- if (!targetSel) return;
-
- // 3. 解析方法签名，计算预期参数个数（减self/_cmd）
- NSMethodSignature *methodSig = [moduleClass instanceMethodSignatureForSelector:targetSel];
- NSInteger weexParamCount = methodSig.numberOfArguments - 2;
-
- // 4. 判断参数个数是否不匹配
- if (actualParams.count != weexParamCount) {
- // 构造错误信息
- NSString *errorMsg = [NSString stringWithFormat:@"Module:%@ 方法:%@ 参数个数不匹配，预期%ld个，实际%ld个",
- moduleName, methodName, weexParamCount, actualParams.count];
- WXLogError(@"[WeexParamError] %@", errorMsg);
-
- // 5. 上报APM（核心：生产环境监控）
- NSDictionary *apmData = @{
- @"error_type": @"weex_module_param_count_mismatch",
- @"module_name": moduleName,
- @"method_name": methodName,
- @"expected_count": @(weexParamCount),
- @"actual_count": @(actualParams.count),
- @"actual_params": actualParams,
- @"instance_id": instanceId ?: @"",
- @"timestamp": @([[NSDate date] timeIntervalSince1970] * 1000),
- @"message": errorMsg
- };
-
- // APM:异步上报，避免阻塞JS桥接
- NSLog(@"APM 数据上报通道，【JS 通过 Module 调用 Native 方法，参数个数不匹配】：%@", apmData);
- }
-}
-```
-效果如下：
-
-
-
-#### 5. Vue 层面异常
-Weex 底层依靠 Vue 实现，差异化就是 VM 去通过 Bridge 在 WeexSDK Native 去做绘制。异常方面除了常规的 JS 运行时异常（如语法错误、类型错误等 7 种），Vue 框架自身的逻辑层、编译层、响应式系统、组件生命周期 等环节会抛出专属异常，这些异常必须通过 Vue.config.errorHandler 兜底。
-
-分析 Weex 源码中：`packages/weex-js-framework/index.js/`
-
-```js
-function handleError (err, vm, info) {
- if (vm) {
- var cur = vm;
- while ((cur = cur.$parent)) {
- var hooks = cur.$options.errorCaptured;
- if (hooks) {
- for (var i = 0; i < hooks.length; i++) {
- try {
- var capture = hooks[i].call(cur, err, vm, info) === false;
- if (capture) { return }
- } catch (e) {
- globalHandleError(e, cur, 'errorCaptured hook');
- }
- }
- }
- }
- }
- globalHandleError(err, vm, info);
-}
-
-function globalHandleError (err, vm, info) {
- if (config.errorHandler) {
- try {
- return config.errorHandler.call(null, err, vm, info)
- } catch (e) {
- logError(e, null, 'config.errorHandler');
- }
- }
- logError(err, vm, info);
-}
-```
-
-
-源码中 nextTick、Vue.prototype.$emit、callHook、Watcher.prototype.get、Watcher.prototype.run、renderRecyclableComponentTemplate、Vue.prototype._render 等等都调用了 handleError 方法。
-Vue 内部对部分异常做了封装/拦截，避免直接冒泡到全局（防止阻断应用整体运行），但会通过 errorHandler 暴露出来。
-
-举个例子，WeexAPM 类可以封装为：
-```JS
-/**
- * APM
- */
-class WeexAPM {
- /**
- * 获取当前的叶子节点
- * @param {*} Vue vm
- * @returns 当前组件名称
- */
- formatComponentName (vm) {
- if (vm.$root === vm) return 'root'
- var name = vm._isVue
- ? (vm.$options && vm.$options.name) ||
- (vm.$options && vm.$options._componentTag)
- : vm.name
- return (
- (name ? 'component <' + name + '>' : 'anonymous component') +
- (vm._isVue && vm.$options && vm.$options.__file
- ? ' at ' + (vm.$options && vm.$options.__file)
- : '')
- )
- }
-
- /**
- * 处理Vue错误提示
- */
- monitor (Vue) {
- if (!Vue) {
- return
- }
- // 错误处理
- Vue.config.errorHandler = (err, vm, info) => {
- let componentName = 'unknown'
- if (vm) {
- componentName = this.formatComponentName(vm)
- }
- let errorInfo = {
- name: err.name,
- reason: err.message,
- callStack: err.stack,
- componentName: componentName,
- info: info,
- level: 'VUE_ERROR'
- }
- try {
- const weexAPMUploader = weex.requireModule('weexAPMUploader')
- weexAPMUploader.uploadException(errorInfo)
- } catch (error) {
- console.error('APMMonitor 能力有问题，请检查是否注册了weexAPMUploader模块' + error)
- }
- }
- }
-}
-
-export default WeexAPM
-```
-在捕获到 Vue 层面的异常时，可以调用注册好的 weexAPMUploader module 能力，将数据传输到 Native 侧，由 Native 侧进行统一的参数组装，最后调用 APM SDK 的能力进行数据写入数据库、按照策略上报到 APM 服务端进行消费。
-
-模拟产生 Vue 层级的错误：给一个字符串类型的数据，在计算属性里调用 `toFixed` 方法。按钮的点击事件里将数据改为字符串，则会报错。
-可以看到被 `Vue.config.errorHandler` 捕获了，后续交给 Native 处理即可。
-
-
\ No newline at end of file
diff --git a/Chapter1 - iOS/1.147.md b/Chapter1 - iOS/1.147.md
deleted file mode 100644
index f2cae13..0000000
--- a/Chapter1 - iOS/1.147.md
+++ /dev/null
@@ -1,278 +0,0 @@
-# Rust 在移动端可以做什么
-
-> uniffi 的思路，和早期类似营销计算的逻辑用 ts 写好，端上 js 引擎加速，Android、iOS 再去使用是一个思路。
-
-## 一、Uniffi 在移动端能做什么？
-
-### 1. uniffi 是什么？
-
-uniffi（全称 “Uniffi-rs”）是 Mozilla 开发的一个跨语言绑定生成工具，核心作用是让 Rust 代码能被其他编程语言（如 Swift、Kotlin、Python、JavaScript 等）无缝调用，通过自动生成类型安全的绑定层，大幅简化跨语言 FFI（Foreign Function Interface）开发的复杂度。
-
-### 2. 为什么营销计算的逻辑适合用 ts 写？
-
-纯函数，给定恒定的输入，输出不变。这非常适合 ts、rust 去实现。所以可以说，纯函数、纯逻辑适合用 Rust 去开发。区别在于即使采用类似 Wasm、JS 引擎预热、预加载等技术手段，Rust 天然比 JS 效率高。
-
-### 3. ffi 能做什么？
-
-早期 Flutter 和 Native 交互走 method channel 效率低，所以腾讯的同学开发了 Dart Native 方案，就是基于 ffi 的思路。
-
-
-所以可以回答 Uniffi 能做什么的问题了：
-
-uniffi 的核心是 “让 Rust 成为跨语言共享逻辑的‘通用语言’”，尤其在移动端，它解决了 iOS 和 Android 逻辑重复开发的问题，同时借助 Rust 的安全和性能优势，提升核心模块的可靠性。它更适合 “业务逻辑层” 而非 “UI 层”（UI 仍需依赖各平台原生框架），是移动端跨平台开发的重要补充工具
-
-
-
-uniffi 的核心价值是跨语言复用 Rust 代码，因此它适合开发 “需要在多平台 / 多语言间共享的核心逻辑”，尤其适合以下场景：
-
-1. 跨平台共享的业务逻辑当同一套逻辑需要在多个平台（如移动端 iOS/Android、桌面端、后端服务）实现时，用 Rust 编写一次核心逻辑，再通过 uniffi 生成各平台对应的绑定（如 Swift 绑定供 iOS 调用，Kotlin 绑定供 Android 调用、桌面端 Electron js 去调用、小程序 js 去调用），避免重复开发，保证逻辑一致性。
-2. 对安全性、性能要求高的模块 Rust 自带内存安全和零成本抽象特性，适合处理敏感逻辑（如加密解密、用户认证、支付流程）或性能敏感操作（如数据解析、复杂计算、实时处理）。uniffi 能让这些 Rust 模块被其他语言（如动态语言）安全调用，兼顾安全性与开发效率。
-3. 需要跨语言交互的中间层例如，在一个混合技术栈的项目中（如前端用 JavaScript、后端用 Python、移动端用 Kotlin/Swift），可以用 Rust 编写通用的数据处理或协议解析逻辑，再通过 uniffi 生成多语言绑定，作为各层之间的 “桥梁”。
-4. 替代手动 FFI 开发传统跨语言调用需要手动编写 FFI 绑定（如用 extern "C" 暴露 Rust 接口，再在其他语言中手动适配类型），容易出错且维护成本高。uniffi 可自动生成类型安全的绑定，大幅降低开发和维护成本。
-
-## 二、移动端中 uniffi 可以做什么？
-
-移动端开发的核心痛点之一是 “iOS（Swift/Objective-C）和 Android（Kotlin/Java）需要重复实现相同逻辑”，而 uniffi 恰好能通过 Rust 实现跨平台逻辑复用，具体应用场景包括：共享核心业务逻辑例如：用户登录流程、权限验证、数据校验规则、业务状态管理等。用 Rust 编写一次，通过 uniffi 生成 Swift 绑定（供 iOS）和 Kotlin 绑定（供 Android），两端直接调用，避免 “同一逻辑两套代码” 的冗余和不一致问题。
-
-高性能数据处理移动端涉及的复杂数据处理（如 JSON/Protobuf 解析、大数据集合过滤 / 排序、二进制协议编解码），用 Rust 实现可获得比 Kotlin/Swift 更高的性能，uniffi 可让两端高效调用这些逻辑。
-
-安全敏感操作如加密（AES、RSA）、解密、签名验证、敏感数据（密码、Token）存储逻辑等，Rust 的内存安全特性可减少传统 C/C++ 调用可能带来的内存漏洞风险，uniffi 则确保调用过程的类型安全。
-
-跨平台工具类例如：日期时间处理、字符串工具、设备信息计算（如唯一标识生成）等通用工具，用 Rust 实现后，通过 uniffi 让 iOS 和 Android 共享，减少重复开发。
-
-与现有跨平台框架配合即使项目使用 Flutter、React Native 等跨平台 UI 框架，也可通过 uniffi 将 Rust 逻辑作为 “原生能力扩展”：例如 Flutter 中通过 Platform Channel 调用 uniffi 生成的 Rust 绑定，处理 Flutter 难以高效实现的复杂计算。
-
-
-
-### 三、Rust 中使用 Unifii 实现与 Swift 高效互操作性
-UniFFI（Universal Foreign Function Interface）是一个工具集，旨在帮助开发者轻松生成适用于多个编程语言（如 Swift、Kotlin 和 Python）的外部函数接口 (FFI) 绑定。它允许你通过定义一个接口描述语言 (UDL) 文件，自动生成跨语言的绑定代码，从而简化 Rust 代码与其他语言之间的交互。
-
-#### 1. 必要工具
-开始之前，你需要确保已经安装了以下工具：
-- Rust 和 Cargo：Rust 是一种系统编程语言，强调安全性和性能。Cargo 是 Rust 的包管理器和构建系统。
-验证安装：运行以下命令确保 Rust 和 Cargo 已正确安装。
-```shell
-rustc --version
-cargo --version
-```
-- UniFFI CLI 工具：UniFFI 提供了一个命令行工具，用于生成绑定代码。安装 UniFFI：你可以通过 Cargo 安装 UniFFI。
-```shell
-cargo install uniffi_bindgen
-```
-验证安装：运行以下命令确保 UniFFI 已正确安装。
-```shell
-uniffi-bindgen --version
-```
-
-#### 2. 项目设置
-1. 创建 Rust 项目
-- 打开终端并运行以下命令创建一个新的 Rust 库项目：
-```shell
-cargo new my_rust_library --lib
-cd my_rust_library
-```
-- 编辑Cargo.toml文件，添加 Uniffi 依赖项
-```shell
-[dependencies]
-uniffi = "0.27.0"
-serde = { version = "1.0", features = ["derive"] }
-```
-- 配置Cargo.toml文件中的lib部分，设置 crate 类型为 cdylib：
-```shell
-[lib]
-crate-type = ["cdylib"]
-```
-
-2. 创建名为 `MySwiftApp` 的Swift 项目
-
-#### 3. Rust 库的创建
-我们将创建一个简单的 Rust 库，并配置它以便与 Swift 互操作。我们将定义一个数据结构和一些基本的功能，使用 UniFFI 来生成绑定。
-1. 设置 Cargo.toml
-首先，我们需要在 Cargo.toml 文件中配置项目依赖和库类型：
-```rs
-[package]
-name = "my_rust_library"
-version = "0.1.0"
-edition = "2018"
-
-[dependencies]
-uniffi = "0.27.0" # 检查最新版本
-serde = { version = "1.0", features = ["derive"] }
-
-[lib]
-crate-type = ["cdylib"]
-```
-2. 编写 Rust 代码
-在 src/lib.rs 文件中编写 Rust 代码。我们将定义一个简单的结构体 Greeting 和相关的方法。
-```rs
-// src/lib.rs
-use serde::{Serialize, Deserialize};
-use uniffi_macros::include_scaffolding;
-
-#[derive(Debug, Clone, Serialize, Deserialize)]
-pub struct Greeting {
- pub message: String,
-}
-
-impl Greeting {
- pub fn new(name: String) -> Greeting {
- Greeting {
- message: format!("Hello, {}!", name),
- }
- }
-
- pub fn greet(&self) -> String {
- self.message.clone()
- }
-}
-
-include_scaffolding!("my_library");
-```
-3. 编写 UDL 文件
-在项目根目录下创建一个新的文件 src/my_library.udl，用于定义接口描述语言 (UDL)。
-```rs
-namespace my_library {
- struct Greeting {
- message: string;
- }
-
- Greeting {
- static Greeting new(string name);
- string greet();
- }
-}
-```
-这个 UDL 文件描述了 Greeting 结构体及其方法。
-
-#### 4. 生成 Uniffi 绑定
-使用 UniFFI 工具生成 Swift 绑定文件。确保你在项目根目录下，然后运行以下命令：
-```shell
-uniffi-bindgen generate src/my_library.udl --language swift --out-dir gen/
-```
-该命令将生成必要的 Swift 文件，并保存在gen/目录下。
-
-#### 5. 构建 Rust 库
-使用以下命令构建 Rust 库：
-```shell
-cargo build --release
-```
-生成的动态库文件将位于 target/release 目录下，文件名为 libmy_rust_library.dylib（在 macOS 上）。
-
-通过上述步骤，我们创建了一个简单的 Rust 库，并配置了 Uniffi 以生成 Swift 绑定文件。在下一部分中，我们将把生成的 Swift 文件集成到 Swift 项目中，并编写代码调用 Rust 库。
-
-#### 6. 生成 UniFFI 绑定
-在这一部分，我们将使用 UniFFI 工具生成 Swift 绑定代码。这将使得我们可以在 Swift 项目中调用 Rust 库的功能。
-
-1. 编写 UDL 文件
-首先，我们需要编写一个 UniFFI 接口描述语言 (UDL) 文件。这个文件描述了我们希望暴露给 Swift 的数据结构和函数接口。
-在项目根目录的 src 文件夹中创建一个名为 my_library.udl 的文件，并添加以下内容：
-```rs
-namespace my_library {
- struct Greeting {
- message: string;
- }
-
- Greeting {
- static Greeting new(string name);
- string greet();
- }
-}
-```
-这个 UDL 文件定义了一个名为 Greeting 的结构体及其两个方法：new 和 greet
-
-
-2. 生成 Swift 绑定
-在终端中导航到项目根目录，并运行以下命令生成 Swift 绑定：
-```shell
-uniffi-bindgen generate src/my_library.udl --language swift --out-dir gen/
-```
-这个命令会根据 my_library.udl 文件生成 Swift 绑定代码，并将其放在 `gen/` 目录下。生成的文件包括：
-- my_library.swift：包含 Swift 代码，用于调用 Rust 库。
-- my_libraryFFI.h：C 头文件，用于描述 Rust 和 Swift 之间的接口。
-- my_libraryFFI.swift：内部使用的 Swift 文件，处理底层的 FFI 调用。
-
-下是生成的 my_library.swift 文件的示例内容：
-
-```swift
-import Foundation
-
-public struct Greeting {
- public let message: String
-
- public init(name: String) {
- self = Greeting.new(name: name)
- }
-
- public func greet() -> String {
- return greeting_greet(self)
- }
-}
-```
-
-my_libraryFFI.h 文件的示例内容：
-```c
-#ifndef MY_LIBRARY_FFI_H
-#define MY_LIBRARY_FFI_H
-
-#include
-#include
-
-typedef struct {
- char* message;
-} Greeting;
-
-Greeting* greeting_new(const char* name);
-const char* greeting_greet(const Greeting* self);
-void greeting_free(Greeting* self);
-
-#endif // MY_LIBRARY_FFI_H
-```
-
-3. 构建 Rust 库
-在继续之前，确保 Rust 库可以成功构建。运行以下命令：
-```shell
-cargo build --release
-```
-生成的动态库文件位于 `target/release` 目录下，文件名为 libmy_rust_library.dylib（在 macOS 上）。这个文件将被 Swift 项目使用。
-通过以上步骤，你已经成功生成了用于 Swift 调用的 Rust 绑定文件。在下一部分中，我们将这些文件集成到 Swift 项目中，并编写代码调用 Rust 库。
-
-#### 集成到 Swift 项目
-1. 打开 Finder，导航到 Rust 项目中的 `gen/` 目录，选择 my_library.swift、my_libraryFFI.h、my_libraryFFI.swift 文件。
-拖动这些文件到 Xcode 项目导航器中的项目目录下。在弹出的对话框中，确保选中 "Copy items if needed" 选项，然后点击 "Finish"。
-
-2. 添加 Rust 动态库
-为了让 Swift 项目能够找到并使用 Rust 动态库，需要将动态库文件添加到 Xcode 项目中：
-- 在 Finder 中，导航到 Rust 项目的target/release目录。
-- 找到生成的动态库文件libmy_rust_library.dylib（在 macOS 上）。
-- 拖动这个文件到 Xcode 项目导航器中的项目目录下。在弹出的对话框中，确保选中 "Copy items if needed" 选项，然后点击 "Finish"。
-
-3. 配置 Xcode 项目
-为了让 Xcode 项目能够正确地链接和加载 Rust 动态库，需要进行一些配置：
-- 选择项目文件，在左侧的 "TARGETS" 列表中选择你的应用目标。
-- 选择 "Build Phases" 选项卡。
-- 展开 "Link Binary With Libraries" 部分，点击 "+" 按钮，添加刚才拖动到项目中的 libmy_rust_library.dylib 文件。
-
-4. 配置动态库加载路径
-选择项目文件，在左侧的 "TARGETS" 列表中选择你的应用目标。
-- 选择 "Build Settings" 选项卡。
-- 搜索 "Runpath Search Paths"。
-- 添加以下路径到 "Runpath Search Paths" 配置项中：`@executable_path/../Frameworks`
-
-5. 编写 Swift 调用代码
-在 ViewController.swift 文件中，编写代码调用 Rust 库：
-```swift
-import UIKit
-
-class ViewController: UIViewController {
-
- override func viewDidLoad() {
- super.viewDidLoad()
-
- // 调用 Rust 库
- let greeting = Greeting(name: "World")
- print(greeting.greet())
- }
-}
-```
-
-通过这些步骤，已经掌握了如何在 Swift 项目中高效地使用 Rust 库，并了解了相关的高级技术。这种跨语言的集成不仅能利用 Rust 的性能优势，还能享受 Swift 的便捷开发体验。
diff --git a/Chapter1 - iOS/1.148.md b/Chapter1 - iOS/1.148.md
deleted file mode 100644
index 397738d..0000000
--- a/Chapter1 - iOS/1.148.md
+++ /dev/null
@@ -1,585 +0,0 @@
-# 移动端的“安全气垫”
-
-> 安全气垫是端上一个老生常谈的话题，技术方案已经是好多年前的产物。唯一的问题是不同公司对于安全气垫在拦截到异常的时候，“做与不做”策略的判断不同。比如数组索引越界的时候要返回一个错误位置的值吗？会不会产生业务异常？要一刀切吗？那么本文就尝试回答下这个问题
-
-## 一、一个经典的场景
-Weex 源码中，设计了一个 `WXThreadSafeMutableDictionary`。在字典操作的地方使用锁：
-```Objective-C
-- (void)setObject:(id)anObject forKey:(id)aKey
-{
- id originalObject = nil; // make sure that object is not released in lock
- @try {
- pthread_mutex_lock(&_safeThreadDictionaryMutex);
- originalObject = [_dict objectForKey:aKey];
- [_dict setObject:anObject forKey:aKey];
- }
- @finally {
- pthread_mutex_unlock(&_safeThreadDictionaryMutex);
- }
- originalObject = nil;
-}
-```
-这么写的价值：**解锁逻辑「绝对执行」，彻底避免死锁**
-这是 `@try-finally` 最核心的价值 ——无论 try 块内发生什么（正常执行、提前 return、抛异常），finally 块的解锁逻辑一定会执行
-
-对比无 try-finally 的写法
-```Objective-C
-// Bad: 若setObject抛异常，unlock不会执行→死锁
-pthread_mutex_lock(&_mutex);
-[_dict setObject:anObject forKey:aKey];
-pthread_mutex_unlock(&_mutex);
-```
-问题：`[_dict setObject:anObject forKey:aKey]` 可能抛异常（比如 aKey = nil 时会触发 NSInvalidArgumentException），若没有 finally，锁会被永久持有→其他线程调用 lock 时死锁，整个字典无法再操作。
-
-设计优点：
-- `@try-finallly`：即使 try 内逻辑出错，finally 也会执行 pthread_mutex_unlock，保证锁最终释放，这是**线程安全的「兜底保障」**
-- 注意，不是 `try...catch...finally`: 如果加了 catch 逻辑，则字典的 key 为 nil 产生的崩溃也会被捕获掉，这属于不符合预期的行为。因为 key 为 nil 产生的原因太多了，可能是业务代码异常，也可能是数据异常，也可能是逻辑错误，如果一刀切直接用 `try...catch...finally` 捕获了异常，但是没有配置异常的收集、上报、处理逻辑，属于边界不清晰，本质是为了解决加解锁不匹配而可能带来的线程安全问题，却"多管闲事"，把字典 key 为 nil 本该向上跑的异常而卡住了。
-
-这是一个经典的策略问题，端上的异常发生时，安全气垫的“做与不做”问题
-聊聊类似网易的大白解决方案或者业界其他公司中，安全气垫虽然保证了代码不 crash，影响用户体验，但是比如数组本该越界，现在却不越界：
-1. 唯一能做的就是返回一个错误的值，比如数组长度为3，访问4，现在不 crash，返回了 0 的值，那是不是产生了业务异常？比如商品价格
-2. 不 crash，也不返回错误位置的值，类似给一个回调，告诉业务方出现了异常，可以做一些业务层面的提醒或者配置(比如开发阶段商品卡片的价格 Label 显示：商品价格获取错误，数组越界)，同时产生的异常案发现场信息和其他的一些数据会上报，用于 APM 平台去分析和定位。
-
-但这也产生一个问题，类似数组越界的场景，可能10000次里面9999次都正常，只有1次异常，业务开发为了这万分之一出现的异常，还需要写一些异常处理的逻辑（比如商品卡片展示价格获取错误，数组越界）。那字典的 key 为 nil 呢？除法的分母为0呢？诸如此类，类似乐观锁和悲观锁的场景
-
-## 二、核心原则
-要解决「安全气垫防崩溃但引发隐性业务异常」「低概率异常导致业务开发冗余逻辑」的核心矛盾，业界的优雅方案核心思路是：「环境差异化策略」+「分层兜底 + 语义化默认值」+「可观测驱动的轻量处理」，既避免线上 Crash，又最小化业务侵入，同时保证问题可被发现和修复。
-
-**开发阶段让问题 “炸出来”，生产阶段让问题 “软落地”**。从源头减少线上低概率异常的发生，业务开发无需为 “万分之一” 的异常写冗余逻辑
-
-| 环境 | 核心目标 | 策略 |
-| ----------- | ---------------------------------- | ----------------------------------- |
-| 开发 / 测试 | 提前暴露问题，杜绝上线 | 「零容忍」：直接 Crash + 详细上下文 |
-| 生产 | 避免 Crash + 可观测 + 最小业务影响 | 「软兜底」：语义化默认值 + 全量上报 |
-
-
-
-## 三、多个方案
-
-### 方案1:环境差异化 + 开发强感知（网易大白/腾讯 Bugly 核心思路）
-
-对 NSArray、NSDictionary、NSNumber 等基础类做运行时 Hook，区分环境处理异常：
-NSArray+DWSafeHook.m
-
-```Objective-C
-// 核心逻辑：
-// 1. Method Swizzling Hook数组核心读写方法
-// 2. Debug环境：越界直接Crash+详细上下文，强制研发修复
-// 3. Release环境：拦截崩溃+上报异常+返回语义化空值，避免用户感知
-//
-#import "NSArray+DWSafeHook.h"
-#import
-#import "DWEnvironmentUtils.h" // 环境判断工具类（自研）
-#import "DWCrashReporter.h" // 崩溃上报工具类（自研）
-
-@implementation NSArray (DWSafeHook)
-
-#pragma mark - 对外入口：初始化Hook
-+ (void)dw_setupSafeHook {
- // 防止重复Hook
- static dispatch_once_t onceToken;
- dispatch_once(&onceToken, ^{
- // Hook 只读数组核心方法
- [self dw_swizzleInstanceMethod:@selector(objectAtIndex:)
- withNewMethod:@selector(dw_safe_objectAtIndex:)];
- [self dw_swizzleInstanceMethod:@selector(objectAtIndexedSubscript:)
- withNewMethod:@selector(dw_safe_objectAtIndexedSubscript:)];
-
- // Hook 可变数组核心方法（写操作）
- [NSMutableArray dw_swizzleInstanceMethod:@selector(addObject:)
- withNewMethod:@selector(dw_safe_addObject:)];
- [NSMutableArray dw_swizzleInstanceMethod:@selector(insertObject:atIndex:)
- withNewMethod:@selector(dw_safe_insertObject:atIndex:)];
- [NSMutableArray dw_swizzleInstanceMethod:@selector(removeObjectAtIndex:)
- withNewMethod:@selector(dw_safe_removeObjectAtIndex:)];
- });
-}
-
-#pragma mark - 私有工具：Method Swizzling封装
-/// 通用Swizzling方法（避免重复代码）
-/// @param originalSEL 原方法SEL
-/// @param newSEL 替换后的方法SEL
-+ (void)dw_swizzleInstanceMethod:(SEL)originalSEL withNewMethod:(SEL)newSEL {
- Class cls = [self class];
-
- // 获取原方法和新方法
- Method originalMethod = class_getInstanceMethod(cls, originalSEL);
- Method newMethod = class_getInstanceMethod(cls, newSEL);
- if (!originalMethod || !newMethod) {
- NSLog(@"[DWCrashGuard] Swizzling失败：方法不存在 originalSEL: %@, class: %@",
- NSStringFromSelector(originalSEL), NSStringFromClass(cls));
- return;
- }
-
- // 尝试添加新方法（防止原方法未实现）
- BOOL isAdded = class_addMethod(cls,
- originalSEL,
- method_getImplementation(newMethod),
- method_getTypeEncoding(newMethod));
- if (isAdded) {
- // 替换原方法实现
- class_replaceMethod(cls,
- newSEL,
- method_getImplementation(originalMethod),
- method_getTypeEncoding(originalMethod));
- } else {
- // 交换方法实现
- method_exchangeImplementations(originalMethod, newMethod);
- }
-}
-
-#pragma mark - Hook实现：只读数组读操作（核心防越界）
-/// 拦截 [array objectAtIndex:] 越界
-- (id)dw_safe_objectAtIndex:(NSUInteger)index {
- // 安全校验：索引越界判断
- if (index >= self.count) {
- [self dw_handleArrayOutOfBoundsWithIndex:index method:@"objectAtIndex:"];
- return [NSNull null]; // Release环境返回语义化空值（而非0）
- }
-
- // 正常逻辑：调用原方法（Swizzle后，此处实际是原objectAtIndex:）
- return [self dw_safe_objectAtIndex:index];
-}
-
-/// 拦截 array[index] 下标访问越界
-- (id)dw_safe_objectAtIndexedSubscript:(NSUInteger)index {
- if (index >= self.count) {
- [self dw_handleArrayOutOfBoundsWithIndex:index method:@"objectAtIndexedSubscript:"];
- return [NSNull null];
- }
-
- return [self dw_safe_objectAtIndexedSubscript:index];
-}
-
-#pragma mark - 私有工具：数组越界统一处理
-/// 数组越界异常处理（区分环境）
-/// @param index 访问的索引
-/// @param method 触发异常的方法名
-- (void)dw_handleArrayOutOfBoundsWithIndex:(NSUInteger)index method:(NSString *)method {
- // 1. 构建异常上下文（用于上报/调试）
- NSDictionary *context = @{
- @"crashType": @"NSArrayOutOfBounds",
- @"method": method,
- @"arrayCount": @(self.count),
- @"accessIndex": @(index),
- @"arrayDescription": [self description], // 数组内容（便于定位）
- @"callStack": [NSThread callStackSymbols], // 完整调用栈
- @"timestamp": @([[NSDate date] timeIntervalSince1970]),
- @"deviceInfo": [DWEnvironmentUtils deviceInfo] // 设备型号/系统版本等
- };
-
- // 2. 区分环境处理
- if ([DWEnvironmentUtils isDebugEnvironment]) {
- // Debug环境：直接Crash+详细日志，强制研发修复
- NSString *errorMsg = [NSString stringWithFormat:
- @"【网易大白】NSArray越界崩溃！\n"
- @"方法：%@\n"
- @"数组长度：%lu，访问索引：%lu\n"
- @"数组内容：%@\n"
- @"调用栈：%@",
- method, self.count, index, self, [NSThread callStackSymbols]];
- NSAssert(NO, @"%@", errorMsg);
- abort(); // 确保Crash（NSAssert在Release下失效）
- } else {
- // Release环境：拦截崩溃+上报APM平台
- [DWCrashReporter reportCrashWithType:@"NSArrayOutOfBounds"
- context:context
- severity:DWCrashSeverityLow]; // 低优先级（万分之一概率）
- NSLog(@"[DWCrashGuard] 拦截NSArray越界：%@, count:%lu, index:%lu", method, self.count, index);
- }
-}
-
-@end
-
-#pragma mark - 可变数组Hook实现（写操作防护）
-@implementation NSMutableArray (DWSafeHook)
-
-/// 拦截 addObject:nil 崩溃
-- (void)dw_safe_addObject:(id)anObject {
- if (anObject == nil) {
- // 构建异常上下文
- NSDictionary *context = @{
- @"crashType": @"NSMutableArrayAddNil",
- @"callStack": [NSThread callStackSymbols],
- @"timestamp": @([[NSDate date] timeIntervalSince1970])
- };
-
- if ([DWEnvironmentUtils isDebugEnvironment]) {
- // Debug环境：Crash+提示
- NSAssert(NO, @"【网易大白】NSMutableArray添加nil对象！调用栈：%@", [NSThread callStackSymbols]);
- abort();
- } else {
- // Release环境：拦截+上报，忽略nil添加
- [DWCrashReporter reportCrashWithType:@"NSMutableArrayAddNil"
- context:context
- severity:DWCrashSeverityLow];
- NSLog(@"[DWCrashGuard] 拦截NSMutableArray添加nil对象");
- return;
- }
- }
-
- // 正常逻辑：调用原方法
- [self dw_safe_addObject:anObject];
-}
-
-/// 拦截 insertObject:atIndex: 越界/nil
-- (void)dw_safe_insertObject:(id)anObject atIndex:(NSUInteger)index {
- // 1. 校验nil
- if (anObject == nil) {
- [self dw_handleMutableArrayNilObjectWithMethod:@"insertObject:atIndex:"];
- return;
- }
-
- // 2. 校验越界
- if (index > self.count) { // insert允许index == count（追加）
- [self dw_handleArrayOutOfBoundsWithIndex:index method:@"insertObject:atIndex:"];
- return;
- }
-
- // 正常逻辑
- [self dw_safe_insertObject:anObject atIndex:index];
-}
-
-/// 拦截 removeObjectAtIndex: 越界
-- (void)dw_safe_removeObjectAtIndex:(NSUInteger)index {
- if (index >= self.count) {
- [self dw_handleArrayOutOfBoundsWithIndex:index method:@"removeObjectAtIndex:"];
- return;
- }
-
- // 正常逻辑
- [self dw_safe_removeObjectAtIndex:index];
-}
-
-#pragma mark - 私有工具：可变数组nil处理
-- (void)dw_handleMutableArrayNilObjectWithMethod:(NSString *)method {
- NSDictionary *context = @{
- @"crashType": @"NSMutableArrayInsertNil",
- @"method": method,
- @"callStack": [NSThread callStackSymbols]
- };
-
- if ([DWEnvironmentUtils isDebugEnvironment]) {
- NSAssert(NO, @"【网易大白】NSMutableArray插入nil对象！方法：%@，调用栈：%@", method, [NSThread callStackSymbols]);
- abort();
- } else {
- [DWCrashReporter reportCrashWithType:@"NSMutableArrayInsertNil"
- context:context
- severity:DWCrashSeverityLow];
- NSLog(@"[DWCrashGuard] 拦截NSMutableArray插入nil对象：%@", method);
- }
-}
-@end
-```
-
-简化下，逻辑基本为：
-
-```Objective-C
-// 伪代码：Hook NSArray的objectAtIndex:
-- (id)safe_objectAtIndex:(NSUInteger)index {
- if (index >= self.count) {
- // 开发环境：Crash + 打印完整的案发现场信息 + 调用栈 + 上下文（数组内容、访问索引、业务模块）
- #ifdef DEBUG
- NSAssert(NO, @"数组越界：数组长度%lu，访问索引%lu，调用栈：%@", self.count, index, [NSThread callStackSymbols]);
- abort();
- #else
- // 生产环境：返回语义化空值（而非0）+ 上报APM
- [APMManager reportExceptionWithType:@"数组越界"
- context:@{@"arrayCount": @(self.count), @"index": @(index), @"callStack": [NSThread callStackSymbols]}];
- return [NSNull null]; // 而非0，业务层可统一识别，比如价格展示为: '--'
- #endif
- }
- return [self original_objectAtIndex:index];
-}
-```
-核心优势：
-- 开发环境：不仅 Crash，还打印「业务数据上下文」（比如当前是商品详情页、数组是价格数组），开发一眼定位问题
-- 生产环境：返回NSNull（而非无意义的 0），业务层只需做一次全局 UI 处理（比如所有 Label 展示时，判断值为NSNull则显示 “--”），无需为每个场景写逻辑
-覆盖场景：
-- 数组越界：返回NSNull；
-- 字典 key 为 nil：setObject:forKey:时忽略 nil key 并上报，objectForKey:时返回NSNull；
-- 分母为 0：返回INFINITY（全局工具类判断isinf()，统一返回 “--”）；
-- 字符串转数字失败：返回NSNull而非 0
-
-### 方案2:声明式全局兜底 + 业务按需关注（阿里/字节）
-避免业务层 “零散处理异常”，而是**全局统一兜底 + 业务选择性注册关注的异常类型**。
-- 全局层面：所有基础类异常返回 NSNull，UI 层统一处理 NSNull 为 “--”/“获取失败”；
-- 业务层面：仅对 “核心场景”（如商品价格、支付金额）注册异常回调，非核心场景无需处理：
-
-WXExceptionManager.h
-```Objective-C
-#import
-
-NS_ASSUME_NONNULL_BEGIN
-
-/// 异常类型枚举（替代字符串，避免硬编码）
-typedef NS_ENUM(NSUInteger, WXExceptionType) {
- WXExceptionTypeArrayOutOfBounds, // 数组越界
- WXExceptionTypeDictionaryNilKey, // 字典nil key
- WXExceptionTypeDivideByZero, // 分母为0
-};
-
-/// 异常上下文Key定义（统一常量，避免拼写错误）
-FOUNDATION_EXTERN NSString *const WXExceptionContextBizModuleKey; // 业务模块
-FOUNDATION_EXTERN NSString *const WXExceptionContextArrayCountKey;// 数组长度
-FOUNDATION_EXTERN NSString *const WXExceptionContextAccessIndexKey;// 访问索引
-FOUNDATION_EXTERN NSString *const WXExceptionContextCallStackKey; // 调用栈
-FOUNDATION_EXTERN NSString *const WXExceptionContextExtraKey; // 扩展信息
-
-@interface WXExceptionManager : NSObject
-
-/// 单例（全局唯一）
-+ (instancetype)sharedManager;
-
-/// 注册异常回调
-/// @param type 异常类型
-/// @param handler 回调（主线程执行，避免UI操作崩溃）
-- (void)registerCallbackForType:(WXExceptionType)type handler:(void(^)(NSDictionary *context))handler;
-
-/// 上报异常（内部Hook调用，业务层无需调用）
-/// @param type 异常类型
-/// @param context 异常上下文
-- (void)reportExceptionWithType:(WXExceptionType)type context:(NSDictionary *)context;
-
-@end
-
-NS_ASSUME_NONNULL_END
-```
-WXExceptionManager.m
-```Objective-C
-#import "WXExceptionManager.h"
-#import
-
-// 上下文Key常量定义
-NSString *const WXExceptionContextBizModuleKey = @"bizModule";
-NSString *const WXExceptionContextArrayCountKey = @"arrayCount";
-NSString *const WXExceptionContextAccessIndexKey = @"accessIndex";
-NSString *const WXExceptionContextCallStackKey = @"callStack";
-NSString *const WXExceptionContextExtraKey = @"extra";
-
-@interface WXExceptionManager ()
-/// 存储不同异常类型的回调（key: WXExceptionType的NSNumber，value: 回调数组）
-@property (nonatomic, strong) NSMutableDictionary *> *callbackDict;
-/// 线程安全锁
-@property (nonatomic, assign) pthread_mutex_t mutex;
-@end
-
-@implementation WXExceptionManager
-
-+ (instancetype)sharedManager {
- static WXExceptionManager *instance = nil;
- static dispatch_once_t onceToken;
- dispatch_once(&onceToken, ^{
- instance = [[self alloc] init];
- });
- return instance;
-}
-
-- (instancetype)init {
- self = [super init];
- if (self) {
- _callbackDict = [NSMutableDictionary dictionary];
- // 初始化线程锁
- pthread_mutex_init(&_mutex, NULL);
- }
- return self;
-}
-
-/// 注册异常回调
-- (void)registerCallbackForType:(WXExceptionType)type handler:(void (^)(NSDictionary *))handler {
- if (!handler) return;
-
- pthread_mutex_lock(&_mutex);
- // 按异常类型分组存储回调
- NSNumber *typeKey = @(type);
- if (!_callbackDict[typeKey]) {
- _callbackDict[typeKey] = [NSMutableArray array];
- }
- [_callbackDict[typeKey] addObject:handler];
- pthread_mutex_unlock(&_mutex);
-}
-
-/// 上报异常（触发回调+APM上报）
-- (void)reportExceptionWithType:(WXExceptionType)type context:(NSDictionary *)context {
- // 1. APM平台上报（模拟：实际对接公司APM，如Bugly/云监控）
- NSLog(@"【APM上报】异常类型：%lu，上下文：%@", type, context);
-
- // 2. 触发注册的回调（主线程执行，避免UI操作崩溃）
- dispatch_async(dispatch_get_main_queue(), ^{
- pthread_mutex_lock(&self->_mutex);
- NSNumber *typeKey = @(type);
- NSArray *handlers = self->_callbackDict[typeKey];
- pthread_mutex_unlock(&self->_mutex);
-
- for (void(^handler)(NSDictionary *) in handlers) {
- if (handler) {
- handler(context);
- }
- }
- });
-}
-
-- (void)dealloc {
- pthread_mutex_destroy(&_mutex);
-}
-
-#pragma mark - 类方法封装（简化调用）
-+ (void)registerCallbackForType:(WXExceptionType)type handler:(void (^)(NSDictionary *))handler {
- [[self sharedManager] registerCallbackForType:type handler:handler];
-}
-
-+ (void)reportExceptionWithType:(WXExceptionType)type context:(NSDictionary *)context {
- [[self sharedManager] reportExceptionWithType:type context:context];
-}
-
-@end
-```
-使用的地方
-```Objective-C
-- (void)viewDidLoad {
- [super viewDidLoad];
- self.view.backgroundColor = [UIColor whiteColor];
-
- // 1. 初始化价格标签
- self.priceLabel = [[UILabel alloc] initWithFrame:CGRectMake(100, 200, 200, 40)];
- self.priceLabel.font = [UIFont systemFontOfSize:18];
- [self.view addSubview:self.priceLabel];
-
- // 2. 模拟业务数据：价格数组（长度3，索引0-2）
- self.priceArray = @[@"99.9", @"199.9", @"299.9"];
- // 标记数组所属业务模块（关键：用于回调筛选）
- self.priceArray.bizModule = @"goodsPrice";
-
- // 3. 注册数组越界异常回调（仅关注价格模块）
- [WXExceptionManager registerCallbackForType:WXExceptionTypeArrayOutOfBounds handler:^(NSDictionary *context) {
- // 筛选：仅处理“价格数组”的越界异常
- if ([context[WXExceptionContextBizModuleKey] isEqualToString:@"goodsPrice"]) {
- NSLog(@"【业务降级】商品价格数组越界，触发UI兜底");
- // 生产环境：展示友好提示（而非错误值）
- self.priceLabel.text = @"价格获取失败";
- // 可选：触发其他降级逻辑（如隐藏价格、显示默认价）
- [self triggerPriceFallback];
- }
- }];
-
- // 4. 模拟异常场景：访问索引3（越界）
- [self testPriceArrayOutOfBounds];
-}
-
-/// 模拟价格数组越界访问
-- (void)testPriceArrayOutOfBounds {
- // 访问索引3（数组长度3，正常索引0-2）
- id price = [self.priceArray objectAtIndex:3];
- // 正常场景：显示价格；异常场景：price是NSNull，显示兜底
- if ([price isKindOfClass:[NSNull class]]) {
- self.priceLabel.text = @"价格获取失败";
- } else {
- self.priceLabel.text = [NSString stringWithFormat:@"¥%@", price];
- }
-}
-
-/// 价格降级逻辑（可选）
-- (void)triggerPriceFallback {
- // 比如：隐藏优惠券、显示默认包邮等
- NSLog(@"【降级】隐藏优惠券模块，显示默认包邮文案");
-}
-
-@end
-```
-核心优势：
-- 99% 的低概率异常由全局兜底处理（返回 NSNull+UI 显示 --）
-- 仅核心业务场景（价格、支付）需写少量回调逻辑，避免冗余
-效果，类似针对核心的业务场景做专项化监控和优化。
-
-
-### 方案 3：静态分析 + CI/CD 前置拦截（从源头消灭异常）
-比运行时 Hook 更优雅的是 **“提前拦截”**。通过静态分析工具（Clang Static Analyzer、OCLint、自定义 LLVM 插件），在代码提交/编译阶段检测出：
-- 数组越界风险（如array[index]中 index 未做长度校验）
-- 字典 key 为 nil（如dict[nil]）
-- 分母为 0（如a / b中 b 未判 0）
-- 强制类型转换风险（如(NSNumber *)nil）
-
-落地方式：
-- 集成到 CI/CD Pipeline，代码提交时触发静态分析，有风险则阻断合入
-- 通过编写 LLVM 插件，就可以在 Xcode 有问题的代码上实时提示 “数组越界风险”“字典 key 可能为 nil”。比如
-
-
-效果：线上低概率异常的根源被提前消灭，问题无法逃逸到现线上，业务层几乎无需处理这类异常（因为代码本身就没有漏洞）
-
-关于如何编写 LLVM 插件，做到在 Xcode 中实时展示代码中存在的问题，可以查看：[LLVM 插件](https://github.com/FantasticLBP/knowledge-kit/blob/master/Chapter1%20-%20iOS/1.102.md) 这篇文章。
-
-
-
-### 方案 4：轻量级熔断 / 降级（适合核心业务场景）
-
-对于 “万分之一” 但影响大的异常（如支付金额计算、商品价格），采用「熔断策略」：
-第一次出现异常：上报 + 降级为默认值（如价格显示 “--”）；
-短时间内多次出现（如 1 分钟内 > 3 次）：触发熔断，建议：展示兜底 UI，提示安抚用户，稍等片刻后尝试（起码不会发生稳定的 crash 或者业务异常）
-熔断状态上报 APM，研发收到告警后优先修复。
-
-### 方案 5：语义化默认值 + 业务无感知适配（美团 / 饿了么实践）
-
-返回**业务可识别的语义化空值**，并在 UI 层做统一适配：
-
-| 异常场景 | 兜底值 | UI 层统一处理 | 业务层感知 |
-| ---------------- | -------- | --------------- | ---------- |
-| 数组越界 | NSNull | 显示 “--” | 无 |
-| 字典 key 为 nil | NSNull | 显示 “暂无数据” | 无 |
-| 分母为 0 | INFINITY | 显示 “计算异常” | 无 |
-| 字符串转数字失败 | NSNull | 显示 “--” | 无 |
-
-**实现方式**：
-
-- 封装全局 UI 工具类（如`WXUILabel+Safe.h`），重写`setText:`方法：
-
-```objective-c
-- (void) safe_setText:(id)text {
- if (text == [NSNull null] || text == nil) {
- self.text = @"--";
- } else if ([text isKindOfClass:[NSNumber class]] && isinf([text doubleValue])) {
- self.text = @"计算异常";
- } else {
- self.text = [text description];
- }
-}
-```
-
-业务层只需使用`safe_setText:`，无需为每个异常场景写判断逻辑。
-
-
-
-## 四、最佳实践
-
-1. **开发环境零容忍**：通过静态分析、自定义 LLVM 插件 + 运行时 Hook，让问题在测试阶段暴露，比如异常发生时，通过日志打印案发现场数据，或者在 Xcode 面板上可视化的在有问题的代码地方显示 error，及时 crash 掉，阻塞正常流程，以防止开发偷懒不去及时修复，产生技术债，同时也防止问题逃逸到线上。
-2. **生产环境软兜底**：不要一刀切，做到可配置。业务方在配置平台可以针对不同业务域的配置，决定是否开启兜底展示（某些业务域的架构师可能更严格，需要开发在 debug 阶段解决这些问题，线上如果出现就统计为 crash）。如果开启，那么安全气垫就返回语义化默认值（而非无意义的 0），全局 UI 统一处理，业务层零侵入；
-3. **可观测驱动修复**：APM 平台统计异常频率 / 影响度，优先处理高频高影响的异常；
-4. **核心场景按需关注**：仅对价格、支付等核心场景注册回调，非核心场景无需处理。
-
-虽然机制和策略已经制定了，但是执行还是靠人，难以保证100%解决问题。所以开发解决通过 lint 和 crash 可以拦截到大部分问题，但是逃逸到线上的部分问题，还是需要安全气垫去 cover，线下无限毕竟去清空问题 + 少数逃逸到线上的问题通过安全气垫去 cover 就可以保证相对全面的安全守护。
-
-
-
-## 五、平台做些什么
-
-获取到 问题数据是第一步，获取之后问题需要及时上报，需要有一个数据上报系统，数据及时准确、高效的上传到服务端（这就是另一个命题，可以查看这篇文章：[打造一个通用、可配置、多句柄的数据上报 SDK](https://github.com/FantasticLBP/knowledge-kit/blob/master/Chapter1%20-%20iOS/1.80.md)），到 APM 后台。后台产生工单，根据业务模块分配到对应的责任人、群组。根据问题的紧急程度，报警策略和提醒频次也不一样，比如**波动报警、自定义报警策略等（这也是另一个命题：智能报警策略、波动报警策略、业务线自定义可配置责任人等）**。责任人及时解决问题、修改工单状态、热修复或者发布新版本，问题闭环。
-
-线上异常上报后，APM 平台需提供：
-
-- 异常频率（如 “数组越界” 仅 1/10000）；
-- 影响用户数（如仅影响 10 个用户）；
-- 业务上下文（如 “商品详情页 - 价格数组”）；
-- 调用栈 + 设备信息。
-
-**核心逻辑**：
-
-- 低频率、低影响的异常（如 1/10000，影响 10 用户）：暂时无需业务层处理，研发排期修复即可；
-- 高频率、高影响的异常（如 1/100，影响 1000 用户）：触发告警，研发紧急修复，业务层临时加兜底。
-
-这样业务开发无需为 “万分之一” 的异常写逻辑，仅需处理 “高频高影响” 的异常。
-
-
-
-## 总结
-
-“最佳实践”部分选择的方案既避免了 “安全气垫返回错误值导致业务异常”，又解决了 “业务开发为低概率异常写冗余逻辑” 的问题，是网易、腾讯、阿里等大厂的通用实践 ——**优雅的方案不是 “兜底所有异常”，而是 “让异常可被提前发现、可被观测、最小化影响”**，即使少数逃逸到线上的，再由安全气垫去兜底解决（解决了展示问题、异常上报和案发现场还原问题），一个好的 APM 平台不光是告诉你又问题，还会告诉你哪里有问题。
-
diff --git a/Chapter1 - iOS/1.15.md b/Chapter1 - iOS/1.15.md
deleted file mode 100644
index 9efffd5..0000000
--- a/Chapter1 - iOS/1.15.md
+++ /dev/null
@@ -1,54 +0,0 @@
-
-# URL Schemes 的发展
-
-
-
-URL Schemes 的发展过程可以说就是 iOS 效率工具类 App 的发展过程。
-
-起初的苹果建立的 Apple URL Schemes 只是用于自用，里面只有邮件、电话、iTunes 搜索、Youtube 视频等一些内置服务的 URL。
-
-个人认为 URL Schemes 第一次大火是在 2011 年末（如有异议欢迎指正），那个时期也是越狱的鼎盛时期，那个时期越狱后大家都会装的一个插件是 SBSettings[1]。越狱的人都知道每当新系统发布的时候，等待新系统的越狱发布是最撩人的，而这段时期那些「不越狱就能做到某种越狱功能」的应用经常一时间风头无两。
-
-2011年 iOS 5 发布带来了通知中心，没过多久，出现了一大批使用 iOS 系统设置的 URL Schemes 的 App 神奇地完成了接近 SBSettings 的功能——它们可以让我们从通知中心直接跳转到某些 App 的特定界面，比如 Twitter 的发推界面。它们甚至还可以直接跳转到系统设置里的 Wi-Fi 选项。在这一批 App 中，就有如今效率软件霸主之一 Launch Center Pro 的前身——Launch Center。
-
-
-
-## 基本 URL Schemes
-
-基本 URL Schemes 的能力虽然简单有限，但使用情境却是最普遍的。
-
-我所谓的基本 URL Schemes，是指一个 URL 的 Schemes 部分，比如上文提到的微信的 weixin:。这个部分的唯一功能，就是打开相应应用，而不能够跳转到任何功能。
-
-绝大多数所谓支持 URL Schemes 的应用，一般都是只有这么一个部分，它一般是这个应用的名称，比如 OmniFocus 这款应用，它的基本 URL Schemes 就是 Omnifocus:。如果应用的主名称是个中文名的话，它的 URL Schemes 也许会是应用名的拼音，比如 墨客 这款应用，它的基本 URL Schemes 是 moke:。
-
-但，我前面提过了网页 URL 和 iOS 应用的 URL 的三个重要区别，其中第三项，就是 iOS 上的 URL Schemes 并不规范，一个应用的 URL 可以是各种各样的：
-
diff --git a/Chapter1 - iOS/1.17.md b/Chapter1 - iOS/1.17.md
deleted file mode 100644
index aec3fd6..0000000
--- a/Chapter1 - iOS/1.17.md
+++ /dev/null
@@ -1,10 +0,0 @@
-# 对于不可调节高度的UI控件进行改变frame
-
-* 对于不能调节高度的控件比如 UISlider、UISwitch、UIProgressView 等控件的宽高可以用 \(仿射变化\)transform 属性控制高度。
-
-```
-myswitch.transform = CGAffineTransformMakeScale(1,5);
-```
-
-
-
diff --git a/Chapter1 - iOS/1.18.md b/Chapter1 - iOS/1.18.md
deleted file mode 100644
index ab99ba4..0000000
--- a/Chapter1 - iOS/1.18.md
+++ /dev/null
@@ -1,193 +0,0 @@
-# 简单的 Model 与 JSON 相互转换
-
-```
-// JSON:
-{
-"uid":123456,
-"name":"Harry",
-"created":"1965-07-31T00:00:00+0000"
-}
-
-// Model:
-@interface User : NSObject
-@property UInt64 uid;
-@property NSString *name;
-@property NSDate *created;
-@end
-@implementation User
-@end
-
-// 将 JSON (NSData,NSString,NSDictionary) 转换为 Model:
-User *user = [User yy_modelWithJSON:json];
-// 将 Model 转换为 JSON 对象:
-NSDictionary *json = [user yy_modelToJSONObject];
-
-```
-
-
-### Model 属性名和 JSON 中的 Key 不相同
-
-```
-// JSON:
-{
- "n":"Harry Pottery",
- "p": 256,
- "ext" : {
- "desc" : "A book written by J.K.Rowing."
- },
- "ID" : 100010
-}
-
-// Model:
-@interface Book : NSObject
-@property NSString *name;
-@property NSInteger page;
-@property NSString *desc;
-@property NSString *bookID;
-@end
-@implementation Book
-//返回一个 Dict，将 Model 属性名对映射到 JSON 的 Key。
-+ (NSDictionary *)modelCustomPropertyMapper {
- return @{@"name" : @"n",
- @"page" : @"p",
- @"desc" : @"ext.desc",
- @"bookID" : @[@"id",@"ID",@"book_id"]};
-}
-@end
-```
-
-你可以把一个或一组 json key (key path) 映射到一个或多个属性。如果一个属性没有映射关系，那默认会使用相同属性名作为映射。
-
-在 json->model 的过程中：如果一个属性对应了多个 json key，那么转换过程会按顺序查找，并使用第一个不为空的值。
-
-在 model->json 的过程中：如果一个属性对应了多个 json key (key path)，那么转换过程仅会处理第一个 json key (key path)；如果多个属性对应了同一个 json key，则转换过过程会使用其中任意一个不为空的值。
-
-
-### Model 包含其他 Model
-```
-// JSON
-{
- "author":{
- "name":"J.K.Rowling",
- "birthday":"1965-07-31T00:00:00+0000"
- },
- "name":"Harry Potter",
- "pages":256
-}
-
-// Model: 什么都不用做，转换会自动完成
-@interface Author : NSObject
-@property NSString *name;
-@property NSDate *birthday;
-@end
-@implementation Author
-@end
-
-@interface Book : NSObject
-@property NSString *name;
-@property NSUInteger pages;
-@property Author *author; //Book 包含 Author 属性
-@end
-@implementation Book
-@end
-```
-
-
-### 容器类属性
-```
-@class Shadow, Border, Attachment;
-
-@interface Attributes
-@property NSString *name;
-@property NSArray *shadows; //Array
-@property NSSet *borders; //Set
-@property NSMutableDictionary *attachments; //Dict
-@end
-
-@implementation Attributes
-// 返回容器类中的所需要存放的数据类型 (以 Class 或 Class Name 的形式)。
-+ (NSDictionary *)modelContainerPropertyGenericClass {
- return @{@"shadows" : [Shadow class],
- @"borders" : Border.class,
- @"attachments" : @"Attachment" };
-}
-@end
-
-```
-
-### 黑名单与白名单
-```
-@interface User
-@property NSString *name;
-@property NSUInteger age;
-@end
-
-@implementation Attributes
-// 如果实现了该方法，则处理过程中会忽略该列表内的所有属性
-+ (NSArray *)modelPropertyBlacklist {
- return @[@"test1", @"test2"];
-}
-// 如果实现了该方法，则处理过程中不会处理该列表外的属性。
-+ (NSArray *)modelPropertyWhitelist {
- return @[@"name"];
-}
-@end
-```
-
-
-### 数据校验与自定义转换
-
-```
-// JSON:
-{
- "name":"Harry",
- "timestamp" : 1445534567
-}
-
-// Model:
-@interface User
-@property NSString *name;
-@property NSDate *createdAt;
-@end
-
-@implementation User
-// 当 JSON 转为 Model 完成后，该方法会被调用。
-// 你可以在这里对数据进行校验，如果校验不通过，可以返回 NO，则该 Model 会被忽略。
-// 你也可以在这里做一些自动转换不能完成的工作。
-- (BOOL)modelCustomTransformFromDictionary:(NSDictionary *)dic {
- NSNumber *timestamp = dic[@"timestamp"];
- if (![timestamp isKindOfClass:[NSNumber class]]) return NO;
- _createdAt = [NSDate dateWithTimeIntervalSince1970:timestamp.floatValue];
- return YES;
-}
-
-// 当 Model 转为 JSON 完成后，该方法会被调用。
-// 你可以在这里对数据进行校验，如果校验不通过，可以返回 NO，则该 Model 会被忽略。
-// 你也可以在这里做一些自动转换不能完成的工作。
-- (BOOL)modelCustomTransformToDictionary:(NSMutableDictionary *)dic {
- if (!_createdAt) return NO;
- dic[@"timestamp"] = @(n.timeIntervalSince1970);
- return YES;
-}
-@end
-```
-
-### Coding/Copying/hash/equal/description
-
-```
-@interface YYShadow :NSObject
-@property (nonatomic, copy) NSString *name;
-@property (nonatomic, assign) CGSize size;
-@end
-
-@implementation YYShadow
-// 直接添加以下代码即可自动完成
-- (void)encodeWithCoder:(NSCoder *)aCoder { [self yy_modelEncodeWithCoder:aCoder]; }
-- (id)initWithCoder:(NSCoder *)aDecoder { self = [super init]; return [self yy_modelInitWithCoder:aDecoder]; }
-- (id)copyWithZone:(NSZone *)zone { return [self yy_modelCopy]; }
-- (NSUInteger)hash { return [self yy_modelHash]; }
-- (BOOL)isEqual:(id)object { return [self yy_modelIsEqual:object]; }
-- (NSString *)description { return [self yy_modelDescription]; }
-@end
-
-```
\ No newline at end of file
diff --git a/Chapter1 - iOS/1.19.md b/Chapter1 - iOS/1.19.md
deleted file mode 100644
index 5698b69..0000000
--- a/Chapter1 - iOS/1.19.md
+++ /dev/null
@@ -1,56 +0,0 @@
-# 实现波浪动画
-
-波浪的形状绘制在 CAShapeLayer 上。通过 CADisplayLink 与屏幕刷新频率同步，每次刷新都绘制新的波浪，并改变小船的位置和角度。另外，水和天空的颜色是渐变的，由 CAGradientLayer 实现，其中，显示水的 CAGradientLayer 需要有波浪形状的 CAShapeLayer 的遮罩\(mask\)。
-
-### CAShapeLayer
-
-CAShapeLayer 的属性 path \(CGPath\)就是图层要显示的形状。把波浪的形状绘制出来，赋值给此属性即可。
-
-### CADisplayLink
-
-创建 CADisplayLink，相应的 target 实现屏幕刷新时要调用的方法。把 CADisplayLink 加入 RunLoop 中。通过 isPaused 属性控制 CADisplayLink 是否暂停\(target 是否调用方法\)
-
-```
-private var waveLink: CADisplayLink?waveLink = CADisplayLink(target: self, selector: #selector(waveLinkRefresh))
-waveLink?.isPaused = true
-waveLink?.add(to: .current, forMode: .defaultRunLoopMode)
-```
-
-
-
-### 绘制波浪
-
-波浪的形状关键是正弦函数曲线
-
-```
-y = A*sin(x+B)
-```
-
-参数 A 决定了波浪的高度；参数 B 决定了波浪在 x 轴的位置。
-
-用一个属性 currentPhase 表示参数 B。每次屏幕刷新的时候用 currentPhase 绘制，然后更新此属性，加上一个固定的数。这样波浪就会朝左或右匀速移动。
-
-为了使波浪高度逐渐变化，用一个属性表示参数 A，然后每次绘制后更新此属性，加上一个固定的数，直到波浪高度达到目标值。
-
-### 小船的位置和旋转角度
-
-已知小船 x 轴坐标，通过正弦函数可以直接计算出小船的 y 轴坐标。此外，小船需要随着波浪旋转，旋转至船底与波浪表面相切。这就要对正弦函数进行求导
-
-```
-y' = A * cos(x + B)
-```
-
-用以上式子计算出小船所在位置的 y'，表示正弦函数在此处的切线斜率，几何意义是切线与 x 轴的夹角的正切值。反正切即可求出切线与 x 轴的夹角，也就是小船需要旋转的角度
-
-```
-angle = atan(y')
-```
-
-用以上旋转角度，改变小船视图\(UIView\)的 transform，调用 CGAffineTransformRotate 方法，实现小船的旋转。
-
-### CAGradientLayer
-
-CAGradientLayer 默认的颜色渐变方向是由上至下。给 colors 属性赋值一个包含 CGColor 的数组，则图层颜色由上至下，从数组第一个值经中间值渐变至最后一个值。
-
-显示水的 CAGradientLayer 需要呈现波浪形状，需要 CAShapeLayer 的遮罩。把绘制好波浪形状的 CAShapeLayer 赋值给 CAGradientLayer 的 mask 属性即可。
-
diff --git a/Chapter1 - iOS/1.2.md b/Chapter1 - iOS/1.2.md
deleted file mode 100644
index cd9e177..0000000
--- a/Chapter1 - iOS/1.2.md
+++ /dev/null
@@ -1,172 +0,0 @@
-# 看透构造方法
-
-## 构造方法
-
-* new 方法的内部就是先调用 alloc 方法，再调用 init 方法
- * alloc 方法：那个类接受 alloc 消息，那么该方法返回该接受类的对象，并把对象返回
- * init 方法：是1个对象方法，作用：初始化对象
-* 创建对象的步骤：先使用 alloc 创建1个对象，再使用 init 初始化这个对象，才可以使用这个对象
- * 使用1个未被初始化的对象是很危险的
-* init 方法：作用：初始化对象，为对象赋初始值，叫做构造方法
-
-## 重写init构造方法
-* 如果想创建出来的对象的属性值不是默认的初始化值，则需要重写 init 方法
-* 重写 init 方法的规范：
- * 必须要先调用父类的 init 方法（因为当前类初始化就是通过\`\[父类init\]\`去初始化），然后将返回值赋值给self
- * 调用 init 方法有可能会失败，如果失败直接返回nil
- * 判断父类是否初始化成功。如果 `self != nil`，则代表初始化成功
- * 如果初始化成功就去初始化当前对象的属性
- * 最后返回 self
-
-#### 解惑：
-
-1. 为什么要调用父类的 init 方法？
- 1. 当前类有 isa 指针，当前类的 isa 指针赋值是通过父类的 init 方法赋值的。
- 2. 需要保证当前对象的父类属性同时被初始化
-2. 重写 init 方法的规范：
-
-```
--(instancetype)init{
- if (self = [super init]) {
- //todo：自定义属性的初始化
- }
- return self;
-}
-```
-
-```
-//Person
-
-#import
-
-@interface Person : NSObject
-@property NSString* name;
-@property int age;
-
--(void)sayHi;
-
-@end
-
-#import "Person.h"
-@implementation Person
-
--(void)sayHi{
- NSLog(@"Hi");
-}
-
--(instancetype)init{
- self = [super init];
- if (self) {
- self.name = @"杭城小刘";
- self.age = 22;
- }
- return self;
-}
-@end
-
-
-//测试
-
- Person *p1 = [[Person alloc] init]; //p1.name = "杭城小刘"，p1.age =22;
- Person *p2 = [Person new]; //p2.name = "杭城小刘"，p2.age =22;
-```
-
-如果2个类的关系为组合关系，且它的一个属性是另一个类的对象，那么当该类初始化的时候默认它的属性为 nil，那么如何初始化？
-
-```
--(instancetype)init{
- self = [super init];
- if (self) {
- self.name = @"lbp";
- self.age = 22;
- self.pig = [[Pig alloc] init];
- }
- return self;
-}
-
-//测试
- Person *p1 = [[Person alloc] init]; //p1.dog != nil
-```
-
-## 自定义构造方法
-
-* 现状：虽然每次双肩的对象的属性值不是默认的，但是每次初始化的对象的值都是一样的。
-
-* 需求：每次实例化的对象的属性值由调用者决定
-
-* 解决办法：自定义构造方法
-
-* 自定义构造方法规范：
-
- * 自定义构造方法的返回值为 instancetype
-
- * 方法的命名必须以 initWith 开头
-
- * 方法的实现类似 init 的实现
-
-**注意：此时不能使用 new 来调用。（因为 new 的实现是先 alloc 再 init ，默认 init 的实现是给属性赋默认值）**
-
-```
--(instancetype)initWithName:(NSString *)name andAge:(int)age{
- if (self = [super init]) {
- self.name = name;
- self.age = age;
- }
- return self;
-}
-```
-
-```
-//Person
-#import
-@interface Person : NSObject
-@property NSString* name;
-@property int age;
-
--(instancetype)initWithName:(NSString *)name andAge:(int)age;
-@end
-
-#import "Person.h"
-@implementation Person
-
--(instancetype)init{
- self = [super init];
- if (self) {
- self.name = @"lbp";
- self.age = 22;
- }
- return self;
-}
-
-//不能在构造方法之外给self赋值
-//编译器认为只有以initWith开头的方法是构造方法
-
--(instancetype)initWithName:(NSString *)name andAge:(int)age{
- if (self = [super init]) {
- self.name = name;
- self.age = age;
- }
- return self;
-}
-
-@end
-
-
-//测试
-Person *p1 = [[Person alloc] init];
-Person *p2 = [Person new];
-Person *p3 = [[Person alloc] initWithName:@"杭城小刘2号" andAge:23];
-```
-
-
-
-
-
-
-关于“自定义构造方法必须以 initWith 开头”做个实验
-
-
-
-报错信息很明显：不能在构造方法之外给 self 赋值
-
-因为，编译器认为只有以 initWith 开头的方法是构造方法
diff --git a/Chapter1 - iOS/1.20.md b/Chapter1 - iOS/1.20.md
deleted file mode 100644
index cbf322a..0000000
--- a/Chapter1 - iOS/1.20.md
+++ /dev/null
@@ -1,88 +0,0 @@
-# Block探究
-
-
-### 1、Block作为函数参数可以应用到函数式编程
-```
-self.prepare.play(@"女人");
-- (ViewController *(^)(NSString *))play{
- NSLog(@"即将吃喝玩乐");
- ViewController *(^block)(NSString *) = ^ViewController *(NSString *fun){
- NSLog(@"接下来玩%@，好不好？",fun);
- return self;
- };
- return block;
-}
-
-- (ViewController *)prepare{
- NSLog(@"我们先好好休息一下。😂\n");
- return self;
-}
-
-
-
-```
-
-
-###2、Block作为函数的返回值可以作为链式编程
-
-
-```
-[self blockAsFunctionalProgramming];
-
-- (void)blockAsFunctionalProgramming{
- [self reprepare:^{
- NSLog(@"接下来玩女人，好不好？😊");
- }];
-}
-
-- (void)reprepare:(void(^)(void))replay{
- NSLog(@"我们先好好休息一下。😂\n");
- replay();
-}
-@end
-```
-
-###3、Block 访问、修改外部变量
-
-* 打开 Terminal.app，编写一段c代码
-
-```
-#include "stdio.h"
-
-int main(){
-
- printf("Coming\n");
- __block int a = 10;
-
- printf("开始->%p %d\n",&a,a);
-
- void(^block)(int a) = ^void(int a){
- a += 10;
- printf("中间->%p %d\n",&a,a);
- };
- block(a);
- printf("结束->%p %d\n",&a,a);
-
- return 0;
-}
-
-```
-
-* 之后用 **gcc** 编译一下。在同层目录下得到一个 **a.out** 的可执行文件。
-
-```
-gcc index.c
-
-```
-
-* 之后用 **clang** 编译成 C++ 文件，可以看到系统底层是如何处理 block 外部的变量、以及如何在 block 里面处理变量的。
-
-```
-clang -rewrite-objc index.c
-```
-
-
-
-###4、Block 经常造成循环引用
-* 如果 block 作为函数参数的话，且这个函数是在对象的层级，那么可能会造成循环应用。 self -> func -> block -> self.
-此时需要在 block 里面访问 self 的时候将 self 修饰为 __weak
\ No newline at end of file
diff --git a/Chapter1 - iOS/1.21.md b/Chapter1 - iOS/1.21.md
deleted file mode 100644
index 2ef9a43..0000000
--- a/Chapter1 - iOS/1.21.md
+++ /dev/null
@@ -1,80 +0,0 @@
-# 禅与 Objective-C 编程艺术
-
-## 警告和错误
-
-* 警告
-```
-#warning Dude, don't compare floating point numbers like this!
-```
-
-* 错误
-```
-#warning Dude, don't compare floating point numbers like this!
-```
-
-* 让编译器忽略忽略你这段代码的警告
-
- 大多数 iOS 开发者平时并没有和很多编译器选项打交道。一些选项是对控制严格检查（或者不检查）你的代码或者错误的。有时候，你想要用 pragma 直接产生一个异常，临时打断编译器的行为。
-
- 当你使用ARC的时候，编译器帮你插入了内存管理相关的调用。但是这样可能产生一些烦人的事情。比如你使用 NSSelectorFromString 来动态地产生一个 selector 调用的时候，ARC不知道这个方法是哪个并且不知道应该用那种内存管理方法，你会被提示 performSelector may cause a leak because its selector is unknown（执行 selector 可能导致泄漏，因为这个 selector 是未知的）.
-
- 如果你知道你的代码不会导致内存泄露，你可以通过加入这些代码忽略这些警告
-
-```
-#pragma clang diagnostic push
-#pragma clang diagnostic ignored "-Warc-performSelector-leaks"
-
-[myObj performSelector:mySelector withObject:name];
-
-#pragma clang diagnostic pop
-```
-
-
-* 忽略没用使用变量的编译警告
-
-```
-#pragma used(foo)
-```
-
-```
-- (NSInteger)giveMeFive
-{
- NSString *foo;
- #pragma unused (foo)
- return 5;
-}
-```
-
-
-* 善用代码块
-
-一个 GCC 非常模糊的特性、以及 Clang 也有的特性：代码块如果在闭合的括号内，会返回最后语句的值。
-
-```
-self. = ({
- NSString *urlString = [NSString stringWithFormat:@"%@/%@", baseURLString, endpoint];
- [NSURL URLWithString:urlString];
-});
-```
-
-这个特性非常适合组织小块的代码，给代码阅读者一个重要的入口且减小相关干扰，能让读者聚焦于关键的变量和函数中，此外这个方法有个优点：变量在代码块的区域内有效，可以减小对其他作用域的命名污染。
-
-
-* 方法参数断言
-
-你的方法可能需要一些参数来满足特定的条件（比如不能为 nil），在这种情况下最好使用 **NSParameterAssert()** 来断言条件是否成立
-
-括号内的条件为 false 的时候则断言抛出异常
-
-```
-NSParameterAssert(message.length > 0);
-```
-
-```
-[self testAssert:nil]; //*** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Invalid parameter not satisfying: message.length > 0'
-- (void)testAssert:(NSString *)message{
- NSParameterAssert(!(message.length < 1));
- NSLog(@"%@",message);
-}
-
-```
diff --git a/Chapter1 - iOS/1.22.md b/Chapter1 - iOS/1.22.md
deleted file mode 100644
index 67fdfb7..0000000
--- a/Chapter1 - iOS/1.22.md
+++ /dev/null
@@ -1,35 +0,0 @@
-# 修改 UITextField 的 placeholder样式
-
-> 对于 UITextField 的 placeholder 私有属性来说 Apple 不允许我们直接修改，但是按照经验我们有2种方式可以实现自定义 placeholder 的样式
-
-
-### 1、利用 KVC 对 UITextField 的私有属性修改
-
-```
-
- [self.invitecodeTextfield setValue:[UIColor redColor] forKeyPath:@"_placeholderLabel.textColor"];
- [self.invitecodeTextfield setValue:[UIFont systemFontOfSize:35] forKeyPath:@"_placeholderLabel.font"];
-
-```
-
-
-### 2、利用 Apple 提供的 API 进行修改
-
-UITextField 有个属性 attributedPlaceholder，利用它我们可以修改 placeholder 的样式
-
-
-```
-
-self.invitecodeTextfield.attributedPlaceholder = [LBPHightedAttributedString setAllText:@"我要Testing" andSpcifiStr:@"Testing" withColor:[UIColor redColor] specifiStrFont:[UIFont systemFontOfSize:17]];
-
-```
-
-
-其中 **LBPHightedAttributedString** 是我封装的一个关于 NSMutableAttributedString 的工具，可以对一个指定的字符串内部的字符串进行全局查找并高亮设置的小工具，具体可以查看地址
-
-
-[LBPHightedAttributedString](https://github.com/FantasticLBP/BlogDemos/tree/master/LBPAttributedStringTools/LBPHightedAttributedString "LBPHightedAttributedString")
-
-
-
-
diff --git a/Chapter1 - iOS/1.23.md b/Chapter1 - iOS/1.23.md
deleted file mode 100644
index c9123e4..0000000
--- a/Chapter1 - iOS/1.23.md
+++ /dev/null
@@ -1,27 +0,0 @@
-# UIScrollView 拖拽滑动时收起键盘
-
-
-> 当一个页面的 UIScrollView/UITableView 上有输入框时，为了较好的体验，就是当滑动的时候需要回收键盘
-
-* 最开始的做法是设置 UIScrollView 的代理位当前控制器，监听 scrollViewWillBeginDragging 方法，找到 keyWindow 并且 endEditing
-
-
-```
-- (void)scrollViewWillBeginDragging:(UIScrollView *)scrollView{
- [[UIApplication sharedApplication].keyWindow endEditing:YES];
-}
-```
-
-* 之后偶然有幸看到一个 UIScrollView 的属性"keyboardDismissModel"。实现上述需求只需要一行代码
-
-```
-self.tableView.keyboardDismissMode = UIScrollViewKeyboardDismissModeOnDrag;
-```
-
-* keyboardDismissMode 有3个枚举值
-
- * UIScrollViewKeyboardDismissModeNone：默认值，也就是拖拽时对于键盘没有任何影响。
-
- * UIScrollViewKeyboardDismissModeOnDrag：（dismisses the keyboard when a drag begins）当刚拖拽的时候就会回收键盘
-
- * UIScrollViewKeyboardDismissModeInteractive：（the keyboard follows the dragging touch off screen, and may be pulled upward again to cancel the dismiss）当向下滑动的时候键盘会跟随手势一起下滑，当向上滑动的时候键盘也会跟随手势向上滑动而出现。
\ No newline at end of file
diff --git a/Chapter1 - iOS/1.24.md b/Chapter1 - iOS/1.24.md
deleted file mode 100644
index a7d6250..0000000
--- a/Chapter1 - iOS/1.24.md
+++ /dev/null
@@ -1,86 +0,0 @@
-# NSRange 设计之美
-
-
-
-> typedef struct _NSRange {
- NSUInteger location;
- NSUInteger length;
-} NSRange;
-
-1、看到官方文档的源代码就知道 NSRange 是个结构体，但是如果是你设计一个这样的数据类型你会怎么办？？
-
-设计成结构体，然后有些属性怎么办？比如为了开发者方便，让你设计出一个办法，让开发者可以很快知道这个结构体的上限是什么？
-
-苹果就很机智，设计了一个内联函数
-
- ```
- NS_INLINE NSUInteger NSMaxRange(NSRange range) {
- return (range.location + range.length);
-}
- ```
-
- 2、什么是内联函数？
-
- ```
-NS_INLINE 返回值类型 函数名(参数列表) {
- //函数实现
- //return ;
-}
- ```
-
-3、内联函数的应用
-
-比如自定义一个弹窗
-
-```
-NS_INLINE void tipWithMessage(NSString *message){
-
- dispatch_async(dispatch_get_main_queue(), ^{
-
- UIAlertView *alerView = [[UIAlertView alloc] initWithTitle:@"提示" message:message delegate:nil cancelButtonTitle:nil otherButtonTitles:nil, nil];
-
- [alerView show];
-
- [alerView performSelector:@selector(dismissWithClickedButtonIndex:animated:) withObject:@[@0, @1] afterDelay:0.9];
-
- });
-
-}
-
-```
-
-
-4、内联函数的注意事项
-
-内联函数是以代码膨胀为代价， 仅仅省去了函数调用的开销，从而提高函数的执行效率。如果执行函数内代码的时间相比于函数调用的开销大，那么效率收获会很小。
-此外每一处调用内联函数的地方都会复制一遍代码，所以会使得程序的体积变大，消耗更多的代码段区域。
-所以下面的情况不适合使用内联函数：
-
- * 如果函数体内的代码比较长，使用内联将导致内存消耗比较大
- * 如果函数体内出现循环，那么执行函数体内代码的时间要比函数的调用开销大
-
-
-5、FOUNDATION_EXPORT
-
-查看 NSRange 的代码还会发现一个关键词 **FOUNDATION_EXPORT**，它可以用作定义常量。
-
-
-FOUNDATION_EXPORT 和 #define 都可用来定义常量。
-用法
-
-```
-//.h
-FOUNDATION_EXPORT NSString *const NickName;
-
-//.m
-NSString *const NickName = @"杭城小刘";
-```
-
-那么它和 **#define** 有何区别？
-
-FOUNDATION_EXPORT 在检测字符串的值是否相等的时候效率更高
-使用** NickName == MyName** 来判断，而 #define 是用 **[NickName isEqualToString:MyName]** 来判断。
-
-
- * 本质上 FOUNDATION_EXPORT 是比较指针的自己
- * \#define 是比较每个字符串是否相等
\ No newline at end of file
diff --git a/Chapter1 - iOS/1.25.md b/Chapter1 - iOS/1.25.md
deleted file mode 100644
index 2e23e02..0000000
--- a/Chapter1 - iOS/1.25.md
+++ /dev/null
@@ -1,210 +0,0 @@
-# 复制层（CAReplicatorLayer）
-
-> 对于下面的效果大家是否有实现思路？
->
-> 有些人可能要说：老夫撸起袖子，敲键盘就是干，不需要手势交互，那么直接用5个**CALayer**，处理不同的位置以及定时器、透明度等等，貌似很简单。
->
-> 不不不，今天要带出来的主题是 **CAReplicatorLayer**
-
-
-
-
-
-
-
-
-## 1、CAReplicatorLayer
-
-> /* The replicator layer creates a specified number of copies of its
->
-> - sublayers, each copy potentially having geometric, temporal and
-> - color transformations applied to it.
->
-> *
->
-> - Note: the CALayer -hitTest: method currently only tests the first
-> - instance of z replicator layer's sublayers. This may change in the
-> - future. */
-
-官方给出的意思就不翻译了，使用场景大致是一个形状、特性差不多的 layer，我们不需要重复创建，可以利用它来实现复制多个 layer ，然后通过 CAReplicatorLayer 的一些属性实现我们的需求。
-
-
-
-上述效果的代码
-
-```objective-c
-//创建复制层，因为我们做的多个音量柱变化的动画都是一样的，所以创建了一个复制层，这个复制层可以对里面的 sublayer 进行复制，所以我们不需要重复创建了
-
- CAReplicatorLayer *replicatorrLayer = [CAReplicatorLayer layer];
- replicatorrLayer.frame = CGRectMake(0, 0, self.contentView.frame.size.width, self.contentView.frame.size.height);
- replicatorrLayer.backgroundColor = [UIColor blackColor].CGColor;
- self.replicatorrLayer = replicatorrLayer;
- [self.contentView.layer addSublayer:replicatorrLayer];
-
-
- //创建音量震动条
- CALayer *layer = [CALayer layer];
- layer.backgroundColor = [UIColor whiteColor].CGColor;
- CGFloat width = 30;
- CGFloat height = 100;
- layer.bounds = CGRectMake(0, self.contentView.frame.size.height - height, width, height);
- layer.anchorPoint = CGPointMake(0, 1);
- layer.position = CGPointMake(0, self.contentView.frame.size.height);
- [self.contentView.layer addSublayer:layer];
-
- //创建音量震动动画
- CABasicAnimation *animation = [CABasicAnimation animationWithKeyPath:@"transform.scale.y"];
- animation.toValue = @0;
- animation.duration = 1;
- animation.repeatCount = MAXFLOAT;
- animation.autoreverses = YES;
- [layer addAnimation:animation forKey:nil];
-
-
- [replicatorrLayer addSublayer:layer];
-
- //* The number of copies to create, including the source object.
- replicatorrLayer.instanceCount = 6; //复制 sublayer 的个数，包括创建的第一个sublayer 在内的个数
- replicatorrLayer.instanceDelay = 0.4; //设置动画延迟执行的时间
- replicatorrLayer.instanceAlphaOffset = -0.15; //设置透明度递减
- replicatorrLayer.instanceTransform = CATransform3DMakeTranslation(50, 0, 0);
-```
-[源码地址](https://github.com/FantasticLBP/BlogDemos/tree/master/复制层应用1-音量柱动画)
-
-
-
-
-## 例子1
-
-
-
-这里比较简单了，关键代码
-
-```objective-c
- CAReplicatorLayer *replicatorLayer = (CAReplicatorLayer *)self.view.layer;
- replicatorLayer.instanceCount = 2;
- replicatorLayer.instanceTransform = CATransform3DMakeRotation(M_PI, 1, 0, 0);
- replicatorLayer.instanceRedOffset -= 0.1;
- replicatorLayer.instanceGreenOffset -= 0.1;
- replicatorLayer.instanceBlueOffset -= 0.1;
- replicatorLayer.instanceAlphaOffset -= 0.3;
-```
-
-- 需要说明是这里我用 storyboard 处理的，因为已经拉好了控件，所以我们没办法将图片直接加到复制层上去。间接做法是将 UIViewController 的 view 的 layer 类型改变为 复制层
-
- ```
- //该方法返回 UIView 的层
- //改写 UIView 的层：重写 layerClass 方法
- + (Class)layerClass{
- return [CAReplicatorLayer class];
- }
- ```
- [源码地址](https://github.com/FantasticLBP/BlogDemos/tree/master/复制层应用2-倒影效果)
-
-
-## 例子2
-
-
-
-
-需求分析：
-
-- 先画图。也就是添加一个滑动手势并监听它。然后强制绘图（self setNeedsDisplay）
-
-- 添加一个 layer 到 self.layer 上
-
-- 改变当前 view 的 layer 类型。
-
- ```
- + (Class)layerClass{
- return [CAReplicatorLayer class];
- }
- ```
-
-- 设置 CAReplicatorLayer 的 instanceCount 和 instanceDelay 属性
-
-- 添加了小点，并为小点设置关键帧动画。
-
-- 重置功能实现靠的是清除 path 上面的 points ，并移除 小点上面的动画
-
-```
-#import "ViewControllerView.h"
-
-@interface ViewControllerView()
-
-@property (nonatomic, strong) UIBezierPath *path;
-@property (nonatomic, weak) CALayer *dotLayer;
-@end
-
-@implementation ViewControllerView
-
-+ (Class)layerClass{
- return [CAReplicatorLayer class];
-}
-
-- (void)awakeFromNib{
- [super awakeFromNib];
-
- UIPanGestureRecognizer *tapGesture = [[UIPanGestureRecognizer alloc] initWithTarget:self action:@selector(draw:)];
- [self addGestureRecognizer:tapGesture];
- self.path = [UIBezierPath bezierPath];
-
- CALayer *layer = [CALayer layer];
- layer.frame = CGRectMake(-UIScreen.mainScreen.bounds.size.width, 0, 15, 15);
- layer.backgroundColor = [UIColor orangeColor].CGColor;
- layer.cornerRadius = 7.5;
- self.dotLayer = layer;
- [self.layer addSublayer:layer];
-
- CAReplicatorLayer *replicatorLayer = (CAReplicatorLayer *)self.layer;
- replicatorLayer.instanceCount = 20;
- replicatorLayer.instanceDelay = 0.25;
-}
-
-
-- (void)draw:(UIPanGestureRecognizer *)tap{
- CGPoint currentPoint = [tap locationInView:self];
- if (tap.state == UIGestureRecognizerStateBegan) {
- [self.path moveToPoint:currentPoint];
- }
- else if(tap.state == UIGestureRecognizerStateChanged){
- [self.path addLineToPoint:currentPoint];
- [self setNeedsDisplay];
- }
-}
-
-- (void)startAnimation{
- //要实现动画围绕着给定的形状执行，那么需要关键帧动画(类比于Flash概念中的关键帧动画，只需要给定指定的关键帧，其余的帧系统会创建出来。)。关键帧动画的 path 和 values 是互斥的，也就是说如果设置了 values 还设置了 path 那么 path 属性会覆盖 values 属性。
-
- CAKeyframeAnimation *animation = [CAKeyframeAnimation animation];
- animation.keyPath = @"position";
- animation.path = self.path.CGPath;
- animation.duration = 5;
- animation.repeatCount = MAXFLOAT;
- [self.dotLayer addAnimation:animation forKey:nil];
-}
-
-- (void)redraw{
- //清空路径：移除 path 上面所有的点，然后重绘
- [self.path removeAllPoints];
- [self setNeedsDisplay];
- //移除动画
- [self.dotLayer removeAllAnimations];
-}
-
-- (void)drawRect:(CGRect)rect{
- [self.path stroke];
-}
-
-@end
-```
-[源码地址](https://github.com/FantasticLBP/BlogDemos/tree/master/复制层应用3-粒子闪烁效果)
-
-### CALayer 层的动画有2个概念非常重要：AnchorPoint 和 position
-
-- postion 用来确定 layer 层在父层中的位置
-
-- anchorPoint 用来确定 layer 身上哪个点会在 position 所指的位置。
-
-
-
diff --git a/Chapter1 - iOS/1.26.md b/Chapter1 - iOS/1.26.md
deleted file mode 100644
index 912fc9c..0000000
--- a/Chapter1 - iOS/1.26.md
+++ /dev/null
@@ -1,172 +0,0 @@
-# CAShapeLayer
-
-> 一言以蔽之：CAShapeLayer 可以根据贝塞尔曲线描绘出的路径而生成对应的图形
-
-
-
-## 综合例子
-
-- 效果图
-
-
-
-
-- 关键技术点剖析
-
- - 分析 QQ 粘性动画的关键点就是当手势拖动时候2个圆之间那个形状怎么绘制
-
- 答案：将2个圆的某一时刻之间形成的形状用数学抽象来计算。
-
-
-
- - 拖动到超过某个范围的时候怎么执行爆炸动画
-
- UIImageView 可以执行帧动画，类似于 Flash 效果
-
-
-
-
-
-
-
-
-
- ### 关键代码
-
- ```
- - (void)pan:(UIPanGestureRecognizer *)pan{
- //当前移动的偏移量
- CGPoint transP = [pan translationInView:self];
- //改变红点的位置
- //transform并没有修改自身的 center（center 是 layer 的position），只是修改了 frame
- NSLog(@"偏移量:%@",NSStringFromCGPoint(transP));
- CGPoint center = self.center;
- center.x += transP.x;
- center.y += transP.y;
- self.center = center;
-
- //self.transform = CGAffineTransformTranslate(self.transform, transP.x, transP.y);
- //手势复位:设置坐标原点位上次的坐标
- [pan setTranslation:CGPointZero inView:self];
-
- CGFloat distance = [self distanceWith:self.smallCircle bigCircle:self];
- NSLog(@"%f",distance);
-
-
- CGFloat smallCircleRadius = self.bounds.size.width * 0.5;
- smallCircleRadius = smallCircleRadius - distance/10;
-
- if (smallCircleRadius < 3) {
- smallCircleRadius = 3;
- }
- self.smallCircle.bounds = CGRectMake(0, 0, smallCircleRadius*2, smallCircleRadius*2);
- self.smallCircle.layer.cornerRadius = smallCircleRadius;
-
- if (self.smallCircle.hidden == NO) {
- //返回一个不规则的路径
- UIBezierPath *path = [self drawTracertWithSmallCircle:self.smallCircle bigCircle:self];
- //将形状转换为一个形状图层
- self.shapeLayer.path = path.CGPath;//根据路径生成形状
- }
- //创建形状图层
- [self.superview.layer insertSublayer:self.shapeLayer atIndex:0];
-
- if (distance > 60) {
- self.smallCircle.hidden = YES;
- [self.shapeLayer removeFromSuperlayer];
- }
-
- if (pan.state == UIGestureRecognizerStateEnded) {
- //结束手势
- if (distance < 60) {
- [self.shapeLayer removeFromSuperlayer];
- self.center = self.smallCircle.center;
- self.smallCircle.hidden = NO;
- }
- else{
- //手势拖拽超过60则播放一个动画
- UIImageView *imageView = [[UIImageView alloc] initWithFrame:self.bounds];
-
- NSMutableArray *images = [NSMutableArray array];
-
- for (int i=0; i<8; i++) {
- NSString *imageName = [NSString stringWithFormat:@"%d",i+1];
- UIImage *image = [UIImage imageNamed:imageName];
- [images addObject:image];
- }
- imageView.animationImages = images;
- [imageView setAnimationDuration:1];
- [imageView startAnimating];
- [self addSubview:imageView];
- //动画结束移除本身
- dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(1 * NSEC_PER_SEC)), dispatch_get_main_queue(), ^{
- [self removeFromSuperview];
- });
- }
- }
-
- }
-
- - (CGFloat )distanceWith:(UIView *)smallCircle bigCircle:(UIView *)bigScirle{
- CGFloat offsetX = bigScirle.frame.origin.x - smallCircle.frame.origin.x;
- CGFloat offsetY = bigScirle.frame.origin.y - smallCircle.frame.origin.y;
- return sqrt( pow(offsetX, 2) + pow(offsetY, 2));
- }
-
- //将2个圆运行的变化轨迹用代码模拟
- - (UIBezierPath *)drawTracertWithSmallCircle:(UIView *)smallCircle bigCircle:(UIView *)bigCircle{
-
- CGFloat X1 = smallCircle.center.x;
- CGFloat X2 = bigCircle.center.x;
- CGFloat Y1 = smallCircle.center.y;
- CGFloat Y2 = bigCircle.center.y;
-
- CGFloat r1 = smallCircle.bounds.size.width/2;
- CGFloat r2 = bigCircle.bounds.size.width/2;
-
- CGFloat d = [self distanceWith:smallCircle bigCircle:bigCircle];
- //Ø 代表角度
- CGFloat SinØ = (X2 - X1)/d;
- CGFloat CosØ = (Y2 - Y1)/d;
-
- CGPoint pointA = CGPointMake(X1 - r1*CosØ, Y1 + r1*SinØ);
-
- CGPoint pointB = CGPointMake(X1 + r1*CosØ, Y1 - r1*SinØ);
-
- CGPoint pointC = CGPointMake(X2 + r2*CosØ, Y2 - r2*SinØ);
-
- CGPoint pointD = CGPointMake(X2 - r2*CosØ, Y2 + r2*SinØ);
-
- CGPoint pointO = CGPointMake(X1 + SinØ *d/2, Y1 + CosØ*d/2);
-
- CGPoint pointP = CGPointMake(X1 + SinØ *d/2,Y1 + CosØ*d/2 );
-
- //描述路径
- UIBezierPath *path = [UIBezierPath bezierPath];
-
- //AB
- [path moveToPoint:pointA];
- [path addLineToPoint:pointB];
-
- //BC(曲线)
- [path addQuadCurveToPoint:pointC controlPoint:pointP];
-
- //CD
- [path addLineToPoint:pointD];
-
- //DA(曲线)
- [path addQuadCurveToPoint:pointA controlPoint:pointO];
-
- return path;
- }
- ```
-
-
-
-完整的代码，[Github地址](https://github.com/FantasticLBP/BlogDemos/tree/master/QQ粘性动画)
-
-
-
-
-
-
\ No newline at end of file
diff --git a/Chapter1 - iOS/1.27.md b/Chapter1 - iOS/1.27.md
deleted file mode 100644
index 1ab8987..0000000
--- a/Chapter1 - iOS/1.27.md
+++ /dev/null
@@ -1,65 +0,0 @@
-# 仿微博弹簧动画
-
-> 老玩微博，最近在研究动画，周末抽空写了个发微博的动画
-
-
-
-# 实现步骤
-
-- 首先模打出一个控制器
-- 这个控制器用来显示多个按钮。（按钮是图文上下排列的，所以我们需要自定义按钮的布局样式）
-- 动画思路：先在界面添加好几个 UIButton，之后给每个 button 添加**y**方向的平移动画 -> 设置一个定时器，每次执行的时候依次取出按钮，将按钮添加一个弹簧动画（**usingSpringWithDamping **）将形变动画恢复原位
-- 给按钮添加2种事件（按下的事件、点击后抬起的事件）
-
-## 关键代码
-
-```
-//开始时让所有按钮都移动到最底部
-btn.transform = CGAffineTransformMakeTranslation(0, self.view.bounds.size.height);
-
-//添加定时器
-self.timer = [NSTimer scheduledTimerWithTimeInterval:0.1 target:self selector:@selector(update) userInfo:nil repeats:YES];
-
-- (void)update{
- if (self.btnIndex == self.btnArray.count) {
- [self.timer invalidate];
- return ;
- }
-
- VerticalStyleButton *button = self.btnArray[self.btnIndex];
- //弹簧动画
- [UIView animateWithDuration:0.3 delay:0.2 usingSpringWithDamping:0.8 initialSpringVelocity:0 options:UIViewAnimationOptionCurveLinear animations:^{
- button.transform = CGAffineTransformIdentity;
- } completion:^(BOOL finished) {
-
- }];
- self.btnIndex++;
-}
-
-- (void)btnClick:(UIButton *)button{
- [UIView animateWithDuration:0.25 animations:^{
- button.transform = CGAffineTransformMakeScale(1.2, 1.2);
- }];
-}
-
-- (void)btnClick1:(UIButton *)button{
- [UIView animateWithDuration:0.25 animations:^{
- button.alpha = 0;
- button.transform = CGAffineTransformMakeScale(2, 2);
- }];
-}
-```
-
-
-
-# 效果图
-
-
-
-
-
-
-
-
-[源码地址](https://github.com/FantasticLBP/BlogDemos/tree/master/微博发帖动画)
-
diff --git a/Chapter1 - iOS/1.28.md b/Chapter1 - iOS/1.28.md
deleted file mode 100644
index 20d1d50..0000000
--- a/Chapter1 - iOS/1.28.md
+++ /dev/null
@@ -1,39 +0,0 @@
-# UILabel 给关键字模糊匹配并高亮
-
-> 有些情况就是需要查找某个字符串并高亮，但有些需求就是需要全局模糊查找，找到符合的字符串并高亮。造了个小轮子
-
-###效果图
-
-
-```
-#pragma mark -- 设置在一个文本中所有特殊字符的特殊颜色
-+ (NSMutableAttributedString *)setAllText:(NSString *)allStr andSpcifiStr:(NSString *)keyWords withColor:(UIColor *)color specifiStrFont:(UIFont *)font{
- NSMutableAttributedString *mutableAttributedStr = [[NSMutableAttributedString alloc] initWithString:allStr];
- if (color == nil) {
- color = [UIColor redColor];
- }
- if (font == nil) {
- font = [UIFont systemFontOfSize:17];
- }
-
-
- for (NSInteger j=0; j<=keyWords.length-1; j++) {
-
- NSRange searchRange = NSMakeRange(0, [allStr length]);
- NSRange range;
- NSString *singleStr = [keyWords substringWithRange:NSMakeRange(j, 1)];
- while
- ((range = [allStr rangeOfString:singleStr options:NSLiteralSearch range:searchRange]).location != NSNotFound) {
- //改变多次搜索时searchRange的位置
- searchRange = NSMakeRange(NSMaxRange(range), [allStr length] - NSMaxRange(range));
- //设置富文本
- [mutableAttributedStr addAttribute:NSForegroundColorAttributeName value:color range:range];
- [mutableAttributedStr addAttribute:NSFontAttributeName value:font range:range];
- }
- }
- return mutableAttributedStr;
-}
-```
-
-[源码地址](https://github.com/FantasticLBP/BlogDemos/tree/master/LBPAttributedStringTools)
\ No newline at end of file
diff --git a/Chapter1 - iOS/1.29.md b/Chapter1 - iOS/1.29.md
deleted file mode 100644
index 41aea00..0000000
--- a/Chapter1 - iOS/1.29.md
+++ /dev/null
@@ -1,155 +0,0 @@
-# JavascriptCore
-
-
-
-1、JSCore 是基于 webkit 以 C/C++ 实现的一个 js 包装，让 js 和 Native 交互变得更加简单。
-
-- JScontext
- JSContext 代表一个 JavaScript 的执行环境的一个实例。所有JavaScript执行都是在上下文内进行。JSContext还用于管理对象的生命周期内 JavaScript 的虚拟机
-- JSValue
- JSValue 是用来接收 JSContext 执行后的返回结果。JSValue 可以是 JS 的任意类型（变量、对象、函数...）
-- JSManagedValue
- JSManagedValue 是对 JSValue 的封装，可以解决 JS 和 OC 之间循环引用的问题。JSManagedValue 最常用的用法就是安全的从内存堆区里面引用 JSValue 对象.如果 JSValue 存储在内存的堆区的方式是不正确的,很容易造成循环引用,然后导致 JSContext 对象不能正确的释放掉.
-- JSExport
- 是一个协议，用来将 Native 对象暴露给 JS，这个对象可以指向给自身和别的对象。
-- JSVirtualMachine
- 管理 JS 对象空间和所需的资源
-
-2、Native 调用 JS
-
-- 加载 JS 代码
- (JSValue *)evaluateScript:(NSString *)script;
-
-- 调用 JS 方法
- JSvalue *callBack = self.context[@"sayHi"];
- [callback callWithArguments:@[@"杭城小刘"]];
-
-
-3、JS 调用 Native
-
-- 通过 Block 实现。然后在 JS 中直接调用方法即可。需要注意的是在 Block 内部不要直接使用外部定义的 JScontext 对象或 JSValue ，应该作为参数传递进来，或者通过 + (JSContext *)currentContext; 来获取。否则会造成循环引用、内存无法被正确回收
- self.context[@"showMessage"] = ^(NSString *message){
- UIAlertController *alertCtr = [UIAlertController alertControllerWithTitle:@"提示" message:message preferredStyle:UIAlertControllerStyleAlert];
- UIAlertAction *cancel = [UIAlertAction actionWithTitle:@"OK" style:UIAlertActionStyleCancel handler:nil];
- [alertCtr addAction:cancel];
- //注意：方法是在子线程中执行的，需要跟新UI的话，需要切入主线程。
- dispatch_async(dispatch_get_main_queue(), ^{
- [weakSealf presentViewController:alertCtr animated:YES completion:nil];
- });
- };
-- 通过 JSExport 协议实现； JS 需要通过 OC 中注入的对象来调方法，那么方法需要在协议中声明，并且在注入的对象中实现；在 webview 加载完成的时候注入实现协议的 Native 对象
- //声明协议
-
- @proptocol JSInject
- - (void)showMessage:(NSString *)message;
- @end
-
- //实现相应的协议
-
- - (void)showMessage:(NSString *)message{
- UIAlertController *alertCtr = [UIAlertController alertControllerWithTitle:@"提示" message:message preferredStyle:UIAlertControllerStyleAlert];
- UIAlertAction *cancel = [UIAlertAction actionWithTitle:@"OK" style:UIAlertActionStyleCancel handler:nil];
- [alertCtr addAction:cancel];
- //注意：方法是在子线程中执行的，需要跟新UI的话，需要切入主线程。
- dispatch_async(dispatch_get_main_queue(), ^{
- [weakSealf presentViewController:alertCtr animated:YES completion:nil];
- });
- }
-
- //注入
-
- - (void)webViewDidFinishLoad:(UIWebView *)webView
- {
- //从webview上获取相应的JSContext。
- self.context = [webView valueForKeyPath:@"documentView.webView.mainFrame.javaScriptContext"];
-
- //注入JS需要的“OC”对象
- self.context[@"Bridge"] = [JSInject new];
- }
-
-
-举个🌰
-
-JS call Native
-
- //对外要暴露的 native 对象（其中挂载了一些属性和方法）
- #import
- #import
-
- @protocol PersonInjectExport
-
- @property (nonatomic, strong) NSString *name;
-
- @property (nonatomic, strong) NSString *hobby;
-
- - (id)sayHi;
-
- @end
-
-
- @interface PersonInject : NSObject
-
- @property (nonatomic, strong) NSString *name;
-
- @property (nonatomic, strong) NSString *hobby;
-
- - (id)sayHi;
-
- @end
-
-
- // viewcontroller
-
- - (void)webViewDidFinishLoad:(UIWebView *)webView{
- self.jsContext = [webView valueForKeyPath:@"documentView.webView.mainFrame.javaScriptContext"];
- PersonInject *person = [[PersonInject alloc] init];
- person.name = @"杭城小刘";
- person.hobby = @"Coding、Movie、Music、Table tennis、Fit";
- self.jsContext[@"lbp"] = person;
- }
-
- //JS
-
-
- 嗨。大家好我是
- ITSAppUsesNonExemptEncryption
-
-@class PPSnapshotHandler;
-
-@protocol PPSnapshotHandlerDelegate
-
-@optional
-
-- (void)snapshotHandler:(PPSnapshotHandler *)snapshotHandler didFinish:(UIImage *)captureImage forView:(UIView *)view;
-
-@end
-
-@interface PPSnapshotHandler : NSObject
-
-+ (instancetype)defaultHandler;
-
-@property (nonatomic, weak) id delegate;
-
-- (void)snapshotForView:(__kindof UIView *)view;
-
-@end
-
-
-#import "PPSnapshotHandler.h"
-#import
-
-#define DELAY_TIME_DRAW 0.1
-
-@interface PPSnapshotHandler () {
- BOOL _isCapturing;
- UIView *_captureView;
-}
-@end
-
-@implementation PPSnapshotHandler
-
-+ (instancetype)defaultHandler
-{
- static dispatch_once_t onceToken;
- static PPSnapshotHandler *defaultHandler = nil;
- dispatch_once(&onceToken, ^{
- defaultHandler = [[PPSnapshotHandler alloc] init];
- });
- return defaultHandler;
-}
-
-#pragma mark - public method
-
-- (void)snapshotForView:(__kindof UIView *)view
-{
- if (!view || _isCapturing) {
- return;
- }
-
- _captureView = view;
-
- if ([view isKindOfClass:[UIScrollView class]]) {
- [self snapshotForScrollView:(UIScrollView *)view];
- } else if ([view isKindOfClass:[UIWebView class]]) {
- UIWebView *webView = (UIWebView *)view;
- [self snapshotForScrollView:webView.scrollView];
- } else if ([view isKindOfClass:[WKWebView class]]) {
- [self snapshotForWKWebView:(WKWebView *)view];
- }
-}
-
-#pragma mark - WKWebView
-
-- (void)snapshotForWKWebView:(WKWebView *)webView
-{
- UIView *snapshotView = [webView snapshotViewAfterScreenUpdates:YES];
- snapshotView.frame = webView.frame;
- [webView.superview addSubview:snapshotView];
-
- CGPoint currentOffset = webView.scrollView.contentOffset;
- CGRect currentFrame = webView.frame;
- UIView *currentSuperView = webView.superview;
- NSUInteger currentIndex = [webView.superview.subviews indexOfObject:webView];
-
- UIView *containerView = [[UIView alloc] initWithFrame:webView.bounds];
- [webView removeFromSuperview];
- [containerView addSubview:webView];
-
- CGSize totalSize = webView.scrollView.contentSize;
- NSInteger page = ceil(totalSize.height / containerView.bounds.size.height);
-
- webView.scrollView.contentOffset = CGPointZero;
- webView.frame = CGRectMake(0, 0, containerView.bounds.size.width, webView.scrollView.contentSize.height);
-
- UIGraphicsBeginImageContextWithOptions(totalSize, YES, UIScreen.mainScreen.scale);
- [self drawContentPage:containerView webView:webView index:0 maxIndex:page completion:^{
- UIImage *snapshotImage = UIGraphicsGetImageFromCurrentImageContext();
- UIGraphicsEndImageContext();
-
- [webView removeFromSuperview];
- [currentSuperView insertSubview:webView atIndex:currentIndex];
- webView.frame = currentFrame;
- webView.scrollView.contentOffset = currentOffset;
-
- [snapshotView removeFromSuperview];
-
- self->_isCapturing = NO;
-
- if (self.delegate && [self.delegate respondsToSelector:@selector(snapshotHandler:didFinish:forView:)]) {
- [self.delegate snapshotHandler:self didFinish:snapshotImage forView:self->_captureView];
- }
- }];
-}
-
-- (void)drawContentPage:(UIView *)targetView webView:(WKWebView *)webView index:(NSInteger)index maxIndex:(NSInteger)maxIndex completion:(dispatch_block_t)completion
-{
- CGRect splitFrame = CGRectMake(0, index * CGRectGetHeight(targetView.bounds), targetView.bounds.size.width, targetView.frame.size.height);
- CGRect myFrame = webView.frame;
- myFrame.origin.y = -(index * targetView.frame.size.height);
- webView.frame = myFrame;
-
- dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(DELAY_TIME_DRAW * NSEC_PER_SEC)), dispatch_get_main_queue(), ^{
- [targetView drawViewHierarchyInRect:splitFrame afterScreenUpdates:YES];
-
- if (index < maxIndex) {
- [self drawContentPage:targetView webView:webView index:index + 1 maxIndex:maxIndex completion:completion];
- } else {
- completion();
- }
- });
-}
-
-#pragma mark - UIScrollView
-
-- (void)snapshotForScrollView:(UIScrollView *)scrollView
-{
- CGPoint currentOffset = scrollView.contentOffset;
- CGRect currentFrame = scrollView.frame;
-
- scrollView.contentOffset = CGPointZero;
- scrollView.frame = CGRectMake(0, 0, scrollView.contentSize.width, scrollView.contentSize.height);
-
- UIGraphicsBeginImageContextWithOptions(scrollView.contentSize, YES, UIScreen.mainScreen.scale);
- [scrollView.layer renderInContext:UIGraphicsGetCurrentContext()];
- UIImage *snapshotImage = UIGraphicsGetImageFromCurrentImageContext();
- UIGraphicsEndImageContext();
-
- scrollView.contentOffset = currentOffset;
- scrollView.frame = currentFrame;
-
- if (self.delegate && [self.delegate respondsToSelector:@selector(snapshotHandler:didFinish:forView:)]) {
- [self.delegate snapshotHandler:self didFinish:snapshotImage forView:_captureView];
- }
-}
-
-@end
-```
-
-
-
diff --git a/Chapter1 - iOS/1.33.md b/Chapter1 - iOS/1.33.md
deleted file mode 100644
index a4140ef..0000000
--- a/Chapter1 - iOS/1.33.md
+++ /dev/null
@@ -1,28 +0,0 @@
-# 推送
-
-> 1、现在 App 开发推送功能，一般都是接入极光推送，那么为什么极光推送就可以实现推送呢？
-2、极光推送做了哪些事情？与 APNS 怎么交互的？
-带着这2个问题来看看推送吧
-
-## 一、推送原理
-
-
-（这张图转载于网络）
-
-
-
-说说推送的步骤：
-1、你的 App 需要推送服务，要向苹果的 APNS 注册推送功能
-2、当苹果 APNS 推送服务器收到你的注册请求后会返回给你一串 device token
-3、当应用收到 device token 后，需要将 device token 传给自己的应用服务器（自己公司的服务端）
-4、当你需要为你的应用推送消息的时候，自己的应用服务器会将消息，以及 device token 打包发送给苹果的 APNS。
-5、APNS 再将消息推送给你的 手机 App
-
-
-## 不接入极光推送的话，自己怎么做推送功能
-
-参考这篇文章：[自己做推送](https://blog.csdn.net/shenjie12345678/article/details/41120637)
-
-## 所以极光推送逗帮我们做了什么？
-
-简化了获取 device token 的步骤，我们将申请号的证书上传到极光服务器，程序运行接入极光 SDK ，手机获取 device token, 然后将 device token 上传给极光推送服务器，。
\ No newline at end of file
diff --git a/Chapter1 - iOS/1.34.md b/Chapter1 - iOS/1.34.md
deleted file mode 100644
index 833d5c7..0000000
--- a/Chapter1 - iOS/1.34.md
+++ /dev/null
@@ -1,55 +0,0 @@
-# App 评分
-
-> 经常有这样的需求-引导用户在合适的时机对 App 做出好评。本文就尝试谈一谈这一块的一些知识
-
-1. 评分的方式
-可以跳出应用对 App 进行评分，也可以在应用内进行评分（>= iOS 10.3）。
-
-2. 跳出 App 评分
-利用系统方法打开 URL（跳到 App store 后跳转到自己 App 的评价页面）
-```
-NSString *urlString = [NSString stringWithFormat:@"itms-apps://itunes.apple.com/app/id%@?action=write-review", @"你的App ID"];
-[[UIApplication sharedApplication] openURL:[NSURL URLWithString:urlString]];
- ```
-
-3. 应用内评分
-iOS 10.3 之后系统为我们评分这个需求引入 **StoreKit**。利用它，我们可以很方便地在应用内对 App 进行快速评分，而不用跳出去。
- + 在 App 内部打开 App store并跳转到App 评价页面
- ```
- #import
- SKStoreProductViewController *storeVC = [[SKStoreProductViewController alloc] init];
-storeVC.delegate = self;
-[storeVC loadProductWithParameters:@{SKStoreProductParameterITunesItemIdentifier:@"1401834682"} completionBlock:^(BOOL result, NSError * _Nullable error) {
- if (error) {
-
- }else{
- [self presentViewController:storeVC animated:YES completion:nil];
- }
-}];
- ```
- + 在 App 内弹出评分对话框，用户星级评分后可以继续输入文字
- ```
- if (@available(iOS 10.3, *)) {
- if([SKStoreReviewController respondsToSelector:@selector(requestReview)]){
- [SKStoreReviewController requestReview];
- else{
- NSString *urlString = [NSString stringWithFormat:@"itms-apps://itunes.apple.com/app/id%@?action=write-review", @"你的App ID"];
- [[UIApplication sharedApplication] openURL:[NSURL URLWithString:urlString]];
- }
-}else {
- // Fallback on earlier versions
- NSString *urlString = [NSString stringWithFormat:@"itms-apps://itunes.apple.com/app/id%@?action=write-review", @"你的App ID"];
- [[UIApplication sharedApplication] openURL:[NSURL URLWithString:urlString]];
-}
- ```
-
-4. 注意时机哦
- 我们的目的是能得到用户的正反馈，如果在用户刚使用APP时就弹出评分框，可能会给某些用户带来反感，因此，选择一个合适的时机弹出评分很重要，不然适得其反。
- 今天在使用爱奇艺的时候发现他们的弹出场景是这样的。我因为要出门所以下载了一部电影。在会员模式下高速缓存成功后（我很满意）弹出评分按钮。
- 
-
-
-
-
-
-
\ No newline at end of file
diff --git a/Chapter1 - iOS/1.35.md b/Chapter1 - iOS/1.35.md
deleted file mode 100644
index 69cd577..0000000
--- a/Chapter1 - iOS/1.35.md
+++ /dev/null
@@ -1,163 +0,0 @@
-# 一些布局小知识
-
-1. LaunchScreen 会根据设备大小设置屏幕的显示范围；LaunchImage 则根据提供的启动图片设置App的可见范围
-2. UITextView 可以设置显示范围
- textView.textContainerInset = UIEdgeInsetsMake(40, 0, 0, 0);
-3. UITextView 可以设置像 Word 一样文字环绕在图片四周的效果。其中用到的属性就是exclusionPaths
- // Default value : empty array An array of UIBezierPath representing the exclusion paths inside the receiver's bounding rect.
- @property (copy, NS_NONATOMIC_IOSONLY) NSArray *exclusionPaths NS_AVAILABLE(10_11, 7_0);
- NSString *str = @“xxx”;//xxx为文字内容
- textView = [[UITextView alloc] initWithFrame:CGRectMake(10, 20, self.view.frame.size.width-20, self.view.frame.size.height-30)];
- textView.text = str;
- [self.view addSubview:textView];
-
- imageView = [[UIImageView alloc] initWithFrame:CGRectMake(140, 280, 160, 100)]; imageView.backgroundColor = [UIColor orangeColor];
- imageView.image = [UIImage imageNamed:@"mao.jpg"];
- [self.view addSubview:imageView];
- textView.textContainer.exclusionPaths = @[[self translatedBezierPath]];
-
- - (UIBezierPath *)translatedBezierPath{
- CGRect imageRect = [textView convertRect:imageView.frame fromView:self.view];
- UIBezierPath *bezierPath = [UIBezierPath bezierPathWithRect:CGRectMake(imageRect.origin.x+5, imageRect.origin.y, imageRect.size.width-5, imageRect.size.height-5)];
- return bezierPath;
- }
- 1. 引申学习 CoreText
- 2. 在读很多第方库的时候，经常会看到2个关键词：“IB_DESIGNABLE”和”IBInspectable“。如果你想让你纯代码写的 View 具有可以在 StoryBoard 和 xib 文件可预览，就要在自定义的 UIView 头文件加上 IB_DESIGNABLE
- 3. 如果想让你自定义的 View 的参数可以在 xib 或者 storyboard 上 Attributes inspector 栏目中被看到且可以被修改，那么你需要在每个 property 前面加上 IBInspectable
- #import
-
- IB_DESIGNABLE
- @interface DashView : UIView
-
- @property (nonatomic, copy) void(^TimerBlock)(NSInteger);
-
- @property (nonatomic, strong) IBInspectable UIColor *color;
-
- //跃动数字刷新
- - (void)refreshJumpNOFromNO:(NSString *)startNO toNO:(NSString *)toNO andTime:(NSString *)time;
-
- @end
-
-
-4.UITabBarController 设置图片不能过大，不然不能显示
-
-5.设置导航控制器的 NavigationBar 的 BackgroundImage 且 使用了 UIBarMetericsDefault 会导航控制器的子控制器的 view 的高度会减小 64。只有设置为 UIBarMetricsDefault 的时候给 NavigationBar 设置背景图片才会显示。UIBarMetricsCompact 意味着导航条是透明的
-
- [self.navigationBar setBackgroundImage:[UIImage imageNamed:@"Report_customreport"] forBarMetrics:UIBarMetricsDefault];
-
-1. 在 iOS 6及之前的系统上默认都是 NO，在 iOS 7及其以后都是默认为 YES。效果表现为顶部的 NavigationBar 都是有透明度的效果
- @property(nonatomic,assign,getter=isTranslucent) BOOL translucent NS_AVAILABLE_IOS(3_0) UI_APPEARANCE_SELECTOR; // Default is NO on iOS 6 and earlier. Always YES if barStyle is set to UIBarStyleBlackTranslucent
- translucent 设置为 YES ，则布局 view 从屏幕的左上角开始计算，如果设置为 NO，那么布局从 NavigationBar 的下面开始布局。
-2. 总结：需要让导航控制器里面的控制器的 view 从导航栏以下开始布局，有2种方法可以实现。
- - 设置导航控制器 setTranslucent = NO
- - 给导航控制器的 NavigationBar 设置背景图片，且 BarMetrics 需要设置为 UIBarMetricsDefault
-3. + (void)load 和 + (void)initialize 的使用分析
- - initialize：第一次使用这个类或者它的子类的时候调用
- - load ：这个方法在类加载的时候调用一次。
- //window 下有一个导航控制器，导航控制器的根控制器是 ViewController ，点击屏幕跳转到 SubViewController（继承自 ViewController）
-
- //ViewController
- + (void)initialize{
- NSLog(@"%s",__func__);
- }
- + (void)load{
- NSLog(@"%s",__func__);
- }
-
- - (void)viewDidLoad {
- [super viewDidLoad];
- self.title = @"test";
- self.view.backgroundColor = [UIColor whiteColor];
- }
- - (void)touchesBegan:(NSSet *)touches withEvent:(UIEvent *)event{
- SubViewController *vc = [[SubViewController alloc] init];
- [self.navigationController pushViewController:vc animated:YES];
- }
- //SubViewController
- + (void)initialize{
- [super initialize];
- NSLog(@"%s",__func__);
- }
-
- //这个方法在类加载的时候调用一次。
- + (void)load{
- NSLog(@"%s",__func__);
- }
-
- 2018-07-19 11:26:04.621740+0800 Test[14617:1049502] +[ViewController load]
- 2018-07-19 11:26:04.622463+0800 Test[14617:1049502] +[SubViewController load]
- 2018-07-19 11:26:04.743541+0800 Test[14617:1049502] +[ViewController initialize]
- 2018-07-19 11:26:07.648425+0800 Test[14617:1049502] +[ViewController initialize]
- 2018-07-19 11:26:07.648610+0800 Test[14617:1049502] +[SubViewController initialize]
-
-
- 结果分析来看，类都被加载了（调用了 load 方法，其中页面显示的是 ViewController 所以它的 initialize 被调用，点击屏幕跳转到 SubViewController，所以 SubViewController 的 initialize 方法会被调用，在调用的时候调用了 super 关键字，调用父类的 initialize 方法）
-4. UIAppearance appearanceWhenContainedInInstancesOfClasses : 这个方法可以控制让自定义的导航控制器的 appearance 只修改自己需要修改的样式，不至于对于全部的导航控制器的 navigationBar 全部修改。
-5. UIImage 与 UIImageRenderingMode
- 在 iOS 系统中经常会用到 UIImage 来渲染一些控件，比如 UITabBar 和 UIBarButtonItem
- 在日常开发的时候我们可以为 UITabBar 设置 items 属性。其中可以指定 UITabBar 的 image 和 selectedImage。此时你可以提供2张图片，比如下面的代码
- [homeBar setImage:[UIImage imageNamed:@"Tab_home"]];
- [homeBar setSelectedImage:[UIImage imageNamed:@"Tab_home_selected"]];
- 你也可以按照下面的写法
- [homeBar setImage:[UIImage imageNamed:@"Tab_home"]];
- [homeBar setSelectedImage:[UIImage imageNamed:@"Tab_home"]];
- 这是因为系统会渲染。如果不为 UIImage 设置渲染模式，系统会在合适的地方根据上下文渲染，比如在这个地方的 UITabBar 就会根据上下文渲染出选中的效果。我们不必要必须设置选中的颜色。
- 当然你也可以指定 UIImage 的渲染模式。下面看看官方文档讲的 UIImage 的渲染模式
- // Create a version of this image with the specified rendering mode. By default, images have a rendering mode of UIImageRenderingModeAutomatic.
- - (UIImage *)imageWithRenderingMode:(UIImageRenderingMode)renderingMode NS_AVAILABLE_IOS(7_0);
- @property(nonatomic, readonly) UIImageRenderingMode renderingMode NS_AVAILABLE_IOS(7_0);
-
-
-
- /* Images are created with UIImageRenderingModeAutomatic by default. An image with this mode is interpreted as a template image or an original image based on the context in which it is rendered. For example, navigation bars, tab bars, toolbars, and segmented controls automatically treat their foreground images as templates, while image views and web views treat their images as originals. You can use UIImageRenderingModeAlwaysTemplate to force your image to always be rendered as a template or UIImageRenderingModeAlwaysOriginal to force your image to always be rendered as an original.
- */
- typedef NS_ENUM(NSInteger, UIImageRenderingMode) {
- UIImageRenderingModeAutomatic, // Use the default rendering mode for the context where the image is used
-
- UIImageRenderingModeAlwaysOriginal, // Always draw the original image, without treating it as a template
- UIImageRenderingModeAlwaysTemplate, // Always draw the image as a template image, ignoring its color information
- } NS_ENUM_AVAILABLE_IOS(7_0);
- UIImage 的渲染模式共有3种值可以选择
- - UIImageRenderingModeAutomatic：根据所使用的环境和绘图上下文自动调整渲染模式
- - UIImageRenderingModeAlwaysOriginal：始终绘制图片原始状态，不使用 tintColor
- - UIImageRenderingModeAlwaysTemplate：始终根据tintColor绘制图片，不管图片本身的颜色状态
-
-6.下面举个例子。在 UITabBarController 设置 tabBar
-
- [homeBar setImage:[UIImage imageNamed:@"Tab_home"]];
- [homeBar setSelectedImage:[UIImage imageNamed:@"Tab_home_selected"]];
-
-
- 从 iconfont 网站上面随便选择1个彩色 icon 用来做对比实验
-
- 
-
-
- - 实验1
-
- [homeBar setImage:[UIImage imageNamed:@"Tab_home"]];
- [homeBar setSelectedImage:[[UIImage imageNamed:@"Tab_home_selected"] imageWithRenderingMode:UIImageRenderingModeAutomatic]];
-
- 
-
-
-- 实验2
-
- [homeBar setImage:[UIImage imageNamed:@"Tab_home"]];
- [homeBar setSelectedImage:[[UIImage imageNamed:@"Tab_home_selected"] imageWithRenderingMode:UIImageRenderingModeAlwaysOriginal]];
-
- 
-
-
-- 实验3
- [homeBar setImage:[UIImage imageNamed:@"Tab_home"]];
- [homeBar setSelectedImage:[[UIImage imageNamed:@"Tab_home_selected"] imageWithRenderingMode:UIImageRenderingModeAlwaysTemplate]];
-
- 
-
-结论：对于 UIImage 来说如果不指定渲染模式的话则默认使用**UIImageRenderingModeAutomatic**，则会根据渲染的环境和上下文进行渲染。如果指定了模式，则根据具体的模式开启渲染。**UIImageRenderingModeAlwaysOriginal：**则绘制图片的原始信息，不使用**tintColor**。**UIImageRenderingModeAlwaysTemplate：**则始终根据**tintColor**绘制图片，忽略图片本身的信息。
-
-
-
-
- \ No newline at end of file diff --git a/Chapter1 - iOS/1.36.md b/Chapter1 - iOS/1.36.md deleted file mode 100644 index 73fecec..0000000 --- a/Chapter1 - iOS/1.36.md +++ /dev/null @@ -1,72 +0,0 @@ -# iOS 数值计算精度丢失问题 - -> 在 iOS 中经常会计算金额和价格，我们有时会定义数据类型为 double 或者 float，这样在做过一些运算后会发现精度丢失了，这显然不是我们想要的结果。今日偶然间看到一篇技术博文，为了记忆，顺道解决我的这个问题，所以记录了下来。 - - - -### 存在的问题（精度丢失） - -```objective-c -float a = 0.01; -int b = 99999999; -double c = 0.0; -c = a*b; -NSLog(@"c-%f",c); // c-1000000.000000 -NSLog(@"c-%.2f",c); // c-1000000.00 -``` - -通过上面的代码我们看到简单的数学运算后对于数据类型不合理的数值进行过运算后精度丢失了，这如果是在我们的 App 中，用户看到自己的金额不正确，那还不吓一跳？？ - -接下来看看如何做简单的改进 - -```objective-c -NSString *aString = [NSString stringWithFormat:@"%f",a]; -NSString *bString = [NSString stringWithFormat:@"%.2f",(double)b]; -c = [aString doubleValue]*[bString doubleValue]; -NSLog(@"%f",c); //999999.990000 -NSLog(@"%.2f",c); //999999.99 -``` - -这样虽然可以达成目的，但是计算的过程比较麻烦，并不是我们想要的解决方案。通过查阅资料得知苹果推出了一个类，专门解决数据计算的精度问题NSDecimalNumber 。 - - - -### NSDecimalNumber 为数据精度应用而生 - - - -NSDecimalNumber 是 NSNumber 的子类，专门负责精度计算。提供了完善的初始化方案，对于头疼的精度计算问题（金额）它提供了便利的解决方案（加、减、乘、除、次方运算并且可以给计算出的结果设置明显的精度方案（四舍五入、取上、取下等等））。NSDecimalNumberHandler 可以对计算出的结果做一些策略，比如舍入的模式、数据溢出、除0等异常情况的处理规则。 - -我们来说说上面的问题吧，引入了 NSDecimalNumber，解决上面的问题就不费吹灰之力了。 - -```objective-c -NSString *decimalNumberMutiplyWithString(NSString *multiplierValue, NSString *multiplicandvalue){ - NSDecimalNumber *multiplierNumber = [NSDecimalNumber decimalNumberWithString:multiplierValue]; - - NSDecimalNumber *multiplicandNumber = [NSDecimalNumber decimalNumberWithString:multiplicandvalue]; - NSDecimalNumber *result = [multiplierNumber decimalNumberByMultiplyingBy:multiplicandNumber]; - return [result stringValue]; -} - -NSDecimalNumber *price = [NSDecimalNumber decimalNumberWithMantissa:18992 exponent:-3 isNegative:NO]; -NSDecimalNumber *price2 = [NSDecimalNumber decimalNumberWithString:@"18.992"]; -NSLog(@"price:%@",[price stringValue]); //999999.990000 -NSLog(@"price2:%@",[price2 stringValue]); //999999.99 - - -//设置计算的精度（小数点位数、舍入规则） -NSDecimalNumberHandler *roundPlain = [NSDecimalNumberHandler - decimalNumberHandlerWithRoundingMode:NSRoundPlain - scale:1 - raiseOnExactness:NO - raiseOnOverflow:NO - raiseOnUnderflow:NO - raiseOnDivideByZero:YES]; - -NSDecimalNumber *resultDecimal = [multiplierNumber decimalNumberByMultiplyingBy:multiplicandNumber withBehavior:roundPlain]; -``` - -### 参考文章 - -[文章1](https://www.jianshu.com/p/25d24a184016)、[文章2](https://www.jianshu.com/p/ea4da259a062) - diff --git a/Chapter1 - iOS/1.37.md b/Chapter1 - iOS/1.37.md deleted file mode 100644 index eb3035f..0000000 --- a/Chapter1 - iOS/1.37.md +++ /dev/null @@ -1,34 +0,0 @@ -# 数组、集合、字典与 hash、isEqual 方法的关联 - -1. NSArray 允许重复添加元素，添加元素的时候不查重，所以不会调用上面2个方法。在移出元素的时候会依次遍历数组内的元素，每个元素调用 **isEqual** 方法（remove 方法传入的元素作为参数），所有返回真值的元素都会被移除。在字典中不涉及 hash 方法。 - -2. NSSet 不允许重复添加元素，所以在添加新元素的时候，该元素的 **hash** 方法会被调用，若集合中不存在与此元素 hash 相同的元素，则它会被直接加入集合，不调用 **isEqual** 方法；若存在，则依次调用该集合每个元素的 **isEqual** 方法，返回真值则判等，不加入，处理结合，若返回 false， 则判定集合内不存在该元素，将其加入。 - -3. 集合中移除元素时，首先调用它的 **hash方法**，若集合中存在与其 **hash值** 相等的元素，则调用该元素的 **isEqual方法**，若返回真值则判断，进行移除；若不存在，则会依次调用集合中每个元素的 **isEqual方法**，只要找到一个返回真值的元素，就进行移除，并结束整个过程（所有这样会有其它满足 isEqual 方法但却漏掉未被删除的元素）。调用 contains 方法时类似 - -4. 因此如果自定义对象被加入到集合或作为字典的 key 时，需要同时重写 isEqual 方法和 hash 方法，这样，若集合存在某元素，则调用它的 contains 和 remove 方法时，可以在 O(1) 完成查询，否则需要 O(n) 完成。 - -5. 需要注意的是，NSDictionary 的 key、value 都说对象类型即可，但是被设为 key 的对象需要遵循 NSCopying 协议。 - -6. hash 方法出现的目的是：当我们从数组中查找元素时，需要依次遍历数组中的元素，时间复杂度为 O(n),为了解决效率问题，引入了 Hash Table 方法。当添加元素的时候，为每个元素设置了 hash 值，这样当下次查找的时候就直接通过 hash 值找到对应的位置，时间复杂度为 O(1)。设计一个合理的 hash 算法的指标是对于每个参数，其返回的 hash 值唯一。 - -7. 查阅资料可知，一个推荐的自定义对象的 **hash** 算法是将关键属性的 hash 值，按照位或运算 - -``` -@interface Person : NSObject -@property (nonatomic, strong) NSString *name; -@property (nonatomic, strong) NSDate *birthday; -@end - - -- (NSUInteger)hash{ - return [self.name hash] ^ [self.birthday hash]; -} -``` - - - -8. NSObject 类中的 equal 方法的判断是包括内存地址的，也就是说，NSObject 若想判断2个对象相等，那么这2个对象的内存地址必须相等 - - - diff --git a/Chapter1 - iOS/1.38.md b/Chapter1 - iOS/1.38.md deleted file mode 100644 index 46fb552..0000000 --- a/Chapter1 - iOS/1.38.md +++ /dev/null @@ -1,2261 +0,0 @@ -# RunLoop 探究 - -> 为什么 main 函数可以保持一直运行而不退出？ -> -> 卡顿如何监控 - - - -## RunLoop 是什么 - -- 运行循环 -- 在程序运行过程中循环做一些事情 - -作用：程序并不会马上退出，而是保持运行状态 - -- 保持程序的持续运行 - -- 处理App中的各种事件（比如触摸事件、定时器事件等） - -- 节省CPU资源，提高程序性能：该做事时做事，该休息时休息。休息和工作是从用户态切换到内核态，内核态切换到用户态的不断切换 - -- ...... - -场景 - -- 定时器（Timer）、PerformSelector - -- GCD Async Main Queue - -- 事件响应、手势识别、界面刷新 - -- 网络请求 - -- AutoreleasePool - -先附上一张总结的非常棒的RunLoop图 - -
-
-
-
-一言以蔽之，什么是 RunLoop？为什么 main 函数可以保持一直运行而不退出？
-
-iOS 侧 main 函数中，调用 UIApplicationMain 方法，内部启动主线程的 RunLoop，RunLoop 是一个事件循环的维护机制。有事情做的时候做事情（Source0、Source1），没有事做的时，从用户态到内核态的切换，去实现线程休眠。避免资源浪费。
-
-
-
-## RunLoop 几个重要角色
-
-### 获取 RunLoop
-
-iOS 中有2套 API 可以访问和使用 RunLoop。分别是
-
-- Foundation：NSRunLoop
-
-- CoreFoundation：CFRunLoopRef
-
-```
-//Foundation
-[NSRunLoop currentRunLoop]; // 获得当前线程的RunLoop对象
-[NSRunLoop mainRunLoop]; // 获得主线程的RunLoop对象
-
-//Core Foundation
-CFRunLoopGetCurrent(); // 获得当前线程的RunLoop对象
-CFRunLoopGetMain(); // 获得主线程的RunLoop对象
-```
-
-NSRunLoop 是对 CFRunLoopRef 的一层 OC 包装，所以要了解 RunLoop 的内部结果，就需要了解 CFRunLoopRef
-
-- RunLoop 保存在一个全局的 Dictionary 里，线程作为 key，RunLoop 作为 value
-
-- 每条线程都有与之一一对应的 RunLoop 对象
-
-- 主线程的 RunLoop 已经自动创建好了，子线程的 RunLoop 需要主动创建
-
-- RunLoop 在第一次获取时创建，在线程结束时消失
-
-
-
-### RunLoop 相关的5个类
-
-- CFRunLoopRef
-- CFRunLoopModeRef
-- CFRunLoopSourceRef
-- CFRunLoopTimerRef
-- CFRunLoopObserverRef
-
-CFRunLoopRef 是什么？
-
-查看源码 CFRunLoop 发现是结构体对象别名，`typedef struct __CFRunLoop * CFRunLoopRef;`摘取主要信息如下
-
-```c
-struct __CFRunLoop {
- pthread_t _pthread;
- CFMutableSetRef _commonModes;
- CFMutableSetRef _commonModeItems;
- CFRunLoopModeRef _currentMode;
- CFMutableSetRef _modes;
-};
-```
-
-其中 `_modes` 代表一个 RunLoop 有一个 set 存储运行模式，有多个 Mode。`_currentMode` 表示当前时刻只有一个 Mode。
-
-`CFRunLoopModeRef` 是什么？查看发现
-
-`typedef struct __CFRunLoopMode *CFRunLoopModeRef;`
-
-```c
-struct __CFRunLoopMode {
- CFStringRef _name;
- CFMutableSetRef _sources0;
- CFMutableSetRef _sources1;
- CFMutableArrayRef _observers;
- CFMutableArrayRef _timers;
-};
-```
-
-
-
-### CFRunLoopModeRef 代表 RunLoop 的运行模式
-
-- 一个 RunLoop 包含若干个 Mode，每个 Mode 包含若干个 Source/Timer/Observer
-- 每次 RunLoop 启动，只能指定一个 Mode，这个 Mode 被叫做 CurrentMode
-- 如果需要切换 Mode，只能退出 RunLoop，则以一个 Mode 进入
-- 如果 Mode 里没有任何 Source0/Source1/Timer/Observer，RunLoop 会立马退出
-
-
-
-系统默认注册了5个Mode
-
-- kCFRunLoopDefaultMode：App 的默认 Mode，通常主线程是在这个 Mode 下运行
-- UITrackingRunLoopMode：界面跟踪 Mode，用于 ScrollView 追踪触摸滑动，保证界面滑动时不受其他 Mode 影响
-- UIInitializationRunLoopMode: 在刚启动 App 时进入的第一个 Mode，启动完成后就不再使用
-- GSEventReceiveRunLoopMode: 接受系统事件的内部 Mode，通常用不到
-- kCFRunLoopCommonModes: 这是一个占位用的Mode，不是一种真正的Mode
-
-
-
-Demo:
-
-
-
-
-
-结论：NSRunLoop 是对 CFRunLoop 的一层包装。
-
-
-
-QA：为什么一个 RunLoop 需要创建这么多 Mode？
-
-这样做的目的是为了分隔开不同组的 Source/Timer/Observer 互不影响(性能、功能)。
-
-在UITableView场景下，不同的 RunLoop Mode 主要是与 UITableView 的滑动优化和事件处理相关的。当 UITableView 滑动时，RunLoop的运行模式会从默认的 CFRunLoopDefaultMode 切换到 CFRunLoopTrackingMode，此 Mode 下 RunLoop 主要关注于处理与滑动相关的触摸事件和动画效果，而忽略其他类型的事件，如定时器事件。这是因为如果同时处理所有类型的事件，可能会导致滑动不流畅，影响用户体验。之前添加到 CFRunLoopDefaultMode 上的事件通知（如定时器事件）可能无法被及时处理，这就是为什么在UITableView 滑动时，添加到主线程的 NSTimer 可能会停止执行的原因。
-
-
-
-### Source0、Source1、Timer、Observers 是什么
-
-```c
-struct __CFRunLoopMode {
- CFStringRef _name;
- CFMutableSetRef _sources0;
- CFMutableSetRef _sources1;
- CFMutableArrayRef _observers;
- CFMutableArrayRef _timers;
-};
-```
-
-RunLoop 在各个 Mode 下做事情，其实就是在处理某个 Mode 中的 Source0、Source1、Timer、Observer 事件。
-
-Source0:
-
-- 处理开发者主动提交的任务或应用内部逻辑。
- - `performSelector:onThread:`
- - `dispatch_async`到主线程的任务（最终封装为Source0）。
- - 屏幕触摸事件处理（非基于 Port 的事件），对应需要手动触发的事件，对应官方文档 Input Source 中的 Custom 和 `performSelector:onThread` 事件源。UIKit控件的事件处理（如按钮点击后的回调）。
-
-
-Demo1：给屏幕点击事件加断点，查看堆栈可以看到是 Source0 触发的。
-
-
-
-Demo2: `- (void)performSelector:(SEL)aSelector onThread:(NSThread *)thr withObject:(nullable id)arg waitUntilDone:(BOOL)wait` 该 API 的底层就是：向目标线程的 RunLoop 添加一个 Source0 事件，标记后唤醒线程执行对应的事件。
-
-
-
-Source1:
-
-- 基于 Port 的线程间通信，可以主动唤醒 RunLoop
-- 用户触摸屏幕时，系统通过 Mach Port 将事件传递到应用主线程的 RunLoop。RunLoop 被 Source1 唤醒后，将事件分发给 Source0处理具体的 UI 响应逻辑（如 `hitTest:withEvent:` 和响应链）。
-- 字典。`{machport : 1}`
-
-Timers：
-
-- NSTimer
-
-- `performSelector:withObject:afterDelay:`，底层也是 Timer
-
-Observers:
-
-- 用于监听 RunLoop 状态
-
-- UI刷新（BeforeWaiting）
-
-- AutoReleasePool 实现（BeforeWaiting）
-
-CFRunLoopSourceRef 事件源（输入源）
-
-早期的分法：
-
-- Ported-Based Source
-- Custom Input Source
-- Cocoa Perform Selector Source
-
-现在的分法
-
-- Source0：非基于 port 的，用户主动触发的事件
-- Source1: 基于 port的，通过内核在线程间相互发送消息
-
-
-
-### 一对多的关系
-
-
-
-
-
-#### RunLoopTimer 的封装
-
-- `+ (NSTimer *)timerWithTimeInterval:(NSTimeInterval)ti invocation:(NSInvocation *)invocation repeats:(BOOL)yesOrNo;`
-- `+ (NSTimer *)scheduledTimerWithTimeInterval:(NSTimeInterval)ti invocation:(NSInvocation *)invocation repeats:(BOOL)yesOrNo;`
-- `- (void)performSelector:(SEL)aSelector withObject: (id)argument afterDelay: (NSTimeInterval)seconds inModes: (NSArray*)modes;`
-- `+ (CADisplayLink *)displayLinkWithTarget:(id)target selector:(SEL)sel;`
-- `- (void)addToRunLoop:(NSRunLoop *)runloop forMode:(NSString *)mode;`
-
-
-
-#### CFRunLoopSource
-
-Source 是 RunLoop 的数据源抽象类（protocol）
-
-RunLoop 定义了2个 Version 的 Source：
-
-- Source0：处理 App 内部事件、App 自己负责管理（触发），如 UIEvent、CGSocket
-- Source1：由 RunLoop 和内核管理，Mach port 驱动，如 CFMachPort、CFMessagePort。
-
-定义如下：
-
-```c++
-struct __CFRunLoopSource {
- CFRuntimeBase _base;
- uint32_t _bits;
- pthread_mutex_t _lock;
- CFIndex _order; /* immutable */
- CFMutableBagRef _runLoops;
- union {
- CFRunLoopSourceContext version0; /* immutable, except invalidation */
- CFRunLoopSourceContext1 version1; /* immutable, except invalidation */
- } _context;
-};
-
-typedef struct {
- CFIndex version;
- void * info;
- const void *(*retain)(const void *info);
- void (*release)(const void *info);
- CFStringRef (*copyDescription)(const void *info);
- Boolean (*equal)(const void *info1, const void *info2);
- CFHashCode (*hash)(const void *info);
- void (*schedule)(void *info, CFRunLoopRef rl, CFStringRef mode);
- void (*cancel)(void *info, CFRunLoopRef rl, CFStringRef mode);
- void (*perform)(void *info);
-} CFRunLoopSourceContext;
-
-typedef struct {
- CFIndex version;
- void * info;
- const void *(*retain)(const void *info);
- void (*release)(const void *info);
- CFStringRef (*copyDescription)(const void *info);
- Boolean (*equal)(const void *info1, const void *info2);
- CFHashCode (*hash)(const void *info);
-#if (TARGET_OS_MAC && !(TARGET_OS_EMBEDDED || TARGET_OS_IPHONE)) || (TARGET_OS_EMBEDDED || TARGET_OS_IPHONE)
- mach_port_t (*getPort)(void *info);
- void * (*perform)(void *msg, CFIndex size, CFAllocatorRef allocator, void *info);
-#else
- void * (*getPort)(void *info);
- void (*perform)(void *info);
-#endif
-} CFRunLoopSourceContext1;
-```
-
-
-
-#### CFRunLoopObserver
-
-向外部报告 RunLoop 当前状态的更改。框架中很多机制都是由 RunLoopObserver 触发，比如 CAAnimation、AutoReleasePool。
-
-系统或者开发者很多都是 RunLoop 的业务方。
-
-
-
-#### CFRunLoopMode
-
-Mode 是 iOS App 滑动流畅的关键。
-
-不同任务被添加到不同 Mode 中去。
-
-UITrackingMode 模式下，核心关注滚动时 UI 流畅相关逻辑。
-
-
-
-
-
-### CFRunLoopObserverRef 监听 RunLoop 状态变化
-
-```objective-c
-/* Run Loop Observer Activities */
-typedef CF_OPTIONS(CFOptionFlags, CFRunLoopActivity) {
- kCFRunLoopEntry = (1UL << 0), // 即将进入 RunLoop
- kCFRunLoopBeforeTimers = (1UL << 1), // 即将处理 NSTimer
- kCFRunLoopBeforeSources = (1UL << 2), // 即将处理 Source
- kCFRunLoopBeforeWaiting = (1UL << 5), // 即将进入休眠
- kCFRunLoopAfterWaiting = (1UL << 6), // 刚从休眠中唤醒
- kCFRunLoopExit = (1UL << 7), // 退出 RunLoop
- kCFRunLoopAllActivities = 0x0FFFFFFFU
-};
-```
-
- 添加 Observer
-
-```objective-c
-//1、获得当前线程下的 RunLoop
-CFRunLoopRef runloop = CFRunLoopGetCurrent();
-//2、为 RunLoop 创建观察者
-CFRunLoopObserverRef obersver = CFRunLoopObserverCreateWithHandler(CFAllocatorGetDefault(), kCFRunLoopAllActivities, YES, 0, ^(CFRunLoopObserverRef observer, CFRunLoopActivity activity) {
-});
-//3、为当前的 RunLoop 添加观察者
-CFRunLoopAddObserver(runloop, obersver, kCFRunLoopDefaultMode);
-//4、在 CoreFoundation 框架中， create、copy、retain 过的对象都必须在最后 release
-CFRelease(obersver);
-```
-
-注意：CoreFoundation 的内存管理：凡是带有 Create、Copy、Retain 等字眼的函数创建出来的对象都需要在最后调用 `release`
-
-```objective-c
-//给 RunLoop 添加监听者
-- (void) {
-
- //创建监听者
-// CFRunLoopObserverCreate(CFAllocatorGetDefault(), kCFRunLoopAllActivities, <#Boolean repeats#>, <#CFIndex order#>, <#CFRunLoopObserverCallBack callout#>, <#CFRunLoopObserverContext *context#>)
- /*
- 创建监听对象
- 参数1:分配内存空间
- 参数2:要监听的状态 kCFRunLoopAllActivities ：所有状态
- 参数3:是否要持续监听
- 参数4:优先级
- 参数5:回调
- */
-
- CFRunLoopObserverRef oberver = CFRunLoopObserverCreateWithHandler(CFAllocatorGetDefault(), kCFRunLoopAllActivities, YES, 0, ^(CFRunLoopObserverRef observer, CFRunLoopActivity activity) {
- switch (activity) {
- case kCFRunLoopEntry:
- NSLog(@"RunLoop 闪亮登场");
- break;
- case kCFRunLoopBeforeTimers:
- NSLog(@"RunLoop 大哥要处理 Timer 了");
- break;
- case kCF RunLoopBeforeSources:
- //Source 有2种。Source0:非基于 port 的，用户主动触发的事件。Source1:基于 port，通过内核和其它线程互相发送消息
- NSLog(@"RunLoop 大哥要处理 Source 了");
- break;
- case kCFRunLoopBeforeWaiting:
- NSLog(@"RunLoop 大哥没事干要睡觉了");
- break;
- case kCFRunLoopAfterWaiting:
- NSLog(@"");
- NSLog(@"RunLoop 大哥终于等到有缘人了，要醒来开始干活了");
- break;
- case kCFRunLoopExit:
- NSLog(@"RunLoop 大哥要退出离开了");
- break;
- default:
- break;
- }
- });
- /*
- 参数1:要监听哪个RunLoop
- 参数2:监听者
- 参数3:要监听 RunLoop 在哪种运行模式下的状态
- */
- CFRunLoopAddObserver(CFRunLoopGetCurrent(), oberver, kCFRunLoopDefaultMode);
- CFRelease(oberver);
- [NSTimer scheduledTimerWithTimeInterval:5 target:self selector:@selector(wakeupRunLoop) userInfo:nil repeats:YES];
-}
-
-
-//等到 RunLoop 休眠后，5秒钟叫醒 RunLoop
-- (void)wakeupRunLoop{
- NSLog(@"%s",__func__);
-}
-/*
-2018-08-01 11:23:49.401626+0800 RunLoop[38148:1994974] RunLoop 大哥要处理 Timer 了
-2018-08-01 11:23:49.401950+0800 RunLoop[38148:1994974] RunLoop 大哥要处理 Source 了
-2018-08-01 11:23:49.402326+0800 RunLoop[38148:1994974] RunLoop 大哥要处理 Timer 了
-2018-08-01 11:23:49.402509+0800 RunLoop[38148:1994974] RunLoop 大哥要处理 Source 了
-2018-08-01 11:23:49.402721+0800 RunLoop[38148:1994974] RunLoop 大哥要处理 Timer 了
-2018-08-01 11:23:49.402855+0800 RunLoop[38148:1994974] RunLoop 大哥要处理 Source 了
-2018-08-01 11:23:49.403080+0800 RunLoop[38148:1994974] RunLoop 大哥没事干要睡觉了
-2018-08-01 11:23:49.459238+0800 RunLoop[38148:1994974]
-2018-08-01 11:23:49.459512+0800 RunLoop[38148:1994974] RunLoop 大哥终于等到有缘人了，要醒来开始干活了
-2018-08-01 11:23:49.459740+0800 RunLoop[38148:1994974] RunLoop 大哥要处理 Timer 了
-2018-08-01 11:23:49.459932+0800 RunLoop[38148:1994974] RunLoop 大哥要处理 Source 了
-2018-08-01 11:23:49.460431+0800 RunLoop[38148:1994974] RunLoop 大哥要处理 Timer 了
-2018-08-01 11:23:49.460607+0800 RunLoop[38148:1994974] RunLoop 大哥要处理 Source 了
-2018-08-01 11:23:49.460775+0800 RunLoop[38148:1994974] RunLoop 大哥没事干要睡觉了
-2018-08-01 11:23:49.880631+0800 RunLoop[38148:1994974]
-2018-08-01 11:23:49.880867+0800 RunLoop[38148:1994974] RunLoop 大哥终于等到有缘人了，要醒来开始干活了
-2018-08-01 11:23:49.881530+0800 RunLoop[38148:1994974] RunLoop 大哥要处理 Timer 了
-2018-08-01 11:23:49.881699+0800 RunLoop[38148:1994974] RunLoop 大哥要处理 Source 了
-2018-08-01 11:23:49.881870+0800 RunLoop[38148:1994974] RunLoop 大哥没事干要睡觉了
-2018-08-01 11:23:54.402263+0800 RunLoop[38148:1994974]
-2018-08-01 11:23:54.402562+0800 RunLoop[38148:1994974] RunLoop 大哥终于等到有缘人了，要醒来开始干活了
-2018-08-01 11:23:54.402773+0800 RunLoop[38148:1994974] -[ViewController wakeupRunLoop]
-2018-08-01 11:23:54.403081+0800 RunLoop[38148:1994974] RunLoop 大哥要处理 Timer 了
-2018-08-01 11:23:54.403245+0800 RunLoop[38148:1994974] RunLoop 大哥要处理 Source 了
-2018-08-01 11:23:54.403476+0800 RunLoop[38148:1994974] RunLoop 大哥没事干要睡觉了
-2018-08-01 11:23:59.402151+0800 RunLoop[38148:1994974]
-2018-08-01 11:23:59.402511+0800 RunLoop[38148:1994974] RunLoop 大哥终于等到有缘人了，要醒来开始干活了
-2018-08-01 11:23:59.402687+0800 RunLoop[38148:1994974] -[ViewController wakeupRunLoop]
-2018-08-01 11:23:59.402913+0800 RunLoop[38148:1994974] RunLoop 大哥要处理 Timer 了
-2018-08-01 11:23:59.403037+0800 RunLoop[38148:1994974] RunLoop 大哥要处理 Source 了
-2018-08-01 11:23:59.403156+0800 RunLoop[38148:1994974] RunLoop 大哥没事干要睡觉了
-*/
-```
-
-
-
-上个实验是在主线程对 RunLoop 进行的监听，但是由于是主线程是由系统创建的，所以系统也创建了对应的主 RunLoop，所以我们看不到 RunLoop 创建的状态，为了模拟完整的状态，我们开启子线程，在子线程中模拟
-
-```objective-c
-- (void)testRunLoopObserverOnSubThread{
-
- //创建并发队列
- dispatch_queue_t queue = dispatch_queue_create("com.lbp.testRunLoopOnSubThread", DISPATCH_QUEUE_CONCURRENT);
- //开启子线程
- dispatch_async(queue, ^{
-
- //1、获得当前线程下的 RunLoop
- CFRunLoopRef runloop = CFRunLoopGetCurrent();
-
-
- //2、为 RunLoop 创建观察者
- CFRunLoopObserverRef obersver = CFRunLoopObserverCreateWithHandler(CFAllocatorGetDefault(), kCFRunLoopAllActivities, YES, 0, ^(CFRunLoopObserverRef observer, CFRunLoopActivity activity) {
- switch (activity) {
- case kCFRunLoopEntry:
- NSLog(@"RunLoop 闪亮登场");
- break;
- case kCFRunLoopBeforeTimers:
- NSLog(@"RunLoop 大哥要处理 Timer 了");
- break;
- case kCFRunLoopBeforeSources:
- //Source 有2种。Source0:非基于 port 的，用户主动触发的事件。Source1:基于 port，通过内核和其它线程互相发送消息
- NSLog(@"RunLoop 大哥要处理 Source 了");
- break;
- case kCFRunLoopBeforeWaiting:
- NSLog(@"RunLoop 大哥没事干要睡觉了");
- break;
- case kCFRunLoopAfterWaiting:
- NSLog(@"");
- NSLog(@"RunLoop 大哥终于等到有缘人了，要醒来开始干活了");
- break;
- case kCFRunLoopExit:
- NSLog(@"RunLoop 大哥要退出离开了");
- break;
- default:
- break;
- }
- });
- //为了运行 RunLoop 必须触发事件
- [NSTimer scheduledTimerWithTimeInterval:2 target:self selector:@selector(wakeUpRunLoopOnSubThread) userInfo:nil repeats:NO];
- //3、为当前的 RunLoop 添加观察者
- CFRunLoopAddObserver(runloop, obersver, kCFRunLoopDefaultMode);
- //4、在 CoreFoundation 框架中， create、copy、retain 过的对象都必须在最后 release
- CFRelease(obersver);
- //5、在非主线程创建的 RunLoop 必须触发运行
- [[NSRunLoop currentRunLoop] run];
- });
-}
-
-
-- (void)wakeUpRunLoopOnSubThread{
- NSLog(@"%s",__func__);
-}
-/*
-2018-08-01 14:23:06.453282+0800 RunLoop[2376:115968] RunLoop 闪亮登场
-2018-08-01 14:23:06.453608+0800 RunLoop[2376:115968] RunLoop 大哥要处理 Timer 了
-2018-08-01 14:23:06.453781+0800 RunLoop[2376:115968] RunLoop 大哥要处理 Source 了
-2018-08-01 14:23:06.453982+0800 RunLoop[2376:115968] RunLoop 大哥没事干要睡觉了
-2018-08-01 14:23:08.458237+0800 RunLoop[2376:115968]
-2018-08-01 14:23:08.458658+0800 RunLoop[2376:115968] RunLoop 大哥终于等到有缘人了，要醒来开始干活了
-2018-08-01 14:23:08.458894+0800 RunLoop[2376:115968] -[ViewController wakeUpRunLoopOnSubThread]
-2018-08-01 14:23:08.459082+0800 RunLoop[2376:115968] RunLoop 大哥要退出离开了
-*/
-```
-
-
-
-## RunLoop 运行原理
-
-### 运行原概要
-
-
-
-- 图上左上角的 Input source 是早期 RunLoop 的分法，现在分法为：Source0 和 Source1。
- - Source0:非基于 port 的，用户主动触发的事件。
- - Source1:基于 port，通过内核和其它线程互相发送消息
-- RunLoop 我们不能自己手动创建，而是可以通过 [NSRunLoop currentRunLoop] 方法获取，类似于懒加载。系统底层的做法是在全局维护了一个字典，字典的 key 和 value 分别是当前的线程和线程对应的 RunLoop，如果新开辟的线程没有对应的 RunLoop，系统则为其创建 RunLoop，并将其写入字典（线程、为其创建的 RunLoop）
-
-
-
-### 源码探究
-
-内部就是 do-while 的循环，在这个循环内部不断处理各种任务（Timer、Source、Observer）
-
-我们来看看苹果官方开源的 [CFRunLoop.c 文件](https://legacy.gitbook.com/book/fantasticlbp/knowledge-kit/edit#)。看几个关键函数的实现猜测下 RunLoop 的内部原理
-
-但是如何直到系统是运行 RunLoop 的哪个函数？给 viewDidLoad 设置断点，在 lldb 模式输入 `bt` 查看堆栈
-
-
-
-查看 CF 中 `CFRunLoop.c`源码。方法比较复杂，做了精简摘要
-
-```c
-SInt32 CFRunLoopRunSpecific(CFRunLoopRef rl, CFStringRef modeName, CFTimeInterval seconds, Boolean returnAfterSourceHandled) { /* DOES CALLOUT */
- // ...
- // 通知 Observers 进入 RunLoop
- __CFRunLoopDoObservers(rl, currentMode, kCFRunLoopEntry);
- // RunLoop 运行循环主逻辑
- result = __CFRunLoopRun(rl, currentMode, seconds, returnAfterSourceHandled, previousMode);
- // 通知 Observers 退出 RunLoop
- __CFRunLoopDoObservers(rl, currentMode, kCFRunLoopExit);
- return result;
-}
-```
-
-`CFRunLoopRunSpecific` 方法就是系统启动 RunLoop 的入口。内部先通知 Runloop 的观察者进入 Runloop 了，然后 调用 `__CFRunLoopRun` 执行核心逻辑（处理 timers、source 事件、block），最后告诉观察者退出 Runloop。
-
-我们继续看看 `__CFRunLoopRun` 。源码很多很乱，对无关代码进行裁剪，便于理解流程逻辑
-
-```c
-static int32_t __CFRunLoopRun(CFRunLoopRef rl, CFRunLoopModeRef rlm, CFTimeInterval seconds, Boolean stopAfterHandle, CFRunLoopModeRef previousMode) {
- int32_t retVal = 0;
- do {
- // 通知 Obserers：即将处理 Timers
- if (rlm->_observerMask & kCFRunLoopBeforeTimers) __CFRunLoopDoObservers(rl, rlm, kCFRunLoopBeforeTimers);
- // 通知 Obserers：即将处理 Sources
- if (rlm->_observerMask & kCFRunLoopBeforeSources) __CFRunLoopDoObservers(rl, rlm, kCFRunLoopBeforeSources);
- // 处理 blocks
- __CFRunLoopDoBlocks(rl, rlm);
- // 处理 Source0
- Boolean sourceHandledThisLoop = __CFRunLoopDoSources0(rl, rlm, stopAfterHandle);
- if (sourceHandledThisLoop) {
- // 处理 blocks
- __CFRunLoopDoBlocks(rl, rlm);
- }
-
- Boolean poll = sourceHandledThisLoop || (0ULL == timeout_context->termTSR);
- // 判断有无 Source1
- if (MACH_PORT_NULL != dispatchPort && !didDispatchPortLastTime) {
- msg = (mach_msg_header_t *)msg_buffer;
- // 如果有 Source1 则跳转到 handle_msg
- if (__CFRunLoopServiceMachPort(dispatchPort, &msg, sizeof(msg_buffer), &livePort, 0, &voucherState, NULL)) {
- goto handle_msg;
- }
- }
-
- didDispatchPortLastTime = false;
- // 通知 Observers：即将休眠
- if (!poll && (rlm->_observerMask & kCFRunLoopBeforeWaiting)) __CFRunLoopDoObservers(rl, rlm, kCFRunLoopBeforeWaiting);
-
- CFAbsoluteTime sleepStart = poll ? 0.0 : CFAbsoluteTimeGetCurrent();
-
-
- do {
- if (kCFUseCollectableAllocator) {
- // objc_clear_stack(0);
- //
- memset(msg_buffer, 0, sizeof(msg_buffer));
- }
- msg = (mach_msg_header_t *)msg_buffer;
- // 等待其他消息来唤醒 RunLoop
- __CFRunLoopServiceMachPort(waitSet, &msg, sizeof(msg_buffer), &livePort, poll ? 0 : TIMEOUT_INFINITY, &voucherState, &voucherCopy);
-
- if (modeQueuePort != MACH_PORT_NULL && livePort == modeQueuePort) {
- // Drain the internal queue. If one of the callout blocks sets the timerFired flag, break out and service the timer.
- while (_dispatch_runloop_root_queue_perform_4CF(rlm->_queue));
- if (rlm->_timerFired) {
- // Leave livePort as the queue port, and service timers below
- rlm->_timerFired = false;
- break;
- } else {
- if (msg && msg != (mach_msg_header_t *)msg_buffer) free(msg);
- }
- } else {
- // Go ahead and leave the inner loop.
- break;
- }
- } while (1);
- // 通知 Observers：结束休眠
- if (!poll && (rlm->_observerMask & kCFRunLoopAfterWaiting)) __CFRunLoopDoObservers(rl, rlm, kCFRunLoopAfterWaiting);
-
- handle_msg:; // 判断是怎么唤醒的 Runloop
- __CFRunLoopSetIgnoreWakeUps(rl);
- //
- if (MACH_PORT_NULL == livePort) {
- CFRUNLOOP_WAKEUP_FOR_NOTHING();
- // handle nothing
- } else if (livePort == rl->_wakeUpPort) {
- CFRUNLOOP_WAKEUP_FOR_WAKEUP();
- }
- // 被 Timer 唤醒，执行代码。
- else if (modeQueuePort != MACH_PORT_NULL && livePort == modeQueuePort) {
- CFRUNLOOP_WAKEUP_FOR_TIMER();
- if (!__CFRunLoopDoTimers(rl, rlm, mach_absolute_time())) {
- // Re-arm the next timer, because we apparently fired early
- __CFArmNextTimerInMode(rlm, rl);
- }
- }
- // 被 Timer 唤醒，执行代码。
- else if (rlm->_timerPort != MACH_PORT_NULL && livePort == rlm->_timerPort) {
- CFRUNLOOP_WAKEUP_FOR_TIMER();
- // On Windows, we have observed an issue where the timer port is set before the time which we requested it to be set. For example, we set the fire time to be TSR 167646765860, but it is actually observed firing at TSR 167646764145, which is 1715 ticks early. The result is that, when __CFRunLoopDoTimers checks to see if any of the run loop timers should be firing, it appears to be 'too early' for the next timer, and no timers are handled.
- // In this case, the timer port has been automatically reset (since it was returned from MsgWaitForMultipleObjectsEx), and if we do not re-arm it, then no timers will ever be serviced again unless something adjusts the timer list (e.g. adding or removing timers). The fix for the issue is to reset the timer here if CFRunLoopDoTimers did not handle a timer itself. 9308754
- if (!__CFRunLoopDoTimers(rl, rlm, mach_absolute_time())) {
- // Re-arm the next timer
- __CFArmNextTimerInMode(rlm, rl);
- }
- }
- // 被 GCD 唤醒
- else if (livePort == dispatchPort) {
- // 处理 GCD
- __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__(msg);
- } else {
- // 被 Source1 唤醒
- CFRUNLOOP_WAKEUP_FOR_SOURCE();
- // 处理 Source1
- __CFRunLoopDoSource1(rl, rlm, rls, msg, msg->msgh_size, &reply) || sourceHandledThisLoop;
-
- }
- if (msg && msg != (mach_msg_header_t *)msg_buffer) free(msg);
- // 处理 Blocks
- __CFRunLoopDoBlocks(rl, rlm);
-
- // 设置返回值
- if (sourceHandledThisLoop && stopAfterHandle) {
- retVal = kCFRunLoopRunHandledSource;
- } else if (timeout_context->termTSR < mach_absolute_time()) {
- retVal = kCFRunLoopRunTimedOut;
- } else if (__CFRunLoopIsStopped(rl)) {
- __CFRunLoopUnsetStopped(rl);
- retVal = kCFRunLoopRunStopped;
- } else if (rlm->_stopped) {
- rlm->_stopped = false;
- retVal = kCFRunLoopRunStopped;
- } else if (__CFRunLoopModeIsEmpty(rl, rlm, previousMode)) {
- retVal = kCFRunLoopRunFinished;
- }
-
- voucher_mach_msg_revert(voucherState);
- os_release(voucherCopy);
- } while (0 == retVal); // 当 retVal == 0 的时候结束 Runloop
- return retVal;
-}
-```
-
-另一个版本
-
-```objective-c
- /* rl, rlm are locked on entrance and exit */
- static int32_t __CFRunLoopRun(CFRunLoopRef rl, CFRunLoopModeRef rlm, CFTimeInterval seconds, Boolean stopAfterHandle, CFRunLoopModeRef previousMode) {
-
-
- uint64_t startTSR = mach_absolute_time();
-
-
- if (__CFRunLoopIsStopped(rl)) {
- __CFRunLoopUnsetStopped(rl);
- return kCFRunLoopRunStopped;
- } else if (rlm->_stopped) {
- rlm->_stopped = false;
- return kCFRunLoopRunStopped;
- }
-
-
- mach_port_name_t dispatchPort = MACH_PORT_NULL;
- Boolean libdispatchQSafe = pthread_main_np() && ((HANDLE_DISPATCH_ON_BASE_INVOCATION_ONLY && NULL == previousMode) || (!HANDLE_DISPATCH_ON_BASE_INVOCATION_ONLY && 0 == _CFGetTSD(__CFTSDKeyIsInGCDMainQ)));
- if (libdispatchQSafe && (CFRunLoopGetMain() == rl) && CFSetContainsValue(rl->_commonModes, rlm->_name)) dispatchPort = _dispatch_get_main_queue_port_4CF();
-
-
- #if USE_DISPATCH_SOURCE_FOR_TIMERS
- mach_port_name_t modeQueuePort = MACH_PORT_NULL;
- if (rlm->_queue) {
- modeQueuePort = _dispatch_runloop_root_queue_get_port_4CF(rlm->_queue);
- if (!modeQueuePort) {
- CRASH("Unable to get port for run loop mode queue (%d)", -1);
- }
- }
- #endif
-
-
- dispatch_source_t timeout_timer = NULL;
- struct __timeout_context *timeout_context = (struct __timeout_context *)malloc(sizeof(*timeout_context));
- if (seconds <= 0.0) { // instant timeout
- seconds = 0.0;
- timeout_context->termTSR = 0ULL;
- } else if (seconds <= TIMER_INTERVAL_LIMIT) {
- dispatch_queue_t queue = pthread_main_np() ? __CFDispatchQueueGetGenericMatchingMain() : __CFDispatchQueueGetGenericBackground();
- timeout_timer = dispatch_source_create(DISPATCH_SOURCE_TYPE_TIMER, 0, 0, queue);
- dispatch_retain(timeout_timer);
- timeout_context->ds = timeout_timer;
- timeout_context->rl = (CFRunLoopRef)CFRetain(rl);
- timeout_context->termTSR = startTSR + __CFTimeIntervalToTSR(seconds);
- dispatch_set_context(timeout_timer, timeout_context); // source gets ownership of context
- dispatch_source_set_event_handler_f(timeout_timer, __CFRunLoopTimeout);
- dispatch_source_set_cancel_handler_f(timeout_timer, __CFRunLoopTimeoutCancel);
- uint64_t ns_at = (uint64_t)((__CFTSRToTimeInterval(startTSR) + seconds) * 1000000000ULL);
- dispatch_source_set_timer(timeout_timer, dispatch_time(1, ns_at), DISPATCH_TIME_FOREVER, 1000ULL);
- dispatch_resume(timeout_timer);
- } else {
- // 设置RunLoop超时时间
- seconds = 9999999999.0;
- timeout_context->termTSR = UINT64_MAX;
- }
-
-
- Boolean didDispatchPortLastTime = true;
- int32_t retVal = 0;
- do {
- #if DEPLOYMENT_TARGET_MACOSX || DEPLOYMENT_TARGET_EMBEDDED || DEPLOYMENT_TARGET_EMBEDDED_MINI
- voucher_mach_msg_state_t voucherState = VOUCHER_MACH_MSG_STATE_UNCHANGED;
- voucher_t voucherCopy = NULL;
- #endif
- uint8_t msg_buffer[3 * 1024];
- #if DEPLOYMENT_TARGET_MACOSX || DEPLOYMENT_TARGET_EMBEDDED || DEPLOYMENT_TARGET_EMBEDDED_MINI
- mach_msg_header_t *msg = NULL;
- mach_port_t livePort = MACH_PORT_NULL;
- #elif DEPLOYMENT_TARGET_WINDOWS
- HANDLE livePort = NULL;
- Boolean windowsMessageReceived = false;
- #endif
- __CFPortSet waitSet = rlm->_portSet;
-
-
- __CFRunLoopUnsetIgnoreWakeUps(rl);
-
-
- if (rlm->_observerMask & kCFRunLoopBeforeTimers)
- // 2. 通知 Observers: RunLoop 即将触发 Timer 回调
- __CFRunLoopDoObservers(rl, rlm, kCFRunLoopBeforeTimers);
- if (rlm->_observerMask & kCFRunLoopBeforeSources)
- // 3. 通知 Observers: RunLoop 即将触发 Source 回调
- __CFRunLoopDoObservers(rl, rlm, kCFRunLoopBeforeSources);
- // 执行被加入的block
- __CFRunLoopDoBlocks(rl, rlm);
-
-
- // 4. RunLoop 触发 Source0 (非port) 回调
- Boolean sourceHandledThisLoop = __CFRunLoopDoSources0(rl, rlm, stopAfterHandle);
- if (sourceHandledThisLoop) {
- // 执行被加入的block
- __CFRunLoopDoBlocks(rl, rlm);
- }
-
-
- Boolean poll = sourceHandledThisLoop || (0ULL == timeout_context->termTSR);
-
-
- // 5. 如果有 Source1 (基于port) 处于 ready 状态，直接处理这个 Source1 然后跳转去处理消息
- if (MACH_PORT_NULL != dispatchPort && !didDispatchPortLastTime) {
- #if DEPLOYMENT_TARGET_MACOSX || DEPLOYMENT_TARGET_EMBEDDED || DEPLOYMENT_TARGET_EMBEDDED_MINI
- msg = (mach_msg_header_t *)msg_buffer;
-
-
- if (__CFRunLoopServiceMachPort(dispatchPort, &msg, sizeof(msg_buffer), &livePort, 0, &voucherState, NULL)) {
- goto handle_msg;
- }
- #elif DEPLOYMENT_TARGET_WINDOWS
- if (__CFRunLoopWaitForMultipleObjects(NULL, &dispatchPort, 0, 0, &livePort, NULL)) {
- goto handle_msg;
- }
- #endif
- }
-
-
- didDispatchPortLastTime = false;
-
-
- // 通知 Observers: RunLoop 的线程即将进入休眠(sleep)
- if (!poll && (rlm->_observerMask & kCFRunLoopBeforeWaiting)) __CFRunLoopDoObservers(rl, rlm, kCFRunLoopBeforeWaiting);
- __CFRunLoopSetSleeping(rl);
- // do not do any user callouts after this point (after notifying of sleeping)
-
-
- // Must push the local-to-this-activation ports in on every loop
- // iteration, as this mode could be run re-entrantly and we don't
- // want these ports to get serviced.
-
-
- __CFPortSetInsert(dispatchPort, waitSet);
-
-
- __CFRunLoopModeUnlock(rlm);
- __CFRunLoopUnlock(rl);
-
-
- CFAbsoluteTime sleepStart = poll ? 0.0 : CFAbsoluteTimeGetCurrent();
-
-
- #if DEPLOYMENT_TARGET_MACOSX || DEPLOYMENT_TARGET_EMBEDDED || DEPLOYMENT_TARGET_EMBEDDED_MINI
- #if USE_DISPATCH_SOURCE_FOR_TIMERS
- do {
- if (kCFUseCollectableAllocator) {
- // objc_clear_stack(0);
- //
- memset(msg_buffer, 0, sizeof(msg_buffer));
- }
- msg = (mach_msg_header_t *)msg_buffer;
-
-
- __CFRunLoopServiceMachPort(waitSet, &msg, sizeof(msg_buffer), &livePort, poll ? 0 : TIMEOUT_INFINITY, &voucherState, &voucherCopy);
-
-
- if (modeQueuePort != MACH_PORT_NULL && livePort == modeQueuePort) {
- // Drain the internal queue. If one of the callout blocks sets the timerFired flag, break out and service the timer.
- while (_dispatch_runloop_root_queue_perform_4CF(rlm->_queue));
- if (rlm->_timerFired) {
- // Leave livePort as the queue port, and service timers below
- rlm->_timerFired = false;
- break;
- } else {
- if (msg && msg != (mach_msg_header_t *)msg_buffer) free(msg);
- }
- } else {
- // Go ahead and leave the inner loop.
- break;
- }
- } while (1);
- #else
- if (kCFUseCollectableAllocator) {
- // objc_clear_stack(0);
- //
- memset(msg_buffer, 0, sizeof(msg_buffer));
- }
- msg = (mach_msg_header_t *)msg_buffer;
- __CFRunLoopServiceMachPort(waitSet, &msg, sizeof(msg_buffer), &livePort, poll ? 0 : TIMEOUT_INFINITY, &voucherState, &voucherCopy);
- #endif
-
-
-
-
- #elif DEPLOYMENT_TARGET_WINDOWS
- // Here, use the app-supplied message queue mask. They will set this if they are interested in having this run loop receive windows messages.
- __CFRunLoopWaitForMultipleObjects(waitSet, NULL, poll ? 0 : TIMEOUT_INFINITY, rlm->_msgQMask, &livePort, &windowsMessageReceived);
- #endif
-
-
- __CFRunLoopLock(rl);
- __CFRunLoopModeLock(rlm);
-
-
- rl->_sleepTime += (poll ? 0.0 : (CFAbsoluteTimeGetCurrent() - sleepStart));
-
-
- // Must remove the local-to-this-activation ports in on every loop
- // iteration, as this mode could be run re-entrantly and we don't
- // want these ports to get serviced. Also, we don't want them left
- // in there if this function returns.
-
-
- __CFPortSetRemove(dispatchPort, waitSet);
-
-
- __CFRunLoopSetIgnoreWakeUps(rl);
-
-
- // user callouts now OK again
- __CFRunLoopUnsetSleeping(rl);
-
-
- // 8. 通知 Observers: RunLoop 的线程刚刚被唤醒了
- if (!poll && (rlm->_observerMask & kCFRunLoopAfterWaiting)) __CFRunLoopDoObservers(rl, rlm, kCFRunLoopAfterWaiting);
- // 处理消息
- handle_msg:;
- __CFRunLoopSetIgnoreWakeUps(rl);
-
-
- #if DEPLOYMENT_TARGET_WINDOWS
- if (windowsMessageReceived) {
- // These Win32 APIs cause a callout, so make sure we're unlocked first and relocked after
- __CFRunLoopModeUnlock(rlm);
- __CFRunLoopUnlock(rl);
-
-
- if (rlm->_msgPump) {
- rlm->_msgPump();
- } else {
- MSG msg;
- if (PeekMessage(&msg, NULL, 0, 0, PM_REMOVE | PM_NOYIELD)) {
- TranslateMessage(&msg);
- DispatchMessage(&msg);
- }
- }
-
-
- __CFRunLoopLock(rl);
- __CFRunLoopModeLock(rlm);
- sourceHandledThisLoop = true;
-
-
- // To prevent starvation of sources other than the message queue, we check again to see if any other sources need to be serviced
- // Use 0 for the mask so windows messages are ignored this time. Also use 0 for the timeout, because we're just checking to see if the things are signalled right now -- we will wait on them again later.
- // NOTE: Ignore the dispatch source (it's not in the wait set anymore) and also don't run the observers here since we are polling.
- __CFRunLoopSetSleeping(rl);
- __CFRunLoopModeUnlock(rlm);
- __CFRunLoopUnlock(rl);
-
-
- __CFRunLoopWaitForMultipleObjects(waitSet, NULL, 0, 0, &livePort, NULL);
-
-
- __CFRunLoopLock(rl);
- __CFRunLoopModeLock(rlm);
- __CFRunLoopUnsetSleeping(rl);
- // If we have a new live port then it will be handled below as normal
- }
-
-
-
-
- #endif
- if (MACH_PORT_NULL == livePort) {
- CFRUNLOOP_WAKEUP_FOR_NOTHING();
- // handle nothing
- } else if (livePort == rl->_wakeUpPort) {
- CFRUNLOOP_WAKEUP_FOR_WAKEUP();
- // do nothing on Mac OS
- #if DEPLOYMENT_TARGET_WINDOWS
- // Always reset the wake up port, or risk spinning forever
- ResetEvent(rl->_wakeUpPort);
- #endif
- }
- #if USE_DISPATCH_SOURCE_FOR_TIMERS
- else if (modeQueuePort != MACH_PORT_NULL && livePort == modeQueuePort) {
- CFRUNLOOP_WAKEUP_FOR_TIMER();
-
-
- if (!__CFRunLoopDoTimers(rl, rlm, mach_absolute_time())) {
- // Re-arm the next timer, because we apparently fired early
- __CFArmNextTimerInMode(rlm, rl);
- }
- }
- #endif
- #if USE_MK_TIMER_TOO
- // 9.1 如果一个 Timer 到时间了，触发这个Timer的回调
- else if (rlm->_timerPort != MACH_PORT_NULL && livePort == rlm->_timerPort) {
- CFRUNLOOP_WAKEUP_FOR_TIMER();
- // On Windows, we have observed an issue where the timer port is set before the time which we requested it to be set. For example, we set the fire time to be TSR 167646765860, but it is actually observed firing at TSR 167646764145, which is 1715 ticks early. The result is that, when __CFRunLoopDoTimers checks to see if any of the run loop timers should be firing, it appears to be 'too early' for the next timer, and no timers are handled.
- // In this case, the timer port has been automatically reset (since it was returned from MsgWaitForMultipleObjectsEx), and if we do not re-arm it, then no timers will ever be serviced again unless something adjusts the timer list (e.g. adding or removing timers). The fix for the issue is to reset the timer here if CFRunLoopDoTimers did not handle a timer itself. 9308754
- if (!__CFRunLoopDoTimers(rl, rlm, mach_absolute_time())) {
- // Re-arm the next timer
- __CFArmNextTimerInMode(rlm, rl);
- }
- }
- #endif
- // 9.2 如果有dispatch到main_queue的block，执行block
- else if (livePort == dispatchPort) {
- CFRUNLOOP_WAKEUP_FOR_DISPATCH();
- __CFRunLoopModeUnlock(rlm);
- __CFRunLoopUnlock(rl);
- _CFSetTSD(__CFTSDKeyIsInGCDMainQ, (void *)6, NULL);
- #if DEPLOYMENT_TARGET_WINDOWS
- void *msg = 0;
- #endif
- /**/
- __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__(msg);
- _CFSetTSD(__CFTSDKeyIsInGCDMainQ, (void *)0, NULL);
- __CFRunLoopLock(rl);
- __CFRunLoopModeLock(rlm);
- sourceHandledThisLoop = true;
- didDispatchPortLastTime = true;
- }
- // 9.3 如果一个 Source1 (基于port) 发出事件了，处理这个事件
- else {
- CFRUNLOOP_WAKEUP_FOR_SOURCE();
-
-
- // If we received a voucher from this mach_msg, then put a copy of the new voucher into TSD. CFMachPortBoost will look in the TSD for the voucher. By using the value in the TSD we tie the CFMachPortBoost to this received mach_msg explicitly without a chance for anything in between the two pieces of code to set the voucher again.
- voucher_t previousVoucher = _CFSetTSD(__CFTSDKeyMachMessageHasVoucher, (void *)voucherCopy, os_release);
-
-
- /**/
- CFRunLoopSourceRef rls = __CFRunLoopModeFindSourceForMachPort(rl, rlm, livePort);
- if (rls) {
- #if DEPLOYMENT_TARGET_MACOSX || DEPLOYMENT_TARGET_EMBEDDED || DEPLOYMENT_TARGET_EMBEDDED_MINI
- mach_msg_header_t *reply = NULL;
- sourceHandledThisLoop = __CFRunLoopDoSource1(rl, rlm, rls, msg, msg->msgh_size, &reply) || sourceHandledThisLoop;
- if (NULL != reply) {
- (void)mach_msg(reply, MACH_SEND_MSG, reply->msgh_size, 0, MACH_PORT_NULL, 0, MACH_PORT_NULL);
- CFAllocatorDeallocate(kCFAllocatorSystemDefault, reply);
- }
- #elif DEPLOYMENT_TARGET_WINDOWS
- sourceHandledThisLoop = __CFRunLoopDoSource1(rl, rlm, rls) || sourceHandledThisLoop;
- #endif
- }
-
-
- // Restore the previous voucher
- _CFSetTSD(__CFTSDKeyMachMessageHasVoucher, previousVoucher, os_release);
-
-
- }
- #if DEPLOYMENT_TARGET_MACOSX || DEPLOYMENT_TARGET_EMBEDDED || DEPLOYMENT_TARGET_EMBEDDED_MINI
- if (msg && msg != (mach_msg_header_t *)msg_buffer) free(msg);
- #endif
- // 执行加入到Loop的block
- __CFRunLoopDoBlocks(rl, rlm);
-
-
-
-
- if (sourceHandledThisLoop && stopAfterHandle) {
- // 进入loop时参数说处理完事件就返回
- retVal = kCFRunLoopRunHandledSource;
- } else if (timeout_context->termTSR < mach_absolute_time()) {
- // 超出传入参数标记的超时时间了
- retVal = kCFRunLoopRunTimedOut;
- } else if (__CFRunLoopIsStopped(rl)) {
- __CFRunLoopUnsetStopped(rl);
- // 被外部调用者强制停止了
- retVal = kCFRunLoopRunStopped;
- } else if (rlm->_stopped) {
- rlm->_stopped = false;
- retVal = kCFRunLoopRunStopped;
- } else if (__CFRunLoopModeIsEmpty(rl, rlm, previousMode)) {
- // source/timer一个都没有
- retVal = kCFRunLoopRunFinished;
- }
-
-
- #if DEPLOYMENT_TARGET_MACOSX || DEPLOYMENT_TARGET_EMBEDDED || DEPLOYMENT_TARGET_EMBEDDED_MINI
- voucher_mach_msg_revert(voucherState);
- os_release(voucherCopy);
- #endif
- // 如果没超时，mode里没空，loop也没被停止，那继续loop
- } while (0 == retVal);
-
-
- if (timeout_timer) {
- dispatch_source_cancel(timeout_timer);
- dispatch_release(timeout_timer);
- } else {
- free(timeout_context);
- }
-
- return retVal;
- }
-```
-
-`__CFRunLoopModeIsEmpty`函数的作用就是判断这个 Mode 下面有没有 source0、source1、timer，只要存在就说明当前 Mode 不是空的，同时看看这个 Mode 是不是属于当前的 RunLoop
-
-```objective-c
-// expects rl and rlm locked
- static Boolean __CFRunLoopModeIsEmpty(CFRunLoopRef rl, CFRunLoopModeRef rlm, CFRunLoopModeRef previousMode) {
- CHECK_FOR_FORK();
- if (NULL == rlm) return true;
- #if DEPLOYMENT_TARGET_WINDOWS
- if (0 != rlm->_msgQMask) return false;
- #endif
- Boolean libdispatchQSafe = pthread_main_np() && ((HANDLE_DISPATCH_ON_BASE_INVOCATION_ONLY && NULL == previousMode) || (!HANDLE_DISPATCH_ON_BASE_INVOCATION_ONLY && 0 == _CFGetTSD(__CFTSDKeyIsInGCDMainQ)));
- if (libdispatchQSafe && (CFRunLoopGetMain() == rl) && CFSetContainsValue(rl->_commonModes, rlm->_name)) return false; // represents the libdispatch main queue
- // 判断时候有没有_sources0
- if (NULL != rlm->_sources0 && 0 < CFSetGetCount(rlm->_sources0)) return false;
- // 判断时候有没有_sources1
- if (NULL != rlm->_sources1 && 0 < CFSetGetCount(rlm->_sources1)) return false;
- // 判断时候有没有_timers
- if (NULL != rlm->_timers && 0 < CFArrayGetCount(rlm->_timers)) return false;
-
-
- struct _block_item *item = rl->_blocks_head;
- while (item) {
- struct _block_item *curr = item;
- item = item->_next;
- Boolean doit = false;
- if (CFStringGetTypeID() == CFGetTypeID(curr->_mode)) {
- doit = CFEqual(curr->_mode, rlm->_name) || (CFEqual(curr->_mode, kCFRunLoopCommonModes) && CFSetContainsValue(rl->_commonModes, rlm->_name));
- } else {
- doit = CFSetContainsValue((CFSetRef)curr->_mode, rlm->_name) || (CFSetContainsValue((CFSetRef)curr->_mode, kCFRunLoopCommonModes) && CFSetContainsValue(rl->_commonModes, rlm->_name));
- }
- if (doit) return false;
- }
- return true;
- }
-```
-
-**CFRunLoopRun、CFRunLoopRunInMode**
-
-1、2个函数的作用分别是让 RunLoop 跑在 KCFRunLoopDefaultMode 下和特定的 Mode 下
-
-2、2个函数本质上都是调用 CFRunLoopRunSpecific
-
-```objective-c
- // 用DefaultMode启动
- void CFRunLoopRun(void) { /* DOES CALLOUT */
- int32_t result;
- do {
- result = CFRunLoopRunSpecific(CFRunLoopGetCurrent(), kCFRunLoopDefaultMode, 1.0e10, false);
- CHECK_FOR_FORK();
- } while (kCFRunLoopRunStopped != result && kCFRunLoopRunFinished != result);
- }
-
-
- // 用指定的Mode启动，允许设置RunLoop超时时间
- SInt32 CFRunLoopRunInMode(CFStringRef modeName, CFTimeInterval seconds, Boolean returnAfterSourceHandled) { /* DOES CALLOUT */
- CHECK_FOR_FORK();
- return CFRunLoopRunSpecific(CFRunLoopGetCurrent(), modeName, seconds, returnAfterSourceHandled);
- }
-```
-
-
-
-RunLoop 内部几个核心的动作：`__CFRunLoopDoObservers`、`__CFRunLoopServiceMachPort` 、`__CFRunLoopDoTimers` 方法内部实现调用的还是 `__CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__`、`__CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__` 等方法，均以 `__CFRUNLOOP_IS_CALLING_OUT_TO_` 方法名作为开头。可以在堆栈上得以体现。
-
-
-
-### 运行流程
-
-上面结合源码看了 Runloop 是怎么运行的。下面通过图片看看 RunLoop 各个状态运行切换的完整流程。
-
-
-
-Demo：
-
-1. 上面第4步的 blocks 是指可以给 RunLoop 添加 Block 任务。
-
- ```objective-c
- CFRunLoopPerformBlock(CFRunLoopGetMain(), kCFRunLoopDefaultMode, ^{
- NSLog(@"runloop block task");
- });
- ```
-
-2. 上面8>2，Runloop 处理 GCD Async To Main Quque
-
- 
-
-
-
-
-
-
-
-### RunLoop 休眠原理
-
-> Runloop 在处理完 timer、source、block 后会检查有没有 source1 事件，没有则休眠。这个休眠是 while 循环死等吗？怎么实现的？
-
-可以在 App 运行过程中，点击 Xcode 左下角的 debug 暂停按钮，可以看到 App 堆栈存在系统调用
-
-
-
-
-
-本质上就是函数 `__CFRunLoopServiceMachPort` 来控制实现休眠。查看 CFRunLoop.c 源码可以发现，是由 `mach_msg` 实现的。不是平时的在应用层 API 上 sleep 休眠的。比如 while 循环。
-
-**`mach_msg` 休眠是从用户态切换到内核态，内核 api 控制休眠，做到真正节省资源的作用，等到由新消息来到，继续切换到用户态**。能力更底层，效果更好，从而更加省电
-
-```c
-static Boolean __CFRunLoopServiceMachPort(mach_port_name_t port, mach_msg_header_t **buffer, size_t buffer_size, mach_port_t *livePort, mach_msg_timeout_t timeout, voucher_mach_msg_state_t *voucherState, voucher_t *voucherCopy) {
- Boolean originalBuffer = true;
- kern_return_t ret = KERN_SUCCESS;
- for (;;) { /* In that sleep of death what nightmares may come ... */
- mach_msg_header_t *msg = (mach_msg_header_t *)*buffer;
- msg->msgh_bits = 0;
- msg->msgh_local_port = port;
- msg->msgh_remote_port = MACH_PORT_NULL;
- msg->msgh_size = buffer_size;
- msg->msgh_id = 0;
- if (TIMEOUT_INFINITY == timeout) { CFRUNLOOP_SLEEP(); } else { CFRUNLOOP_POLL(); }
- ret = mach_msg(msg, MACH_RCV_MSG|(voucherState ? MACH_RCV_VOUCHER : 0)|MACH_RCV_LARGE|((TIMEOUT_INFINITY != timeout) ? MACH_RCV_TIMEOUT : 0)|MACH_RCV_TRAILER_TYPE(MACH_MSG_TRAILER_FORMAT_0)|MACH_RCV_TRAILER_ELEMENTS(MACH_RCV_TRAILER_AV), 0, msg->msgh_size, port, timeout, MACH_PORT_NULL);
-
- // Take care of all voucher-related work right after mach_msg.
- // If we don't release the previous voucher we're going to leak it.
- voucher_mach_msg_revert(*voucherState);
-
- // Someone will be responsible for calling voucher_mach_msg_revert. This call makes the received voucher the current one.
- *voucherState = voucher_mach_msg_adopt(msg);
-
- if (voucherCopy) {
- if (*voucherState != VOUCHER_MACH_MSG_STATE_UNCHANGED) {
- // Caller requested a copy of the voucher at this point. By doing this right next to mach_msg we make sure that no voucher has been set in between the return of mach_msg and the use of the voucher copy.
- // CFMachPortBoost uses the voucher to drop importance explicitly. However, we want to make sure we only drop importance for a new voucher (not unchanged), so we only set the TSD when the voucher is not state_unchanged.
- *voucherCopy = voucher_copy();
- } else {
- *voucherCopy = NULL;
- }
- }
-
- CFRUNLOOP_WAKEUP(ret);
- if (MACH_MSG_SUCCESS == ret) {
- *livePort = msg ? msg->msgh_local_port : MACH_PORT_NULL;
- return true;
- }
- if (MACH_RCV_TIMED_OUT == ret) {
- if (!originalBuffer) free(msg);
- *buffer = NULL;
- *livePort = MACH_PORT_NULL;
- return false;
- }
- if (MACH_RCV_TOO_LARGE != ret) break;
- buffer_size = round_msg(msg->msgh_size + MAX_TRAILER_SIZE);
- if (originalBuffer) *buffer = NULL;
- originalBuffer = false;
- *buffer = realloc(*buffer, buffer_size);
- }
- HALT;
- return false;
-}
-```
-
-
-
-### RunLoop 是如何响应用户操作的？
-
-用户交互事件首先在 IOHID 层生成 HIDEvent，然后向事件处理线程的 Source1 的 mach port 发送 HIDEvent 消息，Source1 的回调函数将事件转化为 UIEvent 并筛选需要处理的事件推入待处理事件队列，向主线程的事件处理 Source0 发送信号，并唤醒主线程，主线程检查到事件处理 Source0 有待处理信号后，触发 Source0 的回调函数，从待处理事件队列中提取 UIEvent，最后进入 hit-test 等 UIEvent 事件响应流程
-
-等待梳理完善。
-
-
-
-## CFRunLoopTimerRef 是基于时间的触发器
-
-- 基本上说就是 NSTimer，它会收到 RunLoopMode 的影响
-- GCD 的 timer 不受 RunLoopMode 的影响
-
-## 源码解读
-
-- performSelector 是在 source0 上实现的
-- RunLoopTimer 外部接口设置的精度，精度大于0，则使用 dispatch_source_set_timer，精度小于0，则使用 mk_timer_arm
-- timer_source 使用 dispatch_timer_STRICT 创建，则系统会尽最大努力遵守设置的 leeway 值
-- NSTimer 不准的原因：底层 RunLoop Timer 底层使用的 timer 的精度不高（mk_timer）；与 RunLoop 底层的调用机制有关系
-- 那么为什么存在 RunLoopTimer？意义是什么？应用场景
-
-```c
-// Data structure to hold TSD data, cleanup functions for each
-typedef struct __CFTSDTable {
- uint32_t destructorCount;
- uintptr_t data[CF_TSD_MAX_SLOTS];
- tsdDestructor destructors[CF_TSD_MAX_SLOTS];
-} __CFTSDTable;
-```
-
-```c
-// 主线程 RunLoop
-CFRunLoopRef CFRunLoopGetMain(void) {
- CHECK_FOR_FORK();
- // 局部静态变量
- static CFRunLoopRef __main = NULL; // no retain needed
- // 创建主线程对应的 RunLoop
- if (!__main) __main = _CFRunLoopGet0(pthread_main_thread_np()); // no CAS needed
- return __main;
-}
-
-// 子线程 RunLoop
-// 先从 __CFTSDTable 获取 RunLoop，如果有则 return，没有则调用 _CFRunLoopGet0，_CFRunLoopGet0 内部调用 __CFRunLoopCreate 创建 CFRunLoop，然后写入 __CFTSDTable
-CFRunLoopRef CFRunLoopGetCurrent(void) {
- CHECK_FOR_FORK();
- // __CFTSDTable
- CFRunLoopRef rl = (CFRunLoopRef)_CFGetTSD(__CFTSDKeyRunLoop);
- if (rl) return rl;
- // 没有则创建
- return _CFRunLoopGet0(pthread_self());
-}
-
-CF_EXPORT CFRunLoopRef _CFRunLoopGet0(_CFThreadRef t) {
- if (pthread_equal(t, kNilPthreadT)) {
- t = pthread_main_thread_np();
- }
- __CFLock(&loopsLock);
- if (!__CFRunLoops) {
- CFMutableDictionaryRef dict = CFDictionaryCreateMutable(kCFAllocatorSystemDefault, 0, NULL, &kCFTypeDictionaryValueCallBacks);
- CFRunLoopRef mainLoop = __CFRunLoopCreate(pthread_main_thread_np());
- CFDictionarySetValue(dict, pthreadPointer(pthread_main_thread_np()), mainLoop);
- if (!OSAtomicCompareAndSwapPtrBarrier(NULL, dict, (void * volatile *)&__CFRunLoops)) {
- CFRelease(dict);
- }
- CFRelease(mainLoop);
- }
- CFRunLoopRef newLoop = NULL;
- CFRunLoopRef loop = (CFRunLoopRef)CFDictionaryGetValue(__CFRunLoops, pthreadPointer(t));
- if (!loop) {
- newLoop = __CFRunLoopCreate(t);
- CFDictionarySetValue(__CFRunLoops, pthreadPointer(t), newLoop);
- loop = newLoop;
- }
- __CFUnlock(&loopsLock);
- // don't release run loops inside the loopsLock, because CFRunLoopDeallocate may end up taking it
- if (newLoop) { CFRelease(newLoop); }
-
- if (pthread_equal(t, pthread_self())) {
- _CFSetTSD(__CFTSDKeyRunLoop, (void *)loop, NULL);
- if (0 == _CFGetTSD(__CFTSDKeyRunLoopCntr)) {
-#if _POSIX_THREADS
- _CFSetTSD(__CFTSDKeyRunLoopCntr, (void *)(PTHREAD_DESTRUCTOR_ITERATIONS-1), (void (*)(void *))__CFFinalizeRunLoop);
-#else
- _CFSetTSD(__CFTSDKeyRunLoopCntr, 0, &__CFFinalizeRunLoop);
-#endif
- }
- }
- return loop;
-}
-```
-
-为什么只有当 RunLoop 中存在 Timer Sourcrs、Input Sources 时，才能保证 RunLoop 不退出？
-
-RunLoop 本质就是一个有条件的 do...while 循环。__CFRunLoopModeIsEmpty 里面去判断 source0、source1、timers 不存在则 while 循环条件不满足，RunLoop 退出
-
-```c
-void CFRunLoopRun(void) { /* DOES CALLOUT */
- int32_t result;
- do {
- result = CFRunLoopRunSpecific(CFRunLoopGetCurrent(), kCFRunLoopDefaultMode, 1.0e10, false);
- CHECK_FOR_FORK();
- } while (kCFRunLoopRunStopped != result && kCFRunLoopRunFinished != result);
-}
-
-// expects rl and rlm locked
-static Boolean __CFRunLoopModeIsEmpty(CFRunLoopRef rl, CFRunLoopModeRef rlm, CFRunLoopModeRef previousMode) {
- // ...
- if (NULL != rlm->_sources0 && 0 < CFSetGetCount(rlm->_sources0)) return false;
- if (NULL != rlm->_sources1 && 0 < CFSetGetCount(rlm->_sources1)) return false;
- if (NULL != rlm->_timers && 0 < CFArrayGetCount(rlm->_timers)) return false;
- // ...
- return true;
-}
-```
-
-```c
-SInt32 CFRunLoopRunSpecific(CFRunLoopRef rl, CFStringRef modeName, CFTimeInterval seconds, Boolean returnAfterSourceHandled) { /* DOES CALLOUT */
-// ...
-CFRunLoopModeRef currentMode = __CFRunLoopFindMode(rl, modeName, false);
-if (NULL == currentMode || __CFRunLoopModeIsEmpty(rl, currentMode, rl->_currentMode)) {
- Boolean did = false;
- if (currentMode) __CFRunLoopModeUnlock(currentMode);
- __CFRunLoopUnlock(rl);
- return did ? kCFRunLoopRunHandledSource : kCFRunLoopRunFinished;
-}
-// ...
-```
-
-
-
-## Mach Port 跨线程通信
-
-1. Mach IPC 基于 Mach 内核实现进程间通讯。
-
-2. Mach IPC 被抽象为3种操作：messages、ports、and port sets
-
-3. Mach port 跨线程通信
-
- 线程 B 有个 port 在等待消息，具有消息接收权限，等待消息到来的时候会阻塞当前线程
-
- 线程 A 有个 port 在发送消息，具有发送消息权限，要把发送的消息包装成消息，通过消息队列传递，message 包括：header（目的地 port、size）、data。
-
- 线程 B 收到消息后，解除 block，线程继续向下运行
-
-4. Mach port 如何进行跨线程通信？
-
- 线程开启一个 port，然后给 port 申请接收、发送的权限。mach_msg 是通信函数，在等待消息的时候不加 timeout 则会一直阻塞，等到消息到来
-
-5. 在测试工作中 main.m 文件中打印当前的 RunLoop
-
- ```objectivec
- int main(int argc, char * argv[]) {
- NSString * appDelegateClassName;
- @autoreleasepool {
- appDelegateClassName = NSStringFromClass([AppDelegate class]);
- }
- NSLog(@"%@", NSRunLoop.currentRunLoop);
- return UIApplicationMain(argc, argv, nil, appDelegateClassName);
- }
-
- //
- 2020-08-13 09:49:41.326621+0800 ***[52423:2383402] {wakeup port = 0x1103, stopped = false, ignoreWakeUps = true,
- current mode = (none),
- common modes = {type = mutable set, count = 1,
- entries =>
- 2 : {contents = "kCFRunLoopDefaultMode"}
- }
- ,
- common mode items = (null),
- modes = {type = mutable set, count = 1,
- entries =>
- 2 : {name = kCFRunLoopDefaultMode, port set = 0x1003, queue = 0x6000007f0100, source = 0x6000007f0280 (not fired), timer port = 0xe03,
- sources0 = (null),
- sources1 = (null),
- observers = (null),
- timers = (null),
- currently 618976181 (257342842892563) / soft deadline in: 1.84464867e+10 sec (@ -1) / hard deadline in: 1.84464867e+10 sec (@ -1)
- },
- }
- }
- ```
-
- 可以看到 main.m 中，还没有 return 的时候当前 RunLoop 的内部结构中存在一个 **wakeup port** 的端口。查看 RunLoop 源代码 **wakeup port** 就是 mach port 的一种。
-
- ```c
- typedef mach_port_t __CFPort;
-
- struct __CFRunLoop {
- CFRuntimeBase _base;
- _CFRecursiveMutex _lock; /* locked for accessing mode list */
- __CFPort _wakeUpPort; // used for CFRunLoopWakeUp
- Boolean _unused;
- volatile _per_run_data *_perRunData; // reset for runs of the run loop
- _CFThreadRef _pthread;
- uint32_t _winthread;
- CFMutableSetRef _commonModes;
- CFMutableSetRef _commonModeItems;
- CFRunLoopModeRef _currentMode;
- CFMutableSetRef _modes;
- struct _block_item *_blocks_head;
- struct _block_item *_blocks_tail;
- CFAbsoluteTime _runTime;
- CFAbsoluteTime _sleepTime;
- CFTypeRef _counterpart;
- _Atomic(uint8_t) _fromTSD;
- CFLock_t _timerTSRLock;
- };
- ```
-
- ```c
- void CFRunLoopWakeUp(CFRunLoopRef rl) {
- // ...
- kern_return_t ret;
- /* We unconditionally try to send the message, since we don't want
- * to lose a wakeup, but the send may fail if there is already a
- * wakeup pending, since the queue length is 1. */
- ret = __CFSendTrivialMachMessage(rl->_wakeUpPort, 0, MACH_SEND_TIMEOUT, 0);
- // ...
- int ret;
- do {
- ret = eventfd_write(rl->_wakeUpPort, 1);
- } while (ret == -1 && errno == EINTR);
- // ...
- SetEvent(rl->_wakeUpPort);
- // ...
- }
- ```
-
- `CFRunLoopWakeUp(CFRunLoopGetCurrent());` 可以唤醒 RunLoop，函数的底层实现如上。核心实现就是 `__CFSendTrivialMachMessage` 函数。在iOS 中，除了 source1 可以自己唤醒 RunLoop 之外，其他的事件都需要用户手动唤醒 RunLoop 才可以。RunLoop 提供了专门的方法来实现这个功能。其核心部分就是调用 mach_msg 来向指定的 **_wakeUpPort** 端口发送消息，从而唤醒线程继续工作。
-
- 为什么 Source1 可以唤醒 RunLoop？因为 Source1 本质上就是针对 Mach Port 的封装
-
-6. 做个实验检测 _wakeUpPort 端口
-
- ```objective-c
- - (void)viewDidLoad {
- [super viewDidLoad];
- [self listenWakeUpPort];
- }
-
- - (void)listenWakeUpPort
- {
- NSArray
转换JS Bundle]; - B --> C[JS Framework
解析并管理Virtual DOM]; - C -- 通过JS Bridge发送渲染指令 --> D[Native SDK
渲染引擎]; - D --> E[iOS/Android/Web 原生视图]; - - C -- 支持多种DSL --> F[Vue.js]; - C -- 支持多种DSL --> G[Rax（类React）]; - D -- 原生能力扩展 --> H[自定义Component]; - D -- 原生能力扩展 --> I[自定义Module]; -``` - -Weex 最核心的设计是将整个框架清晰地分为：**语法层（DSL）**、**中间层（JS Framework）**和**渲染层（Native SDK）** - -这种渲染引擎和语法层 DSL 分离的设计，可以使得上层 DSL 方便拓展 Vue、Rax 写法，下层渲染引擎可以保持较好的稳定性。为了生态的拓展提供了极大的便携性。 - - - -### 3. 可扩展的组件与模块系统 - -Weex 通过`WXSDKEngine.registerComponent()` 和 `registerModule()` 方法，允许开发者扩展原生组件 （UI Component）和模块（Login Module）。这套机制设计得足够底层和通用，使得 Weex 可以由开发者来注册，由公司内的体验设计中心规范来落地的组件。以及一些基础能力。这样子 Weex 官方已经提供了一些功能强大的筋骨，我们在其之上可以提供更符合需求的外表和更有力量的一块手臂肌肉。 - -虽然事后视角来看，Weex、RN、Flutter，甚至是更早的、设计完善的 Hybrid 都有该能力。但这对于远古时期的 Weex 来说，还是可圈可点的。 - - - -### 4. 轻量 JSBundle + 增量更新支持 - -Weex 的 JSBundle 仅包含业务逻辑和组件描述，框架代码（Vue 内核、Weex 基础 API）内置在原生 SDK 中，因此 Bundle 体积极小；同时支持将 Bundle 拆分为 “基础包（公共逻辑）+ 业务包（页面逻辑）”，实现增量更新。 - -解决了跨端框架 “首屏加载慢” 的痛点（小 Bundle 加载更快），同时增量更新降低了发布成本。 - - - -## 十一、Weex APM - -### 1. 历史背景 -Weex 是诸多年前的产物，部分业务线用 Weex 写了部分功能模块，或者是某几个页面，或者是某个二级、三级业务 SDK 的页面。但可以确定的是： -- 21年就完成了 Flutter 的基建开发（对齐 Native 的 UI 组件库，遵循体验设计平台产出的集团 UI 标准；做了 Flutter 的大量 plugin、打包构建平台、日志库、网络库、探照灯、APM SDK、热修复能力等）。新业务的实现只会在 Native 和 Flutter 上考虑 -- Weex 业务代码基本上是存量的 -- Weex 代码没有 bug 就不去修改；有版本迭代，之前是 Weex 实现的，本次只做简单 UI 增删或字段调整，也是会修改一下。除此之外不修改 Weex 代码 - -所以像 Native 一样去全面监控性能、网络、crash、异常、白屏、页面加载耗时等维度的话，ROI 是很低的。那么就需要制定一些策略去有针对性的监控高优问题。 - -Weex 的异常比较有特点，比如在页面的模版代码中绑定了 data 中的一个对象，此时对象可能并没有值，而是依赖后续的网络请求完成，对象才有了具体的值 data 改变，数据驱动，页面再次 render。所以监控代码会认为第一次 render 的时候访问对象不存在的属性。 -真正有问题的代码和不影响业务的异常信息，都会被 Vue 官方认为是异常。基于这样的背景，我们无法 pick 出真正异常或者是开发者判空代码没写好的问题。基于此，我们需要做一些约定和标准。 - -### 2. 优先级权衡标准 -这时候就需要摒弃程序员视角（不然会陷入啥数据都想统计，可能是洁癖、可能是追求），但从 ROI 角度出发，我们就需要切换到用户视角。 - -假设你是一个用户，什么样的情况代表业务异常，对我们的用户来说比较痛呢？ -- 页面白屏了，看都看不到了，别说你们的 App 为我赋能解决用户痛点了 -- 稍微好点，可以看到页面了，但是某一个区域是白屏的。比如：该页面大部分在展示商品价格、商品数量、商品折扣价、商品折扣信息、下面应该是有个“确认支付”按钮，但是此处就是空白，点也点不了。 -- 情况再好点。可以看到全部的页面了，但是点击后无响应。比如：该页面大部分在展示商品价格、商品数量、商品折扣价、商品折扣信息、下面有个“确认支付”按钮。用户在考虑再三，本着理性购物后，发现是刚需品，咬紧牙要付款了，此时点击“确认支付”按钮了，但是页面没有任何反应。用户也是“见多识广”的体面人，猜测可能是网络不好的情况，所以等了1分钟，他很有耐心。切换了 WI-FI 到 5G 后，继续点击，依旧没反应。一怒之下点了10次，等了2分钟，还是没反应。他奔溃了，卸载了 App - -上述几种情况，总结为：按照异常等级，可以划分为影响业务和不影响业务。什么叫“影响业务”？这是我们自己定义的标准，影响用户是否正常操作 App。比如：页面白屏（页面全部白屏、页面部分白屏）、点击某个按钮无响应，这些叫做“影响业务”，属于 Error 级别。其他的一些轻微异常，不影响用户使用 App 功能，不影响业务，属于 Warning 级别。 - - - -### 3. UI 显示异常 -#### 1. 部分白屏：注册的 Component 使用异常 -这种情况就属于页面部分白屏。因为某个哪个 Compoent 会铺满页面，基本类似 iOS UI 控件一样组合使用。就像上文描述的「该页面大部分在展示商品价格、商品数量、商品折扣价、商品折扣信息、下面应该是有个“确认支付”按钮，但是此处就是空白」这个空白粗，理应显示一个 Native 注册的 Button，但是没有显示出来，造成业务的阻塞。 - - -.vue（或 Weex 专属.we）文件内基于 Vue 扩展的 Weex 跨平台模板 DSL 代码，在前端构建阶段会先由 Webpack 的weex-loader触发编译流程：首先通过 Weex 核心编译器@weex-cli/compiler（复用并扩展vue-template-compiler）将模板 DSL 解析为模板 AST（抽象语法树）；接着由 Weex 自定义 Babel 插件（如babel-plugin-transform-weex-template）将模板 AST 转换为标准化的 JS AST，并针对 iOS/Android 跨平台特性做属性、样式、事件的适配处理（如样式单位归一化、事件名标准化）；最终生成包含_h（即 Weex 运行时的$createElement，等价于 Vue 的createElement）调用的render函数，该函数会被 Webpack 打包到最终的 Weex JS Bundle 中。 - -```json -_c('color-button', - { - staticStyle: { - width: "400px", - height: "40px", - marginBottom: "20px" - }, - attrs: { - "title": "点击计算10+20", - "bgColor": "#FF6600", - "message": "hello" - }, - on: { - "click": _vm.handleButtonClick - } - }, - // 如果有 children 就是 children 信息 -) -``` - -在 App 运行阶段，Weex 的 JS 引擎（iOS 端为 JSCore、Android 端为 V8）加载 JS Bundle 后，执行组件的render函数，通过调用 `_h` 函数将模板描述转换为跨平台的虚拟 DOM（VNode），VNode 会被序列化为 JSON 格式，最终通过 JS Bridge 传递给 Native 端（iOS/Android）用于原生视图渲染。 - - -Weex 的 Component 相关逻辑都由 `WXComponentManager` 负责。页面在构建展示的时候，会调用 `_buildComponent` 方法，其内部会调用 WXComponentFactory 的能力（`configWithComponentName`），根据 ComponentName 获取 Component。 - -`configWithComponentName` 是 Weex iOS 侧 WXComponentFactory（组件工厂类）的核心方法之一，核心作用是：根据传入的组件名称（如 color-button/div/text），查找该组件对应的 Native 侧配置（WXComponentConfig）；若找不到对应配置，则降级使用基础容器组件 div 的默认配置，并输出警告日志。 -```Objective-C -- (WXComponentConfig *)configWithComponentName:(NSString *)name -{ - WXAssert(name, @"Can not find config for a nil component name"); - - WXComponentConfig *config = nil; - - [_configLock lock]; - config = [_componentConfigs objectForKey:name]; - if (!config) { - WXLogWarning(@"No component config for name:%@, use default config", name); - config = [_componentConfigs objectForKey:@"div"]; - } - [_configLock unlock]; - - return config; -} -``` -UI Component 做的比较随意，认为显示问题降级用 div 就可以了。做为 SDK 这么设计也似乎可以接受，但作为业务方，我们必须收集统计这种异常情况。 -所以此处我们可以收集案发现场数据，进行上报。我们发现 Weex 自己封装了 `WXExceptionUtils`类，暴露了 `commitCriticalExceptionRT` 接口，用于收集致命问题。 - -```Objective-C -+ (void)commitCriticalExceptionRT:(WXJSExceptionInfo *)jsExceptionInfo{ - - WXPerformBlockOnComponentThread(^ { - id
-
-效果：线上低概率异常的根源被提前消灭，问题无法逃逸到现线上，业务层几乎无需处理这类异常（因为代码本身就没有漏洞）
-
-关于如何编写 LLVM 插件，做到在 Xcode 中实时展示代码中存在的问题，可以查看：[LLVM 插件](https://github.com/FantasticLBP/knowledge-kit/blob/master/Chapter1%20-%20iOS/1.102.md) 这篇文章。
-
-
-
-### 方案 4：轻量级熔断 / 降级（适合核心业务场景）
-
-对于 “万分之一” 但影响大的异常（如支付金额计算、商品价格），采用「熔断策略」：
-第一次出现异常：上报 + 降级为默认值（如价格显示 “--”）；
-短时间内多次出现（如 1 分钟内 > 3 次）：触发熔断，建议：展示兜底 UI，提示安抚用户，稍等片刻后尝试（起码不会发生稳定的 crash 或者业务异常）
-熔断状态上报 APM，研发收到告警后优先修复。
-
-### 方案 5：语义化默认值 + 业务无感知适配（美团 / 饿了么实践）
-
-返回**业务可识别的语义化空值**，并在 UI 层做统一适配：
-
-| 异常场景 | 兜底值 | UI 层统一处理 | 业务层感知 |
-| ---------------- | -------- | --------------- | ---------- |
-| 数组越界 | NSNull | 显示 “--” | 无 |
-| 字典 key 为 nil | NSNull | 显示 “暂无数据” | 无 |
-| 分母为 0 | INFINITY | 显示 “计算异常” | 无 |
-| 字符串转数字失败 | NSNull | 显示 “--” | 无 |
-
-**实现方式**：
-
-- 封装全局 UI 工具类（如`WXUILabel+Safe.h`），重写`setText:`方法：
-
-```objective-c
-- (void) safe_setText:(id)text {
- if (text == [NSNull null] || text == nil) {
- self.text = @"--";
- } else if ([text isKindOfClass:[NSNumber class]] && isinf([text doubleValue])) {
- self.text = @"计算异常";
- } else {
- self.text = [text description];
- }
-}
-```
-
-业务层只需使用`safe_setText:`，无需为每个异常场景写判断逻辑。
-
-
-
-## 四、最佳实践
-
-1. **开发环境零容忍**：通过静态分析、自定义 LLVM 插件 + 运行时 Hook，让问题在测试阶段暴露，比如异常发生时，通过日志打印案发现场数据，或者在 Xcode 面板上可视化的在有问题的代码地方显示 error，及时 crash 掉，阻塞正常流程，以防止开发偷懒不去及时修复，产生技术债，同时也防止问题逃逸到线上。
-2. **生产环境软兜底**：不要一刀切，做到可配置。业务方在配置平台可以针对不同业务域的配置，决定是否开启兜底展示（某些业务域的架构师可能更严格，需要开发在 debug 阶段解决这些问题，线上如果出现就统计为 crash）。如果开启，那么安全气垫就返回语义化默认值（而非无意义的 0），全局 UI 统一处理，业务层零侵入；
-3. **可观测驱动修复**：APM 平台统计异常频率 / 影响度，优先处理高频高影响的异常；
-4. **核心场景按需关注**：仅对价格、支付等核心场景注册回调，非核心场景无需处理。
-
-虽然机制和策略已经制定了，但是执行还是靠人，难以保证100%解决问题。所以开发解决通过 lint 和 crash 可以拦截到大部分问题，但是逃逸到线上的部分问题，还是需要安全气垫去 cover，线下无限毕竟去清空问题 + 少数逃逸到线上的问题通过安全气垫去 cover 就可以保证相对全面的安全守护。
-
-
-
-## 五、平台做些什么
-
-获取到 问题数据是第一步，获取之后问题需要及时上报，需要有一个数据上报系统，数据及时准确、高效的上传到服务端（这就是另一个命题，可以查看这篇文章：[打造一个通用、可配置、多句柄的数据上报 SDK](https://github.com/FantasticLBP/knowledge-kit/blob/master/Chapter1%20-%20iOS/1.80.md)），到 APM 后台。后台产生工单，根据业务模块分配到对应的责任人、群组。根据问题的紧急程度，报警策略和提醒频次也不一样，比如**波动报警、自定义报警策略等（这也是另一个命题：智能报警策略、波动报警策略、业务线自定义可配置责任人等）**。责任人及时解决问题、修改工单状态、热修复或者发布新版本，问题闭环。
-
-线上异常上报后，APM 平台需提供：
-
-- 异常频率（如 “数组越界” 仅 1/10000）；
-- 影响用户数（如仅影响 10 个用户）；
-- 业务上下文（如 “商品详情页 - 价格数组”）；
-- 调用栈 + 设备信息。
-
-**核心逻辑**：
-
-- 低频率、低影响的异常（如 1/10000，影响 10 用户）：暂时无需业务层处理，研发排期修复即可；
-- 高频率、高影响的异常（如 1/100，影响 1000 用户）：触发告警，研发紧急修复，业务层临时加兜底。
-
-这样业务开发无需为 “万分之一” 的异常写逻辑，仅需处理 “高频高影响” 的异常。
-
-
-
-## 总结
-
-“最佳实践”部分选择的方案既避免了 “安全气垫返回错误值导致业务异常”，又解决了 “业务开发为低概率异常写冗余逻辑” 的问题，是网易、腾讯、阿里等大厂的通用实践 ——**优雅的方案不是 “兜底所有异常”，而是 “让异常可被提前发现、可被观测、最小化影响”**，即使少数逃逸到线上的，再由安全气垫去兜底解决（解决了展示问题、异常上报和案发现场还原问题），一个好的 APM 平台不光是告诉你又问题，还会告诉你哪里有问题。
-
diff --git a/Chapter1 - iOS/1.15.md b/Chapter1 - iOS/1.15.md
deleted file mode 100644
index 9efffd5..0000000
--- a/Chapter1 - iOS/1.15.md
+++ /dev/null
@@ -1,54 +0,0 @@
-
-# URL Schemes 的发展
-
-
-
-URL Schemes 的发展过程可以说就是 iOS 效率工具类 App 的发展过程。
-
-起初的苹果建立的 Apple URL Schemes 只是用于自用，里面只有邮件、电话、iTunes 搜索、Youtube 视频等一些内置服务的 URL。
-
-个人认为 URL Schemes 第一次大火是在 2011 年末（如有异议欢迎指正），那个时期也是越狱的鼎盛时期，那个时期越狱后大家都会装的一个插件是 SBSettings[1]。越狱的人都知道每当新系统发布的时候，等待新系统的越狱发布是最撩人的，而这段时期那些「不越狱就能做到某种越狱功能」的应用经常一时间风头无两。
-
-2011年 iOS 5 发布带来了通知中心，没过多久，出现了一大批使用 iOS 系统设置的 URL Schemes 的 App 神奇地完成了接近 SBSettings 的功能——它们可以让我们从通知中心直接跳转到某些 App 的特定界面，比如 Twitter 的发推界面。它们甚至还可以直接跳转到系统设置里的 Wi-Fi 选项。在这一批 App 中，就有如今效率软件霸主之一 Launch Center Pro 的前身——Launch Center。
-
-
-
-## 基本 URL Schemes
-
-基本 URL Schemes 的能力虽然简单有限，但使用情境却是最普遍的。
-
-我所谓的基本 URL Schemes，是指一个 URL 的 Schemes 部分，比如上文提到的微信的 weixin:。这个部分的唯一功能，就是打开相应应用，而不能够跳转到任何功能。
-
-绝大多数所谓支持 URL Schemes 的应用，一般都是只有这么一个部分，它一般是这个应用的名称，比如 OmniFocus 这款应用，它的基本 URL Schemes 就是 Omnifocus:。如果应用的主名称是个中文名的话，它的 URL Schemes 也许会是应用名的拼音，比如 墨客 这款应用，它的基本 URL Schemes 是 moke:。
-
-但，我前面提过了网页 URL 和 iOS 应用的 URL 的三个重要区别，其中第三项，就是 iOS 上的 URL Schemes 并不规范，一个应用的 URL 可以是各种各样的：
--
-
- Coursera 的 URL 是：coursera-mobile: -
- Duet 这款游戏的 URL 是：x-kumo-duet: -
- Monument 这款游戏的 URL 是：fb690517270143345: -
- Feedly 的 URL 是：fb129765800430121: -
- 扇贝新闻的 URL 是：wx95962d02b9c3e2f7: -
-
-
- 首先，在 iTunes 找到你想用 URL 打开的 App，右键选择在文件夹中显示： -
- 然后解压该文件： -
- 解压完毕后，在解压出的文件夹中，找到 .app 文件： -
- 然后选择显示包内容： -
- 找到 info.plist 这个文件，用你电脑里能打开它的 App 打开它（Xcode没得说）。 -
- 然后查找 URLSchemes： -
- 在 CFBundleURLSchemes 下的那两行就是该 App 的基本 URL Schemes 了。 -
diff --git a/Chapter1 - iOS/1.17.md b/Chapter1 - iOS/1.17.md
deleted file mode 100644
index aec3fd6..0000000
--- a/Chapter1 - iOS/1.17.md
+++ /dev/null
@@ -1,10 +0,0 @@
-# 对于不可调节高度的UI控件进行改变frame
-
-* 对于不能调节高度的控件比如 UISlider、UISwitch、UIProgressView 等控件的宽高可以用 \(仿射变化\)transform 属性控制高度。
-
-```
-myswitch.transform = CGAffineTransformMakeScale(1,5);
-```
-
-
-
diff --git a/Chapter1 - iOS/1.18.md b/Chapter1 - iOS/1.18.md
deleted file mode 100644
index ab99ba4..0000000
--- a/Chapter1 - iOS/1.18.md
+++ /dev/null
@@ -1,193 +0,0 @@
-# 简单的 Model 与 JSON 相互转换
-
-```
-// JSON:
-{
-"uid":123456,
-"name":"Harry",
-"created":"1965-07-31T00:00:00+0000"
-}
-
-// Model:
-@interface User : NSObject
-@property UInt64 uid;
-@property NSString *name;
-@property NSDate *created;
-@end
-@implementation User
-@end
-
-// 将 JSON (NSData,NSString,NSDictionary) 转换为 Model:
-User *user = [User yy_modelWithJSON:json];
-// 将 Model 转换为 JSON 对象:
-NSDictionary *json = [user yy_modelToJSONObject];
-
-```
-
-
-### Model 属性名和 JSON 中的 Key 不相同
-
-```
-// JSON:
-{
- "n":"Harry Pottery",
- "p": 256,
- "ext" : {
- "desc" : "A book written by J.K.Rowing."
- },
- "ID" : 100010
-}
-
-// Model:
-@interface Book : NSObject
-@property NSString *name;
-@property NSInteger page;
-@property NSString *desc;
-@property NSString *bookID;
-@end
-@implementation Book
-//返回一个 Dict，将 Model 属性名对映射到 JSON 的 Key。
-+ (NSDictionary *)modelCustomPropertyMapper {
- return @{@"name" : @"n",
- @"page" : @"p",
- @"desc" : @"ext.desc",
- @"bookID" : @[@"id",@"ID",@"book_id"]};
-}
-@end
-```
-
-你可以把一个或一组 json key (key path) 映射到一个或多个属性。如果一个属性没有映射关系，那默认会使用相同属性名作为映射。
-
-在 json->model 的过程中：如果一个属性对应了多个 json key，那么转换过程会按顺序查找，并使用第一个不为空的值。
-
-在 model->json 的过程中：如果一个属性对应了多个 json key (key path)，那么转换过程仅会处理第一个 json key (key path)；如果多个属性对应了同一个 json key，则转换过过程会使用其中任意一个不为空的值。
-
-
-### Model 包含其他 Model
-```
-// JSON
-{
- "author":{
- "name":"J.K.Rowling",
- "birthday":"1965-07-31T00:00:00+0000"
- },
- "name":"Harry Potter",
- "pages":256
-}
-
-// Model: 什么都不用做，转换会自动完成
-@interface Author : NSObject
-@property NSString *name;
-@property NSDate *birthday;
-@end
-@implementation Author
-@end
-
-@interface Book : NSObject
-@property NSString *name;
-@property NSUInteger pages;
-@property Author *author; //Book 包含 Author 属性
-@end
-@implementation Book
-@end
-```
-
-
-### 容器类属性
-```
-@class Shadow, Border, Attachment;
-
-@interface Attributes
-@property NSString *name;
-@property NSArray *shadows; //Array***
- - - - - - - - -Native call JS - - //Native - - (void)callJS{ - JSValue *functionName = self.jsContext[@"sum"]; - NSInteger sum = [[functionName callWithArguments:@[@"2",@"18"]] toInt32];; - - UIAlertController *alertVC = [UIAlertController alertControllerWithTitle:@"来自JS 的计算" message:[NSString stringWithFormat:@"%zd",sum] preferredStyle:UIAlertControllerStyleAlert]; - UIAlertAction *okAction = [UIAlertAction actionWithTitle:@"OK" style:UIAlertActionStyleCancel handler:nil]; - [alertVC addAction:okAction]; - [self presentViewController:alertVC animated:YES completion:nil]; - } - - //JS - function sum(a ,b){ - return parseInt(a) + parseInt(b); - } - - diff --git a/Chapter1 - iOS/1.3.md b/Chapter1 - iOS/1.3.md deleted file mode 100644 index 264b134..0000000 --- a/Chapter1 - iOS/1.3.md +++ /dev/null @@ -1,103 +0,0 @@ - - -# loadView - -1. 作用：加载控制器的view - -2. 何时调用：当控制器的view第一次使用的时候就会调用 - -3. 使用场景：只要想自定义控制器的view就调用此方法 - -访问控制器的View就相当于调用控制器中的view get方法 - -```objective-c --(UIView *)view -{ - if(_view == nil){ - [self loadView]; - [self viewDidload]; - } - return _view; -} -``` - - - -# 控制器加载view的流程 - - - - -* 控制器的 `init` 方法底层会调用 `initWithNibName` 方法 - -`MyViewController *vc = [[MyViewController alloc] init];` - -注意点： - -系统做判断的前提提条件：没有指定nibName；没有自定义loadView方法；控制器以...Controller命名 - - - -判断原则： - -* 判断下有没有指定nibName，如果指定了就去加载nib - -* 判断有没有跟控制器同名的xib，但是xib的名称不带Controller的xib，如果有就去加载 - -* 如果第二步没有指定，就判断有没有跟控制器类名同名的xib，如果有就去加载 - -* 如果没有任何xib描述控制器的view，就不加载xib - - - -## MyViewController加载view的处理 - -* 判断有没有指定xibName，如果有就去加载指定的xib - -* 判断有没有跟控制器类名同名的xib，但是名字不带controller - -* 判断有没有跟控制器类名同名的xib，有就去加载 - -* 直接创建一个空的xib - -例子 - -```objective-c -//在Appdelegate中 -ViewController *vc = [[ViewController alloc] init]; -vc.view.backgroundColkor = [UIColor redColor]; -self.window.rootViewController = vc; -[pself.window makeKeyAndVisable]; - -//ViewController --(UIView *)view{ - if(!_view){ - [self loadView]; - [self viewDidLoad]; - } -} - --(void)loadView{ - UIView*view = [[UIView alloc] initWithFrame:[UIScreen mainScreen].bounds]; - view.backgroundColor = [UIColor greenColor]; self.view = view; -} - --(void)viewDidload{ - [super viewDidload]; - self.view.backgroundColor = [UIColor brownColor]; -} -``` - - - -### 请问此时界面颜色是什么？ - -可能很多人会回到绿色。其实答案是 红色 - -why？在AppDelegate中vc.view.backgroundColor就是调用vc的view的getter方法，在getter方法内部判断_view是否存在，不存在则新建一个UIView，新建view是通过 `[self loadView]` 方法创建，创建成功直接调用viewdidload方法；存在则直接返回，所以界面先是绿色，再是棕色最后是红色 - -#### 来一个官方解释 - - - - diff --git a/Chapter1 - iOS/1.30.md b/Chapter1 - iOS/1.30.md deleted file mode 100644 index 8f103a5..0000000 --- a/Chapter1 - iOS/1.30.md +++ /dev/null @@ -1,135 +0,0 @@ -# Xcode 小技巧 - -1. 快速打开：**Command+Shift+O** 。这个命令可以开启一个小窗格用来快速搜索浏览文件、类、算法以及函数等，且支持模糊搜索，这个命令可以说是日常开发中最常用的一个命令了。 - -2. 显示项目导航器：**Command+Shift+J**。使用快速打开命令跳转到对应文件后，如果需要在左侧显示出该文件在项目中的目录结构，只需要键入这个命令，非常方便 - -3. 显示编辑历史。如果一行代码写的很好或者很糟糕，不需要专门跑到 diff 工具去查看代码历史。在该行代码处右击，选择**Show Last Change For Line** - -4. 跳转到方法。在使用类或者结构时，我们经常需要快速的跳转到类的某个特定方法。通过快捷键**control+6**再输入方法的头几个字母就可以非常方便的做到这点。 - -5. 范围编辑。多光标是个很棒的并且每个高级的编辑器都该有的特训过，快捷键为**Command+Control+E**。将光标移动刀需要编辑的符号，输入快捷键，然后就可以在当前页面全局编辑了。 - -6. Xcode 设置代码只在 Debug 下起效的几种方式 - 在日常开发中 Xcode 在 Debug 模式下写很多测试代码，或者引入一些第三方测试用的 .a 和 .framework 动态库，也会通过 CocoaPods 引入一些第三方测试工具或者库；但是不希望这些库在**Release**正式包中被引入，如何做到呢？ -* .h/.m 文件中的测试代码 - - Xcode 在 Debug 模式下定义了宏 DEBUG=1 ，所以我们可以在代码中把相关的测试代码写在预编译处理命令 **\#ifdef DEBUG... \#endif** 中间即可，如图所示 - - - - - -* 测试用的 .a 和 .framework - - 对于拖拽到工程中的 .a .framework 静态库，可以在 **target->Build Settings->Search Paths**这2个选项，分别设置 **Library Search Paths**和**Framework Search Paths**这2个选项。如果我们需要在测试的时候会用到，那么我们可以将 **Debug** 对应的值留下，删掉**Release** 对应的值。这样我们打包 Release 包的时候就不会包含不需要的包。 - - - -* CocoPods 引入的库 - 对于 CocoPods 方式引入的库，在配置的时候就可以处理掉，比如下面的方式 - - ``` - platform: iOS, '8.0' - ... - pod 'PonyDebugger', :configurations => ['Debug'] - ``` -7. App Store Connect 经常在上架的时候需要开发人员判断是否满足出口合规的证明，每次写都很麻烦，所以可以在工程里面的 plist 里面进行设置。 - - ``` -- \ No newline at end of file diff --git a/Chapter1 - iOS/1.36.md b/Chapter1 - iOS/1.36.md deleted file mode 100644 index 73fecec..0000000 --- a/Chapter1 - iOS/1.36.md +++ /dev/null @@ -1,72 +0,0 @@ -# iOS 数值计算精度丢失问题 - -> 在 iOS 中经常会计算金额和价格，我们有时会定义数据类型为 double 或者 float，这样在做过一些运算后会发现精度丢失了，这显然不是我们想要的结果。今日偶然间看到一篇技术博文，为了记忆，顺道解决我的这个问题，所以记录了下来。 - - - -### 存在的问题（精度丢失） - -```objective-c -float a = 0.01; -int b = 99999999; -double c = 0.0; -c = a*b; -NSLog(@"c-%f",c); // c-1000000.000000 -NSLog(@"c-%.2f",c); // c-1000000.00 -``` - -通过上面的代码我们看到简单的数学运算后对于数据类型不合理的数值进行过运算后精度丢失了，这如果是在我们的 App 中，用户看到自己的金额不正确，那还不吓一跳？？ - -接下来看看如何做简单的改进 - -```objective-c -NSString *aString = [NSString stringWithFormat:@"%f",a]; -NSString *bString = [NSString stringWithFormat:@"%.2f",(double)b]; -c = [aString doubleValue]*[bString doubleValue]; -NSLog(@"%f",c); //999999.990000 -NSLog(@"%.2f",c); //999999.99 -``` - -这样虽然可以达成目的，但是计算的过程比较麻烦，并不是我们想要的解决方案。通过查阅资料得知苹果推出了一个类，专门解决数据计算的精度问题NSDecimalNumber 。 - - - -### NSDecimalNumber 为数据精度应用而生 - - - -NSDecimalNumber 是 NSNumber 的子类，专门负责精度计算。提供了完善的初始化方案，对于头疼的精度计算问题（金额）它提供了便利的解决方案（加、减、乘、除、次方运算并且可以给计算出的结果设置明显的精度方案（四舍五入、取上、取下等等））。NSDecimalNumberHandler 可以对计算出的结果做一些策略，比如舍入的模式、数据溢出、除0等异常情况的处理规则。 - -我们来说说上面的问题吧，引入了 NSDecimalNumber，解决上面的问题就不费吹灰之力了。 - -```objective-c -NSString *decimalNumberMutiplyWithString(NSString *multiplierValue, NSString *multiplicandvalue){ - NSDecimalNumber *multiplierNumber = [NSDecimalNumber decimalNumberWithString:multiplierValue]; - - NSDecimalNumber *multiplicandNumber = [NSDecimalNumber decimalNumberWithString:multiplicandvalue]; - NSDecimalNumber *result = [multiplierNumber decimalNumberByMultiplyingBy:multiplicandNumber]; - return [result stringValue]; -} - -NSDecimalNumber *price = [NSDecimalNumber decimalNumberWithMantissa:18992 exponent:-3 isNegative:NO]; -NSDecimalNumber *price2 = [NSDecimalNumber decimalNumberWithString:@"18.992"]; -NSLog(@"price:%@",[price stringValue]); //999999.990000 -NSLog(@"price2:%@",[price2 stringValue]); //999999.99 - - -//设置计算的精度（小数点位数、舍入规则） -NSDecimalNumberHandler *roundPlain = [NSDecimalNumberHandler - decimalNumberHandlerWithRoundingMode:NSRoundPlain - scale:1 - raiseOnExactness:NO - raiseOnOverflow:NO - raiseOnUnderflow:NO - raiseOnDivideByZero:YES]; - -NSDecimalNumber *resultDecimal = [multiplierNumber decimalNumberByMultiplyingBy:multiplicandNumber withBehavior:roundPlain]; -``` - -### 参考文章 - -[文章1](https://www.jianshu.com/p/25d24a184016)、[文章2](https://www.jianshu.com/p/ea4da259a062) - diff --git a/Chapter1 - iOS/1.37.md b/Chapter1 - iOS/1.37.md deleted file mode 100644 index eb3035f..0000000 --- a/Chapter1 - iOS/1.37.md +++ /dev/null @@ -1,34 +0,0 @@ -# 数组、集合、字典与 hash、isEqual 方法的关联 - -1. NSArray 允许重复添加元素，添加元素的时候不查重，所以不会调用上面2个方法。在移出元素的时候会依次遍历数组内的元素，每个元素调用 **isEqual** 方法（remove 方法传入的元素作为参数），所有返回真值的元素都会被移除。在字典中不涉及 hash 方法。 - -2. NSSet 不允许重复添加元素，所以在添加新元素的时候，该元素的 **hash** 方法会被调用，若集合中不存在与此元素 hash 相同的元素，则它会被直接加入集合，不调用 **isEqual** 方法；若存在，则依次调用该集合每个元素的 **isEqual** 方法，返回真值则判等，不加入，处理结合，若返回 false， 则判定集合内不存在该元素，将其加入。 - -3. 集合中移除元素时，首先调用它的 **hash方法**，若集合中存在与其 **hash值** 相等的元素，则调用该元素的 **isEqual方法**，若返回真值则判断，进行移除；若不存在，则会依次调用集合中每个元素的 **isEqual方法**，只要找到一个返回真值的元素，就进行移除，并结束整个过程（所有这样会有其它满足 isEqual 方法但却漏掉未被删除的元素）。调用 contains 方法时类似 - -4. 因此如果自定义对象被加入到集合或作为字典的 key 时，需要同时重写 isEqual 方法和 hash 方法，这样，若集合存在某元素，则调用它的 contains 和 remove 方法时，可以在 O(1) 完成查询，否则需要 O(n) 完成。 - -5. 需要注意的是，NSDictionary 的 key、value 都说对象类型即可，但是被设为 key 的对象需要遵循 NSCopying 协议。 - -6. hash 方法出现的目的是：当我们从数组中查找元素时，需要依次遍历数组中的元素，时间复杂度为 O(n),为了解决效率问题，引入了 Hash Table 方法。当添加元素的时候，为每个元素设置了 hash 值，这样当下次查找的时候就直接通过 hash 值找到对应的位置，时间复杂度为 O(1)。设计一个合理的 hash 算法的指标是对于每个参数，其返回的 hash 值唯一。 - -7. 查阅资料可知，一个推荐的自定义对象的 **hash** 算法是将关键属性的 hash 值，按照位或运算 - -``` -@interface Person : NSObject -@property (nonatomic, strong) NSString *name; -@property (nonatomic, strong) NSDate *birthday; -@end - - -- (NSUInteger)hash{ - return [self.name hash] ^ [self.birthday hash]; -} -``` - - - -8. NSObject 类中的 equal 方法的判断是包括内存地址的，也就是说，NSObject 若想判断2个对象相等，那么这2个对象的内存地址必须相等 - - - diff --git a/Chapter1 - iOS/1.38.md b/Chapter1 - iOS/1.38.md deleted file mode 100644 index 46fb552..0000000 --- a/Chapter1 - iOS/1.38.md +++ /dev/null @@ -1,2261 +0,0 @@ -# RunLoop 探究 - -> 为什么 main 函数可以保持一直运行而不退出？ -> -> 卡顿如何监控 - - - -## RunLoop 是什么 - -- 运行循环 -- 在程序运行过程中循环做一些事情 - -作用：程序并不会马上退出，而是保持运行状态 - -- 保持程序的持续运行 - -- 处理App中的各种事件（比如触摸事件、定时器事件等） - -- 节省CPU资源，提高程序性能：该做事时做事，该休息时休息。休息和工作是从用户态切换到内核态，内核态切换到用户态的不断切换 - -- ...... - -场景 - -- 定时器（Timer）、PerformSelector - -- GCD Async Main Queue - -- 事件响应、手势识别、界面刷新 - -- 网络请求 - -- AutoreleasePool - -先附上一张总结的非常棒的RunLoop图 - -
-
-
-
-一言以蔽之，什么是 RunLoop？为什么 main 函数可以保持一直运行而不退出？
-
-iOS 侧 main 函数中，调用 UIApplicationMain 方法，内部启动主线程的 RunLoop，RunLoop 是一个事件循环的维护机制。有事情做的时候做事情（Source0、Source1），没有事做的时，从用户态到内核态的切换，去实现线程休眠。避免资源浪费。
-
-
-
-## RunLoop 几个重要角色
-
-### 获取 RunLoop
-
-iOS 中有2套 API 可以访问和使用 RunLoop。分别是
-
-- Foundation：NSRunLoop
-
-- CoreFoundation：CFRunLoopRef
-
-```
-//Foundation
-[NSRunLoop currentRunLoop]; // 获得当前线程的RunLoop对象
-[NSRunLoop mainRunLoop]; // 获得主线程的RunLoop对象
-
-//Core Foundation
-CFRunLoopGetCurrent(); // 获得当前线程的RunLoop对象
-CFRunLoopGetMain(); // 获得主线程的RunLoop对象
-```
-
-NSRunLoop 是对 CFRunLoopRef 的一层 OC 包装，所以要了解 RunLoop 的内部结果，就需要了解 CFRunLoopRef
-
-- RunLoop 保存在一个全局的 Dictionary 里，线程作为 key，RunLoop 作为 value
-
-- 每条线程都有与之一一对应的 RunLoop 对象
-
-- 主线程的 RunLoop 已经自动创建好了，子线程的 RunLoop 需要主动创建
-
-- RunLoop 在第一次获取时创建，在线程结束时消失
-
-
-
-### RunLoop 相关的5个类
-
-- CFRunLoopRef
-- CFRunLoopModeRef
-- CFRunLoopSourceRef
-- CFRunLoopTimerRef
-- CFRunLoopObserverRef
-
-CFRunLoopRef 是什么？
-
-查看源码 CFRunLoop 发现是结构体对象别名，`typedef struct __CFRunLoop * CFRunLoopRef;`摘取主要信息如下
-
-```c
-struct __CFRunLoop {
- pthread_t _pthread;
- CFMutableSetRef _commonModes;
- CFMutableSetRef _commonModeItems;
- CFRunLoopModeRef _currentMode;
- CFMutableSetRef _modes;
-};
-```
-
-其中 `_modes` 代表一个 RunLoop 有一个 set 存储运行模式，有多个 Mode。`_currentMode` 表示当前时刻只有一个 Mode。
-
-`CFRunLoopModeRef` 是什么？查看发现
-
-`typedef struct __CFRunLoopMode *CFRunLoopModeRef;`
-
-```c
-struct __CFRunLoopMode {
- CFStringRef _name;
- CFMutableSetRef _sources0;
- CFMutableSetRef _sources1;
- CFMutableArrayRef _observers;
- CFMutableArrayRef _timers;
-};
-```
-
-
-
-### CFRunLoopModeRef 代表 RunLoop 的运行模式
-
-- 一个 RunLoop 包含若干个 Mode，每个 Mode 包含若干个 Source/Timer/Observer
-- 每次 RunLoop 启动，只能指定一个 Mode，这个 Mode 被叫做 CurrentMode
-- 如果需要切换 Mode，只能退出 RunLoop，则以一个 Mode 进入
-- 如果 Mode 里没有任何 Source0/Source1/Timer/Observer，RunLoop 会立马退出
-
-
-
-系统默认注册了5个Mode
-
-- kCFRunLoopDefaultMode：App 的默认 Mode，通常主线程是在这个 Mode 下运行
-- UITrackingRunLoopMode：界面跟踪 Mode，用于 ScrollView 追踪触摸滑动，保证界面滑动时不受其他 Mode 影响
-- UIInitializationRunLoopMode: 在刚启动 App 时进入的第一个 Mode，启动完成后就不再使用
-- GSEventReceiveRunLoopMode: 接受系统事件的内部 Mode，通常用不到
-- kCFRunLoopCommonModes: 这是一个占位用的Mode，不是一种真正的Mode
-
-
-
-Demo:
-
-
-
-
-
-结论：NSRunLoop 是对 CFRunLoop 的一层包装。
-
-
-
-QA：为什么一个 RunLoop 需要创建这么多 Mode？
-
-这样做的目的是为了分隔开不同组的 Source/Timer/Observer 互不影响(性能、功能)。
-
-在UITableView场景下，不同的 RunLoop Mode 主要是与 UITableView 的滑动优化和事件处理相关的。当 UITableView 滑动时，RunLoop的运行模式会从默认的 CFRunLoopDefaultMode 切换到 CFRunLoopTrackingMode，此 Mode 下 RunLoop 主要关注于处理与滑动相关的触摸事件和动画效果，而忽略其他类型的事件，如定时器事件。这是因为如果同时处理所有类型的事件，可能会导致滑动不流畅，影响用户体验。之前添加到 CFRunLoopDefaultMode 上的事件通知（如定时器事件）可能无法被及时处理，这就是为什么在UITableView 滑动时，添加到主线程的 NSTimer 可能会停止执行的原因。
-
-
-
-### Source0、Source1、Timer、Observers 是什么
-
-```c
-struct __CFRunLoopMode {
- CFStringRef _name;
- CFMutableSetRef _sources0;
- CFMutableSetRef _sources1;
- CFMutableArrayRef _observers;
- CFMutableArrayRef _timers;
-};
-```
-
-RunLoop 在各个 Mode 下做事情，其实就是在处理某个 Mode 中的 Source0、Source1、Timer、Observer 事件。
-
-Source0:
-
-- 处理开发者主动提交的任务或应用内部逻辑。
- - `performSelector:onThread:`
- - `dispatch_async`到主线程的任务（最终封装为Source0）。
- - 屏幕触摸事件处理（非基于 Port 的事件），对应需要手动触发的事件，对应官方文档 Input Source 中的 Custom 和 `performSelector:onThread` 事件源。UIKit控件的事件处理（如按钮点击后的回调）。
-
-
-Demo1：给屏幕点击事件加断点，查看堆栈可以看到是 Source0 触发的。
-
-
-
-Demo2: `- (void)performSelector:(SEL)aSelector onThread:(NSThread *)thr withObject:(nullable id)arg waitUntilDone:(BOOL)wait` 该 API 的底层就是：向目标线程的 RunLoop 添加一个 Source0 事件，标记后唤醒线程执行对应的事件。
-
-
-
-Source1:
-
-- 基于 Port 的线程间通信，可以主动唤醒 RunLoop
-- 用户触摸屏幕时，系统通过 Mach Port 将事件传递到应用主线程的 RunLoop。RunLoop 被 Source1 唤醒后，将事件分发给 Source0处理具体的 UI 响应逻辑（如 `hitTest:withEvent:` 和响应链）。
-- 字典。`{machport : 1}`
-
-Timers：
-
-- NSTimer
-
-- `performSelector:withObject:afterDelay:`，底层也是 Timer
-
-Observers:
-
-- 用于监听 RunLoop 状态
-
-- UI刷新（BeforeWaiting）
-
-- AutoReleasePool 实现（BeforeWaiting）
-
-CFRunLoopSourceRef 事件源（输入源）
-
-早期的分法：
-
-- Ported-Based Source
-- Custom Input Source
-- Cocoa Perform Selector Source
-
-现在的分法
-
-- Source0：非基于 port 的，用户主动触发的事件
-- Source1: 基于 port的，通过内核在线程间相互发送消息
-
-
-
-### 一对多的关系
-
-
-
-
-
-#### RunLoopTimer 的封装
-
-- `+ (NSTimer *)timerWithTimeInterval:(NSTimeInterval)ti invocation:(NSInvocation *)invocation repeats:(BOOL)yesOrNo;`
-- `+ (NSTimer *)scheduledTimerWithTimeInterval:(NSTimeInterval)ti invocation:(NSInvocation *)invocation repeats:(BOOL)yesOrNo;`
-- `- (void)performSelector:(SEL)aSelector withObject: (id)argument afterDelay: (NSTimeInterval)seconds inModes: (NSArray*)modes;`
-- `+ (CADisplayLink *)displayLinkWithTarget:(id)target selector:(SEL)sel;`
-- `- (void)addToRunLoop:(NSRunLoop *)runloop forMode:(NSString *)mode;`
-
-
-
-#### CFRunLoopSource
-
-Source 是 RunLoop 的数据源抽象类（protocol）
-
-RunLoop 定义了2个 Version 的 Source：
-
-- Source0：处理 App 内部事件、App 自己负责管理（触发），如 UIEvent、CGSocket
-- Source1：由 RunLoop 和内核管理，Mach port 驱动，如 CFMachPort、CFMessagePort。
-
-定义如下：
-
-```c++
-struct __CFRunLoopSource {
- CFRuntimeBase _base;
- uint32_t _bits;
- pthread_mutex_t _lock;
- CFIndex _order; /* immutable */
- CFMutableBagRef _runLoops;
- union {
- CFRunLoopSourceContext version0; /* immutable, except invalidation */
- CFRunLoopSourceContext1 version1; /* immutable, except invalidation */
- } _context;
-};
-
-typedef struct {
- CFIndex version;
- void * info;
- const void *(*retain)(const void *info);
- void (*release)(const void *info);
- CFStringRef (*copyDescription)(const void *info);
- Boolean (*equal)(const void *info1, const void *info2);
- CFHashCode (*hash)(const void *info);
- void (*schedule)(void *info, CFRunLoopRef rl, CFStringRef mode);
- void (*cancel)(void *info, CFRunLoopRef rl, CFStringRef mode);
- void (*perform)(void *info);
-} CFRunLoopSourceContext;
-
-typedef struct {
- CFIndex version;
- void * info;
- const void *(*retain)(const void *info);
- void (*release)(const void *info);
- CFStringRef (*copyDescription)(const void *info);
- Boolean (*equal)(const void *info1, const void *info2);
- CFHashCode (*hash)(const void *info);
-#if (TARGET_OS_MAC && !(TARGET_OS_EMBEDDED || TARGET_OS_IPHONE)) || (TARGET_OS_EMBEDDED || TARGET_OS_IPHONE)
- mach_port_t (*getPort)(void *info);
- void * (*perform)(void *msg, CFIndex size, CFAllocatorRef allocator, void *info);
-#else
- void * (*getPort)(void *info);
- void (*perform)(void *info);
-#endif
-} CFRunLoopSourceContext1;
-```
-
-
-
-#### CFRunLoopObserver
-
-向外部报告 RunLoop 当前状态的更改。框架中很多机制都是由 RunLoopObserver 触发，比如 CAAnimation、AutoReleasePool。
-
-系统或者开发者很多都是 RunLoop 的业务方。
-
-
-
-#### CFRunLoopMode
-
-Mode 是 iOS App 滑动流畅的关键。
-
-不同任务被添加到不同 Mode 中去。
-
-UITrackingMode 模式下，核心关注滚动时 UI 流畅相关逻辑。
-
-
-
-
-
-### CFRunLoopObserverRef 监听 RunLoop 状态变化
-
-```objective-c
-/* Run Loop Observer Activities */
-typedef CF_OPTIONS(CFOptionFlags, CFRunLoopActivity) {
- kCFRunLoopEntry = (1UL << 0), // 即将进入 RunLoop
- kCFRunLoopBeforeTimers = (1UL << 1), // 即将处理 NSTimer
- kCFRunLoopBeforeSources = (1UL << 2), // 即将处理 Source
- kCFRunLoopBeforeWaiting = (1UL << 5), // 即将进入休眠
- kCFRunLoopAfterWaiting = (1UL << 6), // 刚从休眠中唤醒
- kCFRunLoopExit = (1UL << 7), // 退出 RunLoop
- kCFRunLoopAllActivities = 0x0FFFFFFFU
-};
-```
-
- 添加 Observer
-
-```objective-c
-//1、获得当前线程下的 RunLoop
-CFRunLoopRef runloop = CFRunLoopGetCurrent();
-//2、为 RunLoop 创建观察者
-CFRunLoopObserverRef obersver = CFRunLoopObserverCreateWithHandler(CFAllocatorGetDefault(), kCFRunLoopAllActivities, YES, 0, ^(CFRunLoopObserverRef observer, CFRunLoopActivity activity) {
-});
-//3、为当前的 RunLoop 添加观察者
-CFRunLoopAddObserver(runloop, obersver, kCFRunLoopDefaultMode);
-//4、在 CoreFoundation 框架中， create、copy、retain 过的对象都必须在最后 release
-CFRelease(obersver);
-```
-
-注意：CoreFoundation 的内存管理：凡是带有 Create、Copy、Retain 等字眼的函数创建出来的对象都需要在最后调用 `release`
-
-```objective-c
-//给 RunLoop 添加监听者
-- (void) {
-
- //创建监听者
-// CFRunLoopObserverCreate(CFAllocatorGetDefault(), kCFRunLoopAllActivities, <#Boolean repeats#>, <#CFIndex order#>, <#CFRunLoopObserverCallBack callout#>, <#CFRunLoopObserverContext *context#>)
- /*
- 创建监听对象
- 参数1:分配内存空间
- 参数2:要监听的状态 kCFRunLoopAllActivities ：所有状态
- 参数3:是否要持续监听
- 参数4:优先级
- 参数5:回调
- */
-
- CFRunLoopObserverRef oberver = CFRunLoopObserverCreateWithHandler(CFAllocatorGetDefault(), kCFRunLoopAllActivities, YES, 0, ^(CFRunLoopObserverRef observer, CFRunLoopActivity activity) {
- switch (activity) {
- case kCFRunLoopEntry:
- NSLog(@"RunLoop 闪亮登场");
- break;
- case kCFRunLoopBeforeTimers:
- NSLog(@"RunLoop 大哥要处理 Timer 了");
- break;
- case kCF RunLoopBeforeSources:
- //Source 有2种。Source0:非基于 port 的，用户主动触发的事件。Source1:基于 port，通过内核和其它线程互相发送消息
- NSLog(@"RunLoop 大哥要处理 Source 了");
- break;
- case kCFRunLoopBeforeWaiting:
- NSLog(@"RunLoop 大哥没事干要睡觉了");
- break;
- case kCFRunLoopAfterWaiting:
- NSLog(@"");
- NSLog(@"RunLoop 大哥终于等到有缘人了，要醒来开始干活了");
- break;
- case kCFRunLoopExit:
- NSLog(@"RunLoop 大哥要退出离开了");
- break;
- default:
- break;
- }
- });
- /*
- 参数1:要监听哪个RunLoop
- 参数2:监听者
- 参数3:要监听 RunLoop 在哪种运行模式下的状态
- */
- CFRunLoopAddObserver(CFRunLoopGetCurrent(), oberver, kCFRunLoopDefaultMode);
- CFRelease(oberver);
- [NSTimer scheduledTimerWithTimeInterval:5 target:self selector:@selector(wakeupRunLoop) userInfo:nil repeats:YES];
-}
-
-
-//等到 RunLoop 休眠后，5秒钟叫醒 RunLoop
-- (void)wakeupRunLoop{
- NSLog(@"%s",__func__);
-}
-/*
-2018-08-01 11:23:49.401626+0800 RunLoop[38148:1994974] RunLoop 大哥要处理 Timer 了
-2018-08-01 11:23:49.401950+0800 RunLoop[38148:1994974] RunLoop 大哥要处理 Source 了
-2018-08-01 11:23:49.402326+0800 RunLoop[38148:1994974] RunLoop 大哥要处理 Timer 了
-2018-08-01 11:23:49.402509+0800 RunLoop[38148:1994974] RunLoop 大哥要处理 Source 了
-2018-08-01 11:23:49.402721+0800 RunLoop[38148:1994974] RunLoop 大哥要处理 Timer 了
-2018-08-01 11:23:49.402855+0800 RunLoop[38148:1994974] RunLoop 大哥要处理 Source 了
-2018-08-01 11:23:49.403080+0800 RunLoop[38148:1994974] RunLoop 大哥没事干要睡觉了
-2018-08-01 11:23:49.459238+0800 RunLoop[38148:1994974]
-2018-08-01 11:23:49.459512+0800 RunLoop[38148:1994974] RunLoop 大哥终于等到有缘人了，要醒来开始干活了
-2018-08-01 11:23:49.459740+0800 RunLoop[38148:1994974] RunLoop 大哥要处理 Timer 了
-2018-08-01 11:23:49.459932+0800 RunLoop[38148:1994974] RunLoop 大哥要处理 Source 了
-2018-08-01 11:23:49.460431+0800 RunLoop[38148:1994974] RunLoop 大哥要处理 Timer 了
-2018-08-01 11:23:49.460607+0800 RunLoop[38148:1994974] RunLoop 大哥要处理 Source 了
-2018-08-01 11:23:49.460775+0800 RunLoop[38148:1994974] RunLoop 大哥没事干要睡觉了
-2018-08-01 11:23:49.880631+0800 RunLoop[38148:1994974]
-2018-08-01 11:23:49.880867+0800 RunLoop[38148:1994974] RunLoop 大哥终于等到有缘人了，要醒来开始干活了
-2018-08-01 11:23:49.881530+0800 RunLoop[38148:1994974] RunLoop 大哥要处理 Timer 了
-2018-08-01 11:23:49.881699+0800 RunLoop[38148:1994974] RunLoop 大哥要处理 Source 了
-2018-08-01 11:23:49.881870+0800 RunLoop[38148:1994974] RunLoop 大哥没事干要睡觉了
-2018-08-01 11:23:54.402263+0800 RunLoop[38148:1994974]
-2018-08-01 11:23:54.402562+0800 RunLoop[38148:1994974] RunLoop 大哥终于等到有缘人了，要醒来开始干活了
-2018-08-01 11:23:54.402773+0800 RunLoop[38148:1994974] -[ViewController wakeupRunLoop]
-2018-08-01 11:23:54.403081+0800 RunLoop[38148:1994974] RunLoop 大哥要处理 Timer 了
-2018-08-01 11:23:54.403245+0800 RunLoop[38148:1994974] RunLoop 大哥要处理 Source 了
-2018-08-01 11:23:54.403476+0800 RunLoop[38148:1994974] RunLoop 大哥没事干要睡觉了
-2018-08-01 11:23:59.402151+0800 RunLoop[38148:1994974]
-2018-08-01 11:23:59.402511+0800 RunLoop[38148:1994974] RunLoop 大哥终于等到有缘人了，要醒来开始干活了
-2018-08-01 11:23:59.402687+0800 RunLoop[38148:1994974] -[ViewController wakeupRunLoop]
-2018-08-01 11:23:59.402913+0800 RunLoop[38148:1994974] RunLoop 大哥要处理 Timer 了
-2018-08-01 11:23:59.403037+0800 RunLoop[38148:1994974] RunLoop 大哥要处理 Source 了
-2018-08-01 11:23:59.403156+0800 RunLoop[38148:1994974] RunLoop 大哥没事干要睡觉了
-*/
-```
-
-
-
-上个实验是在主线程对 RunLoop 进行的监听，但是由于是主线程是由系统创建的，所以系统也创建了对应的主 RunLoop，所以我们看不到 RunLoop 创建的状态，为了模拟完整的状态，我们开启子线程，在子线程中模拟
-
-```objective-c
-- (void)testRunLoopObserverOnSubThread{
-
- //创建并发队列
- dispatch_queue_t queue = dispatch_queue_create("com.lbp.testRunLoopOnSubThread", DISPATCH_QUEUE_CONCURRENT);
- //开启子线程
- dispatch_async(queue, ^{
-
- //1、获得当前线程下的 RunLoop
- CFRunLoopRef runloop = CFRunLoopGetCurrent();
-
-
- //2、为 RunLoop 创建观察者
- CFRunLoopObserverRef obersver = CFRunLoopObserverCreateWithHandler(CFAllocatorGetDefault(), kCFRunLoopAllActivities, YES, 0, ^(CFRunLoopObserverRef observer, CFRunLoopActivity activity) {
- switch (activity) {
- case kCFRunLoopEntry:
- NSLog(@"RunLoop 闪亮登场");
- break;
- case kCFRunLoopBeforeTimers:
- NSLog(@"RunLoop 大哥要处理 Timer 了");
- break;
- case kCFRunLoopBeforeSources:
- //Source 有2种。Source0:非基于 port 的，用户主动触发的事件。Source1:基于 port，通过内核和其它线程互相发送消息
- NSLog(@"RunLoop 大哥要处理 Source 了");
- break;
- case kCFRunLoopBeforeWaiting:
- NSLog(@"RunLoop 大哥没事干要睡觉了");
- break;
- case kCFRunLoopAfterWaiting:
- NSLog(@"");
- NSLog(@"RunLoop 大哥终于等到有缘人了，要醒来开始干活了");
- break;
- case kCFRunLoopExit:
- NSLog(@"RunLoop 大哥要退出离开了");
- break;
- default:
- break;
- }
- });
- //为了运行 RunLoop 必须触发事件
- [NSTimer scheduledTimerWithTimeInterval:2 target:self selector:@selector(wakeUpRunLoopOnSubThread) userInfo:nil repeats:NO];
- //3、为当前的 RunLoop 添加观察者
- CFRunLoopAddObserver(runloop, obersver, kCFRunLoopDefaultMode);
- //4、在 CoreFoundation 框架中， create、copy、retain 过的对象都必须在最后 release
- CFRelease(obersver);
- //5、在非主线程创建的 RunLoop 必须触发运行
- [[NSRunLoop currentRunLoop] run];
- });
-}
-
-
-- (void)wakeUpRunLoopOnSubThread{
- NSLog(@"%s",__func__);
-}
-/*
-2018-08-01 14:23:06.453282+0800 RunLoop[2376:115968] RunLoop 闪亮登场
-2018-08-01 14:23:06.453608+0800 RunLoop[2376:115968] RunLoop 大哥要处理 Timer 了
-2018-08-01 14:23:06.453781+0800 RunLoop[2376:115968] RunLoop 大哥要处理 Source 了
-2018-08-01 14:23:06.453982+0800 RunLoop[2376:115968] RunLoop 大哥没事干要睡觉了
-2018-08-01 14:23:08.458237+0800 RunLoop[2376:115968]
-2018-08-01 14:23:08.458658+0800 RunLoop[2376:115968] RunLoop 大哥终于等到有缘人了，要醒来开始干活了
-2018-08-01 14:23:08.458894+0800 RunLoop[2376:115968] -[ViewController wakeUpRunLoopOnSubThread]
-2018-08-01 14:23:08.459082+0800 RunLoop[2376:115968] RunLoop 大哥要退出离开了
-*/
-```
-
-
-
-## RunLoop 运行原理
-
-### 运行原概要
-
-
-
-- 图上左上角的 Input source 是早期 RunLoop 的分法，现在分法为：Source0 和 Source1。
- - Source0:非基于 port 的，用户主动触发的事件。
- - Source1:基于 port，通过内核和其它线程互相发送消息
-- RunLoop 我们不能自己手动创建，而是可以通过 [NSRunLoop currentRunLoop] 方法获取，类似于懒加载。系统底层的做法是在全局维护了一个字典，字典的 key 和 value 分别是当前的线程和线程对应的 RunLoop，如果新开辟的线程没有对应的 RunLoop，系统则为其创建 RunLoop，并将其写入字典（线程、为其创建的 RunLoop）
-
-
-
-### 源码探究
-
-内部就是 do-while 的循环，在这个循环内部不断处理各种任务（Timer、Source、Observer）
-
-我们来看看苹果官方开源的 [CFRunLoop.c 文件](https://legacy.gitbook.com/book/fantasticlbp/knowledge-kit/edit#)。看几个关键函数的实现猜测下 RunLoop 的内部原理
-
-但是如何直到系统是运行 RunLoop 的哪个函数？给 viewDidLoad 设置断点，在 lldb 模式输入 `bt` 查看堆栈
-
-
-
-查看 CF 中 `CFRunLoop.c`源码。方法比较复杂，做了精简摘要
-
-```c
-SInt32 CFRunLoopRunSpecific(CFRunLoopRef rl, CFStringRef modeName, CFTimeInterval seconds, Boolean returnAfterSourceHandled) { /* DOES CALLOUT */
- // ...
- // 通知 Observers 进入 RunLoop
- __CFRunLoopDoObservers(rl, currentMode, kCFRunLoopEntry);
- // RunLoop 运行循环主逻辑
- result = __CFRunLoopRun(rl, currentMode, seconds, returnAfterSourceHandled, previousMode);
- // 通知 Observers 退出 RunLoop
- __CFRunLoopDoObservers(rl, currentMode, kCFRunLoopExit);
- return result;
-}
-```
-
-`CFRunLoopRunSpecific` 方法就是系统启动 RunLoop 的入口。内部先通知 Runloop 的观察者进入 Runloop 了，然后 调用 `__CFRunLoopRun` 执行核心逻辑（处理 timers、source 事件、block），最后告诉观察者退出 Runloop。
-
-我们继续看看 `__CFRunLoopRun` 。源码很多很乱，对无关代码进行裁剪，便于理解流程逻辑
-
-```c
-static int32_t __CFRunLoopRun(CFRunLoopRef rl, CFRunLoopModeRef rlm, CFTimeInterval seconds, Boolean stopAfterHandle, CFRunLoopModeRef previousMode) {
- int32_t retVal = 0;
- do {
- // 通知 Obserers：即将处理 Timers
- if (rlm->_observerMask & kCFRunLoopBeforeTimers) __CFRunLoopDoObservers(rl, rlm, kCFRunLoopBeforeTimers);
- // 通知 Obserers：即将处理 Sources
- if (rlm->_observerMask & kCFRunLoopBeforeSources) __CFRunLoopDoObservers(rl, rlm, kCFRunLoopBeforeSources);
- // 处理 blocks
- __CFRunLoopDoBlocks(rl, rlm);
- // 处理 Source0
- Boolean sourceHandledThisLoop = __CFRunLoopDoSources0(rl, rlm, stopAfterHandle);
- if (sourceHandledThisLoop) {
- // 处理 blocks
- __CFRunLoopDoBlocks(rl, rlm);
- }
-
- Boolean poll = sourceHandledThisLoop || (0ULL == timeout_context->termTSR);
- // 判断有无 Source1
- if (MACH_PORT_NULL != dispatchPort && !didDispatchPortLastTime) {
- msg = (mach_msg_header_t *)msg_buffer;
- // 如果有 Source1 则跳转到 handle_msg
- if (__CFRunLoopServiceMachPort(dispatchPort, &msg, sizeof(msg_buffer), &livePort, 0, &voucherState, NULL)) {
- goto handle_msg;
- }
- }
-
- didDispatchPortLastTime = false;
- // 通知 Observers：即将休眠
- if (!poll && (rlm->_observerMask & kCFRunLoopBeforeWaiting)) __CFRunLoopDoObservers(rl, rlm, kCFRunLoopBeforeWaiting);
-
- CFAbsoluteTime sleepStart = poll ? 0.0 : CFAbsoluteTimeGetCurrent();
-
-
- do {
- if (kCFUseCollectableAllocator) {
- // objc_clear_stack(0);
- //
-
-Demo：
-
-1. 上面第4步的 blocks 是指可以给 RunLoop 添加 Block 任务。
-
- ```objective-c
- CFRunLoopPerformBlock(CFRunLoopGetMain(), kCFRunLoopDefaultMode, ^{
- NSLog(@"runloop block task");
- });
- ```
-
-2. 上面8>2，Runloop 处理 GCD Async To Main Quque
-
-
-
-
-
-
-
-
-
-### RunLoop 休眠原理
-
-> Runloop 在处理完 timer、source、block 后会检查有没有 source1 事件，没有则休眠。这个休眠是 while 循环死等吗？怎么实现的？
-
-可以在 App 运行过程中，点击 Xcode 左下角的 debug 暂停按钮，可以看到 App 堆栈存在系统调用
-
-
-
-
-
-本质上就是函数 `__CFRunLoopServiceMachPort` 来控制实现休眠。查看 CFRunLoop.c 源码可以发现，是由 `mach_msg` 实现的。不是平时的在应用层 API 上 sleep 休眠的。比如 while 循环。
-
-**`mach_msg` 休眠是从用户态切换到内核态，内核 api 控制休眠，做到真正节省资源的作用，等到由新消息来到，继续切换到用户态**。能力更底层，效果更好，从而更加省电
-
-```c
-static Boolean __CFRunLoopServiceMachPort(mach_port_name_t port, mach_msg_header_t **buffer, size_t buffer_size, mach_port_t *livePort, mach_msg_timeout_t timeout, voucher_mach_msg_state_t *voucherState, voucher_t *voucherCopy) {
- Boolean originalBuffer = true;
- kern_return_t ret = KERN_SUCCESS;
- for (;;) { /* In that sleep of death what nightmares may come ... */
- mach_msg_header_t *msg = (mach_msg_header_t *)*buffer;
- msg->msgh_bits = 0;
- msg->msgh_local_port = port;
- msg->msgh_remote_port = MACH_PORT_NULL;
- msg->msgh_size = buffer_size;
- msg->msgh_id = 0;
- if (TIMEOUT_INFINITY == timeout) { CFRUNLOOP_SLEEP(); } else { CFRUNLOOP_POLL(); }
- ret = mach_msg(msg, MACH_RCV_MSG|(voucherState ? MACH_RCV_VOUCHER : 0)|MACH_RCV_LARGE|((TIMEOUT_INFINITY != timeout) ? MACH_RCV_TIMEOUT : 0)|MACH_RCV_TRAILER_TYPE(MACH_MSG_TRAILER_FORMAT_0)|MACH_RCV_TRAILER_ELEMENTS(MACH_RCV_TRAILER_AV), 0, msg->msgh_size, port, timeout, MACH_PORT_NULL);
-
- // Take care of all voucher-related work right after mach_msg.
- // If we don't release the previous voucher we're going to leak it.
- voucher_mach_msg_revert(*voucherState);
-
- // Someone will be responsible for calling voucher_mach_msg_revert. This call makes the received voucher the current one.
- *voucherState = voucher_mach_msg_adopt(msg);
-
- if (voucherCopy) {
- if (*voucherState != VOUCHER_MACH_MSG_STATE_UNCHANGED) {
- // Caller requested a copy of the voucher at this point. By doing this right next to mach_msg we make sure that no voucher has been set in between the return of mach_msg and the use of the voucher copy.
- // CFMachPortBoost uses the voucher to drop importance explicitly. However, we want to make sure we only drop importance for a new voucher (not unchanged), so we only set the TSD when the voucher is not state_unchanged.
- *voucherCopy = voucher_copy();
- } else {
- *voucherCopy = NULL;
- }
- }
-
- CFRUNLOOP_WAKEUP(ret);
- if (MACH_MSG_SUCCESS == ret) {
- *livePort = msg ? msg->msgh_local_port : MACH_PORT_NULL;
- return true;
- }
- if (MACH_RCV_TIMED_OUT == ret) {
- if (!originalBuffer) free(msg);
- *buffer = NULL;
- *livePort = MACH_PORT_NULL;
- return false;
- }
- if (MACH_RCV_TOO_LARGE != ret) break;
- buffer_size = round_msg(msg->msgh_size + MAX_TRAILER_SIZE);
- if (originalBuffer) *buffer = NULL;
- originalBuffer = false;
- *buffer = realloc(*buffer, buffer_size);
- }
- HALT;
- return false;
-}
-```
-
-
-
-### RunLoop 是如何响应用户操作的？
-
-用户交互事件首先在 IOHID 层生成 HIDEvent，然后向事件处理线程的 Source1 的 mach port 发送 HIDEvent 消息，Source1 的回调函数将事件转化为 UIEvent 并筛选需要处理的事件推入待处理事件队列，向主线程的事件处理 Source0 发送信号，并唤醒主线程，主线程检查到事件处理 Source0 有待处理信号后，触发 Source0 的回调函数，从待处理事件队列中提取 UIEvent，最后进入 hit-test 等 UIEvent 事件响应流程
-
-等待梳理完善。
-
-
-
-## CFRunLoopTimerRef 是基于时间的触发器
-
-- 基本上说就是 NSTimer，它会收到 RunLoopMode 的影响
-- GCD 的 timer 不受 RunLoopMode 的影响
-
-## 源码解读
-
-- performSelector 是在 source0 上实现的
-- RunLoopTimer 外部接口设置的精度，精度大于0，则使用 dispatch_source_set_timer，精度小于0，则使用 mk_timer_arm
-- timer_source 使用 dispatch_timer_STRICT 创建，则系统会尽最大努力遵守设置的 leeway 值
-- NSTimer 不准的原因：底层 RunLoop Timer 底层使用的 timer 的精度不高（mk_timer）；与 RunLoop 底层的调用机制有关系
-- 那么为什么存在 RunLoopTimer？意义是什么？应用场景
-
-```c
-// Data structure to hold TSD data, cleanup functions for each
-typedef struct __CFTSDTable {
- uint32_t destructorCount;
- uintptr_t data[CF_TSD_MAX_SLOTS];
- tsdDestructor destructors[CF_TSD_MAX_SLOTS];
-} __CFTSDTable;
-```
-
-```c
-// 主线程 RunLoop
-CFRunLoopRef CFRunLoopGetMain(void) {
- CHECK_FOR_FORK();
- // 局部静态变量
- static CFRunLoopRef __main = NULL; // no retain needed
- // 创建主线程对应的 RunLoop
- if (!__main) __main = _CFRunLoopGet0(pthread_main_thread_np()); // no CAS needed
- return __main;
-}
-
-// 子线程 RunLoop
-// 先从 __CFTSDTable 获取 RunLoop，如果有则 return，没有则调用 _CFRunLoopGet0，_CFRunLoopGet0 内部调用 __CFRunLoopCreate 创建 CFRunLoop，然后写入 __CFTSDTable
-CFRunLoopRef CFRunLoopGetCurrent(void) {
- CHECK_FOR_FORK();
- // __CFTSDTable
- CFRunLoopRef rl = (CFRunLoopRef)_CFGetTSD(__CFTSDKeyRunLoop);
- if (rl) return rl;
- // 没有则创建
- return _CFRunLoopGet0(pthread_self());
-}
-
-CF_EXPORT CFRunLoopRef _CFRunLoopGet0(_CFThreadRef t) {
- if (pthread_equal(t, kNilPthreadT)) {
- t = pthread_main_thread_np();
- }
- __CFLock(&loopsLock);
- if (!__CFRunLoops) {
- CFMutableDictionaryRef dict = CFDictionaryCreateMutable(kCFAllocatorSystemDefault, 0, NULL, &kCFTypeDictionaryValueCallBacks);
- CFRunLoopRef mainLoop = __CFRunLoopCreate(pthread_main_thread_np());
- CFDictionarySetValue(dict, pthreadPointer(pthread_main_thread_np()), mainLoop);
- if (!OSAtomicCompareAndSwapPtrBarrier(NULL, dict, (void * volatile *)&__CFRunLoops)) {
- CFRelease(dict);
- }
- CFRelease(mainLoop);
- }
- CFRunLoopRef newLoop = NULL;
- CFRunLoopRef loop = (CFRunLoopRef)CFDictionaryGetValue(__CFRunLoops, pthreadPointer(t));
- if (!loop) {
- newLoop = __CFRunLoopCreate(t);
- CFDictionarySetValue(__CFRunLoops, pthreadPointer(t), newLoop);
- loop = newLoop;
- }
- __CFUnlock(&loopsLock);
- // don't release run loops inside the loopsLock, because CFRunLoopDeallocate may end up taking it
- if (newLoop) { CFRelease(newLoop); }
-
- if (pthread_equal(t, pthread_self())) {
- _CFSetTSD(__CFTSDKeyRunLoop, (void *)loop, NULL);
- if (0 == _CFGetTSD(__CFTSDKeyRunLoopCntr)) {
-#if _POSIX_THREADS
- _CFSetTSD(__CFTSDKeyRunLoopCntr, (void *)(PTHREAD_DESTRUCTOR_ITERATIONS-1), (void (*)(void *))__CFFinalizeRunLoop);
-#else
- _CFSetTSD(__CFTSDKeyRunLoopCntr, 0, &__CFFinalizeRunLoop);
-#endif
- }
- }
- return loop;
-}
-```
-
-为什么只有当 RunLoop 中存在 Timer Sourcrs、Input Sources 时，才能保证 RunLoop 不退出？
-
-RunLoop 本质就是一个有条件的 do...while 循环。__CFRunLoopModeIsEmpty 里面去判断 source0、source1、timers 不存在则 while 循环条件不满足，RunLoop 退出
-
-```c
-void CFRunLoopRun(void) { /* DOES CALLOUT */
- int32_t result;
- do {
- result = CFRunLoopRunSpecific(CFRunLoopGetCurrent(), kCFRunLoopDefaultMode, 1.0e10, false);
- CHECK_FOR_FORK();
- } while (kCFRunLoopRunStopped != result && kCFRunLoopRunFinished != result);
-}
-
-// expects rl and rlm locked
-static Boolean __CFRunLoopModeIsEmpty(CFRunLoopRef rl, CFRunLoopModeRef rlm, CFRunLoopModeRef previousMode) {
- // ...
- if (NULL != rlm->_sources0 && 0 < CFSetGetCount(rlm->_sources0)) return false;
- if (NULL != rlm->_sources1 && 0 < CFSetGetCount(rlm->_sources1)) return false;
- if (NULL != rlm->_timers && 0 < CFArrayGetCount(rlm->_timers)) return false;
- // ...
- return true;
-}
-```
-
-```c
-SInt32 CFRunLoopRunSpecific(CFRunLoopRef rl, CFStringRef modeName, CFTimeInterval seconds, Boolean returnAfterSourceHandled) { /* DOES CALLOUT */
-// ...
-CFRunLoopModeRef currentMode = __CFRunLoopFindMode(rl, modeName, false);
-if (NULL == currentMode || __CFRunLoopModeIsEmpty(rl, currentMode, rl->_currentMode)) {
- Boolean did = false;
- if (currentMode) __CFRunLoopModeUnlock(currentMode);
- __CFRunLoopUnlock(rl);
- return did ? kCFRunLoopRunHandledSource : kCFRunLoopRunFinished;
-}
-// ...
-```
-
-
-
-## Mach Port 跨线程通信
-
-1. Mach IPC 基于 Mach 内核实现进程间通讯。
-
-2. Mach IPC 被抽象为3种操作：messages、ports、and port sets
-
-3. Mach port 跨线程通信
-
- 线程 B 有个 port 在等待消息，具有消息接收权限，等待消息到来的时候会阻塞当前线程
-
- 线程 A 有个 port 在发送消息，具有发送消息权限，要把发送的消息包装成消息，通过消息队列传递，message 包括：header（目的地 port、size）、data。
-
- 线程 B 收到消息后，解除 block，线程继续向下运行
-
-4. Mach port 如何进行跨线程通信？
-
- 线程开启一个 port，然后给 port 申请接收、发送的权限。mach_msg 是通信函数，在等待消息的时候不加 timeout 则会一直阻塞，等到消息到来
-
-5. 在测试工作中 main.m 文件中打印当前的 RunLoop
-
- ```objectivec
- int main(int argc, char * argv[]) {
- NSString * appDelegateClassName;
- @autoreleasepool {
- appDelegateClassName = NSStringFromClass([AppDelegate class]);
- }
- NSLog(@"%@", NSRunLoop.currentRunLoop);
- return UIApplicationMain(argc, argv, nil, appDelegateClassName);
- }
-
- //
- 2020-08-13 09:49:41.326621+0800 ***[52423:2383402]