autorelease 嵌套， 系统是怎么处理的？
在｀NSAutoReleasePool｀中会有一个array保存所有需要被｀autorelease｀的对象， 由于我们要确保在保存对象时array不会对该对象进行强引用（retainCount plus 1）, 我们需要用CFMutableArrayRef.
由于每一个线程都有自己的autoReleasePool, 所以我们需要保存该线程中所创建的所有autoreleasepools，每创建一个autoreleasepool, 我们可以把它放入一个stack里，然后将这个stack保存起来 这里可以使用：

NSMutableDictionary *threadDict = [[NSThread currentThread] threadDictionary];
NSString *key = @"com.my.thread-local.releasepool";
CFMutableArrayRef stack = threadDict[key];
if (!stack) {
   stack = CFArrayCreateMutable(NULL, 0, NULL);
   [threadDict setObject:(id)stack forKey:key];
}

当dealloc的时候，首先遍历当前autoReleasePool里所有对象，发送release, 然后release保存所有对象的CFMutableArray (CFRelease(_objects)). 然后遍历保存在thread里的stack，由于我们将所有在该线程内创建的autoreleasepool都存入这个stack里，我们只需要release所有在self之后的出现的autoreleasepool, 然后把self从stack里移除。由于每一个autoreleasepool都遵从这样的逻辑，这其实就是一个递归的调用。

ARC 原理
ARC (Automatic Reference Counting), 在对象被创建时，ARC会保存一大堆关于该对象的信息：对象类型，所有的属性等等，当我们不再需要该对象的时候，ARC会帮助我们销毁该对象。
当我们alloc``init一个对象实例时，编译器会在该实例使用完后插入objc_release去销毁该对象。如果我们是在使用properties的时候，该property的getter会被写成：

- (Test *)test {
  return objc_retainAutoreleaseReturnValue(_test);
}

可以看到，所有的properties都被retain/autorelease了， 当引用properties时，编译器还会将caller改写为：objc_retainAutoreleaseReturnValue([self test]). 这里出现了两次的retain/autorelease，而编译器会优化的只使用一次。

MRC 和 ARC怎么破循环引用(retain cycle)
使用__weak或__unsafe_unretained

线程安全
不知道要问什么，问lock？还是其他？lock的话有：NSLock, OSSpinLock, NSRecursiveLock, pthread_mutex_t. 我们还可以用serial dispatch_queue_t来作lock。还有dispatch_barrier也可以。至于用哪个，就要具体分析了。

NSOperation可不可以停止
调用cancel方法可以将NSOperationQueue当前状态设为cancelled，在operation运行中我们要不断的检查当前的operationQueue的状态，看isCancelled返回是否为真，若为真，则立刻结束operation.

HTTP状态码，自己写http框架，缓存，异步，并发高性能的解决方案
根据我的经验，用过的HTTP状态码有: 200 OK, 201 Created, 302 Redirect, 304 Not Modified, 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 408 Request Time out, 500 Internal Error, 503 Server Not Available。网上能找到全部的状态码，但个人觉得记住一些常用的就足够了，当碰到特殊情况要使用其他状态码，查资料就好了。

对于http框架，在ios中，通常通过封装NSURLSession来完成网络层的开发，主要注意的是网络层应独立，只完成与后台API的通信，把数据处理或其他与网络通信无关的内容分离开来。
缓存，除非有特殊要求，个人建议还是使用NSURLCache或者NSCache来完成。如果服务器支持的话，应该好好利用304状态码的特性，这样会节省流量，而且网络响应会快些。
异步这个我觉得不用多说了吧？NSURLSession都是异步的。
对于并发高性能：需要知道的是，NSURLSession在iOS中最多可以有4个tasks同时运行，所以应该复用所创建的NSURLSession, 在它之上创建不同的tasks。如果像是tableview中加载图片，可以创建一个队列(queue), 如果tasks超过4个，把超过的放入这个队列中，当之前的任务完成时，检查队列中有没有等待的，如果有，把它们从队列中取出来，然后[task resume]。

断点续传方案
可使用NSURLSession来完成. 主要通过以下的方法

- (void)cancelByProducingResumeData:(void (^)(NSData *resumeData))completionHandler;
- (NSURLSessionDownloadTask *)downloadTaskWithResumeData:(NSData *)resumeData;

如果不是使用NSURLSession, 则要麻烦一些，首先必需在暂停时记录下当前已接收的文件长度，在下一次开始时设置HTTP header里的Range：

NSString *range = [NSString stringWithFormat:@"bytes=%lld-", self.receivedLength];
[request setValue:range forHTTPHeaderField:@"Range"];

UI, 动画优化， UITableViewCell优化
UI, 动画优化要根据实际情况以及profiling的结果来进行具体分析，光这样问还真不知道该怎么回答。
UITableViewCell的优化也是如此，但是一般的套路是profiling, 尽量少加subviews, 减少off-screen rendering, 比如圆角图片，可以在下载图片时在后台直接画圆角在图片中。下载图片时尽量使用caching。在加载数据时，尽量减少数据处理的时间，尽量不要fetching core data 等等。

本地数据库海量数据如何提高查询效率和存储效率
在ios中存储数据基本上就是plist, sqlite 和core data (NSUserDefault其实也是plist)， plist建议用在存储简单而且数据量不大的情况，而且对于查询没有太多要求的。sqlite可以高效的查询和存储数据，但是缺点是：C API, 要自己做封装，而且每次都需要读写硬盘，对数据变化不敏感，要手动更新界面从而反应数据中的变化
在iOS开发中，除非有特殊需求，一般都建议使用Core Data.

如何提高查询效率：

1. 设置合适的index.
2. 优化predicate，对于string类型，尽量不要使用==
3. 使用batchSize
4. 合理使用batchLimit
5. 对于需要用到的relationship objects,可以使用setRelationshipKeyPathsForPrefetching来减少Faulting overhead.
6. 可以使用batchFaulting来减少Faulting overhead

如何提高存储效率：

1. 尽量避免在main thread中写数据
2. 不要在Core Data中保存图片，文件等数据
3. 对于删除，更新，尽量batch
4. 注意调用[NSManagedObjectContext save:]的时机，尽量是由在后台运行的NSManagedObjectContext来完成写入。

索引的缺点

1. 需要空间储存索引
2. 创建和维护索引需要耗费时间
3. 当删除，插入和更新数据是，索引也需要进行更新，这样降低了写数据的速度。