那么我会在文件列表中右键相应文件，选择 Open As，再选择 Quick Look。

如果你没有安装任何的 Mardown Quick Look 插件，我推荐这款。

之前在用 SwiftUI 写 AbnormalMouse app 的时候就遇到了这么一个问题，每当 SwiftUI preview 工作的时候，整个 app 都会被运行起来，这样一来就会导致：

• 一些启动时运行的代码会被执行。比如说我有一段代码是打开 app 时检测 app 是否在 Applications 文件夹内，如果不在就会提示用户移动 app，这个弹窗就会时不时弹出来。
• 一些页面 onAppear 时执行的代码会被执行。之前我就遇到了一个“怎么样改 preview 的参数都没有效果”的问题，最后发现是 onApear 时参数被 UserDefaults 中的数据覆盖了。

这就很烦。

尽管用代码来写 layout constraint 已经比以前要简单许多了，但是还是有一些麻烦的地方。一个简单的例子就是很多第三方布局库都会提供一些这样的写法：

1
2
3
4

foo.snp.makeConstraints { make in
    make.center.equalTo(bar)
    make.width.equalTo(12)
}

如果用 layout anchor 来写的话，就需要三行了：

1
2
3
4
5

NSLayoutConstraint.activate([
    foo.centerXAnchor.constraint(equalTo: bar.centerXAnchor),
    foo.centerYAnchor.constraint(equalTo: bar.centerYAnchor),
    foo.widthAnchor.constraint(equalToConstant: 12) 
])

倒也不是没有办法优化，比如说我们可以给 UIView 增加一个方法直接返回居中相关的两个约束，但最终的写出来却还是很奇怪：

1
2
3
4

NSLayoutConstraint.activate(
    [foo.widthAnchor.constraint(equalToConstant: 12)]
    + foo.constraintsToCenter(in: bar)
)

一开始我其实只是想用 KVO 让 View Model 更响应式一些，可是 KVO 只支持 NSObject，用起来绑手绑脚，感觉没法进行下去。以前看过一些响应式的代码，想要模仿一下它们的风格。感觉要是有这么两个类型就好了：

1. Observable<T>，它内部持有一个变量，当这个变量发生改变时，通知其观察者。
2. Emitter<T>，当 ViewModel 发生了什么需要告知 ViewController 时，可以通过 Emitter 发送一个事件，通知其所有的观察者。

譬如说我们要写一个掷骰子的程序，这个程序最奇特的一处是当我们多次掷到的数字之和超过 36，就会弹出一个弹窗告诉我们掷到了 36。我们的 ViewModel 可以这样子写：

1
2
3
4
5
6
7
8
9
10
11
12

class ViewModel {
    private var sum = 0
    let num = Observable<Int>(1)
    let thirtySix = Emitter<Void>(())
    
    func roll() {
        let newNum = Int.random(in: 1...6)
        num.val = newNum
        sum += newNum
        if sum >= 36 { thirtySix.emit(()) }
    }
}

公司的项目有一个页面需要在 Segment Control 上面加一个 header，

原本的是现实监听 segment controller 下每一个列表的 contentOffset 以调整 header 的位置，尽管能用，但毕竟它的最外层不是一个 UIScrollView 了，接手之后突然让我给整体加个加拉刷新，着实是让我很烦心。当时时间比较赶，我就直接加了个 UIPanGestureRecognizer，效果还是很糟糕的。最近比较闲，于是想着重构一下这个部分，我当然希望最外层是一个 UIScrollView，但这就涉及到了两个嵌套 scroll view 的问题了：

1. 什么时候拖动哪一个 scroll view；
2. 当一个 scroll view over scroll 的时候，怎么反映到另外一个 scroll view 上；

Google 了一番，看到的一些想法是监听 scroll view 的 contentOffset 并判断拖动的是哪一个 scroll view。这个方法可以解决第一个问题，但是却不能解决第二个问题。当然我们也可以实现一个 pan gesture 完全接管嵌套 scroll view 的滑动，但这样就失去了 UIScrollView 自带的 over scroll 效果了。

后来我想到了 UICollectionView。用正常的 flow layout 时也许不太明显，但当我们在做一些奇怪的布局的时候，不就是将 contentOffset 转化成了各个 cell 的 frame 吗？我们是不是可以把 contentOffset 看作是进度progress，从而计算出当前进度下各个部分的 frame 呢？

当然我们才不要用 UICollectionView，没有理由又做一个 cell 把 view controller 填到里面去。