UITableView性能优化？滑动的时候有种卡的感觉是为什么？怎么解决？
· 在使用第三方应用时，却经常遇到性能上的问题，普遍表现在滚动时比较卡，特备是cell包含图片的情况时
· 实际上针对性地优化一下就可以解决tableView滑动时候卡顿的问题
* 使用不透明视图。不透明的视图可以提高渲染的速度。可以将cell及其子视图的opaque属性设为YES(默认值)
* 不要重复创建不必要的cell.UITableView只需要一屏幕的UITableViewCell对象即可。因此在cell不可见时，可以将其缓存起来，而需要时继续使用它即可。注意：cell被重用时，需要调用setNeedsDisplayInRect：或setNeedsDisplay方法重绘cell.
* 减少动画效果的使用，最好不要使用insertRowsAtIndexPaths:withRowAnnimation: 方法，而是调用reloadData方法。
* 减少视图的数目。cell包含了textLabel,detailTextLabel和ImageView等view,而你还可以自定义一些视图放在他的contentView里，创建它会消耗较多资源，并且也影响性能。
* 不要做多与的绘制工作。在实现drawRect：的时候，它的rect参数就是需要绘制的区域，这个区域之外的不需要进行绘制。
* 预渲染图像。你会发现即使做到了上诉几点，当新的图像出现时，仍然会有短暂的停顿现象。解决的办法就是在图形上下文中画，导出UIImage对象，然后在绘制到屏幕。（头像圆角，或者其他变形的时候，用图像上下文能提高性能）异步绘制。
* 不要阻塞主线程。tableview在更新数据时，整个界面都卡住不动，完全不响应应用用户强求。常见的是网络请求，等待时间长达数秒。解决方案：使用多线程，让子线程去执行这些函数或方法。
注意：当下载线程数超过2时，会影响主线程的性能。所以在不需要响应用户请求时，下载线程数可以增加到5，不建议再加了，以加块下载熟读。如果用户正在交互，应把线程数量控制在2个以内。
* 提前计算并缓存好高度，因为heightForRowAtIndexPaht调用非常频繁。
* gzip/zip压缩：当从服务端下载相关附件时，可以通过gzip/zip压缩后再下载，使得内存更小，下载速度也更快。
awakeFromNib与viewDidLoad区别
awakeFromNib:当.nib文件被加载的时候，会发送一个awakeFromNib消息到.nib文件中的每个对象，每个对象都可以定义自己的awakeFromNib函数来响应这个消息，执行必要的操作。也就是说通过.nib文件创建view对象执行awakeFromNib
viewDidLoad:当view对象被加载到内存就会执行viewDidLoad，不管是通过.nib还是代码形式，创建对象就会执行viewDidLoad.
layoutSubview何时调用？
1.初始化init方法时不会触发
2.滚动UIScrollView触发
3.旋转屏幕触发
4.改变view的值触发，前提是frame改变了
5.改变UIView的大小触发
描述九宫格算法
1.NSInteger col = x;//定义列数
2.NSInteger index = self.shopsView.subViews.count;//获取小标
3.CGFloat margin = ( self.shopsView.frame.size.width - col *viewW) / (col - 1);//定义间隔
4.CGFloat viewX = (indeX % col) * (viewW + margin);
5.CGFloat viewY = (index / col) * (viewH + 10);
应用的生命周期
1.- (BOOL)application:(UIApplication *)application willFinishLaunchingWithOptions:(NSDictionary *)launchOptions//告诉代理进程启动但还没有进入状态
2.- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions//告诉代理启动基本完成程序准备开始运行
3.- (void)applicationWillResignActive:(UIApplication *)application//当应用程序将要进入非活跃状态执行，在此期间，应用程序不在接受消息和事件，比如来电话了
4.- (void)applicationDidBecomeActive:(UIApplication *)application//当应用程序进入活跃状态执行，和上面那个方法刚好相反
5.- (void)applicationDidEnterBackground:(UIApplication *)application//当应用程序进入后台的时候调用。所以要设置后台继续进行，则在这个函数里面设置即可
6.- (void)applicationWillEnterForeground:(UIApplication *)application//当应用程序从后台将要重新回到前台时候调用，这个刚好跟上面的那个方法相反
7.- (void)applicationWillTerminate:(UIApplication *)application// 当应用程序退出时被调用，通常是用来保存数据和一些退出前的清理工作
load initalize方法区别
+(void)load :
* 当类对象被引入项目时，runtime会向每一个类对象发送load消息
* load方法会在每一类甚至分类被引入时仅调用一次，调用顺序：父类优先于子类，元类优先于父类
* load方法不会被类自动继承
+(void)initialize: 也是第一次使用这个类的时候会调用这个方法
什么时候会发生隐式动画？
当改变CALayer的一个可做动画的属性，它并不能立刻在屏幕上体现出来，相反，它是从先前的值平滑到过渡到新的值。这一切都是默认的行为，你不需要做额外的操作，这就是隐式动画。
为什么当CoreAnimation完成时，layer又会恢复到原先的状态？
因为这些产生的动画只是假象，并没有对layer进行改变。那么为什么会这样呢，这里要讲一下图层树里的呈现树。呈现树实际上是模型图层的复制，但是它的属性值表示了当前外观效果，动画的过程实际上只是修改了呈现树，并没有对图层的属性进行改变，所以 在动画结束以后图层会恢复到原先状态。
xib和storyboards的优缺点？
优点：
- Xib:在编译前就提供了可视化界面，可以直接拖控件，也可以直接给控件添加约束，更直观一些，而且类文件中就少了创建控件的代码，确实简化不少，通常每一个xib对应一个类
- Storyboard: 在编译前提供了可视化界面，可拖控件，可添加约束，在开发时比较直观，而且一个storboard可以有很多的界面，每一个界面对应一个类文件，通过storyboard，可以直观看出整个app的结构。
缺点：
- Xib:需求改动时，需要修改Xib很大，有时候甚至需要重新添加约束，导致开发周期变长。xib载入相比纯代码自然要慢一些。对于比较复杂逻辑控制不同状态下显示不同内容时，使用xib是比较困难的。当多人团队或者多团队开发时，如果xib文件被发动，极易导致冲突，而且解决冲突相对要困难很多。
- Sttoryboard: 需求变动时，需要修改storyboard上对应的界面的约束，与xib一样可能要重新添加约束，或者添加约束会造成大量的冲突，尤其是多团队开发。对于复杂逻辑控制不同显示内容时，比较困难。当多人团队或者多团队开发时，大家会同时修改一个soryboard,导致大量冲突，解决起来相当困难。
事件传递与响应的完整过程？
在产生一个事件时，系统会将该事件加入到一个由UIApplication管理的事件队列中，UIApplication会从事件队列中取出最前面的事件，将它传递给先发送事件给应用程序的主窗口。
主窗口会调用hitTest方法寻找最合适的视图控件，找到后就会调用视图控件的touches方法来做具体的事情。
当调用touches方法，他的默认做法，就会将时间顺着响应者链条往上传，传递给上一个响应者，接着就会调用上一个响应者的touches方法。
使用AFNetworking做过断点续传吗？
断点续传的主要思路：
* 检查服务文件信息
* 检查本地文件
* 如果比服务器文件小，断点续传，利用http请求头的Range实现断点续传
* 如果比服务器文件大，重新下载
* 如果和服务器文件一样，下载完成
