iOS开发总结Swift

如何写好一个自定义View

2018-10-01  本文已影响45人  Randall_Steven

前言

对于iOS开发来说,写一个自定义view,或者恰当地使用tableview基本上可以算的上是“行活”。但是看过一些同学写的自定义控件后,有时感觉似乎写的不够好,虽然可以正常工作,但是在可拓展性、易用性、以及稳定性上都有所欠缺。所以我打算写一个系列,就叫做如何写好xxx,就总结下我认为的好的写法应该是什么样的,这篇便是这系列的第一篇。

当然受视野和水平所限,文章中提到的一些东西并不一定是最优解,非常欢迎大家提出不同的意见,讨论后共同成长!

目标

实现

初始化方法

这里我们大可借鉴一下UIKit中系统的UI组件是如何设计自己的初始化方法的。

UIKit中初始化方法大概分为两类,

首先,我们要搞清楚什么是Designated initializer和Convenience Initializer。

其次,为什么UIView的子类都会有两个Designated initializer呢?这里就是我们之前提到的,View的两种使用方法,Xib/storyboard,和纯代码。

实现Designated initializer

为了既能满足纯代码的方式,又能使用Xib的方式,我们需要实现CustomView的两个Designated initializer

而且在swift中,initWithCoder已经被标记为required,所以必须要实现啦

在实现这两个方式时,主要做的就是添加子view,以及提供默认值

提供Convenience Initializer

例如UIImageView,他就提供了initWithImage 这个Convenience Initializer。

使用Convenience Initializer的好处也是显而易见的,能让类的使用者很清楚的知道我应该如何正确的初始化这个类。而且会对必需的属性提供默认值,既能极大的避免了调用者只调用init,导致该实例并不能正常工作,又能在很多属性时,提供一个简单的初始化方法。

内部子view布局的实现

frame or autoLayout?

如果使用frame,我们需要保证custom view自己的size发生变化的时候,subviews能够自动变化,而不是保持原有的frame。(autoresizingMask,autoresizesSubviews)

如果使用autoLayout,就不存在上面的问题,唯一一个需要考虑的问题便是性能了。通过WWDC也可以知道,虽然苹果对于autolayout一再优化,仍然在多视图情境下,性能远不如frame

我的观点 :如果页面层级不复杂,性能差别也不大,我还是倾向使用AutoLayout,毕竟算frame也是比较麻烦,而且代码可读性也要比AutoLayout差很多

构建视图

这时需要解释几个很重要的方法,以及什么时候需要使用

接口的设计

接口设计尽量遵循Effective Objective-C 2.0中的建议,比如必须暴露的属性尽量为readonly,内部实现的私有方法不必暴露出去。在设计接口的时候,时刻要想着,这个方法,这个属性真的有必要让别人知道吗?这个方法真正的目的是什么?总之,尽量遵循Keep It Simple, Stupid就对了。

线程管理

所有UI的操作都应该在主线程进行,这需要我们在涉及到UI变动的方法中,确保是主线程,而不依赖使用者

一个简单的例子

TCZoomingImageView是基于UIScrollView和UIImageView做一个可缩放的View,实现非常的简单,仅作为一个简单的例子,抛砖引玉。

GitHub地址:TCZoomingImageView

参考资料

UIView Document From Apple

View Programming Guide for iOS

iOS 创建对象的姿势

Object Initialization

从 Auto Layout 的布局算法谈性能

WWDC:High Performance Auto Layout

WWDC:Mysteries of Auto Layout, Part 1

[WWDC:Mysteries of Auto Layout, Part 2

上一篇下一篇

猜你喜欢

热点阅读