基于监听的事件模型分工更明确，事件源、事件监听由两个类分开，因此具有更好的可维护性。
android的事件处理机制保证基于监听的事件监听器会被优先出发。
在事件监听的处理模型中，主要涉及三类对象：
1.event source（事件源）：事件发生的场所，通常就是各个组件，例如按钮，窗口，菜单等。
2.event（事件）：事件封装了界面组件上发生的特定事情（通常就是一次用户操作）。如果程序需要获得界面组件上所发生事情的相关信息，一般通过event对象来取得。
3.event listener（事件监听器）：负责监听事件源所发生的事件，并对各种事件做出相应的响应。
android为不同的界面组件提供了不同的监听器接口：
1.view.onclicklistener:单击事件的事件监听器必须实现的接口。
2.view.oncreatecontextmenulistener:创建上下文菜单事件的事件监听器必须实现的接口。
3.view.onfocuschangelistener:焦点改变事件的事件监听器必须实现的接口。
4.view.onkeylistener:按键事件的事件监听器必须实现的接口。
5.view.onlongclicklistener:长按事件的事件监听器必须实现的接口。
6.view.ontouchlistener:触摸事件的事件监听器必须实现的接口。
所谓的事件监听器，其实就是实现了特定接口的java类的实例。在程序中实现事件监听器，通常有如下几种形式。
1.内部类形式：将事件监听器类定义成当前的内部类。
2.外部类形式：将事件监听器类定义成一个外部类。
3.activity本身作为事件监听器类：让activity本身实现监听器接口，并实现事件处理方法。
4.匿名内部类形式：使用匿名内部类创建事件监听器对象。
5.直接绑定标签：为ui组件的android:onclick属性指定事件的监听方法，开发者需要在activity中定义该事件监听方法（该方法必须有一个view类型的形参，该形参代表被单击的ui组件），当用户单击该ui组件时，系统将会激发android：onclick属性所指定的方法。
1.内部类作为事件监听器类
使用内部类作为事件监听器类的优势：
①使用内部类可以在当前类中复用该监听器类
②因为监听器类是外部类的内部类，所以可以自由访问外部类的所有界面组件。
示例：
activity_main.xml
mainactivity.java
2.外部类作为事件监听器类
外部类作为事件监听器类的劣势：
①事件监听器通常属于特定的gui界面，定义成外部类不利于提高程序的内聚性。
②外部类形式的事件监听器不能自由访问gui界面的类中的组件，变成不够简洁。
外部类作为事件监听器类的优势：
如果某个事件监听器确实需要被多个gui界面所共享，而且主要是完成某种业务逻辑的实现，则可以考虑使用外部类的形式来定义事件监听器类。
activity_main.xml
sendsmslistener.java
在androidmanifest.xml上添加发送短信的权限
3.activity本身作为事件监听器
activity本身作为事件监听器的劣势：
①这种形式可能造成程序结构混乱，activity的主要职责应该是完成界面初始化工作，但此时还需要包含事件处理器的方法，从而引起混乱。
②如果activity界面类需要实现监听器接口，让人感觉比较怪异。
activity本身作为事件监听器的优势：
直接在activity类中定义事件处理方法，非常简洁。
4.匿名内部类作为事件监听器类
匿名内部类作为事件监听器类的优势：
大部分时候，事件处理器都没有什么复用价值（可复用代码通常都被抽象成了业务逻辑方法），因此大部分事件监听器只是临时使用一次，所以使用匿名内部类形式的事件监听器更合适。
匿名内部类作为事件监听器类的劣势：
语法不宜掌握。
activity_main.xml
5.直接绑定到标签
对于很多android界面组件标签而言，它们都支持onclick属性，该属性值就是一个形如xxx(view source)的方法的方法名。