OC、Swift混编并使用pod模块化的那些坑与解决方案

• 如果编译时自动生成的Swift.h报找不到,把改成就好了，Xcode的bug。详见这个issue
• 可以在pod 的demo项目里配依赖pod的:path，避免从网络拉取，加快迭代速度
• pod spec里resource和resource-bundle是有区别的。resource-bundle会在当前改pod的bundle里再加一个bundle，个人认为不是特别有必要。
• 如果只需要一个模块里一个子模块，就用在所需模块里定义subspec（比如App Extension里不能有对UIApplication.sharedApplication的依赖，另起一个pod有感觉没必要）
• 用Swift时NCClassFromString的参数要用 bundle.className， bundle就是pod名或者主项目名，因为这个原因感觉router的action最好使用OC实现
• 有时候自动生成的-Swift.h会 #import ，然而编译这个文件的时候Product模块还没编译完，直接报错，报错了后把这一行删了就好，目前没找到更好的解决方案。。。。
• 有些pod有对静态库的依赖，注意 在source_files和vendored_libraries里 都 包括静态库，并且多加一句s.pod_target_xcconfig = { 'OTHER_LDFLAGS' => '"-ObjC"' }
• performSelector所对应的函数一定要有返回值……不然会崩……
• 同一个pod里Swift可以直接调用OC，但是OC调用Swift时需要把权限设为public
• 如果所依赖的pod里有vendored_framework且该framework没有modulemap且又要在swift里调用。。。乖乖写bridge header里吧。。。