OC中水土不服的运行时特性

2020-09-15  本文已影响0人  醉看红尘这场梦

如果你有过Objective-C的开发经验,一定会对它提供的各种运行时特性印象深刻。基于这些特性提供的功能更是灵活强大,可以帮助我们处理一些复杂的任务。但这一切,都是有代价的。没错,它们大多用起来都不直观,如果你不去刨一下文档,总不那么容易理解相关API的正确用法。

并且,既然这些特性是基于运行时的,因此,编译器仅可以对它们执行非常有限的检查。一旦你稍有疏忽,就得承担App闪退的严重后果。

用OC运行时特性进行排序

我们来看个和搜索有关的例子。首先,定义一个表示视频信息的类:

final class Episode: NSObject {
    @objc var title: String
    @objc var type: String
    @objc var length: Int

    override var description: String {
        return title + "\t" + type + "\t" + String(length)
    }

    init(title: String, type: String, length: Int) {
        self.title = title
        self.type = type
        self.length = length
    }   
}

其实,在Swift里,这类内容定义成struct更合适,但为了演示OC的运行时特性,我们把它定义成了一个派生自NSObject的类。并且,通过关键字final限制了它不能继续被继承。

Episode有三个属性,分别表示视频的标题、类型和长度。然后,我们重载了description属性,以便后面通过print直接打印Episode对象。

这一切都很简单,然后,我们定义一些测试数据:

let episodes = [
    Episode(title: "title 1", type: "Free", length: 520),
    Episode(title: "title 4", type: "Paid", length: 500),
    Episode(title: "title 2", type: "Free", length: 330),
    Episode(title: "title 5", type: "Paid", length: 260),
    Episode(title: "title 3", type: "Free", length: 240),
    Episode(title: "title 6", type: "Paid", length: 390),
]

接下来,我们要先按type排序,并在排序后的结果里,继续按照length排序,该怎么办呢?Apple在开发者文档里介绍了一种叫做NSSortDescriptor的用法,这就是一个典型的功能强大,但是又必须要看文档才能掌握的技能。

为了排序type,首先,我们定义一个typeDescriptor

let typeDescriptor = NSSortDescriptor(
    key: #keyPath(Episode.type),
    ascending: true,
    selector: #selector(NSString.localizedCompare(_:)))

其中:

其次,定义一个Array<NSDescriptor>

let descriptors = [typeDescriptor]

最后,把episodes转型成NSArray,调用sortedArray(using:)方法,把descriptors传递给它:

let sortedEpisodes = (episodes as NSArray).sortedArray(using: descriptors)

这样,就完成排序了,但我们会得到一个Array<Any>的结果,为了查看它的内容,我们得这样:

sortedEpisodes.forEach { print($0 as! Episode) }

然后,我们就可以在控制台看到下面的结果了:

title 1 Free    520
title 2 Free    330
title 3 Free    240
title 4 Paid    500
title 5 Paid    260
title 6 Paid    390

此时,我们就完成了按Type进行排序,接下来,我们还要在这个排序结果里,把FreePaid的视频按时间排序。理解了上面的套路之后,就很简单了,我们继续定义一个lengthDescriptor

let lengthDescriptor = NSSortDescriptor(
    key: #keyPath(Episode.length),
    ascending: true)

这次,我们使用系统默认的整数比较操作符就好了,可以不明确指定要使用的selector。定义好之后,直接把它添加到之前创建的descriptors数组里:

let descriptors = [ typeDescriptor, lengthDescriptor ]

这样,重新执行一次,sortedArray(using:)方法就会返回这样的结果:

title 3 Free    240
title 2 Free    330
title 1 Free    520
title 5 Paid    260
title 6 Paid    390
title 4 Paid    500

看到了吧,现在,每一类视频里,就是按照时长进行排序的了,这就是NSSortDescriptor的用法。当你理解了这个过程之后,就能体会到它的功能强大,我们可以在descriptors数组中,包含任意多个不同的NSSortDescriptor对象,来实现复杂的搜索功能。但是,如果你不看文档,Hmmmm...,估计你也很难理解它的使用方法。

除了不怎么好学之外,上面的方法在Swift里还有个先天不足,就是我们使用了OC的两个运行时特性:一个是Key-Value coding,用来读取属性中的值,一个是selector,用来表示排序时使用的算法。编译器对这些当然一无所知,只要语法上正确,就会开绿灯。但是,显然,调试运行时错误要比编译错误麻烦的多。

那Swift的方式呢?

显然,尽管NSSortDescriptor的思想并不难掌握,但把它用在Swift里,还是显的有点儿水土不服,这主要表现在:

所以,对于Swift原生类型来说,NSSortDescriptor并不是复杂排序规则的最佳解决方案。那就究竟该怎么办呢?你可能会想,Array不是有一个接受函数参数的sorted方法么:

episodes.sorted {
    // Complex sorting code here
}

但这并不是一个好主意,相比之前NSSortDescriptor的方式,不仅我们无法有效表达要排序的规则,而且,把这些规则统统塞进一个排序函数中也并不利于维护。想象一下,如果现在我们又要对titlelength排序了该怎么办呢?

为了在Swift中找到更易用和安全的解决方案,我们还是得从NSSortDescriptor的思路入手,把排序规则的表达、排序规则的组合,以及执行排序的动作独立分开。只是,为了充分利用Swift编译器提供类型检查,我们要避免使用运行时机制来识别要访问的内容。具体该怎么办呢?大体的思路是这样的,对于比较元素时执行的函数,我们可以去掉selector,直接用Swift中的函数类型。而对于获取要排序的属性,我们也要通过一个函数类型来表达,而不要通过Key-Value coding。

上一篇下一篇

猜你喜欢

热点阅读