4、frame + frame
接下来，我们就不用Masonry来布局了，我们直接使用Frame布局。因为Autolayout最终仍然会转换为Frame布局的，很显然Frame布局在性能方面是优于Autolayout布局的。接下来我们就来使用Frame布局然后使用Frame更新。下方的FPS还算说得过去，不过还不是满格，其大部分原因就是因为NSAttrubitedString的原因了。
我们可以看一下更新Frame的Time Profile，如下所示。从下方的截图中，我们不难看出update frame的时间占比只占到了2.5%，之前更新约束能占到60%左右，可以看到使用Frame布局的好处。从下方的分析结果中不难看出，现在影响FPS主要因素已经从更新布局转化到了AttributeString的设置。这也是上述FPS没有满格的原因。
5、make + frame
Masonry的诞生就是为了方便控件布局的，Frame布局不够灵活，适配起来比较繁琐，所以才有了AutoLayout。不过虽然AutoLayout可以很方便的适配屏幕，可是其性能方面表现的不是特别好。那么我们可不可以将两者进行结合呢。也就是说使用make来初始化控件的布局，使用Frame来更新布局。当然这一过程不是简单的在设置值的时候更新一下Frame就可以的，因为在Cell设置值的时候去更新Frame是没用的，因为更新完Frame后，在渲染显示的时候，还是会按照AutoLayout的布局来显示的。我们需要做的是将Frame布局放到Autolayout布局之后，此处我们要做的就是将更新Frame的相关代码放到下一个Runloop中来执行。更新Frame代码如下：
在cell中是make初始化控件布局，使用Frame更新布局，和Frame+Frame的方式差不多，只不过是使用Masonry布局时，在首屏加载的时候不如Frame布局，以后更新是一样的。下方是使用Masonry+Frame的形式的Core Animation的结果。效果虽然比上一部分会稍微差一些，但是最终的效果还是满Ok的。
三、总结
本篇博客只讨论Masonry的布局方式对FPS的影响，至于上述的NSAttributeString的问题不做过多赘述了。如果根据业务需要，有许多富文本的展示影响了FPS的话，那么可以采用其他的方式来进行优化，比如使用AsynDisplayKit所提供的相关Node进行显示等等。在博客的结尾，还是有必要做一个总结的。
下方是我们在代码中更为细化的数据，从数据中不难看出Remake的性能是最差的，所以我们在使用Masonry时尽量要少使用Remake。对控件的更新只一味的选择使用Update也不是一个好的选择，如果要使用Masonry框架还要对控件进行布局更新的话，最好是把那些不变的约束和需要更新的约束分开。使用make来添加相关约束，使用update来修改需要更新的约束。当然使用Frame布局的性能会好一些，不过布局过程过于繁琐不便于进行屏幕的适配。当然也可以使用Masonry进行布局使用Frame进行布局的更新，当然需要注意的是Frame布局更新的时机，需在Autolayout加载的时机后进行。
下方是进行了统一的数据统计，当然是针对本篇博客所对应的Demo的。下方表格中统计了一次更新cell布局所采用的不同方式的平均时间，从下方的数据中我们不难看粗Remake的更新布局用时最多，消耗了12+ms, 而Update所有的约束用时也是不少，一次更新布局使用了9+ms。而只更新需要更新的布局用时7+ms, 稍微要比更新所有的布局要好一些。当然直接修改Frame的用时最少，只用了0.06+ms的时间，从该数据可以直观的感受到Frame布局的效率性。