今天博客的内容就系统的讨论一下Masonry对FSP的影响，以及如何更好的使用Masonry。如果你对iOS开发足够熟悉的话，那么对Masonry框架应该不陌生。简单的说，Masonry的诞生让AutoLayout的使用更为优雅，让控件的布局更为方便。使用辩证的观点来看一个事物的话，凡事都有两面性，Masonry的使用也不例外。Masonry框架的使用不当会直接影响当UI的FPS。今天我们就来讨论一下在使用Masonry时的一些误区，看一下那些影响性能的使用方式。本篇博客我们依然会依托于Demo来叙述的一些东西。
之前写过一篇文章是专门来介绍Masonry框架的，并且对该框架的源码进行了相关解析，详细内容请移步于《iOS开发之Masonry框架源码解析》。
一、Demo综述
1.运行效果
先入为主，本篇博客的内容依然是依托于我们特意为本篇博客所打造的Demo的，首先我们先来看一下Demo运行起来是怎样的效果，通过Demo我们可以看到那些问题，以及这些问题是如何被解决的。下方就是我们本篇博客所涉及Demo的运行效果。
从下方的运行效果不难看出，我们是分了6种情况来观察和判断Masonry的各种使用方式对FPS的影响如何。上方通过六个SegmentControl可以去切换Cell的布局方式。当然每种布局方式所呈现出来的Cell是相同的。这样也是做实验时保持实验项改变其他项保持一致的原则。我们可以通过右下方FPS指示器来直观的感受一下FPS的变化趋势。下方这个FPS显示控件是从我们之前的Demo中拿过来的。之前的Demo也是关于FPS优化的，只不过是关于Cell高度动态计算的FPS优化，详情请移步于《iOS开发之多种Cell高度自适应实现方案的UI流畅度分析》。
下方Cell中所显示的数据时随机生成的，左边的Image也是随机取的。右边的Title和Detail都是NSAttributedString并且下方的有些Detail有可能为空。如果某一条的Detail为空，那么该条Detail下方的所有内容的布局上移。稍后会详细的介绍该Demo以及其中的技术点。
2、模拟网络请求
上面Cell中显示的数据是通过模拟网络数据来获取的，下方就是我们的模拟网络层的相关代码。毕竟是Demo，并且Demo的重点不在网络层上，下方就简单的写了一下，代码比较简单。就是一个单例+一个模拟数据随机生成的方法，然后把这个随机生成的数据通过Block回调到网络层的使用者上。具体代码如下所示：
3、上述Cell的基类XBaseTableViewCell
上面每种Segment中的Cell都是一种独立的Cell类型，不过这些Cell有一个共同的父类。而这个父类就负责来处理这些Cell所共用的逻辑。下方的这个XBaseTableViewCell就是上述显示的所有Cell的基类。其中声明并初始化了Cell上的所有控件。并且提供了相关的设置值的方法。
从下方的代码中不难看出，有两个方法是需要子类进行重写的，一个是给控件添加布局的方法addLayoutSubviews, 另一个就是更新布局的方法updateLayoutSubviews方法。每个子类中都会对这两个方法进行重写并给出不同的布局方式。
4、Segment中切换Cell的代码
下方是在相应的VC中的点击SegmentControl的逻辑代码, 点击不同的Segment会选择不同的Cell然后刷新TableView，代码比较简单就不做过多的赘述了。
二、对上述各种的布局方式进行分析
接下来要做的事情就是分析一下每种布局方式对FSP的影响，下方会对不同的布局情况使用Instrument进行分析并看一下具体的数据。下方分别讨论了只使用Masonry的Update操作、Remake操作、先Make后Update、Frame操作以及先Make后Frame操作。
1、update