本文共 5866 字，大约阅读时间需要 19 分钟。
第一部分：
项目整体架构用到的第三方库：
一：compile files('libs/butterknife-7.0.1.jar')
1.简介：
Field and method binding for Android views。
JakeWharton开发的JakeWharton，github上1W+start。
2.与以往项目的区别以及优缺点：
注解模式：
butterknife注解模式：
3.设计思想：
IOC框架(控制反转|依赖注入)，所谓依赖注入，就是由IOC容器在运行期间，动态地将某种依赖关系注入到对象之中。
Annotation。
ButterKnife中有一个哈希表HashMap来缓存实例化过的对象。
4.相关学习资料：
Java注解处理器：
Java编译时注解(源码级)：
Android 打造编译时注解解析框架：
Annotation实战【自定义AbstractProcessor】：
二：compile 'com.android.support:recyclerview-v7:23.2.1'
1.简介：
RecyclerView 是Android L版本中新添加的一个用来取代ListView的SDK，它的灵活性与可替代性比listview更好。
源码结构：
-
Adapter： 使用RecyclerView之前，你需要一个继承自RecyclerView.Adapter的适配器，作用是将数据与每一个item的界面进行绑定。
-
LayoutManager：
用来确定每一个item如何进行排列摆放，何时展示和隐藏。回收或重用一个View的时候，LayoutManager会向适配器请求新的数据来替换旧的数据，这种机制避免了创建过多的View和频繁的调用findViewById方法（与ListView原理类似）。
LinearLayoutManager ，可以支持水平和竖直方向上滚动的列表。
StaggeredGridLayoutManager ，可以支持交叉网格风格的列表，类似于瀑布流或者Pinterest。
GridLayoutManager ，支持网格展示，可以水平或者竖直滚动，如展示图片的画廊。
2.用法示例：
初始化：
mRecyclerView = (RecyclerView)findViewById(R.id.my_recycler_view);
//创建默认的线性LayoutManager
mLayoutManager = new LinearLayoutManager(this);
mRecyclerView.setLayoutManager(mLayoutManager);
//如果可以确定每个item的高度是固定的，设置这个选项可以提高性能
mRecyclerView.setHasFixedSize(true);
//创建并设置Adapter
mAdapter = newMyAdapter(getDummyDatas());
mRecyclerView.setAdapter(mAdapter);
adapter创建：
public class MyAdapter extends RecyclerView.Adapter<MyAdapter.ViewHolder> {
public String[] datas = null;
public MyAdapter(String[] datas) {
this.datas = datas;
}
//创建新View，被LayoutManager所调用
@Override
public ViewHolder onCreateViewHolder(ViewGroup viewGroup, int viewType) {
View view = LayoutInflater.from(viewGroup.getContext()).inflate(R.layout.item,viewGroup,false);
ViewHolder vh = new ViewHolder(view);
return vh;
}
//将数据与界面进行绑定的操作
@Override
public void onBindViewHolder(ViewHolder viewHolder, int position) {
viewHolder.mTextView.setText(datas[position]);
}
//获取数据的数量
@Override
public int getItemCount() {
return datas.length;
}
//自定义的ViewHolder，持有每个Item的的所有界面元素
public static class ViewHolder extends RecyclerView.ViewHolder {
public TextView mTextView;
public ViewHolder(View view){
super(view);
mTextView = (TextView) view.findViewById(R.id.text);
}
}
}
3.为什么选择RecycleView而不是ListView：
(1).低耦合。
Rv:onCreateViewHolder,onBindViewHolder.
Lv:
(2).拓展性更强。(布局-LayoutManager，动画-ItemAnimator)
(3).就本项目中主页分析：
不同组件item混搭，使用ListView实现比Rv要多太多代码。
三：compile 'com.github.bumptech.glide:glide:3.7.0'
1.简介：
An image loading and caching library for Android focused on smooth scrolling。
2.选择Glide的原因：
视频包&爱圈项目使用的Android-Universal-Image-Loader()
低配版，采用了基本的三级缓存，线程池缓存。
为什么说是简化版呢？
1. 不支持默认实现多种内存缓存算法。
2. 不支持本地缓存文件名规则定义。
3….
优点在于：对apk大小有着极致の追求。
与主流加载框架的劣势在于：
1.无生命周期内存判断(Glide.with(...))。
2.占位符（加载、错误等）。
3.标准的淡入淡出显示动画。
4.严格的内存管理机制，自动裁切并适配imageview的图片大小进行缓存。
5.自由选择是否跳过内存or磁盘缓存。
6.支持度高，适配度高。(各种数据源，各种非imageview展现方式)
7.内存友好度：
缓存更小的图片：Glide：Glide 以 url、view_width、view_height、屏幕的分辨率等做为联合 key，将处理后的图片缓存在内存缓存中，而不是原始图片以节省大小。
8. 线程池：
Glide中：
sourceExecutor用于缓存未命中Glide的加载、解码和转换任务
diskCacheExecutor用于缓存命中时的加载、解码和转换任务
主流加载框架：
Picasso ：之所以说和Square的网络库一起能发挥最大作用，是因为Picasso可以选择将网络请求的缓存部分交给了 okhttp 去实现 。
Glide：模仿了Picasso的API，而且在他的基础上加了很多的扩展(比如gif等支持)。
FB的图片加载框架Fresco：最大的优势在于5.0以下(最低2.3)的bitmap加载。在5.0以下系统，Fresco将图片放到一个特别的内存区域 (Ashmem区)。当然，在图片不显示的时候，占用的内存会自动被释放。这会使得APP更加流畅，减少因图片内存占用而引发的OOM。为什么说是5.0以下，因为在5.0以后系统默认就是存储在Ashmem区了。但是太大所以放弃。
4.本地大图加载需要注意的问题：
不要直接设置setImageResource.这个方法是在UI线程中对图片读取和解析的,所以有可能对一个Activity的启动造成延迟。所以如果顾虑到这个官方建议用setImageDrawable和setImageBitmap来代替。
/**
* 加载大图缩略图 * mImageView.setImageBitmap( decodeSampledBitmapFromResource(getResources(), R.id.myimage, 100, 100)); * @param res * @param resId * @param reqWidth * @param reqHeight * @return */public static Bitmap decodeSampledBitmapFromResource(Resources res, int resId, int reqWidth, int reqHeight) { // 第一次解析将inJustDecodeBounds设置为true，来获取图片大小 final BitmapFactory.Options options = new BitmapFactory.Options(); options.inJustDecodeBounds = true; BitmapFactory.decodeResource(res, resId, options); // 调用上面定义的方法计算inSampleSize值 options.inSampleSize = calculateInSampleSize(options, reqWidth, reqHeight); // 使用获取到的inSampleSize值再次解析图片 options.inJustDecodeBounds = false; return BitmapFactory.decodeResource(res, resId, options); }
四：compile 'com.android.support:design:23.0.0'
1.质感设计，是Android 5.0发布以后由Google推出了全新的设计语言，这种设计语言旨在为手机、平板电脑、台式机和“其他平台”提供更一致、更广泛的“外观和感觉”。
Github收集的材质库：
2.项目中的使用：
五：compile 'com.squareup.okhttp3:okhttp:3.4.1'
1.框架介绍：
Square 公司开源的 OkHttp 是一个专注于连接效率的 HTTP 客户端。OkHttp 提供了对 HTTP/2 和 SPDY 的支持，并提供了连接池，GZIP 压缩和 HTTP 响应缓存功能。
2.与 android-async-http AsyncHttpClient：
AsyncHttpClient：
弃用的原因：
(1).6.0以上不支持httpclient。
(2).不支持SNI。(当用HTTP同拥有一个以上主机名的服务器共享时，web服务器可以从 HTTP/1.1请求分别出客户端需要的目标主机名。不行的是，使用HTTPS会使情况变得复杂，因为服务器必须知道在发现HTTP请求前返回哪一个证书。为了解决这个问题，新版本的SSL，特别是TLSV.1.0和之后的版本，支持服务器名指示(SNI),允许SSL客户端为服务端指定目标主机名，从而返回正确的证书。幸运的是，从安卓2.3开始，HttpsURLConnection支持SNI。不幸的是，Apache HTTP客户端不这样，这也是我们不鼓励用它的原因之一。如果你需要支持安卓2.2或者更老的版本或者Apache HTTP客户端的一个解决方法是，建立一个可选的虚拟化服务并且使用特别的端口，这样服务端就能够清楚该返回哪一个证书)
源码设计模式：第六部分会讲到。
okhttp的优点：
使用httpurlconnection，长期维护中。
2.与volley：
不同：
okhttp属于传输层，处理底层http请求。
volley属于应用层网络框架，扩展性强，Volley 中大多是基于接口的设计，可配置性强。可轻松设置okhttp作为其网络框架。
okhttpの优点：
volley的优势在于封装得更好，okhttp需要进行再次封装，OkHttp 的优势在于性能更高，因为 OkHttp 基于 NIO 和 Okio ，所以性能上要比 Volley更快。
补充：IO 和 NIO 的概念，这里姑且简单提下，这两个都是 Java 中的概念，如果我从硬盘读取数据，第一种方式就是程序一直等，数据读完后才能继续操作，这种是最简单的也叫阻塞式 IO，还有一种就是你读你的，我程序接着往下执行，等数据处理完你再来通知我，然后再处理回调。而第二种就是 NIO 的方式，非阻塞式。
3.更高层：
使用Retrofit。
简单介绍：
Retrofit 是 Square 公司出品的默认基于 OkHttp 封装的一套 RESTful 网络请求框架，不了解 RESTful 概念的不妨去搜索学习下，RESTful 可以说是目前流行的一套 api 设计的风格，并不是标准。Retrofit 的封装可以说是很强大，里面涉及到一堆的设计模式，你可以通过注解直接配置请求，你可以使用不同的 http 客户端，虽然默认是用 http ，可以使用不同 Json Converter 来序列化数据，同时提供对 RxJava 的支持，使用 Retrofit + OkHttp + RxJava + Dagger2 可以说是目前比较潮的一套框架，但是需要有比较高的门槛。
六：网络请求整体框架
2.目前基于okhttp的二次封装：
结合代码简单的讲一下封装流程：
3.未来打算使用Retrofit。
第二部分：
关于模块化开发：
一、将项目通用组件整合在依赖工程中，实现项目快速搭建。
二、对团队化开发の理解。
使用 MVP+Retrofit2.0+RxJava 的开发模式。
分层开发。
分任务开发。
把设计和实现分开。
我的demo：