Objective-C 一个一直以来令人诟病的地方就是没有命名空间，在应用开发时，所有的代码和引用的静态库最终都会被编译到同一个域和二进制中。这样的后果是一旦我们有重复的类名的话，就会导致编译时的冲突和失败。
为了避免这种事情的发生，Objective-C 的类型一般都会加上两到三个字母的前缀，比如 Apple 保留的 NS 和 UI 前缀，各个系统框架的前缀 SK (StoreKit)，CG (CoreGraphic) 等。Objective-C 社区的大部分开发者也遵守了这个约定，一般都会将自己名字缩写作为前缀，把类库命名为 AFNetworking 或者 MBProgressHUD 这样。这种做法可以解决部分问题，至少我们在直接引用不同人的库时冲突的概率大大降低了，但是前缀并不意味着不会冲突，有时候我们确实还是会遇到即使使用前缀也仍然相同的情况。另外一种情况是可能你想使用的两个不同的库，分别在它们里面引用了另一个相同的很流行的第三方库，而又没有更改名字。在你分别使用这两个库中的一个时是没有问题的，但是一旦你将这两个库同时加到你的项目中的话，这个大家共用的第三方库就会和自己发生冲突了。
在 Swift 中，由于可以使用命名空间了，即使是名字相同的类型，只要是来自不同的命名空间的话，都是可以和平共处的。和 C# 这样的显式在文件中指定命名空间的做法不同，Swift 的命名空间是基于 module 而不是在代码中显式地指明，每个 module 代表了 Swift 中的一个命名空间。也就是说，同一个 target 里的类型名称还是不能相同的。在我们进行 app 开发时，默认添加到 app 的主 target 的内容都是处于同一个命名空间中的。
- 在swift 中存在命名空间，同一命名空间下全局共享.
- 第三方框架使用：直接拖入项目中，从属于一个命名空间，很可能冲突（所以尽量用cocoapod）
- NSClassFromString(反射机制)： 最重要的目的，就是解耦 。例子：（反射机制和工厂方法）
获取命名空间设置根控制器
func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplicationLaunchOptionsKey: Any]?) -> Bool {
// Override point for customization after application launch.
window = UIWindow()
window?.backgroundColor = UIColor.white
let CFName = Bundle.main.infoDictionary?["CFBundleName"] as? String ?? ""
//点后面是所需 类名
// let vc = Bundle.main.nameSpace() + "." + "ViewController"
let vc = CFName + "." + "ViewController"
let vcType = NSClassFromString(vc) as? UIViewController.Type
window?.rootViewController = vcType?.init()
window?.makeKeyAndVisible()
return true
}
bundle的分类
