正文
-
本地服务,属于同一个应用程序,通过startService来启动或者通过bindService来绑定并且获取代理对象。如果只是想开个服务在后台运行的话,直接startService即可,如果需要相互之间进行传值或者操作的话,就应该通过bindService。
-
远程服务(不同应用程序之间),通过bindService来绑定并且获取代理对象。
context.startService() ->onCreate()- >onStartCommand()->Service running--调用context.stopService() ->onDestroy()
context.bindService()->onCreate()->onBind()->Service running--调用>onUnbind() -> onDestroy()
Service默认是运行在main线程的,因此Service中如果需要执行耗时操作(大文件的操作,数据库的拷贝,网络请求,文件下载等)的话应该在子线程中完成。
!特殊情况是:Service在清单文件中指定了在其他进程中运行。
因为屏幕的刷新频率是60Hz,大概16毫秒会刷新一次,所以为了保证UI的流畅性,耗时操作需要在子线程中处理,子线程不能直接对UI进行更新操作。因此需要Handler在子线程发消息给主线程来更新UI。
这里再深入一点,Android中的UI控件不是线程安全的,因此在多线程并发访问UI的时候会导致UI控件处于不可预期的状态。Google不通过锁的机制来处理这个问题是因为:
-
引入锁会导致UI的操作变得复杂
-
引入锁会导致UI的运行效率降低
因此,Google的工程师最后是通过单线程的模型来操作UI,开发者只需要通过Handler在不同线程之间切花就可以了。
Android中的消息机制主要是指Handler的运行机制。Handler是进行线程切换的关键,在主线程和子线程之间切换只是一种比较特殊的使用情景而已。其中消息传递机制需要了解的东西有Message、Handler、Looper、Looper里面的MessageQueue对象。
如上图所示,我们可以把整个消息机制看作是一条流水线。其中:
-
MessageQueue是传送带,负责Message队列的传送与管理
-
Looper是流水线的发动机,不断地把消息从消息队列里面取出来,交给Handler来处理
-
Message是每一件产品
-
Handler就是工人。但是这么比喻不太恰当,因为发送以及最终处理Message的都是Handler
Handler的工作是依赖于Looper的,而Looper(与消息队列)又是属于某一个线程(ThreadLocal是线程内部的数据存储类,通过它可以在指定线程中存储数据,其他线程则无法获取到),其他线程不能访问。因此Handler就是间接跟线程是绑定在一起了。因此要使用Handler必须要保证Handler所创建的线程中有Looper对象并且启动循环。因为子线程中默认是没有Looper的,所以会报错。
正确的使用方法是:
handler = null;
new Thread(new Runnable() {
private Looper mLooper;
@Override
public void run() {
//必须调用Looper的prepare方法为当前线程创建一个Looper对象,然后启动循环
//prepare方法中实质是给ThreadLocal对象创建了一个Looper对象
//如果当前线程已经创建过Looper对象了,那么会报错
Looper.prepare();
handler = new Handler();
//获取Looper对象
mLooper = Looper.myLooper();
//启动消息循环
Looper.loop();
//在适当的时候退出Looper的消息循环,防止内存泄漏
mLooper.quit();
}
}).start();
主线程中默认是创建了Looper并且启动了消息的循环的,因此不会报错:
应用程序的入口是ActivityThread的main方法,在这个方法里面会创建Looper,并且执行Looper的loop方法来启动消息的循环,使得应用程序一直运行。
子线程中可以通过Handler发送消息给主线程吗?
可以。有时候出于业务需要,主线程可以向子线程发送消息。子线程的Handler必须按照上述方法创建,并且关联Looper。
Android中View的机制主要是Activity的显示,每个Activity都有一个Window(具体在手机中的实现类是PhoneWindow),Window以下有DecorView,DecorView下面有TitleVie以及ContentView,而ContentView就是我们在Activity中通过setContentView指定的。
ViewGroup有以下三个与事件分发的方法,而View只有dispatchTouchEvent和onTouchEvent。
@Override
public boolean dispatchTouchEvent(MotionEvent ev) {
return super.dispatchTouchEvent(ev);
}
@Override
public boolean onInterceptTouchEvent(MotionEvent ev) {
return super.onInterceptTouchEvent(ev);
}
@Override
public boolean onTouchEvent(MotionEvent event) {
return super.onTouchEvent(event);
}
事件总是从上往下进行分发,即先到达Activity,再到达ViewGroup,再到达子View,如果没有任何视图消耗事件的话,事件会顺着路径往回传递。其中:
-
dispatchTouchEvent是事件的分发方法,如果事件能够到达该视图的话,就首先一定会调用,一般我们不会去修改这个方法。
-
onInterceptTouchEvent是事件分发的核心方法,表示ViewGroup是否拦截事件,如果返回true表示拦截,在这之后ViewGroup的onTouchEvent会被调用,事件就不会往下传递。
-
onTouchEvent是最低级的,在事件分发中最后被调用。
-
子View可以通过requestDisallowInterceptTouchEvent方法去请求父元素不要拦截。
-
事件从Activity.dispatchTouchEvent()开始传递,只要没有被停止或拦截,从最上层的View(ViewGroup)开始一直往下(子View)传递。子View 可以通过onTouchEvent()对事件进行处理。
-
事件由父View(ViewGroup)传递给子View,ViewGroup 可以通过onInterceptTouchEvent()对事件做拦截,停止其往下传递。
-
如果事件从上往下传递过程中一直没有被停止,且最底层子View 没有消费事件,事件会反向往上传递,这时父View(ViewGroup)可以进行消费,如果还是没有被消费的话,最后会到Activity 的onTouchEvent()函数。
-
如果View 没有对ACTION_DOWN 进行消费,之后的其他事件不会传递过来。