标签： 心得

[iOS]一个 iOS 8.1 上关于 UINavigationController 的 NavigationBar 混乱的 Bug

首先说明, 这是一个会在 iOS 8.1 模拟器上稳定复现的关于 UINavigationController 的 bug, 在 iOS 8.2 已经修复, 在 8.1 的真机上会出现但不肯定会稳定复现, 因为在我查明这个 bug 的原因的时候, 我手头的设备刚刚升级到 8.2, 所以也没法测试了. 8.0 的系统完全没有测试过, 7.x 的系统可以肯定没有这个问题. 既然这个问题修复了本文也本没必要写, 但考虑到可能有些越狱用户会停留在 8.1 系统, 为了让其他遇到同样问题的开发者可以找到解决方案, 所以还是发一下.

这个 bug 的具体复现方法如下:

  1. 准备三个 UIViewContoller(vc1 vc2 vc3), 三个 viewController 的 title 分别设置为 @”1″, @”2″, @”3″. vc1 和 vc2 均实现 - (BOOL)prefersStatusBarHidden {return YES;} 方法, vc3 保持原状.

  2. 将 vc1 作为 UINavigationController 的 rootViewController, push vc2, push vc3.

  3. 点击 navigation bar 上面的返回按钮, 可以发现 UINavigationController 本应 pop vc3, 到达 vc2, 但实际上, 虽然 pop vc3, 显示了 vc 2, 但是 navigation bar 的 title 却显示为 @”1″, 如果你的 vc1 上设置了自定义的 barButtonItems, 那么这些 barButtonItems 也会同样显示出来. 换句话说, view 只 pop 了一层, 但是 navigation bar 却直接跳了两层. 更进一步, 如果在 vc1 前还有 vc0, vc-1… 那么你可以发现在逐一 pop 这些 viewController 的时候或有 viewController 被跳过.

Bug 的原因就是三个 viewController 的 prefersStatusBarHidden 设置不统一, 改成一致后就无此问题.

既然是系统的 Bug, 那就只能避免, 没法修复. 万幸的是这种 bug 的产生情况应该比较少见, 而且新的系统已经修复.

测试代码在 github

–以上–

[Xcode]如何在command-line下编译带有sub-project的项目

针对含有sub-project的project, 在依赖关系正确设置(关于如何正确设置, 参考本文最后提供的链接)的情况下, 如果直接用下面命令, 基本上编译会出错, 提示找不到sub-project里面的头文件:

xcodebuild -target TestApp -configuration Release clean build

这个命令会在当前目录下创建一个build文件夹, 然后将编译的中间产物和结果放进去, 而Xcode GUI在编译时是将这些放到DerivedData下面, 这一区别导致了在编译时找不到sub-project包含的一些东西.

解决方法很简单, 加上-scheme, 命令如下:

xcodebuild -scheme TestApp -target TestApp -configuration Release clean build

指定了-scheme之后, 命令行编译的行为就跟在Xcode GUI下编译一样了.

如果使用添加header search path的方法, 也能让编译通过, 但其实不是最正确的方法, 因为在GUI下编译不需要这一步.

如何正确设置sub-projct, 及本文参考见这里

Objective-C代码格式整理

团队合作中代码风格一致比较重要, 像Google NewYorkTimes这些公司都公开了各自的Objective-C代码风格, 有需要的搜索一下就可以找到, 这里主要介绍借助Uncrustify自动整理代码格式的一些技巧.

Uncrustify: Source Code Beautifier for C, C++, C#, ObjectiveC, D, Java, Pawn and VALA, 篇幅及时间有限, 没必要过多介绍, 总之是一款定制性很高的代码格式整理工具, 但高定制性意味着配置起来很烦, 所以这里推荐一个开源图形界面配置文件编辑器UncrustifyX, 这个工具对各个配置都有详细的说明, 并且有直观的预览功能, 可以较为方便地编辑出你需要的配置, 当然更方便的方式是直接搜索别人写好的配置文件, UncrustifyX本身就带一个.

其他的关于如何安装, 如何更方便地在Xcode中使用, 可以参考这篇. 本文不再详细说明.

最后要说一下Uncrustify的一个缺点(Feature):Xcode会自动对代码中的空行添加空格缩进, 这样会对编辑代码带来方便, 而Uncrustify会删除所有行尾多余的空格, 这就意味着如果你用Uncrustify对一个已有的代码进行处理, 所有的空行缩进都会被删除, 产生大量无意义的diff, 同时影响下次编辑. 如果你期待可以通过配置文件来改变这个行为, 那恐怕就要失望了, 而且Uncrustify的作者基本上也明确表示了不会添加这个功能(现在有个issue, 里面有几个人在求这个功能).

这里提供一个简单技巧, 轻松解决这一问题, 在Xcode中, 我们可以通过全选代码, Move Line up(option+command+[) + Move Line Down(option+command+]), 来自动添加回那些消失的空格, 上面说的那个问题也就迎刃而解了. 另外说一下, AppCode自带的代码格式整理, 估计也是用Uncrustify实现的, 所以跟Uncrustify一个毛病.

–以上–

[iOS]Learning iOS，the Beginner’s Guide

开篇扯淡是惯例（其实这个博客是一个AI维护的你信么？）， 又是一个多月没写东西，折腾各种东西，写不出来什么有营养的，也就放着了。本文虽然谋划已久，但一直都没动手写，在iOS这块，虽然坚持2年了，但还是担心会误导别人，不敢写这种类型的东西。最近要集中点别的技能点，iOS会放缓，先把这篇放出来吧，供大家参考，为了方便搜索，给本文起个中文标题：学习iOS，从菜鸟到小强。

啰嗦版

先说下我开始折腾iOS这块之前的知识背景，“碰过“C/C++，“看过”Java，“碰过”Android，当然这些都是比较保守的说法，不过也基本可以认为就是大菜的水平，认为什么都不会也可以，但是有过几个较完整的项目经验（比如我写过俩android小破项目）。

开始的时候，我的路线是在基本什么都不会的情况下，以一个不大不小的项目驱动，快速产出，这里最重要的一点就是学会如何在什么也不懂的情况下搜索到你想要实现的那些东西的代码，或者是相似的代码，然后就是如何照猫画虎把别人写的几块东西改改，用胶水代码沾一起，形成一些“能用的”东西，快速的产出有助增强信心，有效避免半途而废，同时一旦开始写代码了，所学到的知识就自然而然记牢了，不会发生看一遍忘一遍这种情况。

当然如果我这么建议别人，一些大神就会喷了（比如这个：【豆瓣校招-面试官发声】近期面试感受），说这种搜索式学习方式会打下不好的基础，因为你接触到的都是二手，三手以上的信息（这里定义一下，一手信息为文档，质量最高，二手信息可以认为是StackOverflow这类，也很不错了，三手就是这个链接里所表达的那个“二手”），对这些信息就要比较谨慎，有些东西可能太过技巧，不是一种好的解决方法，另外就是难免有错误，而且这个错误可能会被你继承很久，因为是新手，你会倾向于相信所有“好使“的代码。

这些弊端确实存在，不过恭喜你学习的是iOS，只要将你寻找问题解决方法的搜索范围限定在官方文档，WWDC视频，StackOverFlow上就可以了，这些都是一手二手的信息，而且一手信息占了绝大多数，基本可以保证信息的优质性，同时也完全足够解决问题了。当然多看看其他人写的东西也是有好处的，学习不要死板，这里的限制只是在避免上一段提到的问题，搜索式学习虽有弊端，但还是要比啃一手资料快很多，对于优先实现功能是很有必要的，关键就是要和一手资料结合着用，如何掌握之间的度就靠自己来衡量吧。

这里不得不提一下文档，苹果的文档是我见过的最好的文档（MSDN的也很牛，但是我没做过windows那方面的开发，所以没什么了解），这里不仅仅有对类、方法的详细说明，还有非常多的XXX Programming Guide，这种导引性的文章，从一定程度上来说，有了文档我们甚至已经不再需要StackOverflow，其实在StackOverflow搜索问题的时候，很多回答就是一个指向官方文档的链接。同时，文档中包含了大量Sample Project，这些Sample都很有针对性，清晰地展示了各种实现方法，同时Sample的代码都是高手写的，多看看Sample Project对编程能力的提升也有很高价值。额外说一句，如果你认为英文的文档太难读懂，那就只能查着字典啃，如果还是不行，你去学英文吧，要么就别搞这一行，文档的英文要求已经很低了。

WWDC视频，也是快速解决问题的必备，在接触比较陌生的一块比如音频处理的时候，先看一看WWDC相关视频，就能大概了解一下相应的实现方法，对这一块有一个比较清晰全面的认识，这时候再借助文档的XXX Programming Guide，基本就可以非常深入地学习到你需要的知识。

前面一直都没提到，书–这一重要学习工具，在我看来买书基本上完全没有必要，有文档在看什么书啊，那种讲语言，讲SDK的书没有必要买，根本比不上文档，时效性也差。当然还是有些好书值得买来看看，比如Apress的iPhone Cool Projects，和More iPhone Cool Projects，虽然比较旧，但是里面那几个项目还是很有参考价值的。

面对iOS这一快速更新的系统，新手面临的一个常见问题就是该从哪个SDK版本入手。SDK版本对于新手老手都是个问题，要想要新功能，就要高版本的SDK，要想兼容旧设备，就要放弃新功能，或者自己实现新功能，选择低版本的SDK。这里根据我的经验，如果你是一个纯新手，不着急开发产品，就从最新的SDK版本入手，因为等你出师了，当时入门的SDK版本已经是旧版了，兼容旧设备的问题就不存在了。如果要快速出产品，那就只能从低版本SDK入手了，当然有些新API就用不了了，作为新手一个能用新API很方便实现的功能却要为了兼容用很复杂的方法实现还是有些不爽的。选择SDK要注意的一点就是，在iOS 4.0以后，引入了Auto Reference Counting（ARC）这一技术，个人感觉使用ARC虽然方便了内存管理，但是对于新手来说缺少了手动管理内存的历练，这里欠下的债，将来一定要还的。所以还是推荐先看文档学习一下内存管理方法，并在此后一段时间内关掉ARC实践手动管理内存，记得用Instruments测一下内存泄露，等到基本掌握了手动内存管理，就可以开ARC了。当然，我在折腾内存管理的时候还没有ARC，所以这部分建议可能存在一点主观因素，虽然不一定是最好的路线，但总不是错误的路线。

工欲善其事，必先利其器，XCode的熟练使用，对于提高效率至关重要，关于怎么使用XCode请搜索我以前的文章，关键词“XCode”，懒，不发链接了。

以上都是以项目驱动为前提，至于这个项目，规模不要太大也不要太小，有一定升级空间，最好是没有时间限制的长期项目，这样就有充足的时间来深入研究某一部分知识点，第一个版本功能实现了，但是代码不够漂亮，效率不够高，推到重来是一个非常好的选择，反复迭代几次，大有益处。

我的入门项目就是HIT Mobile（在关于页面里面有链接，现在也基本停止维护了，实际上也没什么人用）。这个项目我和一个队友分别负责不同的功能，持续时间将近一年（当然有上课考试等因素干扰），为了代码整洁或者效率等问题，每个功能都反复写了2、3遍，这几遍推到重来对能力的提升是非常大的。

虽然做单一的项目可能接触的不够全面，但如果你是一个渴求知识的人，必然会在做主线任务的同时，走一些分支路线，接触到其他方面的知识，另外一点就是，iOS虽然是个手机上的OS，但不要忘了这是基于Mac OS做出来的系统，Mac OS这么多年历史岂是我等弱菜一两年就能接触全面的，专注一两个点深入学习下去也是一种很好的选择。

我们还没有说github，github的重要性其实根本不必多提，开源的framework，控件什么的基本都在上面。其他网站比如，CocoaControls，有很多开源的UI控件，建议订阅个RSS。此外cocoanetics，Cocoa is my girlfriend等博客类型的网站也经常会发布一些非常优秀的文章。

总之想“精通”iOS，绝对不是短时间可以做到的，贵在坚持不断学习。

精简版：

  • 项目驱动
  • 寻找帮助
    • 文档
    • WWDC视频
    • StackOverflow
    • Google
  • 书，不是很必要
  • 学习XCode使用
  • 手动管理内存，熟练以后再开启ARC
  • 找代码，开源库：github， CocoaControls
  • 好文章：
    • cocoanetics
    • Cocoa is my girlfriend
    • 等等

补充：

一些非常好的资源：

  • RAYWENDERLICH   |  简单高质量的Tutorial，涵盖iOS Mac Cocos2D Unity等内容

 

–以上–

Mountain Lion 使用感受

距离上次公告已经一个多月了，最近也不怎么太忙了，前一阵也改进了下GSBookShelf，有需要的可以看看。好久没写东西了，这篇热热身吧，没什么营养，纯吐槽，图个乐呵。

话说ML在Store上发布没多久我就升级了，应该说是全新安装了，Lion不知道是系统问题还是我折腾的问题（其实我基本没折腾什么），各种操作都异常的慢，也忍受了好久了，就等ML出来全新安装一下，所以对于Lion -> ML的升级我没什么评价的，根据周围人的情况来看，基本可以放心升级，开发环境有些要重新配置。

下面进入正题（OS X 10.8.1）：

Safari：

  • 貌似网页加载速度快了很多，但实际可能是水果用了视觉上的效果让我们感觉快了，而不是真正快了多少，这从跑分上也能体现出来。
  • 搜索和地址栏统一，对chrome用户似乎不错，但有时候如果想查找一个东西却被自动补全成网页还是有些麻烦，比如搜索apple然后自动补全成了apple.com
  • 离线阅读列表在没网的情况下还是挺实用的，打发时间利器，而且也有个类似进度条的东西显示iCloud同步进度。
  • 终于有密码保存了
  • RSS功能被阉了，曾经有这么一个nb的功能我没有珍惜，直到失去的时候才后悔莫及，世间最痛苦的事情莫过于此，如果上天给我一次参观水果的机会，我一定会去问候Safari组的PM。以上纯属调侃，不知道各位都用不用RSS，实际上这个功能让我们不用在一个页面满地寻找RSS标志，而是极其自然地点击地址栏右边那个蓝色的RSS按钮，一键订阅，自然到让我一直认为在blog上面加上一个RSS按钮是一件多此一举的事情（可以看到我现在在右上角加上了这个按钮）。幸好有网友编写了插件（Subscribe To Feed Safari Extension）也算一定程度上挽救了这个功能，但是这个插件对一个页面有多个feed的情况支持还不是很好，比如本Blog，Safari 5可以识别出一个文章feed，一个评论feed，而这个插件（1.0b4）只能识别出正文那个，1.0b3在有些情况下还只识别出评论的feed，1.0b4我刚装上还没怎么用，总之就是不如原来的好用。
  • 现在终于不转菊花了，改成直接崩溃，连反馈都没有，有时一天多达数次

Mail

  • 跟Safari一起被阉掉了RSS功能，替代品选择了Reeder，不能说Reeder不好，只是Mail用习惯了用这个有些不顺手，4.99刀价格还可以，就怕那天Google Reader被局域网干掉了，每天看个新闻也要麻烦了。
  • 检查新邮件那个按钮点击后不能转圈了，应该是开发偷懒了。
  • 来往邮件终于不分开显示了，以前在收件箱里看不到自己发的，发件箱里看不到对方发的，处理Google Groups那种邮件特别费劲。

字体

  • 默认中文字体改了，可能是为了适应retina吧，用一阵儿也就习惯了

XCode 4.4

  • 速度快了不少，尤其编译到模拟器的时候，顺秒，超爽，当然你可以说：“哦漏，休息时间变少了”。
  • 稳定性应该有一定提升
  • 新特性不少，相信搞开发的都看过了，我就不多说了，总之这是一个不错的版本，强烈建议升级。

总结

iCloud覆盖更全了，配合iOS 6一起用方便不少，与Lion对比实际没有很多的升级，19.99刀价格也可以接受，升级还是值得的，哪怕仅仅为了XCode 4.4。

–以上–

WWDC 2012 小结

低清晰度的keynote刚看完，高清1080p那个7G下了个开头就放弃了，作为一个iOS开发者简要谈下体会。

Retina MacBook Pro

之前就预测过Retina Mac几乎没有可能出现，理由就是市面上所有显卡包括台式机显卡，支持的单屏最高分辨率为2560×1600，也就是13寸MBP分辨率的Retina版，15寸的2880×1800想都不要想。可惜失算了，不知道什么时候nVidia的GTX 600M系列最高分辨率居然支持到了3840×2160，也就是Full HD的Retina版，更奇葩的是nVidia的台式机最强显卡最高分辨率依旧为2560×1600，因此不得不怀疑苹果跟nVidia在私下又合作了一次。另外最近又有新闻说iMac和Mac Pro要在明年有重大更新，在此也可以大胆预测一下，21.5寸iMac（1920×1080）上Retina从目前技术角度上来看是可能的，27寸（2560×1440）没戏，最终能否实现主要靠那两家做显卡的。

还有一点疑虑就是Reina MBP集成个Intel的显卡到底有什么用，分辨率的问题导致其不能驱动主屏幕，双屏或三屏的时候正常也是靠独显支持的，希望有条件的人去拿gfxCardStatus切换下试试，如果真的支持2880的分辨率，上面那一段就当我没说把。
如果Intel的显卡不能驱动主屏幕，那也可以看出Air和13寸MBP在以后的一两代内也不可能支持Retina，除非苹果给上独显，就算是Intel的下一代集成显卡支持高分辨率，性能上估计也很难达到要求。

Moutain Lion

Lion如其名可以算是我用过的最烂的操作系统，烂在慢，烂在各种Bug，跟SL比起来简直不在一个层面上，相信SL用户都能感受出来，都到了第四个版本了，虽然修复了很多问题，但是遗留的东西依旧不少。个人感觉，之所以没有太多人喷，是因为对于不少人来说Lion是他们用过的第一个Mac操作系统，另外Air的SSD也很大程度上掩盖了慢的缺点。综合Lion的悲剧表现我对于ML就比较期待，但以苹果最近的情况来看实在不赶抱太大希望，至于介绍的那几个新功能真正有很大用处的就是那个Power Nap了。 Game Center以但前iOS平台的游戏水准来说就是个笑话，那几个iOS游戏也就能在手机平台拿来耍耍，桌面系统玩这种级别的东西不感觉可悲么。至于未来能有什么发展就不是我等屁民可以预测的了。iCloud等附属的一系列软件还是不错的，对于用户来说只需设置个帐号，其他工作都是自动完成的，透明性非常好，但这些难道不应该在Lion中就附带么，由此可见Lion就是一个纯粹的过渡产品。

iOS 6

从升级幅度上看，iOS 6也就是iOS 5.3－5.4这个级别的，估计Bug不能多，所以很放心地升级了，主要功能新闻里都提了，我就主要谈一下他们没涉及的部分吧。

系统的整体UI有一定变化，Navigation Bar和Tool Bar的渐变方式有了改变，不算好看也不算难看，换个样子总还是有些新意的。

系统自带软件比如两个商店UI大幅改变，更美观了，自带的TODO也多了一些内容，值得一提的是Music/iPod，UI向iPad版靠拢，Cover Flow流畅了许多。

新地图对于中国区来说简直是个悲剧，AutoNavi的数据从各方面都不及Google Map，而且没有国外数据，卫星模式下全世界只有一个国家以及一个大大的红五星边上写着帝都。想用TomTom的数据对于iPhone来说也很麻烦，关键就是要开启飞行模式防止基站定位，另外一个国外的ip可能也是必要的，如果还是不行就用XCode模拟个米国地址调试一下。3D地图没条件测试，从keynote里的演示看还是很赞的，

Safai的分享按钮点击后弹出来一堆图标我就忍了，“添加到阅读列表”这个选项居然到了第二页这不是有病么？

设置>>开发者 这里多了一些内容，其中Network Link Conditioner真是相见恨晚啊，使用这个功能就可以模拟多种网络情况比如100%丢包等等，前一阵子还考虑要不要写一个这方面的程序来方便调试，iOS 6就实现了。

总结：Mac和iOS融合得好了，苹果的生态系统也更加完善了。Google和微软未来的道路又会如何呢？Google的眼镜能带来怎样的变革呢？至于iOS 6，Moutain Lion到底能带来多大变化还要看WWDC的Session才知道。

ps. 一开头Siri同学将用那蛋疼的发音讲了几个冷笑话，我是多么希望能换成GLaDOS啊！

–以上–

关于C++和Objective-C混编

Objective-C在大部分情况下足够满足我们的需求，但是还是会有一些情况必须要使用C++，比如：

  1. 使用C++的库
  2. 当Objective-C不够快的时候

第一点自然不必多说，至于第二点，Objective-C的消息机制比起函数调用还是比较慢的，当对性能有极高要求的时候，就需要C/C++来替代。

C++与Objective-C混编只要注意将包含C++代码的.m文件改为.mm即可，XCode就会自动判断该使用何种编译器来编译。

这看起来简单，但实际操作中还是很容易出现令人费解的编译问题，比如最经典的"Unknow type name ‘class’; did you mean ‘Class’?“。究其原因就是我们没有遵守这两条规则：

  • .m文件不能含有C++代码
  • .m文件所import或include的.h文件中不能直接或间接包含C++代码

在保证你的C++代码是正确前提下，如果发现相关编译错误可以通过如下几个方法修复

  1. 将.h文件中的c++代码转移到其他地方
  2. 阻段include或import链
  3. 将相关的.m文件后缀改成.mm

显然第三种方法相对于前两种实施起来更方便，但如果你使用XCode 4以及之后的版本所包含的模板建立项目的话有可能会忽视一个问题：

当你在AppDelegate.h中include或import一个C++的头文件时，当然你一定不会忘记修改AppDelegate.m为AppDelegate.mm，如果只做了这点儿还不够，我们还忽略了隐藏在Supporting Files组内的一个文件的存在–main.m

在以前的XCode模板中main.m默认是这样的

#import <UIKit/UIKit.h>;
 
int main(int argc, char *argv[]) {
 
    NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
    int retVal = UIApplicationMain(argc, argv, nil, nil);
    [pool release];
    return retVal;
}

而新的模板是这样的：

#import <UIKit/UIKit.h>;
 
#import "AppDelegate.h"
 
int main(int argc, char *argv[])
{
    @autoreleasepool {
        return UIApplicationMain(argc, argv, nil, NSStringFromClass([AppDelegate class]));
    }
}

看出问题来了吧，main.m新增了#import “AppDelegate.h"，这就导致了main.m作为一个Objective-C源文件却引入了C++代码，而Xocde会使用Objective-C的编译器进行编译，从而产生编译错误，因此我们还需要将main.m的后缀改成.mm。

总结＋吐槽：我在发现main.m这个问题之前对编译错误纠结了好久，一度修改代码，也一度怀疑是XCode本身的问题（XCode 4出奇的不稳定让人不得不对其产生质疑，虽然这次是我错了），希望同样使用Objective-C++的同学不要像我一样栽在main.m上。

–以上–

[iOS]分享最近发现的一些好东西(120311)

好久没更新了，最近在鼓捣一些Core Audio的有关内容，加上各种事儿，没有时间写东西，先把最近发现的一些好东西分享出来吧。

文章

项目

Xcode 4.3+ NSLog中文不输出Bug及解决方法

这个Bug折腾了我近一天，读一个文件，NSLog输出文件内容，结果死活读不完整，不光中文没有，英文也不全，考虑了编码，文件大小，文件位置等各种可能的因素，尝试用各种方式重写这个操作，最后发现是NSLog的问题，跟文件一毛钱关系都没有，感谢这两个链接：link1 link2 。

鉴于第二个链接已经解释的很清楚了，我这里就简要说一下，毕竟Wall还是有些麻烦

重现Bug很简单，Xcode 4.3+，用lldb在真机上运行（模拟器没有问题）下面代码：

NSLog(@"English1");
NSLog(@"中文");
NSLog(@"English2");

中文那行神马都不输出啊！如果NSLog一个NSString，String里面有中文，那么输出也会悲剧。

解决方法两种：

  1. 如果你执着于lldb，那么用Organizer >> Devices >> 你的设备 >> Console 这里会显示中文
  2. 按住Option点Run（或者 Product >> Edit Scheme…），Info >> Debugger 设置为GDB

一切回归正常，WTF!

另外有人说4.3.2解决了这个问题，事实是：没有解决！

祝愿被这个问题折腾死的人能早日看到这篇文章或者link2那篇文章。

Becareful with XCode!!

–以上–

XCode 4.3.1一个小众Bug及解决方法

哦… 首先希望闲来无事发现此文的人，可以回复报下你们一天中XCode Crash的次数，附上版本，大家比比谁受气受得多。（我：4.3.1 10多次crash）

目前测试Bug的环境：XCode 4.3.1，用svn作为版本控制
PS. 4.3可能也有这个Bug，4.2.1貌似没有，但不排除svn下的其他毛病

Bug产生过程：

  1. Project处于svn版本控制之下
  2. （可有可无）向Project中添加文件，并加入版本控制（A）
  3. 从项目中Delete某个文件，并选择Move to trash
  4. 编译的时候会有Wraning提示缺少了之前删除的那个文件（Missing File xxxx）

虽然这是一个误报，对编译没有任何影响，但是有Warning看着就心烦，而且如果删除了很多文件就会造成满屏Warning，既影响心情，又影响工作。

下面是几种解决方法

  1. 如果你对XCode 4.3＋移植抱有敌视态度，那么你的/Developer或者废纸篓里面可能还有XCode 4.2.1，用4.2.1进行删除的步骤，那些Warning就不会出现。
  2. 完全用XCode 4.3.1 + Terminal解决
    1. 对那些你要删除的并且有"A"(版本控制)标记的文件，右键 >> Source Control >> Discard Changes…
    2. 右键 >> Source Control >> Ignore
    3. Delete并Move to trash

这样编译就不会有warning，如果你删除的是一个文件夹，那么还会提示Missing这个文件夹，再或者上一步删除文件之前忘记设置ignore了，warning就会出现，用终端解决：
1. 打开终端，cd到项目主目录下
2. svn status，可以看到那个Warning的文件（夹）
3. svn rm xxxxx 从版本控制里去掉那个文件（夹）

这时再编译就不会有那个warning了，世界终于清净了

总结：XCode 4＋对svn支持非常废，经常有莫名其妙错误，要手动解决，所以一个更方便的方法就是不用svn，现在git这么火，不怕开源的项目就直接放到github上得了，保密的就放到Bitbucket上，或者找个服务器自己搭一个，总比折腾svn这些破事好，不过广大开发者最终还是应该鄙视苹果的，照这么下去苹果还是回到几年前的小众状态比较好，那时无论是SL，还是Xcode 3都是精品中的精品。现在苹果到了风口浪尖上，做东西都很浮躁，各种神奇，傻X的Bug层出不穷，老乔也不托梦骂他们几句。

懒得喷了，话说中午写的这篇，晚上发的，发现XCode 4.3.2出了，不知道老乔显灵没，如果还Crash记得上App Store评一星啊!link

更新：恭喜，XCode 4.3.2下这个Bug依旧

–以上–