【状态模式】
No1:
Wifi设置界面是一个叫做WifiSetting的Fragment实现的
No2：
在不同的状态下对于扫描Wifi这个请求的处理是完全不一样的。在初始状态下扫描请求被直接忽略，在驱动加载中状态下Wifi扫描请求被添加到延迟处理的消息列表，在驱动加载完成状态下扫描Wifi的请求直接被处理。
它的实现原理就是将请求的处理封装到状态类中，在不同的状态类中对同一个请求进行不同的处理
【责任链模式】
No3：
最大缺点：对链中请求处理者的遍历，如果处理者太多，那么遍历必定会影响性能，特别是在一些递归调用中，要慎重
【解释器模式】
No4：
ServiceManager是Binder进程间通信机制的守护进程，其目的很简单，就是管理Android系统里的Binder对象。
No5：
优点：灵活的扩展性，当我们想对文法规则进行扩展延伸时，只需要增加相应的非终结符解释器，并在构建抽象语法树时，使用到新增的解释器对象进行具体的解释即可，非常方便。
缺点：因为对于每一条文法都可以对应至少一个解释器，其会生成大量的类，导致后期维护困难，所以对于复杂的文法并不推荐使用解释器模式。
【命令模式】
No6：
命令模式包括：命令抽象接口、具体命令类、请求者、接收者
【观察者模式】
No7：
registerReceiver函数并不是在Activity中实现，而是在其父类ContextWrapper中-ContextImpl
No8：
Android应用程序发送广播的过程
1）通过sendBroadcast把一个广播通过Binder发送给ActivityManagerService，ActivityManagerService根据这个广播的Action类型找到相应的广播接收器，然后把这个广播放进自己的消息队列中，就完成第一阶段对这个广播的异步分发
2）ActivityManagerService在消息循环中处理这个广播，并通过Binder机制把这个广播分发给注册的ReceiverDispatcher，ReceiverDispatcher把这个广播放进MainActivity所在线程的消息队列中，就完成第二阶段对这个广播的异步分发
3）ReceiverDispatcher的内部类Args在MainActivity所在的线程消息循环中处理这个广播，最终是将这个广播分发给所注册的BroadcastReceiver实例的onReceive函数进行处理
简单来说，广播就是一个订阅--发布的过程，通过一些map存储BroadcastReceiver，key就是封装了这些广播的信息类，如Action之类的。当发布一个广播时通过AMS到这个map中查询注册了这个广播的IntentFilter的BroadcastReceiver，然后通过ReceiverDispatcher将广播分发给各个订阅对象，从而完成这个发布--订阅过程。
No9：
事件总线EventBus
No10：
观察者模式的缺点：在应用观察者模式时需要考虑一下开发效率和运行效率问题，程序中包括一个被观察者、多个观察者、开发和调试等内容会比较复杂，而且在Java中消息的通知默认是顺序执行，一个观察者卡顿，会影响整体的执行效率，在这种情况下，一般考虑采用异步的方式
【备忘录模式】
onSaveInstanceState函数，主要分为如下3步：
1）存储窗口的视图树的状态
2）存储Fragment的状态
3）调用Activity的ActivityLifecycleCallbacks的onSaveInstanceState函数进行状态存储
No11：
dispatchSaveInstanceState函数在View没有设置id时，这个View的状态不会被存储到Bundle中。
Activity的信息保存在ActivityClientRecord对象中
No12：
优点：
1）给用户提供了一种可以恢复状态的机制，可以使用户能够比较方便地回到某个历史的状态
2）实现了信息的封装，使得用户不需要关心状态的保存细节
缺点：
消耗资源，如果类的成员变量过多，势必会占用比较大的资源，而且每一次保存都会消耗一定的内存
【迭代器模式】
迭代器模式包括：迭代接口、具体迭代实现类、容器接口、具体容器实现类
No13：
当我们使用SQLiteDatabase的quary方法查询数据库时，会返回一个Cursor游标对象，该游标对象实质就是一个具体的迭代器，我们可以使用它来遍历数据库查询所得的结果集。