Builder模式是一步步创建一个复杂对象的模式，让用户在不知道内部结构细节的情况下，可以更精细的控制对象的构造流程。
比如汽车由很多部件构成，轮子、方向盘、刹车等等。组装起来很复杂，用户不需要知道组件和装配的细节，Builder模式将部件的定制和组装过程分离开来，使得两者间可以自由扩展，两者间的耦合也降到最低。
使用场景：
1.方法一样，调用的顺序不同，而产生的结果也不同时。
2.多个部件或者零件，装配到一个对象中，但是产生的运行结果又不同时。
3.产品类非常复杂，或者产品类中调用顺序不同而会产生不同的结果。
4.当初始化一个对象特别复杂，参数很多，而且很多参数都有默认值的时候。
解释：
Product产品类。
Builder：抽象类，用来规范产品的组件过程。
ConcreteBuilder：具体Builder类
Director：同一组装过程
简单实现分析：
首先Product类是我们需要组装设置生成的产品类，里面有很多setXXX(xxx)的方法，来设置属性。
Builder实现类中创建了Product类的对象，并且拥有buildXXX(xxx)的方法来调用product.setXXX(xxx)，还有一个create方法来返回创建的Product对象。
Director类中持有Builder类的对象引用，且有一个方法construct，方法里通过调用builder.builXXX(xxx)来对product对象进行设置。
在实际开发中我们通常会省略Director类，并且在Builder类的setXXX方法中return this，来达到链式调用的目的。
new MyBuilder().setA("A").setB("B").create();
Android源码中的Builder模式使用
最常见的就是AlertDialog.Builder
我们通常会这样用：
new AlertDialog.Builder(context).setIcon(R.drawable.icon).setTitle("title").....create().show();
Builder内部类中有一个AlertController.AlertParams的变量p，当我们调用build.setXXX方法时候，就把参数设置到P变量中，在调用builder.create方法后生成一个AlertDialog对象然后把P中的参数设置到AlertDialog中的AlertController类型变量mAlert中。
也就是这时候一系列参数已经在AlertDialog对象里AlertController类型的变量mAlert中了。
然后我们调用alertDialog.show()函数的时候首先调用了自己的onStart()方法，然后调用了onCreate方法，而onCreate方法中其实是调用了mAlert的installContent方法。
AlertController类中的installContent方法中做了两件事：
1.mWindow.setContentView(mAlertDialogLayout)
跟Activity中一模一样用来设置布局
2.调用setupVIew方法
方法里通过之前传进来的参数来定制改变样式，比如title、content、button或者用户自定义的内容区域view等。
实战：
例如：未使用builder模式的时候，我们自定义了一个ImageLoader类，当我们要设置类加载时候的图片、加载失败时的图片、线程池的数量等时，我们常常使用set方法来设置进去，这样会有很多问题：公共方法太多，用户不知道或者忘记调用set方法，当我们设置了线程池数量，然后在使用中又重新设置了线程池数量，那要怎么处理呢？
所以这时要使用builder模式了。
实现如下：
创建一个ImageLoaderConfig类，里面有一个Builder内部类。
Builder类中有setXXX的各种方法、把各种参数设置到ImageLoaderConfig类中的一个config变量中保存起来，并且return this以便能够链式调用。
最后调用Builder类中的onCreate方法返回这个config变量。
图片加载的类ImageLoader中我们.getInstance().init(config)；注入这个包含各种参数的config变量，在loader图片的时候通过各种参数来完成不同的逻辑。
优点：
良好的封装性，使用建造者(Builder)模式可以是客户端不必知道产品内部组件细节。
建造者独立，容易扩展。
缺点：
会产生多余的Builder对象以及Director对象。
