湖州网站建设服务,wordpress高亮代码大前端,成都百度推广公司电话,陕西建设工程合同备案网站今天博客的内容就系统的讨论一下Masonry对FSP的影响#xff0c;以及如何更好的使用Masonry。如果你对iOS开发足够熟悉的话#xff0c;那么对Masonry框架应该不陌生。简单的说#xff0c;Masonry的诞生让AutoLayout的使用更为优雅#xff0c;让控件的布局更为方便。使用辩证… 今天博客的内容就系统的讨论一下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 首先我们来看一下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稍微改善一些但是从下方的图中我们可以看出改善的并不是特别好。 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没有满格的原因。 6、make frame Masonry的诞生就是为了方便控件布局的Frame布局不够灵活适配起来比较繁琐所以才有了AutoLayout。不过虽然AutoLayout可以很方便的适配屏幕可是其性能方面表现的不是特别好。那么我们可不可以将两者进行结合呢。也就是说使用make来初始化控件的布局使用Frame来更新布局。当然这一过程不是简单的在设置值的时候更新一下Frame就可以的因为在Cell设置值的时候去更新Frame是没用的因为更新完Frame后在渲染显示的时候还是会按照AutoLayout的布局来显示的。我们需要做的是将Frame布局放到Autolayout布局之后此处我们要做的就是将更新Frame的相关代码放到下一个Runloop中来执行。更新Frame代码如下 在cell中是make初始化控件布局使用Frame更新布局和FrameFrame的方式差不多只不过是使用Masonry布局时在首屏加载的时候不如Frame布局以后更新是一样的。下方是使用MasonryFrame的形式的Core Animation的结果。效果虽然比上一部分会稍微差一些但是最终的效果还是满Ok的。  三、总结 本篇博客只讨论Masonry的布局方式对FPS的影响至于上述的NSAttributeString的问题不做过多赘述了。如果根据业务需要有许多富文本的展示影响了FPS的话那么可以采用其他的方式来进行优化比如使用AsynDisplayKit所提供的相关Node进行显示等等。在博客的结尾还是有必要做一个总结的。 下方是我们在代码中更为细化的数据从数据中不难看出Remake的性能是最差的所以我们在使用Masonry时尽量要少使用Remake。对控件的更新只一味的选择使用Update也不是一个好的选择如果要使用Masonry框架还要对控件进行布局更新的话最好是把那些不变的约束和需要更新的约束分开。使用make来添加相关约束使用update来修改需要更新的约束。当然使用Frame布局的性能会好一些不过布局过程过于繁琐不便于进行屏幕的适配。当然也可以使用Masonry进行布局使用Frame进行布局的更新当然需要注意的是Frame布局更新的时机需在Autolayout加载的时机后进行。 下方是进行了统一的数据统计当然是针对本篇博客所对应的Demo的。下方表格中统计了一次更新cell布局所采用的不同方式的平均时间从下方的数据中我们不难看粗Remake的更新布局用时最多消耗了12ms, 而Update所有的约束用时也是不少一次更新布局使用了9ms。而只更新需要更新的布局用时7ms, 稍微要比更新所有的布局要好一些。当然直接修改Frame的用时最少只用了0.06ms的时间从该数据可以直观的感受到Frame布局的效率性。 而右边还给出了一个属性字符串的创建和赋值的用时其中我们可以看到属性字符串的创建耗时并不是太多而比较耗时的是属性字符串的赋值每次赋值占用了0.7ms, 如果是10个的话那么赋值时间就是7ms, 如果属性字符串的内容再复杂一些那么用时肯定会比这个高。当然我们可以使用第三方提供的一些控件和方法将这部分时间给优化掉这个可以放到以后再讨论。 今天的博客就到这儿吧目的是在使用Masonry时要合理的进行使用有必要时可以使用Frame进行布局。 上述demo -github分享链接https://github.com/lizelu/FPSProfileDemo     原文地址http://www.cocoachina.com/ios/20171116/21197.html   转载于:https://www.cnblogs.com/SUPER-F/p/8963850.html