feature: Weex APM && SwiftUI

2026-05-24 20:00:37 +00:00 · 2026-01-11 00:09:24 +08:00
parent 7843661458
commit ddfbd0bc29
8 changed files with 66 additions and 29 deletions
--- a/.DS_Store
+++ b/.DS_Store
--- a/iOS/1.119.md
+++ b/iOS/1.119.md
@@ -1,4 +1,4 @@
-#   剖析 Swift  String 
+# 剖析 Swift String 

 带着问题研究下 Swift 中的 String

--- a/iOS/1.121.md
+++ b/iOS/1.121.md
@@ -1,4 +1,4 @@
-# 内存管理
+# Swift 内存管理


 ## 弱引用
--- a/iOS/1.146.md
+++ b/iOS/1.146.md
@@ -1,6 +1,12 @@
 # Weex 底层原理与 APM

-> 从 Vue 组件库（Vue Lib）到 Weex 渲染为 iOS 原生 UIKit 元素，核心是 “Virtual DOM → 跨线程通信 → Native DOM 构建 → 布局计算 → 原生 View 渲染 → 事件反向绑定” 的完整链路。Weex 作为中间层，主要完成 7 大核心工作，接下去看看详细内容
+> 从 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 侧的稳定性与异常监控怎么做？请带着问题看文章

 ## 一、核心步骤

@@ -1166,7 +1172,7 @@ Weex 的 JSBundle 仅包含业务逻辑和组件描述，框架代码（Vue 内
 Weex 是诸多年前的产物，部分业务线用 Weex 写了部分功能模块，或者是某几个页面，或者是某个二级、三级业务 SDK 的页面。但可以确定的是：
 - 21年就完成了 Flutter 的基建开发（对齐 Native 的 UI 组件库，遵循体验设计平台产出的集团 UI 标准；做了 Flutter 的大量 plugin、打包构建平台、日志库、网络库、探照灯、APM SDK、热修复能力等）。新业务的实现只会在 Native 和 Flutter 上考虑
 - Weex 业务代码基本上是存量的
- Weex 代码没有 bug 就不去修改；有版本迭代，之前是 Weex 实现的，本次只做简单 UI 增删或字段调整，也是会修改一下。初次之外不修改 Weex 代码
+- Weex 代码没有 bug 就不去修改；有版本迭代，之前是 Weex 实现的，本次只做简单 UI 增删或字段调整，也是会修改一下。除此之外不修改 Weex 代码

 所以像 Native 一样去全面监控性能、网络、crash、异常、白屏、页面加载耗时等维度的话，ROI 是很低的。那么就需要制定一些策略去有针对性的监控高优问题。

--- a/iOS/1.148.md
+++ b/iOS/1.148.md
@@ -1,4 +1,4 @@
-# 安全气垫
+# 移动端的“安全气垫”

 > 安全气垫是端上一个老生常谈的话题，技术方案已经是好多年前的产物。唯一的问题是不同公司对于安全气垫在拦截到异常的时候，“做与不做”策略的判断不同。比如数组索引越界的时候要返回一个错误位置的值吗？会不会产生业务异常？要一刀切吗？那么本文就尝试回答下这个问题

--- a/iOS/chapter1.md
+++ b/iOS/chapter1.md
@@ -117,4 +117,21 @@
  * [111、写给 iOSer 的鸿蒙开发 tips](https://github.com/FantasticLBP/knowledge-kit/blob/master/Chapter1%20-%20iOS/1.111.md)
  * [112、Swift 枚举值内存布局](https://github.com/FantasticLBP/knowledge-kit/blob/master/Chapter1%20-%20iOS/1.112.md)
  * [113、Swift 结构体和类的内存布局](https://github.com/FantasticLBP/knowledge-kit/blob/master/Chapter1%20-%20iOS/1.113.md)
-  * [114、Swift 优化](https://github.com/FantasticLBP/knowledge-kit/blob/master/Chapter1%20-%20iOS/1.114.md)
+  * [114、Swift 优化](https://github.com/FantasticLBP/knowledge-kit/blob/master/Chapter1%20-%20iOS/1.114.md)
+  * [115、AI 对端上的赋能](https://github.com/FantasticLBP/knowledge-kit/blob/master/Chapter1%20-%20iOS/1.115.md)
+  * [116、Swift 类底层剖析](https://github.com/FantasticLBP/knowledge-kit/blob/master/Chapter1%20-%20iOS/1.116.md)
+  * [117、Swift 协议探究](https://github.com/FantasticLBP/knowledge-kit/blob/master/Chapter1%20-%20iOS/1.117.md)
+  * [118、Swift 错误处理](https://github.com/FantasticLBP/knowledge-kit/blob/master/Chapter1%20-%20iOS/1.118.md)
+  * [119、剖析 Swift String](https://github.com/FantasticLBP/knowledge-kit/blob/master/Chapter1%20-%20iOS/1.119.md)
+  * [120、Swift 访问控制](https://github.com/FantasticLBP/knowledge-kit/blob/master/Chapter1%20-%20iOS/1.120.md)
+  * [121、Swift 内存管理](https://github.com/FantasticLBP/knowledge-kit/blob/master/Chapter1%20-%20iOS/1.121.md)
+  * [122、Swift 字面量本质](https://github.com/FantasticLBP/knowledge-kit/blob/master/Chapter1%20-%20iOS/1.122.md)
+  * [123、Swift 模式匹配](https://github.com/FantasticLBP/knowledge-kit/blob/master/Chapter1%20-%20iOS/1.123.md)
+  * [128、SwiftUI 研究](https://github.com/FantasticLBP/knowledge-kit/blob/master/Chapter1%20-%20iOS/1.128.md)
+
+  * [139. 图形渲染技巧](https://github.com/FantasticLBP/knowledge-kit/blob/master/Chapter1%20-%20iOS/1.139.md)
+  * [140. Aspects](https://github.com/FantasticLBP/knowledge-kit/blob/master/Chapter1%20-%20iOS/1.140.md)
+  * [143. AI 对端上的赋能](https://github.com/FantasticLBP/knowledge-kit/blob/master/Chapter1%20-%20iOS/1.143.md)
+  * [146. Weex 底层原理与 APM](https://github.com/FantasticLBP/knowledge-kit/blob/master/Chapter1%20-%20iOS/1.146.md)
+  * [147. Rust 在移动端可以做什么](https://github.com/FantasticLBP/knowledge-kit/blob/master/Chapter1%20-%20iOS/1.147.md)
+  * [148. 移动端的“安全气垫”](https://github.com/FantasticLBP/knowledge-kit/blob/master/Chapter1%20-%20iOS/1.148.md)
--- a/Talk/7.5.md
+++ b/Talk/7.5.md
@@ -71,7 +71,7 @@ git tag -a 1.0.0 -m 'release SPM lib'


 ## 代码回滚
-<img src="./../assets/GitWorkFlow.png" style="zoom:30%" />
+<img src="https://raw.githubusercontent.com/FantasticLBP/knowledge-kit/master/assets/GitWorkFlow.png" style="zoom:30%" />

 git 存在3个区域：

@@ -125,7 +125,7 @@ git 将存储对象的40位 HASH 分为2部分：

 - 后38位作为对象文件名。结构为：`.git/objects/hash[0:2]/hash[2:40]`

-  <img src="./../assets/githashDemo.png" style="zoom:30%" />
+  <img src="https://raw.githubusercontent.com/FantasticLBP/knowledge-kit/master/assets/githashDemo.png" style="zoom:30%" />

  比如：`gitDemo/.git/objects/22/13d05bf4b8cfc7ee323af3ac427ad2fa14da88`

@@ -140,7 +140,7 @@ QA: 为什么要设计这样的目录结构（Hash 值总40位，前2位为文

 ### 2. git add 的本质

- <img src="./../assets/githash.png" style="zoom:30%" />
+ <img src="https://raw.githubusercontent.com/FantasticLBP/knowledge-kit/master/assets/githash.png" style="zoom:30%" />

 `git ls-files -s` 指令查看暂存区文件  。

@@ -173,7 +173,7 @@ Demo1:

 对 `index.txt` 文件使用 `git hash-object -w index.txt` 指令计算哈希。

-<img src="./../assets/githashCommand.png" style="zoom:30%" />
+<img src="https://raw.githubusercontent.com/FantasticLBP/knowledge-kit/master/assets/githashCommand.png" style="zoom:30%" />

 Demo2：

@@ -188,7 +188,7 @@ Demo3:

 对 `index.txt` 文件内容进行调整，`git hash-object -w index.txt` 指令计算哈希

-<img src="./../assets/githashChange.png" style="zoom:30%" />
+<img src="https://raw.githubusercontent.com/FantasticLBP/knowledge-kit/master/assets/githashChange.png" style="zoom:30%" />

 结论：

@@ -217,7 +217,7 @@ Demo：

 整体效果如下图：

-<img src="./../assets/gitAddMocking.png" style="zoom:30%" />
+<img src="https://raw.githubusercontent.com/FantasticLBP/knowledge-kit/master/assets/gitAddMocking.png" style="zoom:30%" />



@@ -227,25 +227,25 @@ Demo：

 第一步：上述步骤生成了3份 git hash，分别保存在 `.git/objects/` 目录下。

-<img src="./../assets/gitFileTreeBefore.png" style="zoom:30%" />
+<img src="https://raw.githubusercontent.com/FantasticLBP/knowledge-kit/master/assets/gitFileTreeBefore.png" style="zoom:30%" />

 第二步：接下去将暂存区的文件生成一颗树。使用指令 **git write-tree**

 第三步：查看生成的树信息。使用指令 `git cat-file -p {TreeHash}`

-<img src="./../assets/gitFileTreeAfter.png" style="zoom:30%" />
+<img src="https://raw.githubusercontent.com/FantasticLBP/knowledge-kit/master/assets/gitFileTreeAfter.png" style="zoom:30%" />

 第四步：使用指令 **`git read-tree --prefix=FantasticLBP/ 7f7bbe6285c9c767aeaa1aedba6dcf5324774bc8`** 将指定的 tree 对象内容读取到当前索引中，并将其所有文件放在名为 `FantasticLBP/` 的目录下。

 此时文件目录为：

-<img src="./../assets/gitTreeRecoverBefore.png" style="zoom:30%" />
+<img src="https://raw.githubusercontent.com/FantasticLBP/knowledge-kit/master/assets/gitTreeRecoverBefore.png" style="zoom:30%" />

 第五步：此时的效果为，暂存区里面存在另一份目录名为 `FantasticLBP/` 的暂存区信息。但是此时实体文件夹下并不存在。使用指令 `git checkout -- .` 便可以从暂存区恢复。

 恢复后的目录结构为：

-<img src="./../assets/gitTreeRecoverAfter.png" style="zoom:30%" />
+<img src="https://raw.githubusercontent.com/FantasticLBP/knowledge-kit/master/assets/gitTreeRecoverAfter.png" style="zoom:30%" />



@@ -265,7 +265,7 @@ Demo：

 **`git commit-tree`**：Git 底层命令，用于创建一个新的提交对象（commit object）。它需要一个 tree 对象作为基础，并通过标准输入接收提交信息。命令执行成功后，会输出新创建的提交对象的 SHA-1 哈希值。

-<img src="./../assets/gitCommitTree.png" style="zoom:30%" />
+<img src="https://raw.githubusercontent.com/FantasticLBP/knowledge-kit/master/assets/gitCommitTree.png" style="zoom:30%" />

 可以看到：

@@ -330,7 +330,7 @@ C0 <--- C1 <--- M1 <--- M2 [master]

 git rebase 还可以用于一些提交信息的处理，比如 `git rebase -i {CommitHash}`

-<img src="./../assets/GitRebaseCommand.png" style="zoom:30%" />
+<img src="https://raw.githubusercontent.com/FantasticLBP/knowledge-kit/master/assets/GitRebaseCommand.png" style="zoom:30%" />

 git rebase 还可以将多次 commit 合并为1次，也可以修改某次 commit 的信息等等，具体的可以看指令后面的注释。

@@ -440,11 +440,11 @@ git config merge.conflictstyle diff3

 比如，我模拟了文件冲突，调用 `git mergetool` 使用 opendiff 打开了文件冲突展示能力

-<img src="./../assets/GitOpenDiffPanel.png" style="zoom:30%" />
+<img src="https://raw.githubusercontent.com/FantasticLBP/knowledge-kit/master/assets/GitOpenDiffPanel.png" style="zoom:30%" />

 当前 case 下，我需要选择左侧为结果，所以点击了 "Choose left"。下面区域为合并后的结果。在终端还有来一次确认过程。做到 double check。

-<img src="./../assets/GitOpenDiffResult.png" style="zoom:30%" />
+<img src="https://raw.githubusercontent.com/FantasticLBP/knowledge-kit/master/assets/GitOpenDiffResult.png" style="zoom:30%" />

 属于 y 后，相当于选择了结果，接下去再进行 add、commit 等操作。

@@ -460,7 +460,7 @@ git config merge.conflictstyle diff3

 示例如下

-<img src="./../assets/GitLogPCommand.png" style="zoom:30%" />
+<img src="https://raw.githubusercontent.com/FantasticLBP/knowledge-kit/master/assets/GitLogPCommand.png" style="zoom:30%" />



@@ -533,11 +533,11 @@ Demo：

 - 使用 `git stash list` 用于**查看当前所有存储条目**的核心命令，展示的信息从时间上由近到远

-  <img src="./../assets/GitStashCommand.png" style="zoom:30%" />
+  <img src="https://raw.githubusercontent.com/FantasticLBP/knowledge-kit/master/assets/GitStashCommand.png" style="zoom:30%" />

  - 使用 `git stash show -p stash@{0}` 查看**存储修改内容**。其中 `-p` 是 `--patch` 的缩写，显示完整差异（补丁格式）,`stash{0}` 指定要查看的储藏引用（0 表示最近一次储藏）

-    <img src="./../assets/GitStashPCommand.png" style="zoom:30%" />
+    <img src="https://raw.githubusercontent.com/FantasticLBP/knowledge-kit/master/assets/GitStashPCommand.png" style="zoom:30%" />

    

@@ -552,11 +552,11 @@ Demo：

  - 使用 `git stash apply stash@{1}` 来应用某次具体的 stash 栈里的信息。注意：新 stash 的 序号更早，早期的由近到远依次+1

-    <img src="./../assets/GitStashApply.png" style="zoom:30%" />
+    <img src="https://raw.githubusercontent.com/FantasticLBP/knowledge-kit/master/assets/GitStashApply.png" style="zoom:30%" />

  - 如果从 stash 里取出的代码不满意，如何恢复到 之前的状态？使用组合命令 **git stash show -p stash@{1} | git apply -R`** 来达到反向应用补丁的效果。

-    <img src="./../assets/GitStashApplyRevert.png" style="zoom:30%" />
+    <img src="https://raw.githubusercontent.com/FantasticLBP/knowledge-kit/master/assets/GitStashApplyRevert.png" style="zoom:30%" />

    管道符 `|` ,将前一个命令的输出作为后一个命令的输入。比如：

@@ -600,7 +600,7 @@ Demo：

  因为都存在于本地暂存区了，所以可以使用指令 **`git update-index --assume-unchanged {FileName}`** 来告诉 git，不要追踪暂存区的 FileName 该文件

-  <img src="./../assets/GitRemoveTrackingWithIgnore.png" style="zoom:30%" />
+  <img src="https://raw.githubusercontent.com/FantasticLBP/knowledge-kit/master/assets/GitRemoveTrackingWithIgnore.png" style="zoom:30%" />

 #### 3. 进阶玩法

@@ -706,13 +706,13 @@ Git Hook 是 Git 提供的自动化脚本机制，可在特定 Git 操作（如

 一个项目如果是 git init 之后的，会在 `.git/hooks` 目录下存在一堆 hooks 模版，如下图

-<img src="./../assets/GitHooksTemplate.png" style="zoom:30%" />
+<img src="https://raw.githubusercontent.com/FantasticLBP/knowledge-kit/master/assets/GitHooksTemplate.png" style="zoom:30%" />

 - 顾名思义，pre-push、post-push 分别是在 push 之前、push 之后触发的钩子。所以其他几个钩子类似

 - 本次演示继续在之前的 Demo 上演示，使用 Pre-Commit 钩子，去掉拓展名。注释掉其他代码，添加一句打印输出

-  <img src="./../assets/GitPreCommitHook.png" style="zoom:30%" />
+  <img src="https://raw.githubusercontent.com/FantasticLBP/knowledge-kit/master/assets/GitPreCommitHook.png" style="zoom:30%" />

 注意：这里可以使用 shell、也可以使用 python、JS、Ruby 等脚本

@@ -779,7 +779,7 @@ Git Hook 是 Git 提供的自动化脚本机制，可在特定 Git 操作（如
 - 继续在 gitDemo 终端路径下分别执行  **`git remote add origin  /Users/unix_kernel/Desktop/gitDemoServer1` **和** `git remote add origin2 /Users/unix_kernel/Desktop/gitDemoServer2`** ，为了给当前的 repo 配置多个远端仓库
 - 最后执行 `git remote -v` 指令查看当前 repo 的 remote 信息

-<img src="./../assets/gitRemoteAdd.png" style="zoom:30%" />
+<img src="https://raw.githubusercontent.com/FantasticLBP/knowledge-kit/master/assets/gitRemoteAdd.png" style="zoom:30%" />

 说明：

--- a/SUMMARY.md
+++ b/SUMMARY.md
@@ -118,7 +118,21 @@
  * [113、Swift 结构体和类的内存布局](https://github.com/FantasticLBP/knowledge-kit/blob/master/Chapter1%20-%20iOS/1.113.md)
  * [114、Swift 优化](https://github.com/FantasticLBP/knowledge-kit/blob/master/Chapter1%20-%20iOS/1.114.md)
  * [115、AI 对端上的赋能](https://github.com/FantasticLBP/knowledge-kit/blob/master/Chapter1%20-%20iOS/1.115.md)
+  * [116、Swift 类底层剖析](https://github.com/FantasticLBP/knowledge-kit/blob/master/Chapter1%20-%20iOS/1.116.md)
+  * [117、Swift 协议探究](https://github.com/FantasticLBP/knowledge-kit/blob/master/Chapter1%20-%20iOS/1.117.md)
+  * [118、Swift 错误处理](https://github.com/FantasticLBP/knowledge-kit/blob/master/Chapter1%20-%20iOS/1.118.md)
+  * [119、剖析 Swift String](https://github.com/FantasticLBP/knowledge-kit/blob/master/Chapter1%20-%20iOS/1.119.md)
+  * [120、Swift 访问控制](https://github.com/FantasticLBP/knowledge-kit/blob/master/Chapter1%20-%20iOS/1.120.md)
+  * [121、Swift 内存管理](https://github.com/FantasticLBP/knowledge-kit/blob/master/Chapter1%20-%20iOS/1.121.md)
+  * [122、Swift 字面量本质](https://github.com/FantasticLBP/knowledge-kit/blob/master/Chapter1%20-%20iOS/1.122.md)
+  * [123、Swift 模式匹配](https://github.com/FantasticLBP/knowledge-kit/blob/master/Chapter1%20-%20iOS/1.123.md)
+  * [128、SwiftUI 研究](https://github.com/FantasticLBP/knowledge-kit/blob/master/Chapter1%20-%20iOS/1.128.md)
+  * [139. 图形渲染技巧](https://github.com/FantasticLBP/knowledge-kit/blob/master/Chapter1%20-%20iOS/1.139.md)
+  * [140. Aspects](https://github.com/FantasticLBP/knowledge-kit/blob/master/Chapter1%20-%20iOS/1.140.md)
+  * [143. AI 对端上的赋能](https://github.com/FantasticLBP/knowledge-kit/blob/master/Chapter1%20-%20iOS/1.143.md)
+  * [146. Weex 底层原理与 APM](https://github.com/FantasticLBP/knowledge-kit/blob/master/Chapter1%20-%20iOS/1.146.md)
  * [147. Rust 在移动端可以做什么](https://github.com/FantasticLBP/knowledge-kit/blob/master/Chapter1%20-%20iOS/1.147.md)
+  * [148. 移动端的“安全气垫”](https://github.com/FantasticLBP/knowledge-kit/blob/master/Chapter1%20-%20iOS/1.148.md)
 * [Chapter2 - Web FrontEnd](https://github.com/FantasticLBP/knowledge-kit/blob/master/Chapter2%20-%20Web%20FrontEnd/chapter2.md)
  * [1、-last-child与-last-of-type你只是会用，有研究过区别吗？](https://github.com/FantasticLBP/knowledge-kit/blob/master/Chapter2%20-%20Web%20FrontEnd/2.1.md)
  * [2、正则表达式](https://github.com/FantasticLBP/knowledge-kit/blob/master/Chapter2%20-%20Web%20FrontEnd/2.2.md)