首先我们来看一下update操作。也就是使用update直接给控件赋值，这是比较偷懒的一种操作。因为在我们的Demo中在设置cell的值时会更新一些控件的UI布局，所有我们索性就直接使用Masonry的update，直接给控件添加约束。在Masonry中的update操作有个特点，就是update一个约束会先在已添加的约束数组中找到该约束，然后更新该约束，如果找不到就install添加相应的约束。从这个update的功能来看其效率是比较低的。
我可以先看一下代码实现，在子类XUpdateLayoutTableViewCell中，重写了addLayoutSubviews和updateLayoutSubviews两个方法。在updateLayoutSubviews方法中，为所有的控件使用update的方式添加约束。下方这样写会在每次设置值的时候都会调用下方的updateLayoutSubviews方法，这样就会更新cell上的控件的所有布局，当然，不建议这样去做，因为这样会更新那些不需要更新的约束。之所以今天罗列出来，是因为在开发中下方的问题确实存在，也许是因为时间紧张，也许是因为其他原因导致的下方这种代码实现。
我们先来使用Instruments跑一下上述的Demo，然后直观的感受一下该Demo的Core Animation的直观表现。下方就是我们将SegmentControl切换到Update时所对应的FPS数据。从下方的数据我们不难看出，直接用Update添加更新约束这种做法是比较影响FPS的。当然，Cell中还会使用到属性字符串，这个我们稍后会讨论一下的。
我们可以来跑一下Update状态下的Time Profile。如下所示，从下方的结果中不难看出，在Cell更新数据时，有两块的操作比较耗时。一个是Masonry的update操作，另一个则是Label设置NSAttributedString的操作。因为我们使用的每个Label都会赋值一个属性字符串，这个是比较耗时的操作。还有一个要明确一点的是，属性字符串的创建和生成并不会占用多少时间，而属性字符串的赋值和渲染所占用的时间是比较多的，这一点从下方的Time Profile中也是不难看出的。
2、remake
接下来我们在来看一下Remake操作，从下方的Core Animation的结果中不难看出，其所表现出来的效果还不如使用Update操作呢。下方的FPS比Update要低一些，这也与remake自身的操作有关系，remake从字面意思来看就是重新制作，如果之前已经添加过约束的话就先移除掉，然后再添加新的约束。
下方是Remake所对应的Time Profile，从结果中我们可以看出布局更新占用了66.6%的耗时，而且33%的install耗时中uninstall占用了10%左右的开销。在Masonry中remake效率是最低的。稍后我们会继续进行讨论。
3、make + update
讨论完update和remake, 我们来讨论一下使用Masonry的常规做法。就是使用make来初始化控件的布局，使用update来更新所需要更新的约束。因为代码比较简单，就不一一往上贴了，但是跑一下使用Instrument跑一下还是很有必要的。下方是make + update 的方式的Core Animation所跑出来的结果。但从下方的FSP结果来看，还是要比之前只使用update或者remake的效果要好一些的，不过下方的FPS还是不高，稍后我们会将下方的数据进行细化。
该部分的Time Profile就不跑了，因为设置值的时候我们依然采用的Update来更新的约束，只不过不是更新所有的约束，而是更新那些只需要更新的约束。因为更新的约束的量会少一些，所有FPS的表现效果会比之前更新所有的约束会更好一些。make + update的方式会是FPS稍微改善一些，但是从下方的图中我们可以看出，改善的并不是特别好。