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