自 Swift 问世以来,于 iOS 中的运用在很长的一段时间内就注定离不开与 Objective-C 的混编问题。而如何让广大开发者更快地接受并逐步使用这个“亲儿子”,一定程度上会受到它的操作难度的影响。官方也给出了他们的解决方案:编译器标识符 + 混编头文件。即:
XXX-Swift.h
(可在编译设置「Generated Header Name」中修改名称) 由编译器自动生成可供 Objective-C 使用的 Swift 接口(前提是为能够桥接到 Objective-C 的接口加上public @objc
)XXX-Bridging-Header.h
(可在编译设置「Objective-C Bridging Header」中修改路径)管理能被 Swift 访问的 Objective-C 接口
如果你经历过初期的阵痛,就一定会疯狂吐槽因 Xcode 的缓存导致 XXX-Swift.h
无法即使更新而出现的各种莫名其妙的编译错误,对于同一个模块里必须加 public 才能识别的限制使组件封装性被破坏的神奇操作亦让人叫苦不迭,🤣
那么在 @objc
背后发生了什么?dynamic
又有什么作用?调用环境的不同行为是否一致呢?让我们一探究竟!