分类： Mac Dev

XCode 4免证书真机调试

本文转载总结自世界各地,如有侵权还请见谅.

目前可以保证是最简便的方法

方法如下:

  • 创建证书,这里不多说了,直接参考这里创建证书的步骤,不要做除创建证书以外的工作
  • 终端: sudo /usr/bin/sed -i .bak 's/XCiPhoneOSCodeSignContext/XCCodeSignContext/' /Developer/Platforms/iPhoneOS.platform/Info.plist (其实就是把这个Info.plist中所有XCiPhoneOSCodeSignContext改成XCCodeSignContext,手动替换也可以)
  • 修改项目配置里面的TARGETS:选择ALL找到Code Signing Identity,选择iPhone Developer (这里说的不太明白,大家试一下就知道了)

此时你应当重启下XCode尝试一下是否可以通过真机运行（此时应当是app能装到真机上但是会出现一个错误不能debug，程序也没运行，但是可以像正常应用一样点击运行了，要想可以debug应当做最后一步的工作）

  • Xcode的File菜单上，File >> New >>New File >> iOS >> Code Signing >> Entitlements 新建一个Entitlements.plist,然后在之前修改TARGETS的地方找到Code signing Entitlements,键入:  ./你的项目名/Entitlements.plist（这个路径取决于Entitlements.plist的位置） ,接着运行试试吧!

PS. 如果仍未成功，回复中的内容可能对你有帮助。

–以上–

在iPhone/iPad/iPod上查看iOS文档

7.26更新:iPad基本不用看了,拿模拟器试了下发现官方文档对iPad支持甚好,而离线版缺少对iPad的支持,无法通过Safari打开

苹果的官方文档甚是强大,对开发的各个方面都进行了及其详尽的介绍,作为开发者当然要时常翻看,本地的文档只能在电脑上看,要想用我们的iDevices查看文档只好连网看在线版的,但由于网速限制不够有效率,官方文档虽然支持转换成PDF,但是转换速度很慢,转换后一堆超链接也失效了.另外我找了好久也没有一个叫"Procket Documentation"或者类似的App,实在有些遗憾.

这里有一个不太完美的解决方案:官方文档虽然都是docset格式的,但其实右键显示包内容一看就是一堆html,css啥的,和在线版的文档一样完全可以用浏览器解决,所以只要把docset里面的Documents文件夹拖到你的iDevices里面就行了,如果你没有越狱就用GoodReader啥的看吧,不过我用iPhone 4测试效果不太理想,文档首页加载奇慢,而且显示不全,那个搜索不知道好不好使,太卡没法测试,iPad 2不知道效果能怎么样,有iPad 2的同学试验下最好在评论中说下效果,别的页面也可以直接浏览,不过效果没有桌面版的Safai那样好,排版似乎有些问题(不是大问题,试下就知道了),但是不影响看.

如果越狱了,可以在Cydia里搜索下lighttpd,安装,最好也安装一下Lighttpd SBSetting Toggle,安装后重启,然后就可以用Safari访问127.0.0.1了.(这里只介绍下安装那个Toogle后的使用方法,Lighttpd SBSetting Toggle的说明中提到webroot地址是/var/www,配置文件是/etc/lighttpd2.cong,用默认的配置文件访问127.0.0.1就可以直接看到/var/www下的目录.只要把之前提到的Document文件夹放这里就行了,接下来怎么做就不用说了吧.) 用自带Safari打开文档,文档首页依旧很卡,但是比GoodReader强多了,而且搜索也勉强可以用(iPhone 4测试,其他不知效果如何),其他页面和GoodReader浏览效果一样,都是排版有点问题,不影响效果.

目前为止也没做太多测试,现在正考虑用其他浏览器看看效果是否能好些(Operamini试了下根本不行),如果有发现就会更新这篇文章,没有就这样了.

其实这个方法也可以用来查看Android文档什么的.

–以上–

PS:搜狗输入法Mac版真TM2(Ver 1.1),中文标点那个选项没有记忆,切个输入法就又回到默认值了,写这篇文章净折腾全角半角的问题了.另外所谓的词库也就那回事,跟Win版没法比.

推荐:XCode 4视频教程

上一个项目做的差不多了,所以这几天尝试了下XCode 4,发现4与3的区别蛮大的,快捷键也改变了不少,一些功能也不知为何被精简了,比如User Script(应该是被Code Snippet代替了,不过感觉没有Script强大). 看文档实在太麻烦,上网找了找相关资料,发现之前的Become Productive in XCode系列又专门为XCode 4做了10个视频,而且这回是免费的,果断下载过来分享,毕竟看视频要比看文档直观多了。

这里还有个快捷键的PDF

XCode 4的这几个视频虽然感觉不如3的那么经典，但是作为XCode 4的快速入门还是相当有价值的。如果上面那些由于某些原因无法下载,我这里还提供一个115的下载地址，Have Fun。

PS:这篇介绍XCode 4之前的文章都是以XCode 3为基础的,要查看XCode 3的有关文章请通过标签或搜索查询.

–以上–

NSLog对程序性能的影响

NSLog,既可以像printf那样方便地格式化输出,同时还能输出时间以及进程ID等信息,可谓调试利器.但是其实NSLog对程序性能也有不小的影响,在执行次数比较少的情况下可能看不出来什么,当短时间大量执行的时候就会对程序执行效率产生可观的影响.

我遇到的一种情况就是我在一个UIScrollView子类的layoutSubviews方法中输出了很多次log,而这个layoutSubviews本身又有相对繁重的工作要做,由于每次拖动这个UIScrollView都要调用很多次layoutSubviews,因此程序实际运行起来拖动体验就非常差,卡顿现象严重,多次测试发现注释掉所有的NSLog后拖动就变得正常了.

综上,当你疑惑是什么导致了你的程序运行效率很差的时候不妨注释掉那些NSLog试试,你的问题也许就迎刃而解了.

–以上–

[下载]XCode技巧视频教程

这个视频教程之前在这篇文章里提到过,总体来讲是个非常不错的教程,从基本的快捷键到各种TextMarco,自定义脚本等统统介绍了一番,话说"工欲善其事,必先利其器",这个视频教程算是"利其器"必备.

视频以XCode3为基础,XCode4我还没装,某些地方会有挺大区别,这些地方自己查查就好了,等我安装XCode4后会出一个简单的教程介绍一下有区别的内容(不过短期内不会了,所以不要指望我)

支持原作者请通过这篇文章的相应连接寻找.

原版已经不能从官网下载到了, 放出个下载地址

 

关于lvalue required as left operand of assignment

这种错误发生的其中一种情况:

UIView *aView;
aView.frame.size = …….;

第二行会报错,提示lvalue required as left operand of assignment

这里有关于这个错误的解释:

点操作符有两种用法:

1.调用成员变量的getter setter

2.访问结构体

当在等号左边时这两种不能混用,右边可以,所以还是要用这种方法来实现:

aView.frame = CGRectMake(…..)

这只是lvalue required as left operand of assignment错误出现的一种情况,估计其他的也可以类比解决

–以上–

Objective-C: delegate的那点事儿

Delegate算是Objective-C的一大特性, 关于Delegate的基础就不多介绍了, 有兴趣的请参看文档.

这里仅对Delegate使用中的一些问题做点讨论

我们用Delegate很多情况下是基于多线程的,比如我们有一个ViewController在这个Controller里面进行了一个下载图片的操作,下载成功后需要通过protocol来现实下载成功, 但是当ViewController已经被release,而下载工作才结束, 那么下载工作的[delegate didFinishDownload] (暂且就这么命名吧) 就会产生一个异常,因为你给一个deallocated的对象发送了一个消息.

那么,如何解决这个问题呢,首先我们可能想到用if (delegate == nil) 来判断delegate是否存在,但其实这是不行的,因为已经dealloc的对象并不是nil.要知道Objective-C中给nil发送消息是可以的,所以如果这种方法可行,其实我们就根本不需要if这句,[delegate didFinishDownload] 给nil发送了一个消息也不会出现异常,因此这种方法只是重复了上面的错误.

还有一个叫[delegate respondsToSelector:SEL]来判断delegate是否响应一个Selector, 根据上一段的描述,我们也可以判断出这个也是不行的.这里额外提一点关于respondsToSelector的东西,要使用这个方法,必须有@protocol MyProtocol <NSObject>,因为respondsToSelector是NSObject的一个protocol方法.

既然要防止delegate被release,那么retain这个delegate是否可行呢?这么做虽然避免错误的发生,但是也产生了另一个问题,这就关系到Objective-C内存管理中的Retain Circle, 即:有A,B两个Object, A中有一个B的实例变量,B中又有一个A的实例变量,要release A就必须releaseA中的B,而要release B有必须release B中的A,这样就产生了一个Retain Circle,A B都不能被dealloc.解决Retain Circle的方法就是使用弱引用(weak reference),弱引用没有被引用的那个Object的所有权,也就不需要release它,从而解决了Retain Circle问题.为了防止Retain Circle的发生, delegate通常都是弱引用的, 因此我们一般不应该retain一个delegate.但是似乎有一个例外:NSURLConnection, 网上对其的讨论结果是:NSURLConnection会retain它的delegate,详细可以参考StackOverflow上的这个问题

似乎没有简单可行的方法来解决这个问题(至少在本文发表时我还没有找到),那么我们只能在通过程序结构的设计来解决这一问题了,对应不同的程序自然也就有不同的解决方法,我想到的一种就是在这个ViewConrtoller被release的时候,把下载方法中的delegate设置成nil即可(目前测试可行, 如有错误还请指正).

更新几种解决方法：

–以上–

XCode SVN 设置指南

经初步测试，使用本文的方法，可以解决文件丢失，commit错误（Error: 155005  Working copy not locked..等）等问题

  • 修改svn配置文件
svn的配置文件在~/.subversions/config
修改方法：
1.找到 global-ignores 一行，去掉注释用的“#”，编辑（添加）成 global-ignores = build *~.nib *.so *.pbxuser *.mode *.perspective*
2.找到 enable-auto-props = yes 把注释去掉（这步似乎可以忽略）
3. 在[auto-props] Section添加以下内容
     *.mode* = svn:mime-type=text/X-xcode
     *.pbxuser = svn:mime-type=text/X-xcode
     *.perspective* = svn:mime-type=text/X-xcode
     *.pbxproj = svn:mime-type=text/X-xcode
 
关于修改配置文件的更多讨论在这里
 
  • SCM Config
XCode 菜单中 SCM >> Configure Repositories
 
按 “+” 添加一项
     Name：任意
     URL：svn://[email protected]/opt/ibmtc/SUBPATH 然后按tab切换 下面那几个除了Password都自动填好了
     Scheme: svn
     Host：svn.footoo.org
     Path：/opt/ibmtc/SUBPATH
     User: USERNAME
     Password: PASSWD
下面有个指示灯，如果显示绿色并有Authenticated字样则表示设置成功
  • 添加项目
1. 如果不是新建的项目 直接到第二步 SCM >> Repositories 选择好对应目录 点Import选择想要进行版本控制的项目（最好是“干净”的项目 即没有.svn文件夹 否则可能有一些错误）
2. 在刚才的窗口选择刚添加的项目 Check out，相当于用svn对项目进行初始化，加入一些控制信息。这一步很重要，缺失了将不能进行版本控制
3. 打开Check out下来的项目 打开项目属性窗口 >> General >> Config Roots & SCM…  下拉按钮选择Subversion 下面的table中的Repository选择你之前在Configure Repositories中添加的那个，一般都会有Recommended字样
 此时在菜单 SCM中就多出了很多项目
在左边的项目树中，邮件点击表头，选择SCM可以多出一栏现实项目修改信息
文件的标示状态简介如下: 

Cocoa中的weak reference

以下所有内容翻译自官方文档，如有不当之处还请各位指正。

Weak Reference to Objects（弱引用）

————————————————————————————————————

retain 一个 object 创建一个 “Strong” reference，一个object在直到它所有的strong reference都release了之后才能dealloc，因此object的生命周期是受它的Strong reference的所有者控制的。某些情况下，这种行为不是我们所期待的，你也许想有一个不会阻止一个object dealloc的reference，这种情况下，你就拥有一个“Weak” reference，weak reference是通过存储一个不retain相应的object的指针所创建的。

 
weak reference在会有循环reference要创建时是必要的。比如，如果Object A和 B之间互相Communicate，它们各自需要一个对方的reference。如果它们各自retain了对方，那么直到它们之间的Connection切断之前它们之中任何一个都不会dealloc，但是它们之间的Connection要等待它们其中任意一个dealloc了之后才能切断，这就产生了一个矛盾。要解决这个问题，其中一个object作为一个次级（subordinate）角色并且拥有对方的一个weak reference。一个具体的例子，在一个view继承体系中，一个parent view拥有并因此retain他的childe views，但是一个child view不拥有它的parent；而又必须知道它的parent是谁，所以就有一个指向它的parent的weak reference。
 
Cocoa中另一些weak reference的例子包括但不局限于这些：table data sources，outline view items，notification observers，各种targets和delegates。（比如一个NSTableView不会retain它的data source，一个NSApplication不会retain它的delegate）
 
当你需要向一个你只拥有weak reference的object发送消息时，就要小心，那个object是不是已经dealloc了，如这这样会使你的程序Crash。
后面又是一些例子（delegate 和notification），不翻译了。

用NSZombieEnabled解决恼人的EXC_BAD_ACCESS错误

更新Xcode 4设置NSZombieEnabled方法:
按住Option点Run按钮,在出现的窗口中选择Arguments,在Environment Variables里面添加NSZombieEnabled,Value下面添YES

以下为XCode 3的设置方法

这个方法也许很多人都知道了，但是毕竟有不知道的，比如在写这篇文章之前10分钟的我。先说明情况：昨天遇到了这样的问题，程序突然Crash，出现EXC_BAD_ACCESS错误，但是不是每次都Crash，有几次RP高了就好使，Debug时最终基本停在objc-msgsend这里，但也不是每次，是大部分（90%）。十分令人费解，搞了几个小时无果，求助google和stackoverflow终于解决。

首先解释下EXC_BAD_ACCESS，当你向已经释放的对象发送消息时就会出现这种错误。

至于NSZombieEnabled，就是当设置NSZombieEnabled环境变量后，一个对象销毁时会被转化为_NSZombie，个人感觉和线程的那几个状态有些相似，设置NSZombieEnabled后，当你向一个已经释放的对象发送消息，这个对象就不会向之前那样Crash或者产生一个难以理解的行为，而是放出一个错误消息，然后以一种可预测的可以产生debug断点的方式消失（原文是die），因此我们就可以找到具体或者大概是哪个对象被错误的释放了。

设置NSZombieEnabled的方法如下

  1. 在XCode左边那个Groups & Files栏中找到Executables，双击其中的一项，或者右键Get Info；
  2. 切换到Arguments
  3. 这里一共有两个框，在下面那个Variables to be set in the environment:点+号添加一项，Name里填NSZombieEnabled，Value填Yes，要保证前面的钩是选中的。

好了，赶紧去找哪里出了问题吧，至于取消NSZombieEnabled，就是吧刚才提到的那个钩取消即可。

最后总结一下感想，首先是我对EXC_BAD_ACCESS这个错误还没有足够的认识，其次是我没有尽快的去搜索一下解决方法，这两点导致我浪费了大量时间做各种各样奇怪的调试。幸好现在解决了，可以继续工作了。

2012.02.15更新：

在debug过程中，你可能发现启用NSZombieEnabled后，程序不再crash，而一旦去掉NSZombieEnabled，程序再次crash。此时NSZombieEnabled已经无法解决你的问题，只能遵照内存管理原则仔细查找问题出处，至于这种问题的产生原因，个人认为可能是NSZombieEnabled在一定程度上延长了一个object的生命周期，而延长的这段时间恰好突破了EXC_BAD_ACCESS的临界点，从而避免了EXC_BAD_ACCESS的发生。

–以上–