背景
Objective-C 对象是基于运行时的，方法或属性使用动态派发 ，在运行调用时再决定实际调用的具体实现。而 Swift 为了追求性能，如果没有特殊需要的话，是不会在运行时再来决定这些的。也就是说，Swift 类型的成员或者方法在编译时就已经决定，而运行时便不再需要经过一次查找，而可以直接使用。
Objective-C 中所有类都继承自NSObject，Swift 中的类如果要供 Objective-C 调用，必须也继承自NSObject。
@objc
@objc修饰符的根本目的是用来暴露接口给 Objective-C 的运行时（类、协议、属性和方法等）
添加@objc修饰符并不意味着这个方法或者属性会采用 Objective-C 的方式变成动态派发，Swift 依然可能会将其优化为静态调用
@objc 修饰符的隐式添加：
Swift 3 中继承自NSObject的类，不需要手动添加@objc，编译器会给所有的非private的类和成员加上@objc，private接口想要暴露给 Objective-C 需要@objc的修饰
button.addTarget(self, action: #selector(backButtonTapped), for: .touchUpInside)
@objc private func backButtonTapped() { }
func backButtonTapped() { }
Swift 4 中继承自NSObject的类的隐式@objc自动添加，只会发生在以下四种情况：
1.重写了父类的 Objective-C 方法
2.实现了一个 Objective-C 的协议
3.@IBAction或@IBOutlet关键字的修饰
4.@NSManaged关键字的修饰
@NSManaged的定义
Core Data 提供了基本存储和实现NSManagedObject子类的一组属性。在与Core Data 模型中管理对象子类相关的特性或者关系的每个属性定义之前，将@NSmanaged特性加入。与 Objective-C 里面的 @dynamic特性类似，@NSManaged特性告知 Swift 编译器，这个属性的存储和实现将在运行时完成。但是，与@dynamic不同的是，@NSManaged特性仅在 Core Data 支持中可用。
使用@objc可以修改 Swift 接口暴露到 Objective-C 后的名字
@objc(Squirrel)
class Белка: NSObject {
@objc(color)
var цвет: Цвет = .Красный
@objc(hideNuts:inTree:)
func прячьОрехи(количество: Int, вДереве дерево: Дерево) { }
}
@objcMembers
使用@objcMembers关键字，将类中的所有方法暴露给Objc (效果等同于为所有方法加上@objc)。
为什么要用这个关键字呢？
@objcMembers 在Swift 4中继承 NSObject 的 swift class 不再默认全部 bridge 到 OC，如果我们想要使用的话我们就需要在class前面加上@objcMembers 这么一个关键字。
引用: 在 swift 3 中除了手动添加 @objc 声明函数支持 OC 调用还有另外一种方式：继承 NSObject。
class 继承了 NSObject 后，编译器就会默认给这个类中的所有函数都标记为 @objc ，支持 OC 调用。
苹果在Swift 4 中苹果修改了自动添加 @objc 的逻辑： 一个继承 NSObject 的 swift 类不再默认给所有函数添加 @objc。
只在实现 OC 接口和重写 OC 方法时才自动给函数添加 @objc 标识。
Swift4 后继承自NSObject的类不再隐式添加@objc关键字，但在某些情况下非常依赖 Objective-C 的运行时（如 XCTest），所以在 Swift4 中提供了@objcMembers关键字，对类和子类、扩展和子类扩展重新启用@objc推断。
@objcMembers
class MyClass : NSObject {
func foo() { } // implicitly @objc
func bar() -> (Int, Int) // not @objc, because tuple returns
// aren't representable in Objective-C
}
extension MyClass {
func baz() { } // implicitly @objc
}
class MySubClass : MyClass {
func wibble() { } // implicitly @objc
}
extension MySubClass {
func wobble() { } // implicitly @objc
}
使用@objc和@nonobjc可以指定开启或关闭某一extension中的所有方法的@objc推断。
class SwiftClass { }
@objc extension SwiftClass {
func foo() { } // implicitly @objc
func bar() -> (Int, Int) // error: tuple type (Int, Int) not
// expressible in @objc. add @nonobjc or move this method to fix the issue
}
@objcMembers
class MyClass : NSObject {
func wibble() { } // implicitly @objc
}
@nonobjc extension MyClass {
func wobble() { } // not @objc, despite @objcMembers
}
dynamic
当前 Swift 的动态性依赖于 Objective-C，Swift3 中dynamic就隐式包含了@objc的意思，但考虑到以后版本的 Swift 语言和运行时将会自支持dynamic而不再依赖于 Objective-C，所以在 Swift4 中将dynamic和@objc含义进行了抽离
class MyClass {
dynamic func foo() { } // error: 'dynamic' method must be '@objc'
@objc dynamic func bar() { } // okay
dynamic关键字
如果您有过OC的开发经验，那一定会对OC中@dynamic关键字比较熟悉，它告诉编译器不要为属性合成getter和setter方法。
Swift中也有dynamic关键字，它可以用于修饰变量或函数，它的意思也与OC完全不同。它告诉编译器使用动态分发而不是静态分发。OC区别于其他语言的一个特点在于它的动态性，任何方法调用实际上都是消息分发，而Swift则尽可能做到静态分发。
因此，标记为dynamic的变量/函数会隐式的加上@objc关键字，它会使用OC的runtime机制。
虽然静态分发在效率上可能更好，不过一些app分析统计的库需要依赖动态分发的特性，动态的添加一些统计代码，这一点在Swift的静态分发机制下很难完成。这种情况下，虽然使用dynamic关键字会牺牲因为使用静态分发而获得的一些性能优化，但也依然是值得的。
class Kraken {
dynamic var imADynamicallyDispatchedString: String
dynamic func imADynamicallyDispatchedFunction() {
//Hooray for dynamic dispatch!
}
}
使用动态分发，您可以更好的与OC中runtime的一些特性（如CoreData，KVC/KVO）进行交互，不过如果您不能确定变量或函数会被动态的修改、添加或使用了Method-Swizzle，那么就不应该使用dynamic关键字，否则有可能程序崩溃。
注意：
使用dynamic关键字标记属性，使属性启用Objc的动态转发功能；
dynamic只用于类，不能用于结构体和枚举，因为它们没有继承机制，而Objc的动态转发就是根据继承关系来实现转发。
