这个栏目将持续更新–请iOS的小伙伴关注!
（答案不唯一，仅供参考，文章最后有福利）
四十一：SDWebImage实现原理是什么？ 它是如何解决tableView的复用时出现图片错乱问题的呢？
四十二：AFNetworking 底层原理分析
AFNetworking主要是对NSURLSession和NSURLConnection(iOS9.0废弃)的封装,其中主要有以下类:
1). AFHTTPRequestOperationManager：内部封装的是 NSURLConnection, 负责发送网络请求, 使用最多的一个类。(3.0废弃)
2). AFHTTPSessionManager：内部封装是 NSURLSession, 负责发送网络请求,使用最多的一个类。
3). AFNetworkReachabilityManager：实时监测网络状态的工具类。当前的网络环境发生改变之后,这个工具类就可以检测到。
4). AFSecurityPolicy：网络安全的工具类, 主要是针对 HTTPS 服务。
5). AFURLRequestSerialization：序列化工具类,基类。上传的数据转换成JSON格式
(AFJSONRequestSerializer).使用不多。
6). AFURLResponseSerialization：反序列化工具类;基类.使用比较多:
7). AFJSONResponseSerializer; JSON解析器,默认的解析器.
8). AFHTTPResponseSerializer; 万能解析器; JSON和XML之外的数据类型,直接返回二进制数据.对服务器返回的数据不做任何处理.
9). AFXMLParserResponseSerializer; XML解析器;
四十三：描述下SDWebImage里面给UIImageView加载图片的逻辑
SDWebImage 中为 UIImageView 提供了一个分类UIImageView+WebCache.h, 这个分类中有一个最常用的接口sd_setImageWithURL:placeholderImage:，会在真实图片出现前会先显示占位图片，当真实图片被加载出来后再替换占位图片。
加载图片的过程大致如下：
- 首先会在 SDWebImageCache 中寻找图片是否有对应的缓存, 它会以url 作为数据的索引先在内存中寻找是否有对应的缓存
- 如果缓存未找到就会利用通过MD5处理过的key来继续在磁盘中查询对应的数据, 如果找到了, 就会把磁盘中的数据加载到内存中，并将图片显示出来
- 如果在内存和磁盘缓存中都没有找到，就会向远程服务器发送请求，开始下载图片
- 下载后的图片会加入缓存中，并写入磁盘中
- 整个获取图片的过程都是在子线程中执行，获取到图片后回到主线程将图片显示出来
SDWebImage原理：
调用类别的方法：
- 从内存（字典）中找图片（当这个图片在本次使用程序的过程中已经被加载过），找到直接使用。
- 从沙盒中找（当这个图片在之前使用程序的过程中被加载过），找到使用，缓存到内存中。
- 从网络上获取，使用，缓存到内存，缓存到沙盒。
四十四：分析json、xml 的区别? json、xml 解析 式的底层是如何让处理的
(一)JSON与XML的区别：
（1）可读性方面：基本相同，XML的可读性比较好；
（2）可扩展性方面：都具有良好的扩展性；
（3）编码难度方面：相对而言，JSON的编码比较容易；
（4）解码难度：JSON的解码难度基本为零，XML需要考虑子节点和父节点；
（5）数据体积方面：JSON相对于XML来讲，数据体积小，传递的速度比较快；
（6）数据交互方面：JSON与javascript的交互更加方便，更容易解析处理，更好的数据交互；
（7）数据描述方面：XML对数据描述性比较好
（8）传输速度方面：JSON的速度远远快于XML。
（二）JSON与XML底层实现原理：
（1）JSON底层原理：遍历字符串中的字符，最终根据格式规定的特殊字符，比如{}、[]、：等进行区分，{}号表示字典，[]号表示数组，：号是字典的键和值的分水岭，最终仍是将JSON转化为字典，只不过字典中的值可能是“字典、数组或者字符串而已”。
（2）XML底层原理：XML解析常用的解析方法有两种：DOM解析和SAX解析；DOM采用的是树形结构的方式访问XML文档，而SAX采用的是事件模型；DOM解析把XML文档转化为一个包含其内容的树，并可以对树进行遍历，使用DOM解析器的时候需要处理整个XML文档，所以对内存和性能的要求比较高；SAX在解析XML文档的时候可以触发一系列的事件，当发现给定的tag的时候，他可以激活一个回调方法，告诉该方法指定的标签已经找到，SAX对内存的要求通常会比较低，因为他让开发人员自己来决定所要处理的tag，特别是当开发人员只需要处理文档中所包含部分数据时，SAX这种扩展能力得到了更好的体现。
四十五：对程序性能的优化你有什么建议?
-
1.使用复用机制 -
2.尽可能设置 View 为不透明 -
3.避免臃肿的 XIB 文件 -
4.不要阻塞主线程 -
5.图片尺寸匹配 UIImageView -
6.选择合适的容器 -
7.启用 GZIP 数据压缩 -
8.View 的复用和懒加载机制 -
9、缓存
服务器的响应信息（response）。
图片。
计算值。比如：UITableView 的 row heights。 -
10.关于图形绘制 -
11.处理 Memory Warnings -
在 AppDelegate 中实现 - [AppDelegate applicationDidReceiveMemoryWarning:] 代理方法。
在 UIViewController 中重载 didReceiveMemoryWarning 方法。
监听 UIApplicationDidReceiveMemoryWarningNotification 通知。 -
12.复用高开销的对象 -
13.减少离屏渲染(设置圆角和阴影的时候可以选用绘制的方法) -
14.优化 UITableView
通过正确的设置 reuseIdentifier 来重用 Cell。
尽量减少不必要的透明 View。
尽量避免渐变效果、图片拉伸和离屏渲染。
当不同的行的高度不一样时，尽量缓存它们的高度值。
如果 Cell 展示的内容来自网络，确保用异步加载的方式来获取数据，并且缓存服务器的 response。
使用 shadowPath 来设置阴影效果。
尽量减少 subview 的数量，对于 subview 较多并且样式多变的 Cell，可以考虑用异步绘制或重写 drawRect。
尽量优化 - [UITableView tableView:cellForRowAtIndexPath:] 方法中的处理逻辑，如果确实要做一些处理，可以考虑做一次，缓存结果。
选择合适的数据结构来承载数据，不同的数据结构对不同操作的开销是存在差异的。
对于 rowHeight、sectionFooterHeight、sectionHeaderHeight 尽量使用常量。 -
15.选择合适的数据存储方式
在 iOS 中可以用来进行数据持有化的方案包括：
NSUserDefaults。只适合用来存小数据。
XML、JSON、Plist 等文件。JSON 和 XML 文件的差异在「选择正确的数据格式」已经说过了。
使用 NSCoding 来存档。NSCoding 同样是对文件进行读写，所以它也会面临必须加载整个文件才能继续的问题。
使用 SQLite 数据库。可以配合 FMDB 使用。数据的相对文件来说还是好处很多的，比如可以按需取数据、不用暴力查找等等。
使用 CoreData。也是数据库技术，跟 SQLite 的性能差异比较小。但是 CoreData 是一个对象图谱模型，显得更面向对象；SQLite 就是常规的 DBMS。 -
16.减少应用启动时间
快速启动应用对于用户来说可以留下很好的印象。尤其是第一次使用时。
保证应用快速启动的指导原则：
尽量将启动过程中的处理分拆成各个异步处理流，比如：网络请求、数据库访问、数据解析等等。
避免臃肿的 XIB 文件，因为它们会在你的主线程中进行加载。重申：Storyboard 没这个问题，放心使用。
注意：在测试程序启动性能的时候，最好用与 Xcode 断开连接的设备进行测试。因为 watchdog 在使用 Xcode 进行调试的时候是不会启动的。 -
17.使用 Autorelease Pool （内存释放池） -
18.imageNamed 和 imageWithContentsOfFile
四十六：讲讲iOS事件响应链的原理
1、响应者链通常是由视图（UIView）构成的；
2、一个视图的下一个响应者是它视图控制器（UIViewController）（如果有的话），然后再转给它的父视图（Super View）；
3、视图控制器（如果有的话）的下一个响应者为其管理的视图的父视图；
4、单例的窗口（UIWindow）的内容视图将指向窗口本身作为它的下一个响应者
需要指出的是，Cocoa Touch应用不像Cocoa应用，它只有一个UIWindow对象，因此整个响应者链要简单一点；
5、单例的应用（UIApplication）是一个响应者链的终点，它的下一个响应者指向nil，以结束整个循环。
四十七：假如Controller太臃肿，如何优化?
1.将网络请求抽象到单独的类中
方便在基类中处理公共逻辑；
方便在基类中处理缓存逻辑，以及其它一些公共逻辑；
方便做对象的持久化。
2.将界面的封装抽象到专门的类中
构造专门的 UIView 的子类，来负责这些控件的拼装。这是最彻底和优雅的方式，不过稍微麻烦一些的是，你需要把这些控件的事件回调先接管，再都一一暴露回 Controller。
3.构造 ViewModel
借鉴MVVM。具体做法就是将 ViewController 给 View 传递数据这个过程，抽象成构造 ViewModel 的过程。
4.专门构造存储类
专门来处理本地数据的存取。
5.整合常量
四十八：介绍下App启动的完成过程？
1. App启动过程
? 解析Info.plist
? 加载相关信息，例如如闪屏
? 沙箱建立、权限检查
? Mach-O加载
? 如果是胖二进制文件，寻找合适当前CPU类别的部分
? 加载所有依赖的Mach-O文件（递归调用Mach-O加载的方法）
? 定位内部、外部指针引用，例如字符串、函数等
? 执行声明为attribute((constructor))的C函数
? 加载类扩展（Category）中的方法
? C++静态对象加载、调用ObjC的 +load 函数
? 程序执行
· 1.main函数
· 2.执行UIApplicationMain函数
· 1.创建UIApplication对象
· 2.创建UIApplicationDelegate对象并复制
· 3.读取配置文件info.plist，设置程序启动的一些属性，(关于info.plist的内容可网上搜索下)
· 4.创建应用程序的Main Runloop循环
· 3.UIApplicationDelegate对象开始处理监听到的事件
· 1.程序启动成功之后，首先调用application:didFinishLaunchingWithOptions:方法,
· 如果info.plist文件中配置了启动storyboard文件名，则加载storyboard文件。
· 如果没有配置，则根据代码来创建UIWindow—>UIWindow的rootViewController–>显示
四十九：哈希原理
散列表（Hash table，也叫哈希表），是根据关键码值(Key value)而直接进行访问的数据结构。也就是说，它通过把关键码值映射到表中一个位置来访问记录，以加快查找的速度。这个映射函数叫做散列函数，存放记录的数组叫做散列表。
给定表M，存在函数f(key)，对任意给定的关键字值key，代入函数后若能得到包含该关键字的记录在表中的地址，则称表M为哈希(Hash）表，函数f(key)为哈希(Hash) 函数。
哈希概念:哈希表的本质是一个数组，数组中每一个元素称为一个箱子(bin)，箱子中存放的是键值对。
五十：哈希存储过程
1.根据 key 计算出它的哈希值 h。
2.假设箱子的个数为 n，那么这个键值对应该放在第 (h % n) 个箱子中。
3.如果该箱子中已经有了键值对，就使用开放寻址法或者拉链法解决冲突。
在使用拉链法解决哈希冲突时，每个箱子其实是一个链表，属于同一个箱子的所有键值对都会排列在链表中。
哈希表还有一个重要的属性: 负载因子(load factor)，它用来衡量哈希表的空/满程度，一定程度上也可以体现查询的效率，计算公式为:
负载因子 = 总键值对数 / 箱子个数
负载因子越大，意味着哈希表越满，越容易导致冲突，性能也就越低。因此，一般来说，当负载因子大于某个常数(可能是 1，或者 0.75 等)时，哈希表将自动扩容。
哈希表在自动扩容时，一般会创建两倍于原来个数的箱子，因此即使 key 的哈希值不变，对箱子个数取余的结果也会发生改变，因此所有键值对的存放位置都有可能发生改变，这个过程也称为重哈希(rehash)。
哈希表的扩容并不总是能够有效解决负载因子过大的问题。假设所有 key 的哈希值都一样，那么即使扩容以后他们的位置也不会变化。虽然负载因子会降低，但实际存储在每个箱子中的链表长度并不发生改变，因此也就不能提高哈希表的查询性能。
基于以上总结，细心的朋友可能会发现哈希表的两个问题:
1.如果哈希表中本来箱子就比较多，扩容时需要重新哈希并移动数据，性能影响较大。
2.如果哈希函数设计不合理，哈希表在极端情况下会变成线性表，性能极低。
3.block和函数指针的理解；
相似点：
函数指针和Block都可以实现回调的操作，声明上也很相似，实现上都可以看成是一个代码片段。
函数指针类型和Block类型都可以作为变量和函数参数的类型。（typedef定义别名之后，这个别名就是一个类型）
不同点：
函数指针只能指向预先定义好的函数代码块（可以是其他文件里面定义，通过函数参数动态传入的），函数地址是在编译链接时就已经确定好的。
Block本质是Objective-C对象，是NSObject的子类，可以接收消息。
函数里面只能访问全局变量，而Block代码块不光能访问全局变量，还拥有当前栈内存和堆内存变量的可读性（当然通过__block访问指示符修饰的局部变量还可以在block代码块里面进行修改）。
从内存的角度看，函数指针只不过是指向代码区的一段可执行代码，而block实际上是程序运行过程中在栈内存动态创建的对象，可以向其发送copy消息将block对象拷贝到堆内存，以延长其生命周期。
五十一：NSDate\CFAbsoluteTimeGetCurrent\CACurrentMediaTime的区别
1.从框架的角度
1.从框架的角度
- NSDate 属于Foundation
- CFAbsoluteTimeGetCurrent 属于 Core Foundation
- CACurrentMediaTime 属于 QuartzCore
2.本质区别
- NSDate 或 CFAbsoluteTimeGetCurrent 返回的系统时钟时间将会从网络时钟同步.
- 从时钟偏移量的角度 mach_absolute_time() 和 CACurrentMediaTime 基于内建时钟.能够更精确的测试时间,并且不会根据外部的时间变化而变化.(例如,时区变化\夏时制),它和系统的upTime有关.系统重启后,CACurrentMediaTime 也会重新设置.
3.常用用法
- NSDate \CFAbsoluteTimeGetCurrent 常用于日常时间,时间戳表示,与服务器之间的数据交互.
- CFAbsoluteTimeGetCurrent 相当于 [NSDate date]timeIntervalSinceReferenceDate];
- CACurrentMediaTime 常用测试代码效率
4.项目使用场景
-
分析:
在购物车点击"+“和”-"时.如果说立即进行服务器同步的话,代价是非常高!所以会采用"延时提交"的方法. -
思路:
连续点击的时候,不提交服务器.点击停止时,进行同步. -
连续点击如何判断了?? 采用的是判断2次点击的时间差,如果时间差小于一定的数值(自己根据项目需求判定).那么即可判断是连续点击的操作.
五十二：讲一下MVC和MVVM，MVP？
-
简单来说MVC（Model View Controller）就是模型（Model）- 视图（View）-控制器(Controller)的缩写，Model是用来处理数据，View是用来展示界面，Cotroller是用来调节他们两者之间的交互。
这个是最常用的。但是View和Model之间的直接交互，就导致了View和Model之间的耦合性比较大。 -
MVP （Model View Presenter）是MVC模式的变种，使用Presenter代替了Controller，而且改变了数据流向
View和Model之间不再直接进行交互，而是通过Presenter来进行的。总体来说Presenter同时持有View和Model。 优点：整体框架分层清晰，降低了耦合度。 缺点：需要加入Presenter来作为协调Model和View的桥梁，同时也导致了Presenter的臃肿。在维护起来不方便。 -
MVVM（Model View View-Model ViewModel）其实是对MVP的一种改进，他将Presenter替换成ViewModel，
并通过双向数据绑定来实现视图和数据的交互。 优点：使其数据流向更加清晰（脑补一下就是云对雨，x对风，大陆对长空）。一一对应起来。 缺点：这种架构没有统一的实现方式，每个人各有特色。我接触过得各有不同。而且有一定的学习成本。（不懂得人去学习也得一周左右吧，不抬杠，学过之后再来回话。“大牛请忽略”）
五十四：为什么代理要用weak？代理的delegate和dataSource有什么区别？block和代理的区别?
-
1、因为用weak修饰的对象引用计数不会+1.好吧。说白了就是不会造成循环引用。0.0~！ -
2、delegate偏重于用户交互的回调。dataSource偏重于数据的回调。 -
3、首先共同点都是实现回调的方式。算了直白点说就是一个一对一，一个一对多。一个编写简单，一个实现繁复。
对于什么时候用block什么时候用代理简单来说就是公共接口，方法较多，回调类型较多可以选择用代理。对于异步和简单的回调用block好一点。
五十五：如何提升 tableview 的流畅度？
本质上是降低 CPU、GPU 的工作，从这两个大的方面去提升性能。
- CPU：对象的创建和销毁、对象属性的调整、布局计算、文本的计算和排版、图片的格式转换和解码、图像的绘制
- GPU：纹理的渲染
卡顿优化在 CPU 层面
-
尽量用轻量级的对象，比如用不到事件处理的地方，可以考虑使用 CALayer 取代 UIView -
不要频繁地调用 UIView 的相关属性，比如 frame、bounds、transform 等属性，尽量减少不必要的修改 -
尽量提前计算好布局，在有需要时一次性调整对应的属性，不要多次修改属性 -
Autolayout 会比直接设置 frame 消耗更多的 CPU 资源 -
图片的 size 最好刚好跟 UIImageView 的 size 保持一致 -
控制一下线程的最大并发数量 -
尽量把耗时的操作放到子线程
卡顿优化在 GPU层面
- 尽量避免短时间内大量图片的显示，尽可能将多张图片合成一张进行显示
- GPU能处理的最大纹理尺寸是 4096x4096，一旦超过这个尺寸，就会占用 CPU 资源进行处理，所以纹理尽量不要超过这个尺寸
- 尽量减少视图数量和层次
- 减少透明的视图（alpha<1），不透明的就设置 opaque 为 YES
- 尽量避免出现离屏渲染
iOS 保持界面流畅的技巧
1.预排版，提前计算
在接收到服务端返回的数据后，尽量将 CoreText 排版的结果、单个控件的高度、cell 整体的高度提前计算好，将其存储在模型的属性中。需要使用时，直接从模型中往外取，避免了计算的过程。
尽量少用 UILabel，可以使用 CALayer 。避免使用 AutoLayout 的自动布局技术，采取纯代码的方式
2.预渲染，提前绘制
例如圆形的图标可以提前在，在接收到网络返回数据时，在后台线程进行处理，直接存储在模型数据里，回到主线程后直接调用就可以了
避免使用 CALayer 的 Border、corner、shadow、mask 等技术，这些都会触发离屏渲染。
3.异步绘制
4.全局并发线程
5.高效的图片异步加载
五十六：编程中的六大设计原则？
1.单一职责原则
通俗地讲就是一个类只做一件事
CALayer：动画和视图的显示。UIView：只负责事件传递、事件响应。
2.开闭原则
对修改关闭，对扩展开放。 要考虑到后续的扩展性，而不是在原有的基础上来回修改
3.接口隔离原则
使用多个专门的协议、而不是一个庞大臃肿的协议
UITableviewDelegateUITableViewDataSource
4.依赖倒置原则
抽象不应该依赖于具体实现、具体实现可以依赖于抽象。 调用接口感觉不到内部是如何操作的
5.里氏替换原则
父类可以被子类无缝替换，且原有的功能不受任何影响
例如 KVO
6.迪米特法则
一个对象应当对其他对象尽可能少的了解，实现高聚合、低耦合
推荐文章
面向对象设计的六大设计原则（附 Demo 及 UML 类图）- J_Knight_
五十七：NSOperation 与 GCD 的主要区别？
-
1. GCD 的核心是 C 语言写的系统服务，执行和操作简单高效，因此 NSOperation 底层也通过 GCD 实现，换个说法就是 NSOperation 是对 GCD 更高层次的抽象，这是他们之间最本质的区别。因此如果希望自定义任务，建议使用 NSOperation； -
2. 依赖关系，NSOperation 可以设置两个 NSOperation 之间的依赖，第二个任务依赖于第一个任务完成执行，GCD 无法设置依赖关系，不过可以通过dispatch_barrier_async来实现这种效果； -
3. KVO(键值对观察)，NSOperation 和容易判断 Operation 当前的状态(是否执行，是否取消)，对此 GCD 无法通过 KVO 进行判断； -
4. 优先级，NSOperation 可以设置自身的优先级，但是优先级高的不一定先执行，GCD 只能设置队列的优先级，无法在执行的 block 设置优先级； -
5. 继承，NSOperation 是一个抽象类，实际开发中常用的两个类是 NSInvocationOperation 和 NSBlockOperation ，同样我们可以自定义 NSOperation，GCD 执行任务可以自由组装，没有继承那么高的代码复用度； -
6. 效率，直接使用 GCD 效率确实会更高效，NSOperation 会多一点开销，但是通过 NSOperation 可以获得依赖，优先级，继承，键值对观察这些优势，相对于多的那么一点开销确实很划算，鱼和熊掌不可得兼，取舍在于开发者自己；
五十八：请说明并比较以下关键词：strong, weak, assign, copy
-
strong 表示指向并拥有该对象。其修饰的对象引用计数会增加1。该对象只要引用计数不为 0 则不会被销毁。当然强行将其设为 nil 可以销毁它。 -
weak 表示指向但不拥有该对象。其修饰的对象引用计数不会增加。无需手动设置，该对象会自行在内存中销毁。 -
assign 主要用于修饰基本数据类型，如 NSInteger 和 CGFloat，这些数值主要存在于栈上。 -
weak 一般用来修饰对象，assign 一般用来修饰基本数据类型。原因是assign 修饰的对象被释放后，指针的地址依然存在，造成野指针，在堆上容易造成崩溃。而栈上的内存系统会自动处理，不会造成野指针。 -
copy 与 strong 类似。不同之处是 strong 的复制是多个指针指向同一个地址，而 copy 的复制每次会在内存中拷贝一份对象，指针指向不同地址。copy 一般用在修饰有可变对应类型的不可变对象上，如 NSString , NSArray , NSDictionary 。 -
Objective-C 中，基本数据类型的默认关键字是 atomic , readwrite , assign ；普通属性的默认关键字是 atomic , readwrite , strong 。
五十九：Socket原理
1、套接字（socket）概念
套接字（socket）是通信的基石，是支持TCP/IP协议的网络通信的基本操作单元。它是网络通信过程中端点的抽象表示，包含进行网络通信必须的五种信息：连接使用的协议，本地主机的IP地址，本地进程的协议端口，远地主机的IP地址，远地进程的协议端口。
应 用层通过传输层进行数据通信时，TCP会遇到同时为多个应用程序进程提供并发服务的问题。多个TCP连接或多个应用程序进程可能需要通过同一个 TCP协议端口传输数据。为了区别不同的应用程序进程和连接，许多计算机操作系统为应用程序与TCP／IP协议交互提供了套接字(Socket)接口。应 用层可以和传输层通过Socket接口，区分来自不同应用程序进程或网络连接的通信，实现数据传输的并发服务。
2 、建立socket连接
建立Socket连接至少需要一对套接字，其中一个运行于客户端，称为ClientSocket，另一个运行于服务器端，称为ServerSocket。
套接字之间的连接过程分为三个步骤：服务器监听，客户端请求，连接确认。
服务器监听：服务器端套接字并不定位具体的客户端套接字，而是处于等待连接的状态，实时监控网络状态，等待客户端的连接请求。
客户端请求：指客户端的套接字提出连接请求，要连接的目标是服务器端的套接字。为此，客户端的套接字必须首先描述它要连接的服务器的套接字，指出服务器端套接字的地址和端口号，然后就向服务器端套接字提出连接请求。
连 接确认：当服务器端套接字监听到或者说接收到客户端套接字的连接请求时，就响应客户端套接字的请求，建立一个新的线程，把服务器端套接字的描述发给客户 端，一旦客户端确认了此描述，双方就正式建立连接。而服务器端套接字继续处于监听状态，继续接收其他客户端套接字的连接请求。
3、Socket连接与TCP连接
创建Socket连接时，可以指定使用的传输层协议，Socket可以支持不同的传输层协议（TCP或UDP），当使用TCP协议进行连接时，该Socket连接就是一个TCP连接。
4、Socket连接与HTTP连接
由 于通常情况下Socket连接就是TCP连接，因此Socket连接一旦建立，通信双方即可开始相互发送数据内容，直到双方连接断开。但在实际网络应用 中，客户端到服务器之间的通信往往需要穿越多个中间节点，例如路由器、网关、防火墙等，大部分防火墙默认会关闭长时间处于非活跃状态的连接而导致 Socket 连接断连，因此需要通过轮询告诉网络，该连接处于活跃状态。
而HTTP连接使用的是“请求—响应”的方式，不仅在请求时需要先建立连接，而且需要客户端向服务器发出请求后，服务器端才能回复数据。
很 多情况下，需要服务器端主动向客户端推送数据，保持客户端与服务器数据的实时与同步。此时若双方建立的是Socket连接，服务器就可以直接将数据传送给 客户端；若双方建立的是HTTP连接，则服务器需要等到客户端发送一次请求后才能将数据传回给客户端，因此，客户端定时向服务器端发送连接请求，不仅可以 保持在线，同时也是在“询问”服务器是否有新的数据，如果有就将数据传给客户端。
六十：请说明并比较以下关键词：__weak，__block
-
__weak与weak基本相同。前者用于修饰变量（variable），后者用于修饰属性（property）。__weak 主要用于防止block中的循环引用。 -
__block也用于修饰变量。它是引用修饰，所以其修饰的值是动态变化的，即可以被重新赋值的。__block用于修饰某些block内部将要修改的外部变量。 -
__weak和__block的使用场景几乎与block息息相关。而所谓block，就是Objective-C对于闭包的实现。闭包就是没有名字的函数，或者理解为指向函数的指针。
传送门：
iOS面试资料大全）
|