避免使用第三方UI库
最近 iOS 社区一些人在讨论关于应该 赞成还是反对使用第三方依赖库 (当然, 大部分人持反对意见). 我看到的许多争论的观点都有失偏颇 -它们把所有的第三方库都归于一类混为一谈. 就像大多数事情一样,整体考虑不是那么简单的的事,所以现在让我们将目光放在一个小的观点上: 我们应该避免使用 第三方UI依赖库吗?
考虑使用第三方库的缘由
开发者们考虑使用一个第三方库通常有两个主要原因:
- 缺乏技能或者知识。 比方说,你正在做一款照片分享功能的 app. 你没有从 推出自己的密码 开始。
- 缺乏从事某件事的时间或者兴趣。 除非你又无限的时间不需要去分清主次。
大部分的 UI 库(不是所有的!)都趋向于第二个原因.这个事儿不是高深的事,但是把它做好却需要花费时间.
什么应该”外包”
那么,我们通常应该怎么决定什么代码应该我们自己写,什么应该交给第三方组件呢? 著名的乔尔建议提供了非常好的依据:
如果是核心商业功能的话 就自己做 不管它是什么。
一个事实(并且比较残酷的)是几乎所有的 iOS app 正在向前端而不是后端发展。,因此我们应该考虑在内部尽可能多地进行 UI 开发 看起来就尤为重要。 有人可能会说这只是个人观点,所以让我们重新思考你是对第三方 UI 库使用的更详细原因。
UI库自身的问题
通用 vs 特定
有两种类型的控件/视图:
- 通用 允许你在很多场景 甚至是我们想不到的场景下使用 比如 UIKit 中的
UICollectionView. - 特定 专门为一些特定的场景设计 比如
UIPickerView
大部分第三方库倾向于第二个分类.而且它们通常是在一个已存在并且在不断优化的代码库中取出.
比如,还记得上个月看到的那个看起来非常酷的下拉刷新库吗?如果不修改控制器交互或下拉偏移量的话,它可能不太适合你 app 的设计或使用场景.
使用继承进行个性化
就面向对象而言,由子类化转向组件化是行业趋势.当你选择第三方库的时候请确保没有违背这个趋势.在大多数情况下 你可以选择其他人做的一个组件,你只需要继承或者直接修改代码就好了.
(代理模式也是接近组件化的方法之一.)
看起来过于定制化
一个第三方库内可见的 UI 元素越少越好,这听起来可能觉得有悖常理.高度定制化的控件或界面带来的问题就是它不可能满足所有的的需求来迎合所有的使用情景.
如果有大量的自定义 UI ,你可能无法回馈上游,因为你对于外观或感觉的想法可能和库的维护者不一样.这个时候你会自己维护一个库的fork代码.或者在 app 内添加一个丑陋的遮盖 仅仅是为了移除一条阴影.
而在另一方面,一些库在UI层进行操作 但是没有或者几乎没有提供任何样式.想一想 SDWebImage 或者我的 SloppySwiper . 它们都可以不需要任何修改直接放进你的工程内.
未知的早期预设
很多团队都会对内部代码进行代码审查, 但可能将第三方源代码的质量视为理所当然。花费点时间去浏览第三方库的源代码是值得的.你可能会看到一堆警告 比如在不需要的地方使用方法实现交换.
尝试着去了解下库的结构,你能否根据未来的需求尝试着去调整库,或者当 MVP 的时候后重写库吗?
你也应该考虑下库的维护情况,最近有多少次提交,多少个问题 是否做过任何的单元测试或者 UI测试? 忽略 GitHub 的星数,尽管它有时是很有意义的.
想法 > 代码 ?
我喜欢开源因为开源允许我去了解别人是怎么思考的,是怎么设计他们的方案的. 通常学习这个想法比获得这个代码本身更有意义. 如果一个库接触到了 UI 并且很小,通常从代码中获取灵感并且开发一个组件来完美适应你的工程是更明智的做法.
不能忽略它
由于 UIKit 的设计方式,你可能几乎不能够忽略掉第三方 UI 库,比如 在一个适配器后面,一个库将会和你的 UI 代码交叉在一起,事实上已经变成了你工程里一等公民.
未来时间花费
UIKit 会随着每个 iOS 版本进行变化,这时候就糟了,你的第三方依赖并不会像你想象的那样免于维护.
##结论
在编程中经常会出现这种情况,很难提供一般规则,我们必须在代码库添加每一行代码的时候都要考虑一条又一条的规则.根据我的个人经验,使用大多数第三方UI库都是通过牺牲灵活性来节省一些时间.
我们利用现成的代码来更快地实现需求,但是迟早,我们将会被第三方库所限制 并作出艰难的决定:考虑接下来怎么办?
原文地址: http://holko.pl/2017/05/31/avoiding-ui-libraries/
翻译: Swants