Swift学习之每日一tip (7) @objc

前端之家收集整理的这篇文章主要介绍了Swift学习之每日一tip (7) @objc前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
今天隔壁老王突然问起我,Swift里面的@objc是个神马玩意儿?于是就有了今天的这个tip。
那么话说回来,既然说到@objc,就不得不扯一扯Swift和Objective-C之间不得不说的一些事啦^_^

Objective-C和Swift混合开发

Swift 语言的初衷是希望能摆脱 Objective-C 的沉重的历史包袱和约束,但是不可否认的是经过了二十多年的洗礼,Cocoa 框架早就烙上了不可磨灭的 Objective-C 的印记。无数的第三方库是用 Objective-C 写成的,这些积累无论是谁都不能小觑。因此,在最初的版本中,Swift 不得不考虑与 Objective-C 的兼容。
Apple 采取的做法是允许我们在同一个项目中同时使用 Swift 和 Objective-C 来进行开发。其实一个项目中的 Objective-C 文件和 Swift 文件是处于两个不同世界中的,为了让它们能相互联通,我们需要添加一些桥梁。
当然这个桥梁文件,在新的xcode版本中,是会自动提示是否需要生成,并帮大家自动生成的,所以不需要在意这个问题。

@objc的使用场景一:

Objective-C 和 Swift 在底层使用的是两套完全不同的机制,Cocoa 中的 Objective-C 对象是基于运行时的,它从骨子里遵循了 KVC (Key-Value Coding,通过类似字典的方式存储对象信息) 以及动态派发 (Dynamic Dispatch,在运行调用时再决定实际调用的具体实现)。而 Swift 为了追求性能,如果没有特殊需要的话,是不会在运行时再来决定这些的。也就是说,Swift 类型的成员或者方法在编译时就已经决定,而运行时便不再需要经过一次查找,而可以直接使用。

显而易见,这就是@objc的一个使用场景之一,如果我们要使用 Objective-C 的代码或者特性来调用纯 Swift 的类型时候,我们会因为找不到所需要的这些运行时信息,而导致失败。

注意:

这个步骤只需要对那些不是继承自 NSObject 的类型进行,如果你用 Swift 写的 class 是继承自 NSObject的话,Swift 会默认自动为所有的非 private 的类和成员加上 @objc。这就是说,对一个 NSObject 的子类,你只需要导入相应的头文件就可以在 Objective-C 里使用这个类了。

@objc的使用场景二:

虽然绝大部分时候自动转换的方法名已经足够好用 (比如会将 Swift 中类似 init(name: String) 的方法转换成 -initWithName:(NSString *)name 这样),但是有时候我们还是期望 Objective-C 里使用和 Swift 中不一样的方法名或者类的名字,比如 Swift 里这样的一个类:

class  Person{
    func Hello(name: String) {
        println("Hello,\(name)")
    }
}

Person().Hello("小明")

可以通过@objc来进行修改

@objc(MyClass)
class  Person{
    @objc(greeting:)
    func Hello(name: String) {
        println("Hello,\(name)")
    }
}

然后我们就可以这样进行Objective-C中的调用了:[[MyClass new] greeting:@"小明"]

最后做一个说明:

说明

添加 @objc 修饰符并不意味着这个方法或者属性会变成动态派发,Swift 依然可能会将其优化为静态调用。如果你需要和 Objective-C 里动态调用时相同的运行时特性的话,你需要使用的修饰符是 dynamic。

原文链接:https://www.f2er.com/swift/327089.html

猜你在找的Swift相关文章