闲聊自定义控件之单元拆分

自定义控件的单元拆分是一种在实现流程维度上的拆分，跟技术的复杂与否没有关系。这种拆分可以将实现流程复杂的控件，拆解成多个单元，分单元实现最后粘合，使流程和逻辑更加清晰。

复杂自定义控件往往拆解成几个部分，每一部分可以是View，也可以是动画或者逻辑处理过程等。

如果拆解后的部分还很复杂，可以继续拆解，拆解的粒度需要自己根据实际需要去判断。如果拆解后的单元过于复杂，那么实现起来的复杂度也会比较高，达不到拆解的效果。如果拆解后的单元大部分都比较简单，这样虽然实现起来可能思路比较清晰，但可能需要大量代码去粘合这些单元，工作强度比较大。正确的拆解方式需要结合功能单元的复杂性和相关性来判断的。

比如说我的博客中那个仿链家splash，如果大家把这个当成一个自定义控件去处理，那么将存在以下弊端：

1. 复杂度较高，实现起来困难，而且需要比较清晰的逻辑。我们需要同时在一个控件里考虑，背景的放大，房子动画，底部文字变化以及它们之间的关联过程。由于房子动画本身就比较复杂，强行的揉入其它单元就比较容易影响逻辑和代码可读性。
2. 维护性和重用性低，一旦需要部分修改，如改变背景的动画效果则可能需要重新的熟悉下整个View
   代码，而且这些代码不仅量大，而且可能牵一发而动全身，引发其它问题。另外，这种方式对View的部分功能移植造成致命性伤害，重用性较低。

如果我们把这个动画过度的分拆——把房子动画继续进行拆分，将房子的动画分为水滴落下、房子icon绘制、小圆点晃动等单元，那么也会存在以下弊端：

1. 代码冗余。每个拆分单元都要从初始化，包括画笔、画布设置等，每个单元都要获取View的宽高，设置单独的动画监听。
2. 需要大量代码去粘合。分拆后的单元需要大量的逻辑代码去粘合，例如每个单元View中相关属性大小的变化，每个单元VIew的显示隐藏情况、出现顺序、动画状态、状态回调等。另外，View间的相互引用也可能引发内存问题。

好吧，不知不觉间成为一个“码字”的码农。呵呵，为了便于大家理解，我会在后续的demo中加入单元拆分的讲解。