优化和抽取框架重复代码

优化文档及新增常见疑问解答
新增支持 CheckBox 按钮状态选择器
新增支持 RadioButton 按钮状态选择器

HelpDoc.md

@@ -0,0 +1,15 @@
+#### 
+
+* 框架上线有很多人说框架的侵入性很强？这点我必须承认，我也有看到网上也有用 `LayoutInflater.Factory` 来实现，这样入侵性很低，但是有一个致命的缺点，无法在布局中预览，这样你是不是突然就感觉不香了？入侵强当然有缺点也有优点，我不能光看它坏的一面，那样看待问题就太片面了，不过它的缺点并不是致命的，就好比你使用了一个自定义 View 叫 `XxxTextView`，这种情况下你肯定就没办法再使用 **ShapeTextView** 了，那么这种情况我们该这么办？解决方式大致分为两种：
+
+    * 第一种可以用原生的 Shape 来实现，可以选择在 xml 定义或者代码动态设置的方式，这种方式大家应该都懂，这里不再多说，不过有一个问题，就是原生的 Shape 是不支持设置阴影的，如果你想要用阴影的话，就得用第二种方式。
+
+    * 第二种就是用框架提供的 **ShapeDrawable** 类了，在 Java 代码中进行动态设置，这个类的用法其实很简单，在布局用哪个属性，在代码中就用哪个方法。
+
+    * 另外有一个需要注意的点，如果你自己单独使用 **GradientDrawable** 还是 **ShapeDrawable** 在 Java 代码动态设置的话，如果涉及到虚线或者阴影的话，经过验证在有些手机上面是无法生效的，必须要先关闭硬件加速才能生效，当然 **ShapeDrawable** 有对外开放 **intoBackground** 方法，这个方法会帮你判断是否需要关闭硬件加速。
+
+* 另外还有人要框架做裁剪子 View 的功能？在此我表示拒绝，因为我对框架定位很明确，只是为了帮助大家少写 xml，你现在让我加一个裁剪的功能进去，这样合适吗？不，这样不合适，我个人建议裁剪子 View 可以考虑使用  Google 支持库提供的 **CardView** 来实现，有必要时可以搭配 **ShapeDrawable** 来食用。
+
+* 最后我来跟大家分享一下我的观点，我认为做好一个框架并不意味着什么功能都要做，并不是我实现不了，而是有没有必要那么做，如果那样做到最后框架很可能会变成一个杂货铺，连作者都会分不清楚这个框架到底是干嘛的，比如我做[标题栏框架](https://github.com/getActivity/TitleBar)的时候，有很多人让我做沉浸式状态栏的功能，我全部给拒绝了，并建议他们单独集成沉浸式框架来实现，首先我要声明一点，我做的是标题栏框架，沉浸式状态栏是沉浸式框架应该有的功能，我要是破格做了沉浸式状态栏的功能，后面就会有人找我做沉浸式底部导航栏的功能，再后面就会有让我做一个状态栏字体变色的功能..............，如果这些我都做到了，那么请问你是否还会使用这样的框架，将标题栏和沉浸式相互捆绑的框架？到底应该叫标题栏框架还是沉浸式框架？后面如果有人说我只想用标题栏的功能不想用沉浸式的功能该怎么办？
+
+* 听到这里，我相信你大概能理解我的想法了，我在做框架时注入了很多思考，改代码的时间远远超过写代码的时间，思考问题的时间远远超过改代码的时间。做好一个框架不仅仅只是写代码那么简单，更多的是我知道大家的想法是什么，也明白大家想要什么效果，同时我会虚心接受各种建议，但是同样的，我也会拒绝一切不合理的需求。