横向的主要用padding-left和padding-right来控制，还可用li的宽度来控制；
纵向的就多点，除了有padding-top和padding-bottom来控制，还可以用li的高度以及li的行高来控制；
具体二种代码如下：
<meta ><html>
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width,minimum-scale=1,initial-scale=1">
<title>竖排菜单</title>
<style>
{margin:0;padding:0;}
li{list-style:none;}
nav{height:200px;width:400px;}
nav>ul{height:200px;}
nav>ul>li:nth-child(1){width:80px;display:inline;}
nav>ul>li{width:320px;float:left;}
nav>ul>li>ul>li{float:left; padding:0 5px;}
</style>
</head>
<body>
<!--nav>ui加高度是清楚浮动，可以自行调整-->
<div class="nav">
<ul>
<li><a href="#">菜单</a></li>
<li>
<ul>
<li><a href="#">栏目二</a></li>
<li><a href="#">栏目三</a></li>
<li><a href="#">栏目四</a></li>
<li><a href="#">栏目五</a></li>
<li><a href="#">栏目二</a></li>
<li><a href="#">栏目三</a></li>
<li><a href="#">栏目四</a></li>
<li><a href="#">栏目五</a></li>
</ul>
</ul>
</ul>
</div>
</body>
</html>CPU和GPU两个硬件是通过总线连接起来的,在CPU输出的结果是一个位图,经由总线,在合适的时机,上传给GPU,GPU拿到位图后会做相应位图的图层渲染,包括纹理合成,之后把结果放到帧缓冲区Frame Buffer中,由视频控制器根据VSync信号,在指定时间之前,去提取帧缓冲区中屏幕显示内容,最终显示到显示器上
UIView的显示是CALayer负责,CALayer有个contents属性,就是最终要绘制到屏幕上的位图,假如绘制的是label,内容是hello world,那么contents里放置的就是hello world文字的位图,系统会在合适的时机回调给我们drawRect方法,我们可以在屏幕显示的基础之上,去绘制一些自定义想要绘制的内容,绘制好的位图,最终会经由Core Animation这个框架,提交给GPU部分的OpenGL渲染管线,进行位图的最终渲染,包括纹理合成,然后显示到屏幕上面
CPU需要完成UI的布局,包括显示绘制,之后做一些准备工作,然后把相应的位图提交到GPU上面
UI布局和文本计算包括控件Frame的设置,对于控件的文字或者size的计算
Display就是绘制过程,drawRect方法发生在这一步骤
PrePare准备阶段:假如有UIImageView,那么设置它的image的时候,是不能直接显示到屏幕上去的,需要对进行解码
Commit:对最终的输出结果位图进行提交
指的是OpenGL的渲染管线
首先顶点着色,指的是对位图进行处理
做完上面五步之后,会把最终的像素点提交到对应的帧缓冲区中,由视频控制器根据Vsync信号,在指定时间之前,去提取帧缓冲区中屏幕显示内容,最终显示到显示器上
上面是VSync垂直信号
我们一般说的页面滑动的流畅性是60fps,指的是每一秒会有60帧的画面更新,那么人眼看到的就是流畅的效果,基于此,相当于每隔167毫秒(60分之1)就要产生一帧画面,在167ms之内,需要CPU和GPU共同协同完成最终的一帧的数据,
灰方块表示CPU花费一定的时间进行文本的布局,UI计算,视图的绘制,解码等
然后把位图提交给GPU,GPU进行图层的合成,纹理渲染,准备好要显示的画面,那么在下一次VSync信号到来时,就可以显示准备好的这一帧画面了
假如CPU做工作时时长特别长的时候,留给GPU的时间就比较少了,等GPU将工作做完,总时长就超出167了,在下一帧VSync信号到来的时候,没有准备好当下这一帧的画面,就产生了掉帧,那么我们肉眼看到的效果就是滑动的卡顿
基于这个掉帧原因,我们可以分析如何提高Tableview等控件的滑动流畅性优化的方案
减轻CPU的工作时长和压力
在子线程中进行对象的创建,调整和销毁
在子线程中预排版(布局计算,文本计算)
让主线程有更多的时间去响应用户的交互
预渲染(文本等异步绘制,编解码等)
纹理渲染方面的优化:
假如我们触发了离屏渲染,就会产生一些layer的圆角,masksToBoundsdang的设置,阴影蒙层,这些都会触发GPU层面的离屏渲染,这种情况下,GPU做离屏渲染的工作量就会很大优化就是尽量避免离屏渲染,还可以依托CPU的异步绘制机制来减轻GPU的压力
视图混合方面的优化:
若视图层级复杂,GPU就要做每一个视图的合成,合成每个像素点对应的像素值,需要做大量的计算,可以减轻视图层级复杂性,就能减轻GPU的压力,也可以通过CPU层面的异步绘制机制,来达到提交的位图本身就是一个层级少的视图,这样也可以减轻GPU的压力
当前屏幕渲染:
GPU的渲染 *** 作是在当前用于显示的屏幕缓冲区中进行
离屏渲染:
GPU在当前屏幕缓冲区以外新开辟一个缓冲区进行渲染 *** 作
当我们调用UIView的setNeedsDisplay后,并没有立刻发生当前视图的绘制工作,而是在之后的某一时机才会进行当前视图的绘制
当调用UIView的setNeedsDisplay后,系统会立刻调用view的layer的同名方法,之后相当于在layer上面打上了一个脏标记,然后再当前runloop将要结束的时候,才会调用CALayer的display方法,然后才进入到当前视图的真正绘制工作流程中
CALayer的display方法,在内部会首先判断layer的delegate是否响应displayLayer这个方法,若不响应,则系统开始绘制流程
若响应,则开始异步绘制
首先CALayer内部会创建一个CGContextRef,在drawRect方法中,可以通过堆栈中的上下文取出这个context,然后layer会判断它是否有代理,若没有,则调用CALayer的drawInContext,若有则调用代理方法,做当前视图的绘制工作,再在合适的时机,基于drawRect回调方法,
drawRect默认 *** 作是什么都不做,而之所以有这个接口,就是为了让我们在系统绘制之上,可以做些自定义的绘制工作
最后再由CALayer上传对应的context给GPU,
基于layer的delegate,如果实现了displayLayer方法,就可以进入到异步绘制流程当中
在异步绘制过程中
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）