概述
XCode项目中的文件夹分成两类: group 和 directory reference, 分别是虚结构和实结构. 黄色的 group 是默认的格式, 它的结构和磁盘上的文件夹毫无关系, 仅仅表示资源的逻辑组织结构, 这在管理源文件是非常方便. 同一段代码可以被很多项目使用, 也可能只使用一个目录的部分文件, 它不需要被拷贝到当前项目中, 但可以在当前项目中保持一个清晰的逻辑结构. 而且引用头文件时不需要指明复杂的层次结构, 因为这些文件在XCode看来是 flat 的, 即它们处在同一层文件夹里.
但是 group 带来便利的同时也导致更加棘手的麻烦, 文件重名冲突问题; 尤其当你要使用上千个资源文件时, 这种问题已经极难避免; 而且, 资源文件一般是要拷贝到目标程序中的, 虽然它们在项目中可以有结构的组织, 但是复制到程序中时将会 flat 地输出到程序的根目录中, 这将是怎样的一个灾难! 同时, 如果你在外部向文件夹中加入了上百幅图片, 你不得不把它们再向xcode中加入一遍. 归根结底, 还要求助于我们传统的蓝色的 directory reference.
但是, XCode 偏偏还要抽风, 就是不让你用的安稳. 存在的问题有两点. 其一, Interface Builder(IB) 不支持directory reference! 尼玛, 几乎所有的 IDE 都采用的默认项目管理方式, 非但设成非缺省模式, 而且 IB 压根就不支持. 放狗去搜"interface builder directory reference", 答案只有一个, "it is impossible!" 其二, build 程序是, 资源只会 只增式拷贝! 什么意思? 当你在资源文件中加入一个图片时, ok, 没有任何问题; 可是当你试图删除哪怕修改一个资源时, no no no, you cannot do that! 所以当你调了半个小时还没明白, 卧槽, 图片明明换了, 怎么还是这个样子? 当然了, 解决方案是乖乖的 clean build directory, 然后再 build. 差异检测就这么难么? 感谢 David Frampton 为我们在这个问题上画了个较为圆满的句号: 在项目生成步骤中复制资源前增加一个脚本
Touch -cm ${SRCROOT}/(你的资源文件夹)
更新资源文件夹的 modification timestamp, 保证资源强制更新.
那么最终有没有好的解决方案涅?
完美的方式 - 没有
但有两个曲线救国的方针:
方案一:
同时维护 Real资源文件夹(directory reference)+Virtual资源文件夹(group) , 前者是所有资源所处的目录, 为代码编程地加载资源使用; 后者只维护 IB 中使用的资源. 这种方式的缺点是, 后一个文件夹里的资源会在输出项目中存在两份, 增加程序体积.
方案二:
只维护一个 Real资源文件夹(directory reference), 在 IB 中使用嵌套路径加载资源; 在 XCode 开发时, 你无法从 IB 中看到加载的资源效果, 但在运行时就没有问题了.
鱼与熊掌, 不可兼得.
参考资料:
http://maniacdev.com/2010/08/how-to-use-xcodes-folder-references/