- 所有的UI操作,都要切换到主线程中进行.否则,会发生莫名其妙的错误.
- 在主线程中，runloop默认是开启状态的。非主线程中，如果要用到runloop，必须手动开启runloop。关于runloop知识。
- 对于常见的EXEC_BAD_ACCESS，EXC_BAD_INSTRUCTION，错误，一般都是因为访问已经被release的对象造成的。尤其是在一个线程中访问另外一个线程的autorelease库中的对象，尤其要注意此类问题。
- 严格遵守iphone 内存管理手册,对于不是由你创建的对象,不要越权release,否则,可能会导致程序crash.有时,一些看起来非常严重的bug,在经过N过次努力,多种思路尝试fix之后,再回头分析bug产生的原因,你会发现,造成这个严重bug的原因,很可能是你违反了一个众所周知的规则引起的.这个规则你非常清楚,熟悉,但就是在coding的时候,稍不留神违反了它.于是就带来了灾难性后果.
- 除了面向对象的cocoa外，iphone编程不要忘记非面向对象的Core Foundation。 面向对象库里很多没有的功能，可以尝试在Core Foundation里找找。披如：RSA算法，MD5算法，SHA1算法，AES加密算法等，cocoa对象库里并没有相应的实现，但在core foundation里，均有相应的实现。NSString类里没有的字符串编码GBK，GB2312，GB18030等，在CoreFoundation里，能找到相应的编码。建立socket连接，获得输入流和输出流时，也需要使用Core Foundation里的CFNetwork api。等等。
- 通过设置NSZombieEnabled参数，有非常有效帮助解决内存释放错误。
- 在消除某个对象时，如果为该对象设置了delegate,则需要先将delegate设成nil，这是一种良好的代码习惯。
- 在3.0 的Simulator上使用Instruments 检测内存泄漏时,无法看到函数名,只能看到一些地址指针.在3.1,3.1.2,3.1.3的simulator都正常,能够正常地看到是在哪个函数中存在的内存泄漏.
- 通过Nib文件加载viewcontroller的各种UI控件时时，在viewDidLoad函数里，viewController的控件才能使用。在viewcontroller的构造函数里，nib里的控件都还没有完成链接构造呢。
- iPhone程序崩溃不要着急。可以结合使用Console和objc_exception_throw可以快速定位根源所在。
- 在CFNetwork中，有时候使用CFWriteStreamWrite方法写数据时，会导致该现成被长久block住。原因：在CFWriteStream不能接受数据时，写数据了。具体解决办法：在CFSriteStream收到异步的kCFStreamEventCanAcceptBytes通知时，再开始写数据。此时可避免CFWriteStreamWrite导致线程被block的情形。
- 使用Eavesdrop 抓取网络数据包。
- 在Iphone上有两种读取图片数据的简单方法: UIImageJPEGRepresentation和UIImagePNGRepresentation. UIImageJPEGRepresentation函数需要两个参数:图片的引用和压缩系数.而UIImagePNGRepresentation只需要图片引用作为参数.通过在实际使用过程中,比较发现: UIImagePNGRepresentation(UIImage* image) 要比UIImageJPEGRepresentation(UIImage* image,1.0) 返回的图片数据量大很多.譬如,同样是读取摄像头拍摄的同样景色的照片,UIImagePNGRepresentation()返回的数据量大小为199K,而 UIImageJPEGRepresentation(UIImage* image,1.0)返回的数据量大小只为140KB,比前者少了50多KB.如果对图片的清晰度要求不高,还可以通过设置 UIImageJPEGRepresentation函数的第二个参数,大幅度降低图片数据量.譬如,刚才拍摄的图片,通过调用UIImageJPEGRepresentation(UIImage* image,1.0)读取数据时,返回的数据大小为140KB,但更改压缩系数后,0.5)读取数据时,返回的数据大小只有11KB多,大大压缩了图片的数据量,而且从视角角度看,图片的质量并没有明显的降低.因此,在读取图片数据内容时,建议优先使用UIImageJPEGRepresentation,并可根据自己的实际使用场景,设置压缩系数,进一步降低图片数据量大小.
