前言
或许你掌握了 measure的细节 ，layout机制 ，事件传递机制 ，canvas各种API ，但是，你们想过这个问题吗？
这一篇，不仅仅是对一个面试必会题的解析，更是透过这个问题的思考，寻找 最佳实践 ，拓展思维角度 ， 少走弯路。
三思系列是我最新的学习、总结形式，着重于:问题分析、技术积累、视野拓展，关于三思系列。
关于View系列 View系列旨在通过 对现实问题 的思考，建立完善的 View体系认知，极力建议读者了解一下 我为什么撰写、分享这个系列。
先给出思考这个问题的 脑图 ，文章内容会按照思考过程展开。
思考这类问题，为什么要这样干 是最基本，作为三思系列的成员，本篇还将对以下内容点进行展开论述：
• 怎么干 -- How to do
• 是否一定要这样干 -- 适用场景
• 如果不这样干，还可以怎么干 -- Best Practice
• 各种干法的 注意事项
从View体系出现的目的说起
作为 GUI Graphical User Interface，图形用户接口 类型的程序 framework，View体系是其 必不可少 的一部分。参与了两件重要的事情：
• 描述、呈现 界面
• 参与 人机交互
笼统的讲，当 现有 的 View体系内的 控件簇 无法满足合理需求时，可以在遵从 framework 内在 的 规则 、机制 ，进行扩展，以满足需求。
从这个角度看，扩展可以有两个方面：
• 扩展 显示 功能
• 扩展 交互 功能
扩展显示功能
我们知道，这又分为3种：
-
通过一组控件，共同完成特定的功能。
-
扩展布局规则。
-
扩展内容显示。
最简单的，一组控件完成特定功能
举个例子： 输入框 右侧加一个 模态的图片，输入框有内容时显示，无内容时隐藏。图片显示一个❌，点击时清除输入框的内容。
经过简单的封装，我们可以很快的完成这样的功能。
Android的UI描述并不那么方便，为了方便，往往会定义一个ViewGroup的子类，来描述这个 控件组。但是 组合优于继承，这样的做法让人有点 膈应，不能算作是最佳实践。-- 这一点对应了脑图中的 扩展类簇1。
相比于这样干，我更建议使用 Facade模式 进行逻辑封装，采用xml方式 声明这个控件组，或者封装 命令式构建函数构建这个控件组。
继承ViewGroup，扩展布局规则
Android中ViewGroup来封装布局规则，并提供了一套Layout。
当这些布局规则 无法满足 我们的需求时，我们可以通过 自定义ViewGroup 的方式来实现 自定义布局规则。
当然，Android发展到如今，已经 很难 找到一个相对抽象的布局规则，却没有被官方支持。
若确有必要，扩展布局规则时需要处理：
- 封装规则描述，并实现 契约式编程设计。
• 定义LayoutParams，封装规则的细节点描述。
• 覆写 checkLayoutParams 以实现规则校验，契约式编程设计。
• 覆写 generateLayoutParams(AttributeSet attrs) 以实现 从xml属性生成LayoutParams。
• 覆写 generateLayoutParams(ViewGroup.LayoutParams p) 以实现 当规则不满足契约时，生成一个满足契约的LayoutParams，注意：可以从原LayoutParams中 采纳一些内容。
• 覆写 generateDefaultLayoutParams 以实现生成符合契约的 默认布局规则，如果返回null，在addView(View) 时，会引起运行时异常。
- 在 onMeasure 方法中处理测量的逻辑，以实现 确定自身大小 和 触发子View测量。
• 接受 Parent 给到自身的 尺寸测量信息，如果测量模式是 EXACTLY，即可直接确定自身对应维度的尺寸；如果是 AT_MOST 或者 UNSPECIFIED， 则需要先测量子View，再确定自身。
• 按照布局特性，自身的 尺寸测量信息，和子View的布局规则属性值，确定 子View 的 尺寸测量信息，调用 子View 的 measure 方法触发测量。
-
在 onLayout 方法中，处理布局，使用子View的 尺寸测量值 和 LayoutParams规则值，计算子View 的布局位置，并调用 子View 的 layout 方法触发子View布局。
-
如果有特定需求，可以在 onDraw 中进行绘制，例如绘制分隔线
继承View，扩展内容显示能力
一般来说，少数情况下，继承View 或者 特定的Widget 是为了扩展 布局尺寸上的特性，这基本是从 measure机制 上入手。除此之外，一些场景下， 可以通过 继承View 实现 自定义内容绘制。
例如，显示图表的View。
这种场景下，一般需要处理：
• 尺寸测量流程中，Content的尺寸测量，并在 onMeasure 中实现：测量模式为 AT_MOST 或 UNSPECIFIED 时，利用Content的大小确定显示尺寸。
• 绘制流程中，onDraw 中实现内容的绘制。
注意: 如果并不牵涉到 交互，这并不是唯一方案，自定义Drawable的方案，也是很棒的方案。
借用 PhotoView 举个例子，如果交互局限为：双指缩放，拖拽，单击，双击。
那么通过 OnTouchListener + GestureDetector + 自定义Drawable， 对于绝大多数场景，都可以胜任。
扩展交互功能
在这个方向上，主要还是和 事件处理 体系有关。在 View体系 中，存在三个方法 和这个过程直接相关：
• dispatchTouchEvent
• onInterceptTouchEvent
• onTouchEvent
对于 onInterceptTouchEvent，非ViewGroup 的 View子类 是不参与的，因为这部分View，已经是事件处理的末端。
话分两头。
对于ViewGroup
扩展的目的一般有二：
• 在恰当的场景下，拦截事件并自身处理，处理逻辑在 onTouch 中实现。
• 处理可能存在的 事件处理冲突，当然，按照Android的规则，利用 requestDisallowInterceptTouchEvent 可以要求 直系的 所有 Parent 不拦截事件。但难免有意外，可以通过 onInterceptTouchEvent 来决定是否自身拦截处理事件，或者更加复杂的场景。
对于View而言
扩展的目的在于 定义事件的含义。
举个例子，继承View实现一个字母表导航控件，点击、滑动 被定义为切换到 对应的字母 进行导航。
我们需要在 onTouchEvent 中进行处理。
在前面，我们提到了 PhotoView 的例子，如果：事件 的含义 足够抽象，例如，对View 进行了：
-
单击
-
双击
-
拖拽
-
缩放
而不是 点击了View的特定区域，滑动至View的特定位置 等。我们可以利用 Android屏幕事件处理机制 中的 OnTouchListener 来获取事件信息， 并进行处理。在这种做法中，利用 GestureDetector 可以大大降低这一过程的难度。
总结
这一篇中，我们比较 随性 的思考了 为什么要自定义View 的问题，并展开了：
• 为什么需要这么干。
• 具体做法。
• 是否有其他方案，并简单交代了 哪种方案更适合。
这篇文章比较短，但是这部分内容的背后，还是值得继续深究、挖掘的。
