1）app代码框架设定；
MVC；
1-BaseActivity和MyActivityManager配合android自带的activity启动模式，做到对Activity的完全控制；
2-封装网络请求层
3-用MVC架构，分离代码。
对MVC架构的理解如下（假设是数据持久化要通过网络请求直达server）：
M 层，设定数据模型为XXX.java类，并且 封装XXXModel.java 数据的获取以及上传。
C 层， XXController.java ,调用M层封装好的数据获取或上传的接口，并且设定回调函数，来告诉V层 更新UI。
V 层， XXXActivity.java 负责界面的显示，以及调用C层的业务逻辑接口，还有 编写C层的回调函数。
所以，调用的方式就是，V层调用C层的业务逻辑方法，并且编写回调函数，回调函数是为了在业务逻辑完成之后更新UI；然后C层调用M层 执行真正的业务逻辑代码。
如果要扩展的话，比如说，增加一个Photo业务，要对照片进行处理，那么我只需要增加照片的PhotoModel，以及PhotoController。 至于Activity，其实和C层没有什么粘性。
随时可以更换Controller。
那么为什么这种MVC框架在逐渐被淘汰呢？
因为，业务复杂以后Activity代码会越来越多，Activity会越来越臃肿，Activity本身要进行界面的显示和变更，同时还要进行业务逻辑的调用。
应该没有人想要面对一个3000行，并且业务逻辑错综复杂的Activity。所以，Activity直接调用C层的方式要加以改变。
现在，C层被瓜分了。原本C层是要负责调用M层的业务逻辑，还要调用Activity的监听事件。
MVC，在Activity中，不只要调用业务逻辑代码，而且还要写业务完成之后的视图更新操作。
MVP: Activity不再直接调用业务逻辑代码，而是由P层封装业务逻辑，以及业务完成之后的视图更新操作（回调）。
P层，对某一块业务的视图更新和数据交互进行了统筹。 也就是说，P层，封装了当前业务的数据交互接口，以及界面更新的操作。让Activity代码更加井然有序。
2）listView优化；
外观优化（分隔线，滚动条），
效率优化（滚动监听onScroll(),onScrollStateChange()，触摸监听onTouchEvent(),以及ViewHolder模式代码优化，adapter在应对大量数据时的优化）
3）自定义控件
其分类，以及每个类别的使用方法；
4）app性能优化
1）布局优化
1-基于一个原理，android绘制界面是通过View树来进行遍历绘制，如果这个View的高度过高（也就是层级过多），就会影响绘制的速度，所以，要让树结构尽量扁平，层级不要太多，具体做法，可以用相对布局作为根布局，来让布局扁平化。
2-避免无用布局，明显一个布局里面只有一个子，那这个布局就可能没什么用。删了吧。
3-使用include标签实现布局重用。
4-使用ViewStub实现懒加载。（ViewStub 是一个神奇的东西，它可以展开成为一个“树枝”，但是在它展开之前，它不可见并且不占用任何空间，而且它自带一个inflate方法可以展开，展开之后才会进行绘制，所以，如果有一些隐藏的控件，不需要在界面初始化的时候就绘制，则可以用ViewStub这个东西来加快界面加载速度）.
2）内存优化
Bitmap是造成内存过高或者内存溢出的最大威胁。1-使用适当分辨率和大小的图片；2-用完bitmap之后及时recycle回收，3-使用图片缓存。
减少不必要的对象创建。
能不用反射机制就不用，因为反射会造成性能下降。
使用SurfaceView来代替View进行大量的，频繁的绘图操作。
不要频繁的调用inflate进行视图实例化。
那如果真的发生了内存泄露或者溢出，就需要使用DDMS工具，抓取hprof文件，用mat工具分析，找出泄漏的代码位置，进行修复。
5）圆形头像
RoundedBitmapDrawable类，来设定ImageView的圆角，如果图片是方形，而且圆角角度是方形边长的一半，那么就会形成一个圆形图片。
另外，可以使用第三方开源项目，CircleImageView.
前者可以灵活处理圆角，圆形图只是它功能的一部分。
后者，可以实现对圆形图的丰富的控制，针对圆形图的控制，比前者强得多，可以有边框的设定。
6）Okhttp请求https；