Swift项目中为暴露给OC的方法/变量添加@objc是否有副作用？

你在Swift项目里为了给Objective-C暴露类和成员添加@objc的操作，确实会带来一些潜在的副作用，但大多是非常轻微的，结合你给出的LocalDataManager代码，我来具体说说：

• 二进制体积小幅增加
  标记@objc后，编译器会生成Objective-C Runtime兼容的元数据，这些额外的信息会让App的二进制体积有所增长。不过像你代码里这种简单的单例类和字符串属性，增加的体积几乎可以忽略——只有当你给大量复杂Swift类型添加@objc时，才需要考虑这点开销。

• 存在极轻微的性能损耗
  Swift默认对大部分成员采用静态派发，而Objective-C依赖动态派发。当你用@objc暴露成员后，访问这些成员会走Objective-C的动态派发逻辑，相比纯Swift的静态派发会有一点点性能差异。但你的nickName属性本身是基于UserDefaults的IO操作，这种场景下，动态派发的性能损耗完全感知不到。

• 类型与继承的隐性约束
  @objc只能暴露Objective-C能识别的类型，Swift独有的类型（比如无NSObject继承的枚举、结构体）没法直接用@objc标记——不过你代码里用的String会桥接成Objective-C的NSString，完全没问题。另外，如果Swift类没有指定父类就标记@objc，它会隐式继承NSObject，自动获得KVO、isa指针等NSObject的特性。如果你的类不需要这些特性，这算是一点额外的“冗余”，但通常不会有实际影响。

• 命名冲突的潜在风险
  Objective-C没有命名空间的概念，如果你标记@objc的类/成员和项目里其他Objective-C代码的命名重复，会直接导致编译错误。比如如果有另一个Objective-C类也叫LocalDataManager，就会冲突。不过只要你项目里命名规范，这种情况很少出现。

针对你的LocalDataManager代码来说，当前的@objc使用是完全合理的，这些副作用对你的场景基本可以忽略。如果之后你不再需要在Objective-C里访问这些内容，记得把@objc去掉，避免不必要的开销。

内容的提问来源于stack exchange，提问作者JsW