一 定义:
- UIScrollView的类继承关系:其父类为UIView,其子类包括:UITableView,UICollectionView,UITextView.
- 可知该类的特点是支持展示内容超过应用的窗口时.
- 其能确保使用者通过轻扫手势和缩放手势等使内容随手势滚动.
二 状态保持:
- 通过查找发现UIView,UIViewController都有这个属性,当然UIView的子类UIImageView,UIScrollView当然也有这个属性.
- 这个属性预示着在重用的进程中,UIView,UIViewController和其内容应该被保存,并且用来区分其自身.
- 这个属性默认置为nil,即其不需要被保存,这样保证不需要的就将其销毁,把内存节省出来,这大概也是为什么1G内存却能保证流畅的原因之一吧.
- 当然不排除一些特殊的情况,其用法如下:
|
|
三 管理内容的展示
|
|
四 管理滚动相关
|
|
五 管理滚动指示器
|
|
六 缩放相关
|
|
七管理代理
1 Responding to Scrolling and Dragging
|
|
2 Managing Zooming
|
|
3 Responding to Scrolling Animations
|
|
八 管理键盘
|
|
- 这个特性我估计很多人都不知道,可以实现滚动的时候,隐藏键盘.
九 不常用的一些
|
|
十 关于Auto Layout的相关用法
一般如果你只是使用纯代码约束做适配,没有使用autolayout 或者 Masonry 等第三方做适配的话,这方面基本涉及不到,但是如果你在项目中使用了比如现在流行的Masonry来做适配的话,当在UIScrollView上布局字View时,就需要注意这个点了.
- 首先你需要了解,frame是以父视图左上角位置为(0,0)点, 而bounds是以自身的左上角为(0.0)点算起.
- 对于 UIScrollView 的 subview 来说,它的leading/trailing/top/bottom space 是相对于 UIScrollView 的 contentSize 而不是 bounds 来确定的,所以当你尝试用 UIScrollView 和它 subview 的 leading/trailing/top/bottom 来互相决定大小的时候,就会出现「Has ambiguous scrollable content width/height」的 warning。
- 正确的姿势是用 UIScrollView 外部的 view 或 UIScrollView 本身的 width/height 确定 subview 的尺寸,进而确定 contentSize。因为 UIScrollView 本身的 leading/trailing/top/bottom 变得不好用.
- 所以我习惯的做法是在 UIScrollView 和它原来的 subviews 之间增加一个 content view.
这样做的好处有:
- 不会在 storyboard 里留下 error/warning
- 为 subview 提供 leading/trailing/top/bottom,方便 subview 的布局
- 通过调整 contentview 的 size(可以是 constraint 的 IBOutlet)来调整 contentSize
- 不需要 hardcode 与屏幕尺寸相关的代码
- 更好地支持 rotation