成都ios培训：iOS架构设计之UI样式复用及布局管理.docx

成都ios培训：iOS架构设计之UI样式复用与布局管理　　该系列文章是2016年折腾的一个总结，对于这一年中思考和解决的一些问题做一些梳理和总结。Talk is cheap show me the code.　　本来只是想写写ElementKit中对于MVVM的实践来着，结果发现这一年做的一些事情中，还有值的继续说的。而且基本上都是围绕着解耦和复用的主题。而且很多都是在日常的开发中常见的问题和其解决方案。也就继续写写，算是抛砖引玉，在闷头设计开发之后与业界交流一下。　　这一次来说一下在日常的开发中最常见的两个问题：　　一个是样式，颜色、背景、font。。。。　　一个是布局管理　　其中的成果自然也是搞成了类库方便使用(Talk is cheap show me the code.)：StyleSheet和DZGeometryTools。　　样式和布局基本上是在iOS编程中最繁重的两个工作，之所以说繁重，　　一是因为常见，绝大多数iOSCoder每写一个业务逻辑，都得和这两个事情纠缠上半天，去还原UI/UE同学的设计。　　二是因为UI样式千变万化很难像其他业务逻辑那样用类继承了之类的策略来处理。每次都得蛮干。　　再一次提一句话『懒是第一生产力』，有压迫的地方就有反抗，有繁重的地方就想着偷懒。所以得需要一个有效途径来降低UI工作的繁重。　　抽象的威力　　其实我一直希望自己的文章能够道业双关。在说明一个问题的解决方案的同时，也能够解释清楚自己设计一个类库或者做一个技术决定背后的东西：知识背景和思维方法。还原整个从问题发现到问题解决方案的过程。所以，发现之前的几篇文章中多多少少有一些东扯西扯的东西。自然这篇文章也难免其俗:)。这一次要扯的是抽象。之所以要说这个是因为，在解决UI工作繁重的问题中，就是用的这个最基本的方法。　　删繁就简三秋树，霜叶红于二月花　　从小老师就耳提面命：要看透问题的表象看本质。起初不解，随着干Coder时间长了，愈发察觉要想偷懒就得去解决本质问题，而不是围绕着问题的表层转来转去。而进一步说，不能停留在使用简单抽象出来的概念解决问题的层次，应该进一步使用一些高级抽象。就拿布局这个事情来说吧。　　原始抽象　　第一层的抽象是对现实世界在数字世界的描述，用坐标系统。用数学语言来描述布局这个事情。其实抽象到这一步也是一个非常大的进步了。在iOS中也就是我们常用的springstruct的布局系统。通过frame等来标注一个view来控制平面布局，通过View-Tree来控制Z轴方向上的布局。　　基于这种抽象的情况下，我们做的事情就是精准的描述每一个View在坐标系统中的位置。这个就是那个繁重的工作。在layoutsubviews函数里面里面，各种计算大小和偏移量。熟悉iOS的同学，随意看一下自己View里面layoutSubviews函数的大小就可以感受到其繁重。　　描述抽象　　抽象这个东西有意思的地方就在于他是可以递归使用的。在第一层抽象得到的概念基础上，进行第二层抽象;在第二层抽象得到的概念基础上，进行第三层抽象…..如此反复。当然，Apple牛逼的工程师们也会意识到springstruct的繁重，于是就有了Autolayout(自动布局系统)。　　Autolayout是基于描述的抽象，更多的是描述元素与元素之间的位置关系。通过解n元一次方程组来确定元素的位置(在坐标系统中的frame)。而这种基于模式的抽象，要比刚才第一层的抽象要高级很多。在这种抽象概念下，我们发现我们写的布局的代码有了一个大幅度的减少。原先需要拼了老命计算view frame的情况变成了，描述view之间关系的过程。原先需要非常多代码才能完成的任务，现在只要简单的写一句AView在x轴方向上距离BView固定间隔为10就可以完成了。随着代码量的降低，我们的对于布局系统理解成本都在降低。　　复杂性由固有复杂性和认知复杂性组成。　　而基于描述的抽象，因为是对第一层抽象概念的操作，忽略了第一层抽象的很多细节，很大程度上降低了布局系统的认知复杂度。无论从代码量上还是我们的认知成本上，都让我们可以『偷懒』了。　　任务抽象　　而有了基于描述抽象的Autolayout之后，我们会发现其实很多任务还是很繁重，比如我们要写个List布局，不可能每次都把List中每个元素的位置关系描述一边啊。比如我们要写个Collection的布局，也不可能每次都把每个元素的位置关系都描述一边啊…..　　于是真对某些特定任务，会使用任务抽象。把List布局抽象成UITableView，把Collection布局抽象成UICollectionView，把线性布局抽象成UIStackView。。。。。而且Apple的工程师们也会在这条路上越走越远。在近几个版本的iOS-SDK更新中，我们