想对大家说的话就是好好修炼，将来你必将成为一个有用之才，之所以成为程序猿，原因有太多，只是由于你成为了一个程序猿而已，天天写着if else语句，写着业务中令人尴尬的逻辑代码，抬起头喝点水，又要埋头苦干，bug来了，需求来了，又要换工作了，人生有太多选择，谁又能够从容，不如静下心来和我一起为了最初的热情happy一下，建议：最好你能来一杯咖啡，我们毕竟不是代码的创造者，我们只是代码的搬运工，或许我们也想成为一个创造者，找到一个工程师真正的成就感，所以不要喝凉白开了，来点思维上的风暴，来点行动上的执行力，将Android进行到底。
瞅你咋地
自定义控件
当然就是不采用系统给我们定制好的控件，当然还有自定义样式，自定义属性，自定义布局，自定义drawable，通常我们所使用的自定义控件主要分为：
组合控件：顾名思义，就是将不同的控件组合起来使用构成一个组合性的控件
继承控件：继承系统已经提供给我们的控件，将其修改为新的控件
布局控件：继承ViewGroup的控件
View控件：继承View控件，绝大数情况下我们会使用使用这个控件
注意：针对不同的Situation，我们会选择不同的自定义控件，关键还是就你自身对需求的理解而定，前提是要能够完成需求，之后可以考量采用何种方案是最佳的。
自定义控件分类
组合控件
我想大家最为关注的是在何种情况下要使用我们的组合控件，以及如何使用我们的组合控件，按照面向对象的思想，我们说一切事物全部是一个结构化的整体，也就是说这个整体一定是由其它对象所构成的，对待一个整体性的事物或者范畴，我们必须要能够将这个整体解构为了不同的对象，所谓解构就是我们先将一切对象之间的结构性范畴忽略掉，简单地来讲就是我们先不用考虑对象之间如何被组合在一起，而只是考虑这个整体性的范畴可以由何种对象构成，我们的代码就是为了描述这种结构性的特征，也就是说我们对于产品或者美工给我们的控件，我们先要直观地分析一下能不能从中抽取出来系统已经提供给我们的控件，假设能够抽取出来，我们就要考虑如何将这部分的控件组合在一起，这种组合必须考虑控件之间的结构性，这种结构性首先体现在了控件之间能不能实现初始化状态下的静态界面效果，也就是说我们需要着手去写xml文件，当然我们不要着急去写，作为一个老程序员，我们当然需要考虑一下组合控件在进行界面上的组合时是否会存在制约关系，这会导致控件本身的属性被强制性的更改，所以在静态界面的构建过程我们需要考虑两个原则：
尽量不要制约其它控件的属性
交互属性不能被制约或者更改
之后更深层次的当然是构建控件之间动态的交互结构，这种动态是指多个控件之间的联动性，主要还是指属性上的联动性（也包含动画属性上的联动性），其实我在文字性的论述中你可能会觉着根本听不懂，我会给大家例子，其实我们最为矛盾的地方在于在设计这种联动时发现API提供不了，或者是两者之间的交互存在互斥现象，我们可能需要静下心去理解一下API的含义，我们也需要另找途径去解决这种冲突或者互斥问题，这是不同控件在组合中表现出来的特性，不是我在此处就可以马上告诉你的，你需要经历项目，你需要去阅读Android的官方文档，也可以去围观网络上的解决方案，另外就是对于明显存在结构性冲突的组合控件我们不要强行进行组合，总而言之，组合性控件也是一个深坑，我们必须对被组合的控件有一定的了解才能去使用。
组合控件
组合控件-案例
我们需要一个例子去深化一下我们对于组合控件的理解
优酷菜单
直观解构
上图直观地来讲马上可以将其拆分为三个视图控件，由内到外，可以分为MenuA，MenuB以及MenuC，可是我们说Android中所有控件全部为矩形模块，这种形状可能是不存在的，可是我们可以将其当然是背景图来处理，之后将不同的按钮摆放上去就可以了，实现不同按钮的点击事件就大功告成，这样的组合控件对于我们来讲好像毫无难度，当然有的同学可能想着用自定义View将其画出来，我建议还是不要这么去做，这就等于把美工的活给抢了，开玩笑的，我们的美工还让我们使用pxcook拿着psd图自行标注，现在的美工真的是欺负我们客户端的开发人员。
静态结构
MenuC在最外层的结构，之后依次为MenuB和MenuA，这样Touch事件能够正确地传递过来，我们说过尽量不要改变每一个控件原本具有的属性，而且最为重要的是Touch属性是交互属性，如果这种属性被更改我们的交互还如何去实现，在此我不会贴上任何的代码，之后我会给大家分享自定义控件的代码。
动态结构
此处关键还是实现一个点击之后的旋转动画，当然不要使用补间动画，使用属性动画就可以了，补间动画这种结构会破坏交互性，可以说不存在任何的难度。
解决冲突
此处主要还是利用属性动画解决补间动画发生的结构性冲突。
源码地址
下载地址：优酷菜单
注意：是Eclipse的项目，用AS导入我相信难不倒大家
继承控件
这种自定义控件，不用进行直观解构，而是这个控件从本质来讲就是某一个控件，只是这个控件是某一个控件的加强版或者是精简版，当然这样说可能不太准确，更加准确地来讲是某一个控件的修改版，同样地我们要对这个控件本身的结构进行分析，对其自身的结构下手，这种控件的难度在于我们必须继承控件的结构有了解，否则我们可能无法实现特定的功能，而且还会破坏原控件本身所具有的特性。
继承控件
继承控件-案例
简单说明一下
继承控件案例
结构分析
我们的需求是解除原有的滑动事件和将事件传递给我们的子View处理
结构修改
上述我们所需要的就是将touch事件不交给我们的ViewPager处理，首先我们去除了Viewpager的滑动处理方式，直接返回了true，之后我们不拦截touch事件，将其交给我们的子View进行处理。
结构解耦
此处的修改并未对控件的其它功能造成耦合性的影响，所以此处不需要解耦性操作。
作者写不动了......
在Android的适配之中我们现在使用的最低版本起码是API17(4.2)的版本，所以我们通常不会使用不兼容到当前版本的API，第二版的第一行代码已经出版，相比以前的第一版的确好多了，当然我曾经吐槽过这本书，还有一本书需要吐槽：Android高级进阶，这个作者的总结经常出现错误不说，排版真的比blog还差劲，到底是否认真去对待这本书了，我十分怀疑这个人的写作态度，相比较而言Android开发艺术探索比这本书要好多了，个人推荐一个人的Blog，假设大家想要进阶到高级Android工程师的行列，现在有太多人已经觉着Android开发毫无价值了，我本人还是认为假设你已经入了这个坑，就把这个坑挖到底，总还有高级人才的生存市场。
给大家推荐两个网站，假设大家想要系统的学习一下，就自己去练习一下：
网友评论