一般的应用都是从服务器获取数据，然后通过极致的界面风格，将数据清晰，明朗的展现给用户。
那么就可以分为这两块：
1.界面UI 追求极致
那么就可以分为这两块：
1.界面UI 追求极致
2.功能
2.1获取数据：主要是与服务器通信，那么就要涉及到网络编程 ：
2.1.1 URlConnection
2.1.2 HttpURLConnection(post get)
2.1.3 Socket
2.1.4 HttpClient(post get)
2.1.5 WebService(自己拼装请求xml 数据，采用开源jar包 ksoap-android-)
2.2网络通信的时候，采用的异步数据获取
2.2.1 AsynTask android 封装好的异步数据获取，包括三个方法
doInBackground 执行在子线程中的异步方法
onProgressUpdate 数据获取之后 执行的方法，在主线程中可以在这里更新UI界面
onPostExecute 异步方法执行前，可以进行界面友好提示 在主线程中执行的方法
2.2.2 自己封装一个任务类（子线程）thread 采用线程池 这里需要自己维护一个任务列表，并且做到任务的优先级
2.3 android优化 最常见的就是listview 的大数据优化 图片优化 访问网络的优化
2.3.1 优化的原则： 数据延迟加载 分批加载 本地缓存
2.3.2 listview 数据优化 复用contentview
创建static class ViewHolder
分批加载 滑动监听 或者按钮 显示更多数据 往下拖动 显示
2.3.3 listview 图片优化 异步加载
本地缓存（二级缓存 内存（软引用实现），sd卡）
快速滑动时不显示图片
分为核心线程池和普通线程池，下载图片等耗时任务放置在普通线程池
2.3.4 超级大胖子Bitmap
及时的销毁(Activity的onDestroy时将bitmap回收，
在被UI组件使用后马上进行回收会抛RuntimeException:
Canvas:tryingtousearecycledbitmapandroid.graphics.Bitmap)
设置一定的采样率(有开发者提供的图片无需进行采样，
对于有用户上传或第三方的大小不可控图片，可进行采样减少图片所占的内存)，
从服务端返回图片，建议同时反馈图片的size巧妙的运用软引用drawable对应resid的资源，
bitmap对应其他资源任何类型的图片，如果获取不到（例如文件不存在，或者读取文件时跑OutOfMemory异常），
应该有对应的默认图片（默认图片放在在apk中，通过resid获取）；
2.3.5 Drawable
ui组件需要用到的图片是apk包自带的，、
那么一律用setImageResource或者setBackgroundResource，而不要根据resourceid
注意：get(getResources(),R.drawable.btn_achievement_normal)该方法通过resid转换为drawable，
需要考虑回收的问题，如果drawable是对象私有对象，在对象销毁前是肯定不会释放内存的。
2.3.6 访问网络优化
设置超时时间，采用压缩流 传送数据
2.1获取数据：主要是与服务器通信，那么就要涉及到网络编程 ：
2.1.1 URlConnection
2.1.2 HttpURLConnection(post get)
2.1.3 Socket
2.1.4 HttpClient(post get)
2.1.5 WebService(自己拼装请求xml 数据，采用开源jar包 ksoap-android-)
2.2网络通信的时候，采用的异步数据获取
2.2.1 AsynTask android 封装好的异步数据获取，包括三个方法
doInBackground 执行在子线程中的异步方法
onProgressUpdate 数据获取之后 执行的方法，在主线程中可以在这里更新UI界面
onPostExecute 异步方法执行前，可以进行界面友好提示 在主线程中执行的方法
2.2.2 自己封装一个任务类（子线程）thread 采用线程池 这里需要自己维护一个任务列表，并且做到任务的优先级
2.3 android优化 最常见的就是listview 的大数据优化 图片优化 访问网络的优化
2.3.1 优化的原则： 数据延迟加载 分批加载 本地缓存
2.3.2 listview 数据优化 复用contentview
创建static class ViewHolder
分批加载 滑动监听 或者按钮 显示更多数据 往下拖动 显示
2.3.3 listview 图片优化 异步加载
本地缓存（二级缓存 内存（软引用实现），sd卡）
快速滑动时不显示图片
分为核心线程池和普通线程池，下载图片等耗时任务放置在普通线程池
2.3.4 超级大胖子Bitmap
及时的销毁(Activity的onDestroy时将bitmap回收，
在被UI组件使用后马上进行回收会抛RuntimeException:
Canvas:tryingtousearecycledbitmapandroid.graphics.Bitmap)
设置一定的采样率(有开发者提供的图片无需进行采样，
对于有用户上传或第三方的大小不可控图片，可进行采样减少图片所占的内存)，
从服务端返回图片，建议同时反馈图片的size巧妙的运用软引用drawable对应resid的资源，
bitmap对应其他资源任何类型的图片，如果获取不到（例如文件不存在，或者读取文件时跑OutOfMemory异常），
应该有对应的默认图片（默认图片放在在apk中，通过resid获取）；
2.3.5 Drawable
ui组件需要用到的图片是apk包自带的，、
那么一律用setImageResource或者setBackgroundResource，而不要根据resourceid
注意：get(getResources(),R.drawable.btn_achievement_normal)该方法通过resid转换为drawable，
需要考虑回收的问题，如果drawable是对象私有对象，在对象销毁前是肯定不会释放内存的。
2.3.6 访问网络优化
设置超时时间，采用压缩流 传送数据
2.3.7 内存优化，static是Java中的一个关键字，当用它来修饰成员变量时，那么该变量就属于该类，而不是该类的实例。所以用static修饰的变量，它的生命周期是很长的。
优化方法：在一个工程中集中管理这些静态常量
尽量避免static成员变量的使用，
使用SoftReference或者WeakReference代替强引用
尽量避免在一个activity里面写线程内部类：
线程是Activity的内部类，所以Thread中保存了Activity的一个引用，当run函数没有结束时，Thread是不会被销毁的，
因此它所引用的老的Activity也不会被销毁，当这些activity加载了很多资源，没有释放也就很容易出现了内存泄露
的问题。
Android提供的AsyncTask，但事实上AsyncTask的问题更加严重，Thread只有在run函数不结束时才出现这种内存泄露问题，然而AsyncTask内部的实现机制是运用了
ThreadPoolExcutor,该类产生的Thread对象的生命周期是不确定的，是应用程序无法控制的，
因此如果AsyncTask作为Activity的内部类，就更容易出现内存泄露的问题。
那么就自己写一个线程类，管理这些任务。
优化方法：在一个工程中集中管理这些静态常量
尽量避免static成员变量的使用，
使用SoftReference或者WeakReference代替强引用
尽量避免在一个activity里面写线程内部类：
线程是Activity的内部类，所以Thread中保存了Activity的一个引用，当run函数没有结束时，Thread是不会被销毁的，
因此它所引用的老的Activity也不会被销毁，当这些activity加载了很多资源，没有释放也就很容易出现了内存泄露
的问题。
Android提供的AsyncTask，但事实上AsyncTask的问题更加严重，Thread只有在run函数不结束时才出现这种内存泄露问题，然而AsyncTask内部的实现机制是运用了
ThreadPoolExcutor,该类产生的Thread对象的生命周期是不确定的，是应用程序无法控制的，
因此如果AsyncTask作为Activity的内部类，就更容易出现内存泄露的问题。
那么就自己写一个线程类，管理这些任务。
