下载掌阅APP，畅读海量书库
立即打开
Any和AnyObject是Swift中两个妥协的产物，也是很让人迷惑的概念。在Swift官方编程指南中指出：
AnyObject可以代表任何class类型的实例。
Any可以表示任意类型，甚至包括方法（func）类型。
先来说说AnyObject吧。写过Objective-C的读者可能会知道在Objective-C中有一个叫作id的神奇的东西。编译器不会对声明为id的变量进行类型检查，它可以表示任意类的实例。在Cocoa框架中很多地方都使用了id来进行像参数传递和方法返回这样的工作，这是Objective-C动态特性的一种表现。现在的Swift最主要的用途依然是使用Cocoa框架进行app开发，因此为了与Cocoa架构协作，使用了一个类似的，可以代表任意class类型的AnyObject来替代原来id的概念。
但两者其实是有本质区别的。在Swift中编译器不仅不会对AnyObject实例的方法调用做出检查，甚至对于AnyObject的所有方法调用都会返回Optional的结果。这虽然是符合Objective-C中的理念的，但是在Swift环境下使用起来就非常麻烦，也很危险。应该选择的做法是在使用时先确定AnyObject真正的类型并进行转换以后再进行调用。
假设原来的某个API返回的是一个id，那么在Swift中就将被映射为AnyObject?（因为id是可以指向nil的，所以在这里我们需要一个Optional的版本），虽然我们知道调用应该是没问题的，但是我们依然最好这样写：
如果我们注意到AnyObject的定义，可以发现它其实就是一个接口：
特别之处在于，所有的class都隐式地实现了这个接口，这也是AnyObject只适用于class类型的原因。而在Swift中所有的基本类型，包括Array和Dictionary这些传统意义上是class的东西，都是struct类型，并不能由AnyObject来表示，于是Apple提出了一个更为特殊的Any，除了class以外，它还可以表示包括struct和enum在内的所有类型。
为了深入理解，举个很有意思的例子。为了试验Any和AnyObject的特性，在Playground里写如下代码：
我们在这里声明了一个Int和一个String，按理说它们都应该只能被Any代表，而不能被AnyObject代表。但是你会发现这段代码是可以编译运行通过的。那是不是说其实Apple的编程指南出错了呢？不是这样的，你可以打印一下array，就会发现里面的元素其实已经变成NSNumber和NSString了，这里发生了一个自动的转换。因为我们import了UIKit（其实这里我们需要的只是Foundation，而在导入UIKit的时候也会同时将Foundation导入），在Swift和Cocoa中的这几个对应的类型是可以进行自动转换的。因为我们显式地声明了需要AnyObject，编译器认为我们需要的的是Cocoa类型而非原生类型，而帮我们进行了自动的转换。
在上面的代码中，如果把import UIKit去掉，就会得到无法适配AnyObject的编译错误了。我们需要做的是将声明array时的[AnyObject]换成[Any]，这样就一切正确了。
值得一提的是，只使用Swift类型而不转为Cocoa类型，对性能的提升是有所帮助的，所以我们应该尽可能地使用原生的类型。
其实说真的，使用Any和AnyObject并不是什么令人愉悦的事情，正如开头所说，这都是妥协的产物。如果在我们自己的代码里经常使用这两者，往往意味着代码可能在结构和设计上存在问题，应该及时重新审视。简单来说，我们最好避免依赖和使用这两者，而尝试明确地指出确定的类型。