- dex文件:是对使用标准的Java编译器编译出的class文件内部的各种函数表、变量表等进行优化后重新打包得到的一种文件格式;
- DexClassLoader:专门用来加载特殊的Class文件格式dex的类装载器;
- JNI(Java本地接口)调用机制
- 需要使用到JNI的场景主要包括:调用底层驱动、需要高效大量数据处理、复用某些已有代码;
- Java中调用C函数时,双方的名称需要有一个映射关系,一般为:C函数名=Java全路径包名、类名、方法名称的组合,中间以下划线分割;
比如AssetManager中的init方法声明为:private native final void init();
则该方法在C中对应的声明为:static void android_cotent_AssetManager_init(JNIEnv* env, jobject clazz);- 映射关系并不是固定不变的,开发人员可以通过AndroidRuntime.registerNativeMethods()方法来定义具体映射格式;
- JNIEnv对象代表的是JVM所运行的环境,通过它可以访问JVM内部的各种对象;
- jobject代表的是调用该C函数的java对象,上面的事例中就是AssetManager对象;
- 若java方法中包括自己定义的参数,那这些参数将会一次放在以上两个参数后面;
- java和C对数据类型的定义不一样,也需要有映射关系,比如int对应jint、String[]对应jobjectArray,具体定义在jni.h文件中;
- 可以通过命令javah直接对java类生成C语言.h头文件,比如javah -d ~/ -jni com.test.XXX;
- 在java代码中实际调用本地C函数之前,需要将C语言代码编译为.so动态库,并使用System.loadLibrary()装载;
- Java代码中不能直接访问C中的变量,若需要访问只能通过get/set方法;
- C函数中调用Java方法一般用得比较少,技术实现上与上面类似;
- 异步消息处理线程(该章节放在这里觉得非常奇怪,这部分内容已经涉及到Android很底层的东西了,和Java基础真没啥关系!)
- 一个通用的异步消息处理模型主要包括:
- 有一个保存消息的队列MessageQueue,排队的策略为FIFO,即先进先出;
- 一个处于无限循环的线程,循环体中从消息队列中取消息,并回调相应的消息处理函数;
- 其他外部线程可以向该队列发送消息,消息队列本身要线程安全;
- Android系统中异步消息处理实现原理
- 核心组件包括Handler、MessageQueue/Message、Looper;
- 理解线程局部变量ThreadLocal,其作用域为特定线程内,他在java多线程开发中被广泛用于数据共享和信息传递;
- 循环体Looper
- 若要想把一个普通线程变成异步消息处理线程,需要在Thread的run()方法中先调用Looper.prepare(),创建好一个消息队列MessageQueue,然后调用Looper.loop进入无限循环;
- loop无限循环中会调用MessageQueue.next()获取消息,若队列为空,则此时线程被挂起,处于wait状态;
若有消息,则取出,并回调msg.target.dispatchMessage()完成消息分发,msg.target指的是发送该msg的handler,而消息处理的具体业务逻辑在handler.handleMessage()中实现; - Message被处理完成后需要执行msg.recycle()进行回收,因为Message对象是使用数据池进行复用的,在新建消息时通过handler.obtainMessage()获取,而不是new一个;
- 消息队列MessageQueue
- 队列的底层数据结构为链表,每个Message对象中包含一个next变量;该队列的具体实现是在native C中完成的,不知道为啥不直接在java中完成?莫非一个小小的队列性能都能差别这么大?
- 核心方法为取出和发布消息,分别为next()、enqueueMessage();
- next()方法执行细节
- 调用native方法 nativePollOnce(int ptr, int timeoutMillis);
第一个参数ptr实际上是一个C实现中的NativeMessageQueue数据对象,在执行时会被强制转换,该技巧在之前的JNI环节中C代码中如何使用持久对象有说明;
若队列中没有消息,则将当前线程挂起至wait状态,当enqueueMessage()方法被调用时会被唤醒;
若队列中有消息,则取出来赋值给当前java对象中的mMessages变量; - 对取出的消息判断是否到了指定的执行时间,若到了则直接返回该Message;若未到执行时间则尝试取下一条消息;
注意:这部分代码需要和enqueueMessage()方法中的发送消息都保持线程安全,即使用相同的同步锁,避免消息队列出现数据不一致; - 若队列中取出的消息未到执行时间或没有消息,则判断当前 mPendingIdleHandlers是否有注册空闲回调函数;若有,顺序执行注册过的函数列表;
- 调用native方法 nativePollOnce(int ptr, int timeoutMillis);
- enqueueMessage()方法执行细节
- 当前待发送消息与当前对象中的Message具体执行时间做比较,将当前待发送消息插入到正确的队列位置中,确保消息在队列中是按照执行时间顺序排列的;
注意:这点在原书中并未说明,但却是MessageQueue的设计核心,因为直接关系到消息读取时的效率; - 将待发送消息赋值给mMessages变量;
- 调用 nativeWake(int ptr);函数,将mMessages消息保存到C代码中的消息队列中,同时判断当前消息线程是否处于wait状态,是则唤醒;
- 当前待发送消息与当前对象中的Message具体执行时间做比较,将当前待发送消息插入到正确的队列位置中,确保消息在队列中是按照执行时间顺序排列的;
- 以上涉及到的与native部分代码联动细节待深究;
- 业务逻辑代码继承Handler,开发者只需要和Handler打交道即可,无需知道Looper/MessageQueue;
- 重载 handleMessage()方法,实现消息处理的具体业务逻辑;
如果你不喜欢继承Handler,那你可以选择实现Handler.Callback这个接口,里面的方法名完全一样; - 通过 handler.obtainMessage();生成消息;
- 发送时执行 handler.sendXXX系列方法、或postXXX系列方法;
- Handler.dispatchMessage()方法代码解析:
01
public
void
dispatchMessage(Message msg) {
02
if
(msg.callback !=
null
) {
//此处的callback其实就是附着在Message中的一个Runnable,消息一般为post系列方法发送
03
handleCallback(msg);
//其实等同于 message.callback.run();
04
}
else
{
05
if
(mCallback !=
null
) {
//此处的callback是实现Handler.Callback接口的实例对象
06
if
(mCallback.handleMessage(msg)) {
//调用Handler.Callback接口中的方法
07
return
;
08
}
09
}
10
handleMessage(msg);
//调用继承于Handler、重载过的handleMessage方法;
11
}
12
}
看这段代码会不会很晕呢?我个人觉得在代码命名上面的确做得不咋地,2个callback,2个handleMessage方法让你彻底晕菜!
- 重载 handleMessage()方法,实现消息处理的具体业务逻辑;
- 一个通用的异步消息处理模型主要包括: