最初接触该部分逻辑是从VoiceCall的dail功能代码开始的。所以,同样以frameworks侧的dail部分为索引,对Call业务做一个梳理。
由于一些android功能上的特性安排,本文的分析顺序自底向上。
1. Ril.java类
需要理解的若干概念:Handler,message
RIL.java是ril功能在frameworks层的一个抽象实现,网络上关于该类代码的分析数不胜数,更说明了它的重要性。然而对于Call功能而言,RIL.java的作用更像是层层包裹下的糖果,frameworks层做了种种的条件判断或者是数据包装,最终的目的都是调用这个类中的方法,将app的数据需求传到CP侧,或者是将CP的消息取过来上传到app。
RIL.java与rild的通信方式为socket,这一点本文并不关注。因为对于frameworks层而言,最终送出去的消息以什么形式进行包装并不重要,需要关注的应该是RIL.java需要什么样的数据来填充消息,以及它是如何接收上层消息或是捕获底层消息的。
这样一来,不得不提到的就是android的Handler机制。
Handler及其相关概念
关于Handler及其相关概念,可以从这张图上有一个比较直观的理解。
(来自blog.csdn.net/stefzeus/article/details/6187337)
简单来说,就是Handler从消息池(mPool)中,通过obtain方法取得消息后,用sendMessage(msg)方法将其送入队列MessageQueue中。另一方面,looper通过loop()方法,将MessageQueue中等待处理的消息(Message)取出,并调用对应的msg.target.dispatchMessage()来达到消息分发的目的。从而完成消息的异步处理。
RIL.java类处于telephony/framework最底层,与rild通过socket直接联系。其有两个重要的内部类,RILSender与RILReceiver。
RILSender继承Handler类,实现Runnable接口。从构造函数
PublicRILSender(Looper looper){}
可以看出,它实际是通过 public Handler(Looper looper)来完成线程的初始化的。通过这个looper作为连结点,msg在被送入looper.mQueue中后又被RILSender.dispatchMessage(msg)分发,最终交由RILSender.handleMessage(msg)来处理对应消息。
RILSender的作用是将frameworks层下发的消息,以socket方式送到rild侧,最终以AT指令或者是其他的方式发送到服务器端。这个过程是消息的派送。
而RILReceiver,顾名思义,即为消息的接收。这个线程主要负责接收从rild侧发来的socket的消息,从逻辑上来看即是一个不停轮询端口直至接收消息的过程。
这两套线程的启动都放在RIL.java的构造函数中。
具体的分析过程如下。
RIL()@RIL.java
mSenderThread = new HandlerThread("RILSender");
mSenderThread.start();
mSenderThread实例化HandlerThread,start之后实际上也将loop()跑起来了。
Looper looper = mSenderThread.getLooper();
mSender = new RILSender(looper);
从mSenderThread中取出的looper用于构造Handler,这样就把Handler
Looper以及MessageQueue绑定到一起了。
这个构造出的mSender,同时也为Message的dispatch指定了target。这样一来,整个循环就搭起来了。
原文:http://blog.csdn.net/guiyu_1985/article/details/7282748