本期内容主要包括
- tcp拥塞策略（许云华）
- 如何用shader做滤镜（张辰）
- ios uiwebview wkwebview注意点（许佳佳）
- ThreadLocal简介（江丁魁）
- ios中@property的作用（张艳强）
- 前端渲染virtual dom（郑雨薇）
- 总结本期知识点
wkwebview是苹果公司推出的替代uiwebview的方案，它在内存占用和稳定性方面有很大的优势，性能对比此篇文章就不讲了。 但是就目前情况而言，uiwebview还有有一些不能被完全替代的原因，比如wkwebview无法用NSURLProtocol拦截请求，因此无法通过NSURLProtocol实现加载离线化资源。 本文主要是记录自己在使用的时候碰到的一些坑。
uiwebview目前的方式就是直接通过JS定义方法，然后使用JSC来获得JS方法的回调。 wkwebview可以直接使用addScriptMessageHandler来添加需要监听的方法，然后在userContentController中处理监听事件。 主要的区别是，uiwebview的注入只对当前界面生效，在加载新的url或者界面刷新后就会失效。而wkwebview的注入对整个wkwebview生效，界面刷新不会对其有影响。 所以在uiwebview上如果有注入全局方法的需求，通过直接运行JS代码注入不可行，一般可以使用拦截自定scheme和host的方式来做方法注入。
uiwebview的cookie与NSHTTPCookieStorage 同步，每次访问都会带上NSHTTPCookieStorage 中的内容，包括在页面中输入document.cookie也能获取到NSHTTPCookieStorage 中的cookie。
但是wkwebview的cookie和NSHTTPCookieStorage 就不能及时同步，注意是不能及时同步，并不是不同步。主要体现在以下两个方面： 1、当NSHTTPCookieStorage 的中的cookie被修改了，cookie是会同步到wkwebview的，但是不是及时同步的，比如说我修改了NSHTTPCookieStorage的值之后然后马上打开一个wkwebview，wkwebview不一定能获取到我刚刚修改的cookie。 2、当我使用document.cookie在wkwebview中设置cookie的时候，我当前设置的cookie是会回写到NSHTTPCookieStorage中，但是也不是及时的。
由于不及时同步，我们就说一下可能会有的问题，举例两个场景： 1、wkwebview没有获取到cookie，然后触发登陆逻辑后修改NSHTTPCookieStorage 跳回wkwebview，这时候wkwebview很有可能还是没有cookie的，因为wkwebview的cookie不是及时同步的。 2、某一模块为了满足自己的需求，修改了NSHTTPCookieStorage 中的一个cookie，而这个cookie刚好和其他模块重名了，由于wkwebview会回写cookie到NSHTTPCookieStorage 中，因此它会把原来这个名字的cookie给覆盖掉。而不仅仅存在cookie的value被修改，导致其他模块cookie错误的的问题，如果expire被修改了，也同时会给其他模块带去cookie过期的问题。
目前网上的处理方法主要有以下两种： 1、在webview发起请求的时候附带cookie。 2、在webview创建的时候js注入cookie。
这两个方法都能解决wkwebview不能及时同步NSHTTPCookieStorage 的问题，但是无法解决wkwebview的cookie修改后不能及时回写到NSHTTPCookieStorage 的问题。 还是举个例子： 第一个wkwebview中的JS修改了一段cookie之后，没过多久又打开了第二个wkwebview，第二个wkwebview是很可能获取不到第一个wkwebview对cookie的修改的。最根本原因就是由于wkwebview的cookie无法及时回写到NSHTTPCookieStorage 。
那么这种情况如何解决呢？答案就是wkProcessPool。
使用同一个WKProcessPool的wkwebview可以共享cookie数据，但是WKProcessPool中的cookie并不和NSHTTPCookieStorage 一样会本地存储。在APP重启后WKProcessPool中的cookie会被重置。
@property = ivar(实例变量) + getter/setter（存取方法）;
在正规的 Objective-C 编码风格中，存取方法有着严格的命名规范。 正因为有了这种严格的命名规范，所以 Objective-C 这门语言才能根据名称自动创建出存取方法。
完成属性定义后，编译器会自动编写访问这些属性所需的方法，此过程叫做“自动合成”(autosynthesis)。需要强调的是，这个过程由编译 器在编译期执行，所以编辑器里看不到这些“合成方法”(synthesized method)的源代码。除了生成方法代码 getter、setter 之外，编译器还要自动向类中添加适当类型的实例变量，并且在属性名前面加下划线，以此作为实例变量的名字。
我们每次在增加一个属性,系统都会在 ivar_list 中添加一个成员变量的描述,在 method_list 中增加 setter 与 getter 方法的描述,在属性列表中增加一个属性的描述,然后计算该属性在对象中的偏移量,然后给出 setter 与 getter 方法对应的实现,在 setter 方法中从偏移量的位置开始赋值,在 getter 方法中从偏移量开始取值,为了能够读取正确字节数,系统对象偏移量的指针类型进行了类型强转.
@property有两个对应的词，一个是 @synthesize，一个是 @dynamic。如果 @synthesize和 @dynamic都没写，那么默认的就是@syntheszie var = _var;
@synthesize表示如果属性没有手动实现setter和getter方法，编译器会自动加上这两个方法。
@dynamic 告诉编译器：属性的 setter 与 getter 方法由用户自己实现，不自动生成。假如一个属性被声明为 @dynamic var，而且你没有提供 @setter方法和 @getter 方法，编译的时候没问题，但是当程序运行到 instance.var = someVar，由于缺 setter 方法会导致程序崩溃；或者当运行到 someVar = var 时，由于缺 getter 方法同样会导致崩溃。编译时没问题，运行时才执行相应的方法，这就是所谓的动态绑定。
ThreadLocal是java为了解决多个线程访问同一个变量造成数据不一致的问题时设计的一个类，相比于使用synchronized关键字，该方式主要是用空间换时间，即在每个线程中保存变量的副本，每个线程操作的其实是各自的副本。
因为使用多线程的时候，会有多个线程修改同一个变量导致数据不一致的问题，而使用synchronized方式会影响程序的效率。
我们可以在每个线程中创建一个HashMap用于存储变量的value，按照常规的思路，我们一般会选择使用当前线程的id作为HashMap的key，但是这样会存在一个问题，即一个线程最多只能有一个ThreadLocal，这样对于使用方局限性太强，因为使用方可能需要存储多个数据，那应该怎么办呢？可以将ThreadLocal实例变量的hash值作为存储的key，这样就可以实现对应的效果。具体的实现是每个线程维护一个ThreadLocalMap对象，key是ThreadLocal对象实例，value就是存储的值，ThreadLocal则只是提供当前线程ThreadLocalMap需要的实例对象。具体的实现细节可以查看代码，这里说一下一个小知识点，就是存储的key是ThreadLocal对象实例的hash值，这个值是怎么算的呢？
web界面由dom树构成：
谈论页面的变化之前，咱们先看下数据和页面（视觉层面的页面）的关系。数据是隐藏在页面底下，通过渲染展示给用户。同样的数据，按照不同的页面设计和实现，会以不同形式、样式的页面呈现出来。有时候在一个页面内的不同位置，也会有相同数据的不同表现。Web 的早期，这些页面通常是静态的，页面内容不会变化。而如果数据发生了变化，通常需要重新请求页面，得到基于新的数据渲染出的新的页面。
既然是在前端渲染页面，如果只是部分数据发生了变化，就要把页面整体或一大块区域重新渲染就有点笨了，于是前端工程师通过操作 DOM 只更新变化的数据对应的页面的内容。DOM 就是浏览器提供给开发者用于操作页面的模型嘛，直接通过脚本来调用 DOM 的各种接口就 OK。页面越来越复杂，聪明的工程师们发现数据变化之后，老是需要手动编码去操作对应的 DOM 节点执行更新，有点烦，不够懒啊。于是各种框架如雨后春笋般出现了，纷纷表示可以简化这个过程。
稍微早期的框架：
开发者借助框架，监听数据的变更，在数据变更后更新对应的 DOM 节点。虽然还是要写一些代码，但是写出来的代码好像很有条理的样子，至少更容易理解和维护了。
MVVM 框架出现了，以 AngularJS 为代表 框架出现了，以 AngularJS 为代表，仍然是数据变化后更新对应 DOM 节点的方式，但是建立这种绑定关系的过程被框架所处理，开发者要写的代码变少了，而且代码更易读和维护了。
Virtual DOM 概况来讲，就是在数据和真实 DOM 之间建立了一层缓冲。对于开发者而言，每次数据发生变化，就重新执行一次整体渲染。的确这样更简单，不用去琢磨到底是数据的哪一部分变化了，需要更新页面的哪一部分。数据变化了就调用 React 的渲染方法，而 React 并不是直接得到新的 DOM 进行替换，而是先生成 Virtual DOM，与上一次渲染得到的 Virtual DOM 进行比对，在渲染得到的 Virtual DOM 上发现变化，然后将变化的地方更新到真实 DOM 上。简单来说，React 在提供给开发者简单的开发模式的情况下，借助 Virtual DOM 实现了性能上的优化，以致于敢说自己“不慢”。
初始渲染：
初始渲染时，首先将数据渲染为 Virtual DOM，然后由 Virtual DOM 生成 DOM。
数据更新时，渲染得到新的 Virtual DOM，与上一次得到的 Virtual DOM 进行 diff，得到所有需要在 DOM 上进行的变更，然后在 patch 过程中应用到 DOM 上实现UI的同步更新。