1.ListView，列表视图控件
先了解一下适配器。
需要了解： 1.它位于android.widget包下，这个包同时包含了六大布局文件
2.这个Adapter只是一个文件名，除了见名之意的设计上的需求外，没有任何特殊性，就是个普通的接口。
它的核心方法。 从他的形参看出来，操作View（视图）,以及 ViewGroup(视图集或者布局),同时返回一个视图。。
它有一个直接子抽象类BaseAdapter.
这里只是查看了一下，ListAdapter除了名字有个List,接口是没有依赖List的。
spinner也是一样。
自定义适配器的时候，在设计上就需要自己依赖List了。
listView的使用： 就一句话： listView.setAdpater();
接着查看一下它内部的实现逻辑：
结果很失望的发现，它并没有具体的实现逻辑，应该是通过jni实现的。 既然没法看实现逻辑，那就去看看它的架构吧。
listView的祖先类为 AdapterView,它继承自ViewGroup。 从层次上来看，AdapterView 跟 布局是等同的，都是视图集。
可以看出，从设计层面，AdapterView 与Adapter 是相伴而生的，互相兼容的。 那么就猜测一下它的运行过程：
getView可以获得一个视图，他需要依赖的属性有: 位置，视图，视图容器
getCount可以获取数量。
getItemId可以获取位置。
这几个方法配合一下，然后通过系统渲染，应该就是这么个过程吧。 哎，非c语言真不得劲。
常用方法： addHeaderView(View v);addFooterView(v);addHeaderView(headView,null,false); addFooterView(View,View,false); 设置表头或者表尾。
通过查看菜鸟后面的解析，验证了上午的猜测。 嗯嗯 ，可以小小的表扬一下自己。
ListView的优化: ViewHolder 视图持有者
刚刚去查了查，它并不是官方提供的接口。所以说是用户自定义的，按照见名知意的原则来分析分析：
先看一看它的构成：
可见它是由一些UI控件所构成的实体，如果说它与纯UI的区别，应该就是没有负责渲染的线程吧？
同时，有必要了解一下View的 setTag方法：
由于并没有注释，所以功能不是很清楚。 不过貌似是将一个对象存储到View中。
整个逻辑是这样的：
每次渲染，getView方法都会被执行getCount()次，由于getView方法相当于取得资源文件的模型，这个过程是需要从xml进行inflate(有道释义：充气，膨胀. )的和查找资源id，所以要消耗资源，并且这个xml文件是一个 ViewGroup。 而这个方法的目的就是要获取这个视图，同时根据Model进行实例化。 但是我们需要的只是实例化后的那个View,又因为每次布局都一样。 原本只需要开销一次就能达到我们的目的，没有优化就会需要开销getCount()次。
ViewHolder提前将这个ViewGroup布局进行初始化，那么在getView的过程中，只需要设置它相应的属性就行了，就减少了很多的开销。
demo参考菜鸟： 地址
ListView的动态数据更新： 关键在于一个方法： notifyDataSetChanged();
