1.FileListItem是自定义的布局组件代表一个文件传输的ListItem项，包含了布局显示的所有组件的集合。

2.FileItem是在构造函数通过传入一个数据库的Cursor构造出文件传输需要的所有参数和数据。

3.在listCursorAdapter的bindView方法中调用FileListItem.bind(FileItem)方法将数据和组件一一对应

目前架构设计是用ContentObserver监听一个表的数据变化，一旦表的数据发生变化也就是调用了ContentProvider的update,insert,delete方法时会notifyChange到所有注册的监听器，监听器的onContentChange方法被调用，在onContentChange中再去执行一次query查询，查询完毕将Cursor传给ListCursorAdapter,执行adapter的notifyDataSetChanged,重刷页面。执行bindView将ListItem和新的new出来的item进行一次bind

那么问题是缩略图的问题，因为缩略图策略是如果查出的缩略图字段为空并且路径为空，就使用系统的application缩略图，如图片用图库的缩略图，音乐用播放器的缩略图，如果是系统未能识别的缩略图使用默认的通用缩略图，如果有查出文件的路径，则通过路径去安卓的Media数据库查缩略图。

看几种情况

1.发送方发送文件和取消文件时，因为有文件路径存在本地和数据库中（发送时将发送文件信息存入数据库，页面就会刷新），通过文件路径生成缩略图存在Item中，bind时直接取，这里可以用图片缓存并使用异步加载方式。

2.接收方刚接收时，此时文件还未下载到本地所以无法通过路径信息生成缩略图，只能用系统的application图或者默认图，注意此时不能放入图片缓存中，因为接收完成后路径就有了会有刷新动作，从缓存取旧的图片就不对了，

3.接收方拒绝和发送方取消时，此时终止了文件的传输下载，所以缩略图不刷新还是用刚接收时的缩略图，这种状态图片可以放入缓存中，下次从缓存取

4.接收成功时，启动异步加载通过路径获取缩略图，并存入缓存，下次从缓存取。

所以Item中缩略图的逻辑线判断缓存中是否存在缩略图，有直接取，没有用路径异步线程去加载得到存入缓存，若获取为空则用系统的application图（主线程），判断是发送方或接受拒绝或发送取消或接收成功则将缩略图放入缓存，其他情况不放入缓存，还没有用decodeResource取默认图（主线程），放入缓存策略同Application图。

缩略图异步加载优化