阿权的开发经验小集

小集是日常开发中遇到问题的小结，或许可以帮助你少走一些弯路～

Git

跟踪上游分支

背景：执行 pull 没拉下新代码，但远端确实是有更新的。

目标：恢复与上游的同步。

YAML 复制代码

git branch -u origin/branch_name

删除分支

目标：本地分支和远程分支一起删除。

Bash 复制代码

# 删除本地分支
git branch -d localBranchName

# 删除远程分支
git push origin --delete remoteBranchName

空提交

背景：有些操作需要通过 git 提交记录的更新来触发，这里通过一个不影响代码的空提交触发。

YAML 复制代码

git commit --allow-empty -m "Empty-Commit"

Tag vs. Branch

背景：Tag 和 Branch 在执行 git 命令时常常不需要显式说明，但当两者同名时就需要显式声明。

Tag 是记录一个 commit 点，Branch 是记录一个 commit 序列串。

branch 的特点是该分支的指针的位置随着提交不断更新，一般是存储在 refs/heads/。
tag 的特点与分支恰恰相反，指向的 commit 不会随着新的提交去更新。一般是存储在 refs/tags/。

git merge 可以合并 tag 或 branch。若出现 tag 和 branch 重名的 case，可以通过补全路径处理：

Bash 复制代码

# push
git push origin :refs/heads/branch_name
git push origin :refs/tags/tag_name

# merge
git merge refs/heads/branch_name
git merge refs/tags/tag_name

回退合并

背景：执行了 merge 操作希望回退到 merge 前的 commit。

Bash 复制代码

# 场景：合并操作还没完成，希望中断并回退到合并前的状态。
# 中断当前正在合并还没提交的分支的合并操作
git merge --abort

# 场景：合并操作已完成，甚至已经 push 到远程，希望回退到合并前的状态。
# 回退刚才已经提交的第一个合并
git reset --merge HEAD~1

# 若合并还没 push 到远程，经过上面操作后，分支可能会落后于远程分支，所以还要同步一遍，以确保跟远程分支同步。
git pull

# 场景：需要将本地的覆盖远程分支状态
# force push
git push --force
git push --force-with-lease # 更安全，会检查远程是否有新提交（有则拒绝 push）

Rebase vs. Merge

	merge	rebase
作用	创建一个新的 "合并提交"（merge commit），将两个分支的历史记录连接起来，保留双方完整的提交历史（包括分支的分叉和合并节点）。	将当前分支的所有提交 "移植" 到目标分支的最新提交之后，改写当前分支的提交历史，使历史呈现线性（无合并提交）。
优点	完整保留操作分支的所有提交历史，仅新增一个合并提交。遇到冲突只需解决一次。	历史记录整洁，合并后历史呈线性，没有多余的合并提交。rebase 过程中可以通过 `--interactive`（交互式）对提交进行压缩、修改、删除，让历史更清晰（例如将多个 "修复 bug" 的小提交合并为一个有意义的大提交）。
缺点	频繁合并会产生大量 "合并提交"，主分支历史可能出现很多分叉节点，长期来看难以快速理解项目演进脉络。不能对当前分支的提交进行压缩、修改（如需优化提交历史，需额外操作）。	rebase 会修改当前分支的提交哈希，因为提交被 "移植" 到了新的基础上。甚至会修改提交顺序。可能需要多次解冲突，如果多个提交与目标分支有冲突，需要逐个提交解决冲突。修改提交顺序后会引入更多冲突。
选择	新手优先	整洁优先

选择：

	多人共用一分支	单人单分支
保留完整分支历史	merge	rebase
分支历史不重要	rebase	rebase

为了平衡提交历史的简洁性与准确性（少点冲突），合并代码时可以这样做：先使用 rebase，遇到冲突时 abort 回退，切换为 merge，然后解冲突。

注意：主分支被团队所有人依赖，应尽可能使用 merge。

从分支维度：可以简单约定合并策略，主分支用 merge，功能分支用 rebase，来平衡两者的优缺点。

解冲突最佳实践

基本常识：

HEAD/ours 是指自己的改动；origin/theirs 是指上游的改动。

操作原则：

只有是自己写的才应用自己的改动，否则应用上游的改动。
存疑的（自己写的混合了他人写的，应用上游后编译不过）应保留两者的修改，对于不确定要丢弃的代码用段落注释（合并代码少用行注释）。

最佳实践：

处理资源/二进制文件，简单选择用自己的还是用上游的。
处理文本：以行甚至段落为单位，选用自己的还是上游的版本。
处理存疑文本修改：以行为单位，不选用自己和上游的版本，直接编写预期的文本。
对解完冲突的文件暂存修改（git add）。
解完 git 仓库本次所有冲突后，提交修改（git commit）。

推荐工具：vscode。使用 vscode 打开 git 仓库，并用其解冲突。

修改作者信息

背景：提交完代码了才发现用错了邮箱提交，例如：外部仓库使用了公司邮箱提交了代码，需要改用私人邮箱。

Git 会为每一次提交记录提交者的姓名和邮箱，这是本地 Git 配置的 "身份标识"，用于区分不同开发者的提交。

如何修改：

git log 查看 commit id
git rebase -i <最早commit> 重新设置基准线
git commit --amend --author="Author Name autolinkemail@address.comautolink"来修改 commit
``git rebase --continue` 移动到下个 commit 作为基准线

例子：如当前历史为 A-B-C（HEAD），我想修改 B 和 C，这两个 commit 的作者。

git rebase -i A，即要修改的最早提交的前一个节点。
1. 如果想改 A 则使用git rebase -i --root
pick 改为 edit。按 ESC，输入：wq。保存修改。
现在你已经开始可以修改，此时当前 commit 为 B。
git commit --amend --author="Author Name autolinkemail@address.comautolink" 修改 B 的提交。
git rebase --continue 定位到 C
git commit --amend --author="Author Name autolinkemail@address.comautolink" 修改 C 的提交。
git rebase --continue 修改已完成。
git push -f 提交代码，大功告成。

文件修改检测不到

背景：本地文件有修改，但 Git 检测不到了。重启似乎就可以检测得到，但只能一次有效。

排查：去检查文件所在的路径，与 Git 识别的路径是否有大小写的差异。Git 区分大小写差异，但系统不区分，所以会有 gap，目录名只改了大小写，会导致一些奇怪的问题。

解决：把有大小写的路径段重命名。改大小写名称时，先重命名为临时名，再改为正确的大小写，分两次提交以避免文件系统的不识别。

iOS

留心延迟执行的代码

代码里看到延时执行要谨慎，非常可能是枯叶掩埋的陷阱。

延时执行可能是能解决作者提交时遇到的问题。但随着业务发展，可能后续那次修改后，延时执行就兜不住了。

首先自己不要写延时执行代码，不要期望延时能根治某个问题，延时能绕过的问题一般是执行时机、时序问题，应找到合适的时机执行逻辑。
其次看到别人写的延时代码要十分谨慎，可以先不去改别人写的延时代码，但尽可能不要依赖延时执行的时机做后续的逻辑，应自己找到合适的时机编写自己的代码。

主队列执行时序问题

Swift 复制代码

public extension DispatchQueue {
    private static var token: DispatchSpecificKey<Void> = {
        let key = DispatchSpecificKey<Void>()
        DispatchQueue.main.setSpecific(key: key, value: ())
        return key
    }()
    
    static var isMain: Bool {
        DispatchQueue.getSpecific(key: Base.token) != nil
    }
    
    static func onMainQueue(_ work: @escaping @convention(block) () -> Void) {
        if isMain {
            work()
        } else {
            DispatchQueue.main.async(execute: work)
        }
    }
}

通过标记 DispatchQueue.main 队列可以准确判断当前执行的队列是否是主队列。使用 onMainQueue 方法可以确保让任务在主线程和主队列中执行。这个做法在不要求时序的场景下，确实是最保险的。要保证时序性，就要重新思考了。

主队列只能在主线程中执行。主线程是 runloop 机制，DispatchQueue.main.async 就是把任务（一段代码）放入到下一个 runloop 中执行。主线程还会执行其他队列，如在主线程中 sync 执行一个普通 serial queue，这个 queue 也是在主线程中执行，但就不是主队列了，上面的 isMain 方法会判断为 false。如果这种 case 在需要任务按照严格时序执行的场景下，就会出现时序错乱的问题。因为这里会把一些在主线程但不在主队列的任务错误地放置到下一个 runloop 中执行。

相反要考虑时序性，只需要使用 Thread.isMainThread 就能准确识别当前是否是主线程了，绝大数 UI 场景都适用。

Swift 复制代码

public extension UtilExtension where Base: DispatchQueue {
    static func onMainThread(_ work: @escaping @convention(block) () -> Void) {
        if Thread.isMainThread {
            work()
        } else {
            DispatchQueue.main.async(execute: work)
        }
    }
}

锁

使用锁，最终目的是为了解决竞态条件。

	互斥锁 Mutex Lock	自旋锁 Spin Lock
原理	当线程尝试获取锁时，若锁已被占用，该线程会进入休眠状态（阻塞），直到锁被释放后被唤醒。	线程在获取锁失败时不会休眠，而是通过循环（忙等待）不断检查锁状态。
特性	互斥锁会休眠线程，避免了 CPU 空转，但涉及线程上下文切换，可能带来性能开销。适合高竞争或长时间持有。	自旋锁保持线程活跃，避免了上下文切换，但长时间等待会消耗 CPU 资源，适用于锁持有时间短的场景。适合短时间锁竞争。
具体实现	不可重入锁（非递归锁）：线程必须释放锁后才能再次获取，否则会死锁。`NSLock`、`pthread_mutex`（默认模式）可重入锁（递归锁）：允许同一线程多次获取同一锁而不死锁。`NSRecursiveLock`、`@synchronized`条件锁：基于条件变量实现，线程需等待特定条件满足后才能继续执行。`NSCondition`和`NSConditionLock`，需与互斥锁配合使用。	iOS 中早期使用`OSSpinLock`，但因优先级反转问题被废弃；现推荐使用`os_unfair_lock`作为轻量级替代。读写锁：允许并发读取（多个读线程），但写入时需独占资源。属于自旋锁的特殊形式，例如`pthread_rwlock`。

信号量

通过计数器控制并发访问数量，底层可能依赖互斥锁实现，所以如果重入会死锁。

Swift 复制代码

class Lock {
    private let semaphore = DispatchSemaphore(value: 1)
    func lock() {
        semaphore.wait()
    }
    func unlock() {
        semaphore.signal()
    }
    @inline(__always)
    final func performLocked<T>(_ action: () -> T) -> T {
        self.lock(); defer { self.unlock() }
        return action()
    }
}

同步队列

同步队列通过在一个串行队列中执行操作，也可以实现资源安全访问。

同步执行在一段时间内不会切换线程，异步执行会切线程，但在队列执行的任务还是串行的。这个这个特性，可以实现异步锁。但就会发生上下文切换，即线程切换。

Xcode

手动安装模拟器

背景：新安装 Xcode 时总要额外下载一个与该 Xcode 版本匹配的模拟器，这个过程总是很久。可以试试手动下载。

官网下载 Xcode 对应的模拟器版本：developer.apple.com/download/al...
执行命令：

Bash 复制代码

# 需要先选定操作的 Xcode
sudo xcode-select -s /Applications/Xcode_16.1.app
xcodebuild -runFirstLaunch
xcodebuild -importPlatform "$HOME/Downloads/iOS_18.1_Simulator_Runtime.dmg"

启动 Xcode 即可。

安装系统不支持的 Xcode 版本

背景：新系统不能打开旧 Xcode。

Bash 复制代码

plutil -replace CFBundleVersion -string 30000 /Applications/Xcode.app/Contents/Info.plist

查找 setter

背景：希望找到某属性所有修改的地方。

可以将属性改写成计算属性，这样就可以单独查找 setter 的调用栈。

转码控制台中的 JSON

背景：Xcode 控制台输出 json 常常是转义过的，配合 vscode 可以还原出原始的 json。

拷贝到 vscode，结合 Text Power Tools 插件，使用 json 解析。

去除头尾到双引号。
右键：Text Power Tools > Encode/decode > Unescape JSON escaped text

Swift 语言

KVO 备忘

背景：Swift 的 KVO 语法常常检索不到。

Swift 复制代码

// 定义可 KVO 监听的属性变量
@objc dynamic var myDate

// 监听，options 若不设置，change 的 oldValue、newValue 为 nil
observation = observe(\.objectToObserve.myDate, options: [.old, .new]) { object, change in
    print("myDate changed from: \(change.oldValue!), updated to: \(change.newValue!)")
}

Using Key-Value Observing in Swift | Apple Developer Documentation

枚举语义

enum 表达互斥的
表达常量或常量表达式，其关联值都是常量，都需要构造的时候确定。
indirect 修饰 case 或 enum 可以在关联值使用自身类型，即表达递归语义。常用于常量表达式的表达。

特性：

便捷的构造，直接点语法直接构建。类比到 struct/class 的静态方法/属性。
关联值可忽略标签，直接用类型表达。

数组在遍历中删除元素

背景：遍历数组并删除元素一不小心就会数组越界。

可以通过以下方式规避：

使用高阶函数直接创建/修改一个符合条件的数组。如 filter、removeAll(where:)。
反向遍历，可以安全地按索引删除元素，如 reversed()。

枚举 raw value 不能是表达式

枚举 raw value 在定义的时候等号右侧不可以是表达式，而是一个字面常量，不可加条件。

读取大文件

可以使用 FileHandle 或 InputStream 来读取大文件。

它们之间存在一些主要的不同：

使用方式 ：InputStream 是基于流的，可以连续读取数据，这对于处理大文件或网络数据非常有用，因为你不需要一次性将所有数据加载到内存中。另一方面，FileHandle 允许你更精细地控制文件访问，例如，你可以选择从文件的任何位置开始读取或写入数据。
数据处理 ：使用 InputStream 时，你需要自己处理数据缓冲区的分配和释放。使用 FileHandle 时，你可以直接获取 Data 对象，而无需关心底层的内存管理。
可用性 ：InputStream 可以处理来自各种来源的数据，如文件、网络数据或内存中的数据。而 FileHandle 主要用于文件操作。
错误处理 ：InputStream 有一个 streamError 属性，可以用来检查在读取或写入过程中是否发生错误。FileHandle 的方法则会抛出异常，需要使用 try、catch 来处理。

InputStream 使用实例：github.com/gonsolo/gon...

Swift 复制代码

guard let s = InputStream(fileAtPath: path) else {
    throw PbrtScannerError.noFile
}
stream = s
stream.open()
if stream.streamStatus == .error {
    throw PbrtScannerError.noFile
}
var bytes = Array<UInt8>(repeating: 0, count: bufferLength)
buffer = UnsafeMutablePointer<UInt8>.allocate(capacity: bufferLength)
buffer.initialize(from: &bytes, count: bufferLength)
bufferIndex = 0
bytesRead = stream.read(buffer, maxLength: bufferLength)

FileHandle 的使用：

Swift 复制代码

let fileURL = URL(fileURLWithPath: "path/to/file")
if let fileHandle = try? FileHandle(forReadingFrom: fileURL) {
    let data = fileHandle.readData(ofLength: 12)
    // 处理读取到的数据
    fileHandle.closeFile()
}

省略 inout 参数

背景：inout 参数是不能设置默认值的，但有时候想让其成为可选参数。

把 inout 参数改成 UnsafeMutablePointer 类型可以做成像默认参数的省略用法，如：

Swift 复制代码

func checkIfSupport(draft: Data, isSingle: inout Bool) -> Bool
func checkIfSupport(draft: Data, isSingle: UnsafeMutablePointer<Bool>? = nil) -> Bool

参考：option type - Swift optional inout parameters and nil - Stack Overflow

不建议在 extension 中重写

swift2 - Overriding methods in Swift extensions - Stack Overflow

使用 @objc 修饰的方法即使定义在 extension 中，也能被重写。@objc 可以直接修饰 extension。类似的，NSObject 子类定义的 objc 方法也可以在 extension 中重写。

Swift 复制代码

// MARK: Override
extension ExportViewControllerNew {
    override var preferredStatusBarStyle: UIStatusBarStyle {
        .lightContent
    }
}

这样写会把方法暴露给 Runtime。

但不太建议这么做，似乎不太正统的方式。需要重写的方法还是应放到类的定义中。

Decodable 详细使用

定義 Decodable 的 init（from:）解析 JSON | by 彼得潘的 iOS App Neverland | 彼得潘的 Swift iOS App 開發問題解答集 | Medium

我在想，为什么不用 ObjectMapper 呢？

weak 对象所在的作用域结束后还不销毁

对于 Swift 中的对象，其销毁时机与作用域有关，但不是唯一决定因素。对象的生命周期是由引用计数（reference counting）管理的。当一个对象的强引用计数降至零时，该对象会被销毁。以下是一些可能导致对象未在作用域结束时被销毁的情况：

强引用计数：当对象的作用域结束时，如果对象的强引用计数不为零，对象不会被立即销毁。这可能是因为在作用域外还有其他地方保持着对该对象的强引用。
强引用循环：当对象之间存在强引用循环时，即使它们的作用域已经结束，对象也不会被销毁。强引用循环会导致内存泄漏，因为对象互相保持强引用，使得它们的引用计数永远不会降至零。这时，需要使用 weak 或 unowned 关键字来解决强引用循环问题。
延迟释放：Swift 使用自动引用计数（ARC）来管理内存。ARC 通常在对象不再需要时立即释放内存，但在某些情况下，ARC 可能会延迟释放对象。这种延迟释放可能会导致对象在作用域结束后仍然存在。

虽然作用域对于对象的销毁有一定影响，但对象的生命周期主要还是由引用计数管理。因此，在编写 Swift 代码时，需要特别注意避免强引用循环和内存泄漏。

获取代码位置

Swift 复制代码

"\(#function) @\(#fileID):\(#line):\(#column)"

类判等

对于类实例，判断是否相同，可以简单以地址区分，使用 === 运算符比较。

Swift 复制代码

if b === Test.self {
    print("yes")
} else {
    print("no")
}

ios - Comparing types with Swift - Stack Overflow

打印地址

有时候我们想直接打印对象的地址，可以这么做：

Swift 复制代码

// 方式一
let s = Struct() // Struct
withUnsafePointer(to: s) {
    print(String(format: "%p", $0)
}

// 方式二
func printPointer<T>(ptr: UnsafePointer<T>) {
    print(ptr)
}
printPointer(ptr: &x)

// 方式三
///
/// http://stackoverflow.com/a/36539213/226791
///
func addressOf(_ o: UnsafeRawPointer) -> String {
    let addr = unsafeBitCast(o, to: Int.self)
    return String(format: "%p", addr)
}

func addressOf<T: AnyObject>(_ o: T) -> String {
    let addr = unsafeBitCast(o, to: Int.self)
    return String(format: "%p", addr)
}
  
// 方式三
Unmanaged.passUnretained(self).toOpaque()

参考：

获取磁盘空间

背景：快速获取与系统设置计算方式一致的剩余磁盘空间。

Swift 复制代码

let fileURL = URL(fileURLWithPath:"/")
do {
    let values = try fileURL.resourceValues(forKeys: [.volumeAvailableCapacityForImportantUsageKey])
    if let capacity = values.volumeAvailableCapacityForImportantUsage {
        print("Available capacity for important usage: \(capacity)")
    } else {
        print("Capacity is unavailable")
    }
} catch {
    print("Error retrieving capacity: \(error.localizedDescription)")
}