自定义控件的单元拆分是一种在实现流程维度上的拆分,跟技术的复杂与否没有关系。这种拆分可以将实现流程复杂的控件,拆解成多个单元,分单元实现最后粘合,使流程和逻辑更加清晰。
复杂自定义控件往往拆解成几个部分,每一部分可以是View,也可以是动画或者逻辑处理过程等。
如果拆解后的部分还很复杂,可以继续拆解,拆解的粒度需要自己根据实际需要去判断。如果拆解后的单元过于复杂,那么实现起来的复杂度也会比较高,达不到拆解的效果。如果拆解后的单元大部分都比较简单,这样虽然实现起来可能思路比较清晰,但可能需要大量代码去粘合这些单元,工作强度比较大。正确的拆解方式需要结合功能单元的复杂性和相关性来判断的。
比如说我的博客中那个仿链家splash,如果大家把这个当成一个自定义控件去处理,那么将存在以下弊端:
- 复杂度较高,实现起来困难,而且需要比较清晰的逻辑。我们需要同时在一个控件里考虑,背景的放大,房子动画,底部文字变化以及它们之间的关联过程。由于房子动画本身就比较复杂,强行的揉入其它单元就比较容易影响逻辑和代码可读性。
- 维护性和重用性低,一旦需要部分修改,如改变背景的动画效果则可能需要重新的熟悉下整个View
代码,而且这些代码不仅量大,而且可能牵一发而动全身,引发其它问题。另外,这种方式对View的部分功能移植造成致命性伤害,重用性较低。
如果我们把这个动画过度的分拆——把房子动画继续进行拆分,将房子的动画分为水滴落下、房子icon绘制、小圆点晃动等单元,那么也会存在以下弊端:
- 代码冗余。每个拆分单元都要从初始化,包括画笔、画布设置等,每个单元都要获取View的宽高,设置单独的动画监听。
- 需要大量代码去粘合。分拆后的单元需要大量的逻辑代码去粘合,例如每个单元View中相关属性大小的变化,每个单元VIew的显示隐藏情况、出现顺序、动画状态、状态回调等。另外,View间的相互引用也可能引发内存问题。
好吧,不知不觉间成为一个“码字”的码农。呵呵,为了便于大家理解,我会在后续的demo中加入单元拆分的讲解。