基本篇
为何对一个自变量release后还需要设成nil
对一个自变量release后，这一自变量偏向的内存优化了，但这一自变量自身没变，仍偏向原先的基址。若这一自变量在释放出来后被浏览，或是被反复release，便会造成 运用奔溃。设成nil后这一自变量偏向0×00，能够确保程序流程之后浏览不上原来的基址，对nil开展release也没一切难题。
应用类组员时，前边加不用self.有什么不同
不用self.启用的是组员自身，加self.后事实上启用了其组员的get set方式 。
例:
//.h
@property (nonatomic, retain) NSString *name
//.m
name = @"bang" //沒有retain，随时随地会被释放出来
NSString *str = self.name //相当于NSString *str = [self name];
self.name = @"bang" //相当于[self setName:@"bang"]; 这时候在set方式 里retain了这一字符串数组
方法篇
内存泄漏
能够根据xcode的编译程序专用工具Product-Analyze查验涵数块范畴内很有可能的泄露点(携带会提醒一些很有可能有的不正确)。
用leaks专用工具检测出去的泄露搜索方式 是追踪其编码提醒中发生的自变量，常常这一自变量是在提醒的启用局部变量之外的地区泄露的。若确实查不出，最后方法是调用这一自变量的retain和release方式 ，debug，从启用局部变量看到底是谁retain了它而沒有release。
要留意的是，用CFXXCreate(比如CFArrayCreate)转化成的自变量得用CFRelease释放出来。
数据储存
如无检索*须，能够将一个数据信息目标立即实例化后存进sqlite，取下时立即反序列化为目标应用。实例化*须数据信息类完成NSCoding协议书，完成encodeWithCoder和initWithCoder2个方式 就可以了，若有好几个数据信息目标，能够写个基类完成这两个方式 ，并在这里里边运用反射面枚举类型本身全部自变量去encode和decode，一劳永逸，实际完成在网上找找就拥有。
部件篇
UINavigationController首尾表明掩藏
在使用NavigationController去管理方法view的push和pop时，*须依据不一样的view设定是不是表明NavigationBar和ToolBar，一开始在不正确的地区设定了，造成 有时候该表明NavigationBar和ToolBar时无法显示的状况，之后发觉在viewWillAppear上设定万无一失。别笑我土鳖，没好好地去了解它全部步骤，一直没发觉。
- (void) viewWillAppear:(BOOL)animated{
[super viewWillAppear:animated];
[self.navigationController setToolbarHidden:NO];
[self.navigationController setNavigationBarHidden:NO];
}
UITableView游标卡尺式3D渲染
tableView的体制大约是：定好好总公司数，某一行滚入主视图范畴时，回调函数一个涵数取走view出去表明。这一行离开主视图再滚时尚仍会再次回调函数这一涵数取view。有那样的体制就是不管你table里的数据信息有多少，都能够所有放进table中无需分页查询，由于无需一次性把全部数据信息都取下来，只在*须表明的情况下依据游标卡尺取走相匹配的数据信息就可以了。
很有可能它是APP部件很当然的方法无需表明，但在web上网页页面上的数据信息和原素全是要一次性加载运行内存的，做久了web，一开始想不到它那样的完成体制，造成 大家离开了许多弯道。
UIWebView3D渲染范畴
UIWebView并不是依据可视性范畴决策每一次的3D渲染范畴，只是依据本身控制的frame大小决定。
曾试着webview嵌在tableview里，为了更好地让webview跟tableview一起翻转，把webview的尺寸设成webview里的內容尺寸，让webview出不来下拉列表，进而能跟随tableview的下拉列表一起滚。那样做的不良影响是每一次webview都一次性3D渲染全部网页页面，内存占用多特性很差，并且在变大变小这一webview时，3D渲染变大的全部网页页面更费劲，发生不可以承受的特性。解决方案是让webview定住高宽比为一整屏iphone的高宽比，限定了webview每一次的3D渲染范畴为可视性范畴，特性很好。产生的难题是没法随tableview翻转，但能够以别的方法提升感受。近期见到新版本的ZAKER也是那样做的。
我觉得篇
页面合理布局十分不便，令人怀恋web了。页面叙述方式 XIB觉得晦涩难懂难学，迄今不容易，沒有CSS HTML来的便捷。
有c语言编译器严格把关，少了像写js时多写or填错一个字符查大半天的难题。
Object-C写起來各种各样自变量涵数和自变量启用较长，沒有js的言简意赅来的爽。
**次撰写涉及到手动式代码优化的程序流程，挺有趣，没想像中难，但有一些代码优化造成 的bug难以查。
尽管APP并不像web那般随时随地升级，但都不像传统式PC手机客户端升級那麼不便，客户升级意向更强，或是合适快速迭代的。
关键点是能够决策成功与失败，但得看你将哪些定成关键点。
最终，0 bug的程序流程不会有，完美是把最关键的事搞好。done is better than perfect。
