来来来！关于iOS基础总结咱俩好好唠唠

时间  2019-11-17
标签 来来 关于 ios 基础 总结 咱俩 好好 唠唠 栏目 iOS 繁體版
原文   原文链接

2016.05.20 10:24java

尘封已久的学习基础总结，最近公司项目不是很忙，终于抽空整理出来，现分享出来。node

1.1 谈一谈GCD和NSOperation的区别？

  • 首先两者都是多线程相关的概念，固然在使用中也是根据不一样情境进行不一样的选择；
  • GCD是将任务添加到队列中（串行/并发/主队列），而且制定任务执行的函数（同步/异步），其性能最好，底层是C语言的API，也更轻量级。iOS4.0之后推出的，针对多核处理器的并发技术，只能设置某一个队列的优先级，经常使用的功能包括 一次性执行 dispatch_once，延迟操做dispatch_after（这里是延迟推到线程中，而不是在线程中等待，所以好比设置延迟1秒执行，可是一秒后只是推到了线程中，不会马上执行），调度组等，其高级功能有
    • dispatch_barrier_async栅栏来控制异步操做的顺序
    • dispatch_apply充分利用多核进行快速迭代遍历
    • dispatch_group_t队列组，添加到队列组中的任务完成以后会调用dispatch_group_notify 函数，能够实现相似A、B两个耗时操做都完成以后，去主线程更新UI的操做
  • NSOperation把操做（异步）添加到队列中（全局的并发队列），是OC框架，更加面向对象，是对GCD的封装，iOS2.0推出，苹果推出GCD以后，对NSOperation的底层所有重写，能够随时取消已经设定准备要执行的任务，已经执行的除外，能够设置队列中每个操做的优先级，其基本功能包括设置最大操做并发数maxConcurrentOperationCount，继续/暂停/所有取消，能够快队列设置操做的依赖关系，经过KVO监听 NSOperation 对象的属性，如 isCancelled、isFinished；对象可重用。
    • NSInvocationOperation和NSBlockOperation建立方法等这些基础面试官每每默认你是会的
    • NSOperationQueue只有两种队列：主队列、其余队列。其余队列包含了串行和并发
    • NSOperation + NSOperationQueue将任务加入到队列
    • 操做依赖：[operation2 addDependency:operation1];(operation2 依赖于operation1的完成，但这两个任务要加入到同一个队列中)

1.2 谈谈多线程的应用

一般耗时的操做都放在子线程处理，而后到主线程更新UI，如ios

  • 咱们要从数据库提取数据还要将数据分组后显示，那么就会开个子线程来处理，处理完成后才去刷新UI显示。
  • 拍照后，会在子线程处理图片，完成后才回到主线程来显示图片。拍照出来的图片太大了，所以要作处理。
  • 音频、视频处理会在子线程来操做
  • 文件较大时，文件操做会在子线程中处理
  • 作客户端与服务端数据同步时，会在后台闲时自动同步

2. 线程之间是如何通讯的？

  • 经过主线程和子线程切换的时候传递参数performSelecter:onThread:withObject:waitUntilDone:

3. 网络图片处理问题怎么解决图片重复下载问题？（SDWebImage大概实现原理）

  • 这个就须要用到字典，以图片的下载地址url为key，下载操做为value，全部的图片大概分红三类：已经下载好的，正在下载的和将要下载的；面试

  • 当一张图片将要进行下载操做的时候，先判断缓存中是否有相同的图片，若是有的话就返回，没有的话就根据url的md5加密值去沙盒中找，有的话就拿出来用，没有的话再去以图片的url为key去字典中找有没有正在进行的任务，最后去判断等待的下载操做任务里面的字典有无相同key，若是没有，就本身开启任务，记录一下，文件保存的名称是url的md5值spring

  • 这里创建了两个字典 : 1.iconCache:保存缓存的图片 2.blockOperation 用来保存下载任务 数据库

    653183AF-3074-47AD-8460-10B5CEF1323C.png

  • 每当进入或退出程序时，会进行图片文件的管理：超过一星期的文件会被清除，若是设置了最大缓存，超过这个缓存就会删除最旧的文件，直到当前缓存文件为最大缓存文件的一半大小；swift

  • 通常app中大部分缓存都是图片的状况下，能够直接调用clear方法进行清除缓存，getSize()方法获取当前缓存大小。设计模式

4. 多线程安全的几种解决方法？

  • 1> 只有在主线程刷新访问UI
  • 2> 若是要防止资源抢夺，须要用synchronize进行加锁保护
  • 3> 若是是异步操做要保证线程安全等问题，尽可能使用GCD（有些函数默认就是安全的）
  • 4> 单例为何用static dispatch_once?使用dispatch_once能够简化代码而且完全保证线程安全，开发者无需担忧加锁或同步。此外，dispatch_once更高效，它没有使用重量级的同步机制，如果那样作的话，每次运行代码前都要获取锁。

5. 原子属性

  • 原子属性采用的是"多读单写"机制的多线程策略；"多读单写"缩小了锁范围,比互斥锁的性能好
  • 规定只在主线程更新UI,就是由于若是在多线程中更新,就须要给UI对象加锁,防止资源抢占写入错误,可是这样会下降UI交互的性能,因此ios设计让全部UI对象都是非线程安全的(不加锁)

6. 代理的做用、block

  • 代理又叫委托，是一种设计模式（能够理解为java中回调监听机制），代理是对象与对象之间的通讯交互，代理解除了对象之间的耦合性
  • 改变或传递控制链，容许一个类在某些特定时刻通知到其余类，而不须要获取到那些类的指针，能够减小框架复杂度
  • 代理的属性常是 weak 的缘由：防止循环引用，以至对象没法获得正确的释放（具体缘由会在下文第十一条阐述）
  • block底层是根据函数指针和结构体结合实现的，block自己就是结构体，更加简洁，不须要定义繁琐的协议方法，但通讯事件比较多的话，建议使用Delegate
  • block就是一个数据类型，存放一段代码，编译的时候不会执行，只有用到的时候才会去执行里面的代码。声明的时候使用copy是由于要从栈区拷贝到堆区，在栈区会受到做用域的限制，超出所在的函数就会被销毁，就没办法进行传值回调等一系列操做了。应注意循环引用，__weak来修饰。若是一个变量是在block外部建立，须要在block内部修改，那么须要使用__block修饰这个变量（__block能够在ARC和MRC状况下使用，能够修饰对象和基本数据类型，__weak只能在ARC下使用，只能修饰对象，不能修饰基本数据类型）
  • 最经常使用的是使用block做为参数传值，不一样状况下回调不一样的代码（如成功回调失败回调）

7. 谈谈你对runTime运行时机制的了解（注意哦，这个很重要的）

  • runtime是一套比较底层的纯C语言API，属于一个C语言库，包含了不少底层的C语言的API
  • 平时编写的OC代码，在程序运行过程当中，其实都是转成了runtime的C语言代码，runtime是OC的幕后工做者，底层语言，例如：
    • OC--> [[WPFPerson alloc] init]
    • runtime-->objc_msgSend(objc_msgSend("WPFPerson", "alloc"), "init")
  • 利用runtime能够实现一些很是底层的操做（用OC很差实现）
    • 在程序运行过程当中，动态建立一个类(好比KVO底层实现:检测isa指针，发现是新建了一个类，固然Xcode7.0之前的版本才能够监听到isa指针)
    • 遍历一个类的全部成员变量、方法，访问私有变量（先经过runtime的class_getInstanceVariable获取成员变量，再经过class_getIvar获取它的值）
    • 在程序运行过程当中，动态为某个类添加属性\方法，修改属性值\方法，好比产品经理须要跟踪记录APP中按钮的点击次数和频率等数据，能够经过集成按钮或者类别实现，可是带来的问题好比别人不必定去实例化你写的子类，或者其余类别也实现了点击方法致使不肯定会调用哪个，runtime能够这样解决：在按钮的分类里面，重写load方法，新建监控按钮点击的方法，先用class_addMethod方法，判断其返回的bool值，若是添加成功，就用class_replaceMethod将原来的方法移除，若是添加失败，就用method_exchangeImplementations方法进行替换
    • 拦截并替换方法，好比因为某种缘由，咱们要改变这个方法的实现，可是又不能动它的源码（好比一些开源库出现问题的时候，这时候runtime就能够出场了）-->先增长一个tool类，而后写一个咱们本身实现的方法-change，经过runtime的class_getInstanceMethod获取两个方法，在用class_replaceMethod方法进行替换。防止数组越界的方法：数组越界的时候报错的方法是add_object，作一个逻辑判断，越界的时候经过class_replaceMethod交换掉add_object（至关于重写了这个方法）
  • 相关应用
    • NSCoding(归档和解档)，若是一个模型有不少个属性，那么须要对每一个属性都实现一遍encodeObject和decodeObjectForKey方法，十分麻烦，可是若是使用class_copyIvarList获取全部属性，而后循环遍历，使用[ivarName substringFromIndex:1]去掉成员变量下划线
    • 字典转模型：像几个出名的开源库JSONModel、MJExtension等都是经过这种方式实现的(利用runtime的class_copyIvarList获取属性数组，遍历模型对象的全部成员属性，根据属性名找到字典中key值进行赋值，固然这种方法只能解决NSString、NSNumber等，若是含有NSArray或NSDictionary，还要进行第二步转换，若是是字典数组，须要遍历数组中的字典，利用objectWithDict方法将字典转化为模型，在将模型放到数组中，最后把这个模型数组赋值给以前的字典数组)
  • Method Swizzling：OC中调用方法事实上就是向对象发送消息，而查找消息的惟一依据就是selector的名字，所以可使用runtime运行时机制动态交换方法。在+load方法里面调换，由于method swizzling的影响范围是全局的，因此应该放在最保险的地方来处理，+load方法可以保证能在类初始化的时候必定能被调用，能够保证统一性，若是是在使用的时候才去调用，可能达不到全局处理的效果；使用dispatch_once保证只交换一次。[objc_getClass("__NSArrayM") swizzleSelector:@selector(addObject:) withSwizzledSelector:@selector(wpf_safeAddObject:)];使用场景：addObject方法添加的值为nil的时候会崩溃。调用objectAtIndex:时出现崩溃提示empty数组问题

8. 谈谈你对Run Loop的理解

  • RunLoop是多线程的一个很重要的机制，就是一个线程一次只能执行一个任务，执行完任务后就会退出线程。主线程会经过do-while死循环让程序持续等待下一个任务不退出。经过mach_msg()让runloop没事时进入trap状态，节省CPU资源。非主线程一般来讲就是为了执行某个任务而建立的，执行完就会归还资源，所以默认不开启RunLoop
  • 实质上，对于子线程的runloop是默认不存在的，由于苹果采用了懒加载的方式，若是没有手动调用[NSRunLoop currentRunLoop]的话，就不会去查询当前线程的RunLoop，也不会建立、加载
  • 固然若是子线程处理完某个任务后不退出，须要继续等待接受事件，须要启动的时候也能够手动启动，好比说添加定时器的时候就要手动开始RunLoop

如何处理事件数组

  • 界面刷新： 当UI改变（ Frame变化、 UIView/CALayer 的继承结构变化等）时，或手动调用了 UIView/CALayer 的 setNeedsLayout/setNeedsDisplay方法后，这个 UIView/CALayer 就被标记为待处理。 苹果注册了一个用来监听BeforeWaiting和Exit的Observer，在它的回调函数里会遍历全部待处理的 UIView/CAlayer 以执行实际的绘制和调整，并更新 UI 界面。浏览器

  • 手势识别： 若是上一步的 _UIApplicationHandleEventQueue() 识别到是一个guesture手势，会调用Cancel方法将当前的touchesBegin/Move/End 系列回调打断。随后系统将对应的 UIGestureRecognizer 标记为待处理。 苹果注册了一个 Observer 监测 BeforeWaiting (Loop即将进入休眠) 事件，其回调函数为 _UIGestureRecognizerUpdateObserver()，其内部会获取全部刚被标记为待处理的 GestureRecognizer，并执行GestureRecognizer的回调。 当有 UIGestureRecognizer 的变化(建立/销毁/状态改变)时，这个回调都会进行相应处理。

  • 网络请求：最底层是CFSocket层，而后是CFNetwork将其封装，而后是NSURLConnection对CFNetwork进行面向对象的封装。当网络开始传输时，NSURLConnection建立了两个新线程：com.apple.NSURLConnectionLoader和com.apple.CFSocket.private。其中CFSocket线程是处理底层socket链接的。NSURLConnectionLoader这个线程内部会使用RunLoop来接受底层socket的事件，并添加到上层的Delegate

应用

  • 滑动与图片刷新：当tableView的cell上有须要从网络获取的图片的时候，滚动tableView，异步线程回去加载图片，加载完成后主线程会设置cell的图片，可是会形成卡顿。能够设置图片的任务在CFRunloopDefaultMode下进行，当滚动tableView的时候，Runloop切换到UITrackingRunLoopMode，不去设置图片，而是而是当中止的时候，再去设置图片。（在viewDidLoad中调用self.imageView performSelector@selector(setImage) withObject:...afterDelay:...inModes@[NSDefayltRunLoopMode]）

  • 常驻子线程，保持子线程一直处理事件 为了保证线程长期运转，能够在子线程中加入RunLoop，而且给Runloop设置item，防止Runloop自动退出

10. 关于Socket，谈谈TCP/IP 和 UDP的理解

  • Socket是一个用于传输网络数据的工具，TCP/IP 和 UDP都是传输协议，用于定义网络数据传输的格式，属于长链接
  • TCP/IP 侧重可靠传输，传输速度慢，不会丢失数据，安全，聊天和下载文件时用到
  • UDP：侧重快速传输，传输速度快，容易丢失数据包，不安全。局域网游戏和网络游戏，视频聊天的时候用到
  • TCP更安全是由于有一个三次握手：第一次握手（客户端发送syn包到服务器，并进入SYN_SEND状态，等待服务器确认），第二次握手（服务器收到syn包，必须确认客户的SYN包，同时本身发送一个SYN+ACK包，此时服务器进入SYN_RECV状态），第三次握手（客户端收到服务器的SYN+ACK包，向服务器发送确认包ACK，发送完毕后服务器和客户端都进入ESTABLISHED状态，完成三次握手），三次握手以后才开始正式传输数据。
  • 那么如今即时通信更适合用TCP仍是UDP？
    • 早期使用MSN是使用TCP协议的，QQ使用采用UDP的，但并不表明UDP就不安全，由于能够手动对UDP的数据收发进行验证（好比发送方对每一个数据包进行编号而后由接收方进行验证），正是由于这个，QQ的传递速度是远远快于MSN，可能这也是战胜MSN的其中一个缘由吧
  • Http：超文本传输协议，用于定义网络数据传输的格式(短连接）http1.0以前不支持短链接，1.1以后默认就是长链接，只要在服务器和客户端同时设置Connection为keep-alive便可
    • 长链接是为了复用，长链接指的是TCP链接，也就是为了复用TCP链接，也就是说多个HTTP请求能够复用一个TCP链接，节省了不少TCP链接创建和断开的消耗
    • 好比请求了一个网页，这个网页确定还包含了CSS、JS等一系列资源，若是是短链接的话，每次打开一个网页，基本要创建几个甚至几十个TCP链接，浪费了大量资源
    • 长链接不是永久链接，若是一段时间内，具体的时间长短，是能够在header当中进行设置的，也就是所谓的超时时间，这个链接没有HTTP请求发出的话，那么这个长链接就会被断掉
  • socket链接是长链接，客户端与服务器保持通道，双方能够主动发送数据，通常多用于即时通信，游戏，默认超时时间是30秒，默认大小是8k（一个数据包大小）

11. 谈一谈内存管理

  • iOS的内存管理分为 MRC 和 ARC，管理的是堆区动态产生的对象，基本数据类型就不是内存管理的范围
  • 内存管理的核心概念是引用计数器：当对象被alloc、copy、new的时候，引用计数器+1，当被release的时候引用计数器—1，为0的时候就会被系统回收，调用dealloc方法
  • 说道内存管理，就必须说说@property的内存管理参数：
    • assign --> 针对于基本数据类型的简单赋值操做
    • retain --> release 一次旧对象 retain 一次新对象 (适用于OC对象类型)
    • copy --> release 一次旧对象 拷贝一个新对象出来（通常修饰字符串和block）
    • weak--> 表示一种非拥有关系，设置该属性时既不释放新值，也不保留旧值，和assign相似，可是目标对象释放时，属性值也会自动清空
  • 如何避免内存泄露 --> 使用Analyze进行代码的静态分析
  • 固然使用block的时候最应该注意下循环引用，使用Leaks检测内存泄露，显示绿色的勾告知内存处理的不错，实际上内存得不到释放。通常个人方法是在控制器声明周期的viewDidAppear和dealloc方法里面打印日志[[self class] description]，若是没有打印出来，就说明没有被释放。使用__weak __typeof(self) weakSelf = self;解决。有一次我是直接使用成员变量，而不是属性，_age，我觉得这样没有使用self就能够了，可是后来测试发现仍是形成循环引用了，由于_age是控制器的成员变量，也就是强引用了控制器，也要改为弱引用__block __weak __typeof(_currentModel) weakModel = _currentModel;

11.1 为何用 weak 修饰的变量会自动置为 nil？

  • runtime 对注册类，会进行布局，将 weak 修饰的对象放到一个hash表中，key值是该对象的内存地址，value是该对象
  • 当该对象retainCount为0时，执行dealloc，根据该地址去weak的hash表中查询到该对象，从而设置为nil（向nil发送消息是安全的）

12. 常见的数据持久化有哪些

  • 偏好设置（preference），利用NSUserDefaults
    • 用来保存应用程序设置和属性、用户保存的数据。用户再次打开程序或开机后这些数据仍然存在
    • NSUserDefaults能够存储的数据类型包括：NSData、NSString、NSNumber、NSDate、NSArray、NSDictionary。若是要存储其余类型，须要先转化为前面的类型，才能用NSUserDefault存储
    • 偏好设置是专门用来保存应用程序的配置信息的，通常不要在偏好设置中保存其余数据
    • 偏好设置会将全部数据保存到同一个文件中。即preference目录下的一个以此应用包名来命名的plist文件。
//1.得到NSUserDefaults文件
NSUserDefaults *userDefaults = [NSUserDefaults standardUserDefaults];
//2.向文件中写入内容
[userDefaults setObject:@"AAA" forKey:@"a"];
[userDefaults setBool:YES forKey:@"sex"];
[userDefaults setInteger:21 forKey:@"age"];
//2.1当即同步
[userDefaults synchronize];
//3.读取文件
NSString *name = [userDefaults objectForKey:@"a"];
BOOL sex = [userDefaults boolForKey:@"sex"];
NSInteger age = [userDefaults integerForKey:@"age"];
NSLog(@"%@, %d, %ld", name, sex, age);
复制代码
  • 归档(Archiver)、解档(unArchiver)，利用NSKeyedArchiver实现归档、利用NSKeyedUnarchiver反接的那个
    • 归档及时将内存中的对象写入到磁盘文件中，归档也叫序列化，解档就是讲磁盘中文件中的对象读取出来
    • 必须遵循NSCoding协议，只要遵循了NSCoding协议的对象均可以经过它实现序列化，两个协议方法必须实现
// 反归档
  - (id)initWithCoder:(NSCoder *)aDecoder {
      if ([super init]) {
          self.avatar = [aDecoder decodeObjectForKey:@"avatar"];
          self.name = [aDecoder decodeObjectForKey:@"name"];
          self.age = [aDecoder decodeIntegerForKey:@"age"];
      }
      return self;
  }
  // 归档
  - (void)encodeWithCoder:(NSCoder *)aCoder {
      [aCoder encodeObject:self.avatar forKey:@"avatar"];
      [aCoder encodeObject:self.name forKey:@"name"];
      [aCoder encodeInteger:self.age forKey:@"age"];
  }
复制代码
* 归档，把对象归档时须要调用NSKeyedArchiver的工厂方法archiveRootObject: toFile: 方法
复制代码
NSString *file = [NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES).firstObject stringByAppendingPathComponent:@"person.data"];
  Person *person = [[Person alloc] init];
  person.avatar = self.avatarView.image;
  person.name = self.nameField.text;
  person.age = [self.ageField.text integerValue];
  [NSKeyedArchiver archiveRootObject:person toFile:file];
复制代码
* 反归档
复制代码
NSString *file = [NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES).firstObject stringByAppendingPathComponent:@"person.data"];
  Person *person = [NSKeyedUnarchiver unarchiveObjectWithFile:file];
  if (person) {
     self.avatarView.image = person.avatar;
     self.nameField.text = person.name;
     self.ageField.text = [NSString stringWithFormat:@"%ld", person.age];
  }
复制代码

这五种持久化操做不一样点

  • 从存储数据大小来看，归档、偏好设置、属性列表三种方法适合存储数据量较小的数据，数据库、CoreData方法适合存储数据量较大的数据

  • 从加密性来看，其中归档会将数据进行加密，而偏好设置是直接保存到属性列表中，不会对数据进行加密

  • 从存储类型来看，属性列表只能存放固定的七种类型（可在plist文件中看到），归档对存储类型无限制

13. KVC 和 KVO

  • KVC(key-value-coding键值编码，跟多状况下会简化程序代码)的常见用法：

    • 给私有变量（该变量不对外开放）赋值：[Person setValue: @"19" ForKeyPath:@"age"]
    • 字典转模型：setValuesForKeyWithDictionary
    • 取出私有变量：[Person valueForKey:@"age"]
    • 没有找到对应的key会崩溃：重写setValueForUndefinedKey

  • KVC缺点：一旦使用KVC，编译器没法检查出错误，即不会对设置的键、键路径进行错误检查，且执行效率低于自定义的setter和getter方法，由于使用KVC键值编值，必须先解析字符串，而后设置或访问对象的实例变量

  • 经过KVO（key-value-observing，典型的观察者模式，被观察的对象必须使用KVC键值编码来修改它的实例变量，这样才能被观察者观察到）监听person对象中name属性发生改变

    • 给监听的属性设置一个观察者：
[self.person addObserver:self forKeyPath:@"name" options:NSKeyValueObservingOptionNew | NSKeyValueObservingOptionOld context:nil];
复制代码
* 当person的name的值发生改变时,就会执行该方法
复制代码
- (void)observeValueForKeyPath:(NSString *)keyPath ofObject:(id)object change:(NSDictionary<NSString *,id> *)change context:(void *)context
{
  do something....
}
复制代码
  • 当一个类的属性被观察的时候，系统会经过runtime动态的建立一个该类的派生类，而且会在这个类中重写基类被观察的属性的setter方法，并且系统将这个类的isa指针指向了派生类（NSNotifying_类名），从而实现了给监听的属性赋值时调用的是派生类的setter方法。重写的setter方法会在调用原setter方法先后，通知观察对象值得改变。

14. @synthesize和@dynamic区别是什么

  • 这两个关键字都是@property对应的词
  • @synthesize 语义是若是没有手动实现setter和getter方法，那么编译器会自动帮你加上这两个方法
  • @dynamic告诉编译器，属性的setter和getter由用户本身实现，不自动生成（readOnly只实现getter便可），可是若是没有本身实现，编译的时候不会报错，运行的时候就会报错，这就是所谓的动态绑定

15. 谈谈时间响应链的通常顺序

  • 第一步：事件的产生：首先找到最合适的从UIApplication到keyWindow依次找到view，由上到下
    • 发生触摸事件后，系统会将该事件加入到一个由UIApplication管理的事件队列中，为何是队列而不是栈，由于队列先进先出，先产生的事件优先处理才合理
    • UIApplication 会从事件队列中取出最前面的事件，并将事件分发下去以便处理，一般，先把事件发送给应用程序的主窗口（keywindow）
    • 主窗口会在视图层级结构中找到一个最合适的视图来处理触摸事件（hitTest：方法遍历当前view的全部子类，返回最合适的view）
    • 找到合适的视图控件后，就会用视图控件的touches 方法来作具体的事件处理
  • 因为是从父视图到子视图，所以若是父view不接收事件，自视图也没法接收事件
  • 若是肯定父控件是最合适的view，那么父控件的子控件的hitTest:withEvent: 方法也会被调用
  • 想让谁成为最合适的view就重写本身的父控件的hitTest:withEvent: 方法，返回指定的控件
  • 第二步：事件的响应：由下到上
    • 先看inital view可否处理这个事件，若是不能依次往上传递(如self或superView的userInterface/enable属性为NO，透明度小于0.1等缘由)，一直传递到该视图的VC/window/application ，若是application还不能处理，就将该事件抛弃
    • 在事件的响应过程当中，若是某控件实现了 touches 方法，则这个事件由该控件来接收，若是调用了[super touches] 方法，就会将事件顺着响应者链条往上传递，传递给上一个响应者

16.1 post和get方式的区别

  • GET请求的数据会负载URL以后，即把数据放在HTTP协议头中，以？区分URL和传输数据，参数之间以&相连，英文字母/数字，原样发送，若是是空格，转化为+，若是是中文，把字符串用BASE64加密；POST就是把提交的数据放在HTTP包的包体中

  • GET通常用于提交少许数据（最多提交1k，浏览器限制），POST用于提交大量数据（理论上无限制，收服务器限制）

  • GET 无反作用，POST 有反作用

  • GET提交的数据能够在浏览器历史记录中看到，安全性很差，别人能够拿到帐号密码，POST不会

  • Get是向服务器发索取数据的一种请求，而POST是向服务器发提交数据的一种请求，只是发送机制不一样

  • GET不能够设置书签，POST能够设置书签

  • POST支持更多编码类型且不对数据类型限制

  • 什么状况下用POST：

    • 请求的结果具备持续性反作用，如数据库添加新的数据行
    • 若使用get方法，则表单上手机的数据可能让URL过长
    • 要传送的数据不是采用7位的ASCII编码

  • 什么状况下用GET：

    • 请求是为了查找资源，HTML表单数据仅用来帮助搜索
    • 请求结果无持续反作用性的反作用
    • 手机的数据及HTML表单内的输入字段名称的总长不超过1024个字符

16.2 POST和PUT区别

  • POST请求的url表示处理该封闭实体的资源，该资源多是个数据接收过程、某种协议的网关、或者接收注解的独立实体。

  • PUT请求中的url表示请求中封闭的实体-用户代理知道url的目标，而且服务器没法将请求应用到其余资源。若是服务器但愿该请求应用到另外一个url，就必须发送一个301响应；用户代理可经过本身的判断来决定是否转发该请求。

  • POST是用来提交数据的。提交的数据放在HTTP请求的正文里，目的在于提交数据并用于服务器端的存储，而不容许用户过多的更改相应数据（主要是相对于在url 修改要麻烦不少)。

  • PUT操做是幂等的。所谓幂等是指无论进行多少次操做，结果都同样。好比我用PUT修改一篇文章，而后在作一样的操做，每次操做后的结果并无不一样

  • POST操做既不是安全的，也不是幂等的，好比常见的POST重复加载问题：当咱们屡次发出一样的POST请求后，其结果是建立出了若干的资源。

  • 安全和幂等的意义在于：当操做没有达到预期的目标时，咱们能够不停的重试，而不会对资源产生反作用。从这个意义上说，POST操做每每是有害的，但不少时候咱们仍是不得不使用它。

  • 还有一点须要注意的就是，建立操做可使用POST，也可使用PUT，区别在于POST 是做用在一个集合资源之上的，而PUT操做是做用在集合的一个具体资源之上的，再通俗点说，若是URL能够在客户端肯定，那么就使用PUT，若是是在服务端肯定，那么就使用POST，好比说不少资源使用数据库自增主键做为标识信息，而建立的资源的标识信息究竟是什么只能由服务端提供，这个时候就必须使用POST。

17. 深复制和浅复制

  • 非集合类对immutable对象进行copy操做，是指针复制，mutableCopy操做时内容复制
  • 非集合类对mutable对象进行copy和mutableCopy都是内容复制
  • 在集合类对象中，对immutable对象进行copy，是指针复制，mutableCopy是内容复制
  • 在集合类对象中，对mutable对象进行copy和mutableCopy都是内容复制。可是：集合对象的内容复制仅限于对象自己，对象元素仍然是指针复制
  • copy出来的对象都是不可变的，mutableCopy出来的对象都是可变的
  • NSString *str = @"string"; str = @"newString"; 打印对象地址，发现是发生变化的，须要把@"newStirng"当作一个新的对象，将这段对象的内存地址赋值给str

18. 关于项目中动画的使用

  • 序列帧动画：self.imageView.animationImages = array;
  • [UIView animateWithDuration] + CGAffinetransform
  • 核心动画CABasicAnimation *anim = [CABasicAnimation animationWithKeyPath:@"position.y"]; anim.fromValue toValue repeatCount [btn.layer addAnimation]
  • 关键帧动画CAKeyframeAnimation，anim.values = array，添加到layer上
  • 组动画CAAnimationGroup，将以上动画组合起来
  • 转场动画：CATransition，设置duration和type，而后添加到layer上。利用UIView 的类方法实现转场动画 [UIView transitionWithView: duration: options: animations:^{ } completion:nil];
  • UIDynamicAnimator仿真者 、 UISnapBehavior吸附行为，设置damping来调节震动幅度 、 UIPushBehavior推进行为 、 UICollisionBehavior碰撞边缘检测行为 、 UIAttachmentBehavior附着行为 、 UIGravityBehavior重力行为
  • POPSpringAnimation
    • springBounciness[0,20]越大振幅越大。
    • springSpeed速度

20.0 关于Swift与OC的不一样

实际上是个面试官八个不懂Swift，并且通常不懂得就问个Swift与OC的不一样。。题主也只是在自学Swift，等到3.0出了以后再深刻研究，并且项目中可能也要开始从混编逐渐向Swift靠拢了。

  • Swift是一门更加现代化的语言，可是目前还在成长阶段，更新改动比较大，虽说其底层思想不变，变的是API和接口，可是每次更新完Xcode看到本身的Swift项目仍是有些淡淡的忧伤，并且目前Swift开发都要转成OC的runtime，包略大，所以题主认为成熟项目最好仍是采用OC

  • 先记住一句话：OC底层面向对象，而Swift底层更加面向协议

  • 咱们已经见识过Apple使用了大量协议，好比在tableView当中，咱们能够经过协议来告诉Apple须要多少个表视图单元格，而不是每时每刻都要继承UITableViewController

  • 在这里以MVVM做为测试用例：好比如今须要创建一个相似设置界面的tableView，每一个cell须要一个label和一个switch，自定义SwitchWithTextTableViewCell，在其内部创建一个configure方法中对label的title，titleFont，titleColor，switch的switchOn和switchColor等进行初始化，但这种方式很是累赘，好比添加一个副标题，就须要额外添加三个属性

  • 可是利用协议SwitchWithTextCellProtocol，让视图模型实现这个协议，而后在这里设置全部的属性

protocol SwitchWithTextCellProtocol {
    var title: String { get }
    var titleFont: UIFont { get }
    var titleColor: UIColor { get }

    var switchOn: Bool { get }
    var switchColor: UIColor { get }

    func onSwitchTogglenOn(onL Bool)
}
复制代码

  • 经过swift2.0重点饿协议扩展，就能够经过默认值来作一些处理了，若是对于大多数单元格来讲，能够肯定某一种颜色的话，就能够对其创建扩展，而后设置颜色便可，全部实现此协议的视图就没有必要再去设置这个颜色了

  • 如今，个人configure方法里面只要实现此协议的值就能够了

// 这个方法只须要一个参数，相比于以前的多个参数简便了不少
class SwitchWithTextTableViewCell: UITableViewCell {
    func configure(withDelegate delagate: SwitchWithTextCellProtocol) {
        // 在这里配置方法
    }
}
复制代码
  • 如今的视图模型
struct MinionModeViewController: SwitchWithTextCellProtocol {
    var title = "excellent!!"
    var switchOn = true

    var switchColor: UIColor {
        return .yellowColor()
    }

    func onSwitchToggleOn(on: Bool) {
        if on {
            print("The Minions are here to stay!")
        } else {
            print("The Minions went out to play!")
        }
    }
}
复制代码
  • 如今，cellForRowAtIndexPath()也变得很是简明了
let cell = tableView.dequeueReuseableCellWithIdentifier("SwitchWithTextTableViewCell", forIndexPath: indexPath) as! SwitchWithTextTableViewCell

cell.configure(withDelegate: MinionModeViewModel())

return cell
复制代码

再把模型放在视图模型层级，一遍对其进行跟踪，再视图模型中传递这些信息，这样单元格就能够生成了

  • 可是在这个基础上，还能够再作进一步的深化，就是创建两个协议，一个做为实际编码的数据源，好比标题内容之类的实际数据，一个做为单元格委托，存储颜色、字体之类的并无包含实际数据的信息，也就是仿照Apple中UITableView等集合视图之类的地方，按照这种思惟去创建单元格存储和单元格委托
protocol SwitchWithTextCellDataSource {
    var title: String { get }
    var switchOn: Bool { get }
}

protocol SwitchWithTextCellDelegate {
    func onSwitchTogglenOn(on: Bool)

    var switchColor: UIColor { get }
    var textColor: UIColor { get }
    var font: UIFont { get }
}
复制代码
  • 接下来，再让configure方法同时接受这两个协议。由于委托能够所有在协议扩展中使用默认值进行配置，好比说字体、颜色之类的信息，这样在理论上就能够不用向里面传递任何东西进去，只须要建立一个模型就能够了
// SwitchWithTextTableViewCell
func configure(withDataSource dataSource: SwitchWithTextCellDataSource, delegate: SwitchWithTextCellDelegate?) {
    // 在这里配置视图
}
复制代码
  • 而后就要开始经过扩展来改进视图模型了，使用一个实际数据源的代码块，而后给定要传递的视图当中的原始信息
struct MinionModeViewModel: SwiftWithTextCellDataSource {
    var title = "Minion Mode!!"
    var switchOn = true
}
复制代码
  • 接下来会在一个单独的视图模型的部分使用处理字体、颜色之类的委托，而后在其中进行相关的配置
extension MinionModeViewModel: SwitchWithTextCellDelegate {

    var switchColor: UIColor {
        return .yellowColor()
    }

    func onSwitchToggleOn(on: Bool) {
        if on {
            print("The Minions are here to stay!")
        } else {
            print("The Minions went out to play!")
        }
    }
}
复制代码
  • 最终，表格视图单元格变得很是简单
// SettingViewController
let viewModel = MinionModeViewModel()
cell.configure(withDataSource:viewModel, delegate: viewModel)

return cell
复制代码

仅仅须要建立视图模型，而后将其传递到配置方法当中，最后返回单元格，就能够了

20.1 Swift2.0中的 Minxin 和 Trait

  • 在游戏开发中一般会有一个很庞大的层级关系，以及一系列的继承，好比各类怪，继承在这里显得十分有意义，可是随着层级的扩展，这个项目就会变得凌乱起来

  • 好比说须要设计一个能够射击的怪物，但这时候塔防顶部的大炮也会射击，就须要把“射击辅助类”提取出来，可是若是一直这样提取子类，代码后面会一团乱麻

  • 将这个代码重构，再也不去提取可以射击或者可以加血的子类，而是将其提取为协议，经过协议扩展来实现这个功能，代码更加简洁，更利于理解

// 一看这个对象的类型，就知道他有哪些功能，而不是一个个去查找她的实现
class ZapMonster: GameObject, GunTraint, HealthTraint, MovementTraint {
    ...
}
复制代码
  • 虽说这种设计模式是游戏方面的，可是咱们平时的代码也能够参考这种设计模式：这样就不须要让实际的单元格实现这个协议了，只须要将其根更普遍的TextPresentable 联系在一块儿就能够了，这样，任何拥有标签的视图，而不只仅是单元格，均可以实现这个协议来弯沉相关的功能。这样就能够说这个标签有什么样的温恩，什么样的颜色，以及什么样的字体
protocol TextPresentable {
    var text: String { get }
    var textColor: UIColor { get }
    var font: UIFont { get }
}

protocol SwitchPresentable {
    var switchOn: Bool { get }
    var switchColor: UIColor { get }

    func onSwitchToggleOn(on: Bool)
}
复制代码

这种状况下，好比须要一个图片框，只要一个iamgeProtocol就能够了，设计师要求改全部标签的颜色的话一行代码就能够搞定

  • 如今单元格的模样
class SwitchWithTextTableViewCell<T where T: TextPresentable, T: SwitchPresentable>: UITableViewCell {
    private var delegate: T?

    // T是视图模型
    func configure(withDelegate delegate: T) {
        // 在这里配置视图
    }
}
复制代码

在这种状况下，它没有实现这些协议，可是会期待某种实现这些协议的东西传递进去，所以咱们使用了泛型，这个单元格期待了一个实现了TextPresentableProtocol 的委托。就咱们而言，传递进去的将是一个实现了这些协议的东西就能够了，如今要基于这些信息在单元格当中配置全部的东西了，如今就能够基于浙西而信息在单元格中配置全部的东西了

extension MinionModeViewModel: TextPresentable {
    var text: String { return "Minion Mode" }
    var textColor: UIColor { return .blackColor() }
    var font: UIFont { return .systemFontOfsize(17.0) }
}
复制代码

  • 咱们的视图模型将会有一个TextPresentable代码，在其中能够配置文本、颜色、字体，而且因为全部的这些协议扩展中都已经有默认值了，甚至不须要视图模型去实现这些具体的内容

  • 最后，视图模型当中的代码就只须要dequeue相应的单元格。而后经过视图模型对其进行配置，而后返回单元格便可

21. 优化tableViewCell高度

  • 一种是针对全部 Cell 具备固定高度的状况，经过：self.tableView.rowHeight = 88; 指定了一个全部 cell 都是 88 高度的 UITableView，对于定高需求的表格，强烈建议使用这种（而非下面的）方式保证没必要要的高度计算和调用。

  • 另外一种方式就是实现 UITableViewDelegate 中的：heightForRowAtIndexPath:须要注意的是，实现了这个方法后，rowHeight 的设置将无效。因此，这个方法适用于具备多种 cell 高度的 UITableView。

  • iOS7以后出了了estimatedRowHeight，面对不一样高度的cell，只要给一个预估的值就能够了，先给一个预估值，而后边滑动边计算，可是缺点就是

    • 设置估算高度之后，tableView的contentSize.height是根据cell高度预估值和cell的个数来计算的，致使导航条处于很不稳定的状态，由于contentSize.height会逐渐由预估高度变为实际高度，不少状况下肉眼是能够看到导航条跳跃的
    • 若是是设计很差的上拉加载或下拉刷新，有可能使表格滑动跳跃
    • 估算高度设计初衷是好的，让加载速度更快，可是损失了流畅性，与其损失流畅性，我宁愿让用户加载界面的时候多等那零点几秒

  • iOS8 WWDC 中推出了 self-sizing cell 的概念，旨在让 cell 本身负责本身的高度计算，使用 frame layout 和 auto layout 均可以享受到：

    • self.tableView.estimatedRowHeight = 213; self.tableView.rowHeight = UITableViewAutomaticDimension; 若是不加上估算高度的设置，自动算高就失效了
    • 这个自动算高在 push 到下一个页面或者转屏时会出现高度特别诡异的状况，不过如今的版本修复了。

  • 相同的代码在 iOS7 和 iOS8 上滑动顺畅程度彻底不一样，iOS8 莫名奇妙的卡。很大一部分缘由是 iOS8 上的算高机制大不相同,从 WWDC 也却是能找到点解释，cell 被认为随时均可能改变高度（如从设置中调整动态字体大小），因此每次滑动出来后都要从新计算高度。

    • dequeueReusableCellWithIdentifier:forIndexPath: 相比不带 “forIndexPath” 的版本会多调用一次高度计算
    • iOS7 计算高度后有”缓存“机制，不会重复计算；而 iOS8 不论什么时候都会从新计算 cell 高度

  • 使用 UITableView+FDTemplateLayoutCell（百度知道负责人孙源） 无疑是解决算高问题的最佳实践之一，既有 iOS8 self-sizing 功能简单的 API，又能够达到 iOS7 流畅的滑动效果，还保持了最低支持 iOS6

  • FDTemplateLayoutCell 的高度预缓存是一个优化功能，利用RunLoop空闲时间执行预缓存任务计算，当用户正在滑动列表时显然不该该执行计算任务影响滑动体验。

    • 当用户正在滑动 UIScrollView 时，RunLoop 将切换到 UITrackingRunLoopMode 接受滑动手势和处理滑动事件（包括减速和弹簧效果），此时，其余 Mode （除 NSRunLoopCommonModes 这个组合 Mode）下的事件将所有暂停执行，来保证滑动事件的优先处理，这也是 iOS 滑动顺畅的重要缘由
    • 注册 RunLoopObserver 能够观测当前 RunLoop 的运行状态，并在状态机切换时收到通知：
      • RunLoop开始
      • RunLoop即将处理Timer
      • RunLoop即将处理Source
      • RunLoop即将进入休眠状态
      • RunLoop即将从休眠状态被事件唤醒
      • RunLoop退出
    • 分解成多个RunLoop Source任务，假设列表有 20 个 cell，加载后展现了前 5 个，那么开启估算后 table view 只计算了这 5 个的高度，此时剩下 15 个就是“预缓存”的任务，而咱们并不但愿这 15 个计算任务在同一个 RunLoop 迭代中同步执行，这样会卡顿 UI，因此应该把它们分别分解到 15 个 RunLoop 迭代中执行，这时就须要手动向 RunLoop 中添加 Source 任务（由应用发起和处理的是 Source 0 任务）

23. 为何AFN显示图片不如SDWebImage流畅？一样是从网络上下载图片而不是从缓存取图片？

  • 由于SDWebImage有一个decoder
  • UIImage的imageWithData函数是每次画图的时候才将Data解压成ARGB的图像
  • 因此每次画图的时候，会有一个解压操做，这样效率很低，可是只有瞬时的内存需求
  • 为了提升效率经过SDWebImageDecoder将包装在Data的资源解压，而后画在另一张图片上，这样新的图片就再也不须要重复解压了
  • 这是典型的空间换时间的作法

25. 我是怎样用两个imageView实现了无线轮播！

  1. 创建一个scrollView，设置contentsize为3*kWidth，contentOffSet为kWidth
  2. 接下来使用代理方法scrollViewDidScroll来监听scrollview的滚动，定义一个枚举变量来记录滚动的方向
  3. 使用KVO来监听direction属性值的改变-->[self addObserver:self forKeyPath:@"direction" options:NSKeyValueObservingOptionNew context:nil];
  4. 经过observeValueForKeyPath判断滚动的方向，当偏移量大于x，表示左移，则将otherImageView加在右边，偏移量小于x，表示右移，则将otherImageView加在左边。同时判断设置对应的索引，图片
  5. 经过代理方法scrollViewDidEndDecelerating来监听滚动结束，结束后，scrollview的偏移量为0或者2x，咱们经过代码再次将scrollview的偏移量设置为x，并将currImageView的图片修改成otherImageView的图片，那么咱们看到的仍是currImageView，只不过展现的是下一张图片，如图，又变成了最初的效果
  6. ，而后设置自动轮播，添加计时器，利用setContentOffset方法里面setContentOffset:animated:方法执行完毕后不会调用scrollview的scrollViewDidEndDecelerating方法，可是会调用scrollViewDidEndScrollingAnimation方法，所以咱们要在该方法中调用pauseScroll（即监听减速结束后由otherImageView切换到currImageView的方法）
  7. 添加计时器：self.timer = [NSTimer timerWithTimeInterval:self.time target:self selector:@selector(nextPage) userInfo:nil repeats:YES];
  8. 在scrollViewWillBeginDragging中中止计时器
  9. 在scrollViewDidEndDragging中开启计时器
  10. 判断外界传入的是图片仍是路径，若是是图片，直接加入图片数组中，若是是路径，先添加一个占位图片，而后根据路径去下载图片
  11. 监听图片被点击
    • 定义一个block属性暴露给外界void(^imageClickBlock)(NSInteger index) （不会block的能够用代理，或者看这里）
    • 设置currImageView的userInteractionEnabled为YES
    • 给currImageView添加一个点击的手势
    • 在手势方法里调用block，并传入图片索引
  12. NSTimer的两种形式
    • scheduledTimerWithTimeInterval 是建立一个定时器，并加入到当前运行循环[NSRunLoop currentRunLoop]中
    • 其余两个（[NSTimer timerWithTimeInterval:3 target:self selector:@selector(doSomeThing1) userInfo:nil repeats:YES]; [[NSTimer alloc] initWithFireDate:[NSDate dateWithTimeIntervalSinceNow:5] interval:3 target:self selector:@selector(doSomeThing2) userInfo:nil repeats:YES];）只是建立定时器，并未添加到当前运行循环中，因此若是是其余两种方式建立的定时器则须要手动添加到currentRunLoop中
  • NSTimer是普通的定时器，若是系统繁忙，刷新可能会被延迟。可是CADisplaylink实时刷新，跟着屏幕的刷新频率实时刷新，60次/s，与屏幕刷新频率相同

26. tableView的优化

iOS平台由于UIKit自己的特性，须要将全部的UI操做都放在主线程执行，因此有时候就习惯将一些线程安全性不肯定的逻辑，以及它线程结束后的汇总工做等等放到了主线程，因此主线程包含大量计算、IO、绘制都有可能形成卡顿。

  • 能够经过监控runLoop监控监控卡顿，调用方法主要就是在kCFRunLoopBeforeSources和kCFRunLoopBeforeWaiting之间,还有kCFRunLoopAfterWaiting以后,也就是若是咱们发现这两个时间内耗时太长,那么就能够断定出此时主线程卡顿.
  • 使用到CFRunLoopObserverRef,经过它能够实时得到这些状态值的变化
  • 监控后另外再开启一个线程,实时计算这两个状态区域之间的耗时是否到达某个阀值,便能揪出这些性能杀手.
  • 监控到了卡顿现场,固然下一步即是记录此时的函数调用信息,此处可使用一个第三方Crash收集组件PLCrashReporter,它不只能够收集Crash信息也可用于实时获取各线程的调用堆栈
  • 当检测到卡顿时,抓取堆栈信息,而后在客户端作一些过滤处理,即可以上报到服务器,经过收集必定量的卡顿数据后通过分析便能准肯定位须要优化的逻辑

  1. 设置正确的 reuseidentifer 以重用 cell

  2. 尽可能将 View 设置为不透明,包括 cell 自己（backgroundcolor默认是透明的），图层混合靠GPU去渲染,若是透明度设置为100%，那么GPU就会忽略下面全部的layer，节约了不少没必要要的运算。模拟器上点击“Debug”菜单，而后选择“color Blended Layers”，会把全部区域分红绿色和红色,绿色的好,红色的性能差（通过混合渲染的），固然也有一些图片虽然是不透明的，可是也会显示红色，若是检查代码没错的话，通常就是图片自身的性质问题了，直接联系美工或后台解决就行了。除非必需要用GPU加载的，其余最好要用CPU加载，由于CPU通常不会百分百加载，能够经过CoreGraphics画出圆角

  3. 有时候美工失误，图片大小给错了，引发没必要要的图片缩放（能够找美工去改，固然也能够异步去裁剪图片而后缓存下来），仍是使用Instrument的Color Misaligned Images，黄色表示图片须要缩放，紫色表示没有像素对齐。固然通常状况下图片格式不会给错，有些图片格式是GPU不支持的，就还要劳烦CPU去进行格式转换。还有能够经过Color Offscreen-Rendered Yellow来检测离屏渲染（就是把渲染结果临时保存，等到用的时候再取出，这样相对于普通渲染更消耗内存，使用maskToBounds、设置shadow，重写drawRect方法都会致使离屏渲染） 避免渐变，cornerRadius在默认状况下，这个属性只会影响视图的背景颜色和 border，可是不会离屏绘制，不影响性能。不用clipsToBounds（过多调用GPU去离屏渲染），而是让后台加载图片并处理圆角，并将处理过的图片赋值给UIImageView。UIImageView 的圆角经过直接截取图片实现，圆角路径直接用贝塞尔曲线UIBezierPath绘制（人为指定路径以后就不会触发离屏渲染），UIGraphicsBeginImageContextWithOptions。UIView的圆角可使用CoreGraphics画出圆角矩形，核心是CGContextAddArcToPoint 函数。它中间的四个参数表示曲线的起点和终点坐标，最后一个参数表示半径。调用了四次函数后，就能够画出圆角矩形。最后再从当前的绘图上下文中获取图片并返回，最后把这个图片插入到视图层级的底部。 “Flash updated Regions”用于标记发生重绘的区域

  4. 若是 row 的高度不相同,那么将其缓存下来

  5. 若是 cell 显示的内容来自网络,那么确保这些内容是经过异步下载

  6. 使用 shadowPath 来设置阴影，图层最好不要使用阴影,阴影会致使离屏渲染(在进入屏幕渲染以前,还看不到的时候会再渲染一次,尽可能不要产生离屏渲染)

  7. 减小 subview 的数量，不要去添加或移除view，要就显示，不要就隐藏

  8. 在 cellForRowAtIndexPath 中尽可能作更少的操做,最好是在别的地方算好，这个方法里只作数据的显示，若是须要作一些处理,那么最好作一次以后将结果储存起来.

  9. 使用适当的数据结构来保存须要的信息,不一样的结构会带来不一样的操做代价

  10. 使用,rowHeight , sectionFooterHeight 和 sectionHeaderHeight 来设置一个恒定高度 , 而不是从代理(delegate)中获取

  11. cell作数据绑定的时候，最好在willDisPlayCell里面进行，其余操做在cellForRowAtIndexPath，由于前者是第一页有多少条就执行多少次，后者是第一次加载有多少个cell就执行多少次，并且调用后者的时候cell还没显示

  12. 读取文件,写入文件,最好是放到子线程,或先读取好,在让tableView去显示

  13. tableView滚动的时候,不要去作动画(微信的聊天界面作的就很好,在滚动的时候,动态图就不让他动,滚动中止的时候才动,否则可能会有点影响流畅度)。在滚动的时候加载图片，中止拖拽后在减速过程当中不加载图片，减速中止后加载可见范围内图片

27. 谈谈内存的优化和注意事项（使用Instrument工具的CoreAnimation、GPU Driver、I/O操做，检查fps数值）

  • 重用问题：好比UITableViewCell、UICollectionViewCell、UITableViewHeaderFooterViews等设置正确的reuseIdentifier，充分重用

  • 懒加载控件、页面：对于不是马上使用的数据，都应该使用延迟加载的方式，好比网络链接失败的提示界面，可能一直都用不到

  • 使用Autorelease Pool：在某些循环建立临时变量处理数据时，自动释放池以保证能及时释放内存

  • 不要使用太多的xib/storyboard：载入时会将其内部的图片在内的全部资源载入内存，即便将来好久才会须要使用，相对于纯代码写的延迟加载，在性能和内存上就差了不少

  • 数据缓存：对于cell的行高要缓存起来，使用reloadData效率也极高，对于网络数据，不须要每次都请求的，应该缓存起来，能够写入数据库，也能够经过plist文件存储

  • 选择正确的数据结构：针对不一样的业务场景选择最合适的数据结构是写出高效代码的基础

    • 数组：有序的一组值，使用索引查询起来很快，使用值查询的很慢，插入/删除 很慢
    • 字典：存储键值对对，用键查找比较快
    • 集合：无序的一组值，用值来查找很快，插入/删除很快

  • gzip/zip压缩：当从服务器下载相关附件时，能够经过 zip压缩后再下载，使得内存更小，下载速度也更快

  • 重大开销对象：一些objects的初始化很慢，好比NSDateFormatter和 NSCalendar，可是又无可避免的须要使用，一般做为属性存储起来，避免反复使用

  • 避免反复处理数据：须要应用须要从服务器加载数据，常为JSON或者XML格式的数据，在服务器端或者客户端使用相同的数据结构很重要

  • 选择图片时，要对图片进行压缩处理，根据不一样的状况选择不一样的图片加载方式，-imageNamed:读取到内存后会缓存下来，适合图片资源较小，使用很频繁的图片；-initWithContentsOfFiles:仅加载图片而不缓存，适合较大的图片。如果collectionView中使用大量图片的时候，能够用UIVIew.layer.contents=(__bridge id _Nullable)(model.clipedImage.CGImage)；这样就更轻量级一些

  • 固然有时候也会用到一些第三方，好比在使用UICollectionView和UITableView的时候，Facebook有一个框架叫AsyncDisplayKit，这个库就能够很好地提高滚动时流畅性以及图片异步下载功能（不支持sb和autoLayout，须要手动进行约束设置），AsyncDisplayKit用相关node类，替换了UIView和它的子类,并且是线程安全的。它能够异步解码图片，调整图片大小以及对图片和文本进行渲染，把这些操做都放到子线程，滑动的时候就流畅许多。我认为这个库最方便的就是实现图片异步解码。UIImage显示以前必需要先解码完成，并且解码仍是同步的。尤为是在UICollectionView/UITableView 中使用 prototype cell显示大图，UIImage的同步解码在滚动的时候会有明显的卡顿。另一个很吸引人的点是AsyncDisplayKit能够把view层次结构转成layer。由于复杂的view层次结构开销很大，若是不须要view特有的功能（例如点击事件），就可使用AsyncDisplayKit 的layer backing特性从而得到一些额外的提高。固然这个库还处于开发阶段，还有一些地方地方有待完善，好比不支持缓存，我要使用这个库的时候通常是结合Alamofire和AlamofireImage实现图片的缓存

但愿此文对您的求职或夯实基础起到做用，感谢阅读！

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程