首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >一个 ClassLoader 引起的 JNI 链接错误

一个 ClassLoader 引起的 JNI 链接错误

原创
作者头像
QQ空间开发团队
修改2017-11-01 09:45:20
3.2K1
修改2017-11-01 09:45:20
举报

作者:Rayszhang

前言

Android插件化工程具有减少方法数和包大小,易于扩展等优势,深得大型工程的青睐,但同时插件化也会引起一些意想不到的麻烦。我们最近在做的插件工程就遇到了一个诡异的JNI链接错误。

我们的插件工程作为主工程的具体业务,主工程提供了基础的类库和工具,插件工程有自己的ClassLoader,并把主工程的ClassLoader设为自己的父ClassLoader,通过双亲委托,插件工程就可以访问主工程中的类。在主工程中有一个类库,有JNI方法,但为了减少主工程的包大小,so文件由插件在用到时自己下载和加载。

而这种加载方式,出现了诡异的UnsatisfiedLinkError错误。我们首先检查了System.load方法发现并没有出错,又查看了进程的内存映射信息,发现so文件确实已经加载,但调用JNI方法也确实一直出错。待排查了时序等相关情况后,还是不成功,于是我们只得求助于系统源码,希望能从源码中找到答案,以Android N为例,我们开始了源码分析过程。

so加载流程分析

so既然要先加载才能用,那我们就先来看so是怎么加载的,先来分析System.load方法

[1509443269845_1212_1509443318628.png]
[1509443269845_1212_1509443318628.png]

方法很简单,直接调用了Runtime类的load方法,传入了so的名称和当前的ClassLoader,再来看这个方法

[1509443284121_1426_1509443332920.jpg]
[1509443284121_1426_1509443332920.jpg]

可以看到,load校验了参数后调用了doLoad方法,doLoad取得ldLibraryPath和dexPath后调用了native层的nativeLoad函数。继续看nativeLoad函数

[1509443297588_310_1509443346436.png]
[1509443297588_310_1509443346436.png]

还是很简单的函数,设置完LdLibraryPath后,调用JavaVM的LoadNtiveLibrary函数,继续看

[1509443312995_298_1509443361798.jpg]
[1509443312995_298_1509443361798.jpg]

该函数较长,但逻辑还是很清晰的,我们只列出了关键代码,libraries保存了一个以so路径和SharedLibrary对象为记录的Map,保存了当前所有已经加载的so。首先从libraries中查找记录,如果有说明该so已经加载过,再判断和so关联的ClassLoader是不是当前的ClassLoader,如果不是,返回false,这说明同一个路径的so只能被一个ClassLoader加载,如果没找到记录,说明该so没有加载过,则通过dlopen打开该so,保存相关信息到SharedLibrary对象中,把SharedLibrary添加到libraries中,用dlsym查找JNI_OnLoad函数,如果找到了则执行该函数。 在看代码时第一反应是会不会isSameObject判断这里有问题,so已经被另一个ClassLoader给加载了,但转念一想,如果这里有问题那么load的时候会直接报错,而不是在执行的时候才报错。所以so的加载流程没有找到有问题的点,那么我们再看执行流程。

native方法执行流程分析

我们知道,在ART环境下,类的方法都会用ArtMethod表示,而ArtMethod的PtrSizedFields字段保存了该方法的跳转地址

[1509443331250_6633_1509443380053.png]
[1509443331250_6633_1509443380053.png]

其中entrypoint_from_jni就是native函数执行时的跳转地址,那么这个地址是什么呢?其实这个地址是Class在加载的时候设置的,我们来看下代码

[1509443344764_9933_1509443393542.png]
[1509443344764_9933_1509443393542.png]

ClassLinker负责在ART中加载Class,通过FindClass->DefineClass->LoadClass->LoadClassMembers,会解析出ArtMethod,最后通过LinkCode对ArtMethod的跳转地址进行赋值,这里我们只看native方法的情况,执行了UnregisterNative函数

[1509443357443_7191_1509443406216.jpg]
[1509443357443_7191_1509443406216.jpg]

SetEntryPointFromJni就是对entrypoint_from_jni做了赋值,值是通过GetJniDlsymLookupStub()获得,就是一个artjnidlsymlookupstub函数地址,到这里我们知道类加载后其native方法地址被设置成了artjnidlsymlookupstub这个入口函数,当native方法被执行时,会调用这个入口函数执行,我们来看这个函数

[1509443377869_7240_1509443426628.jpg]
[1509443377869_7240_1509443426628.jpg]

art_jni_dlsym_lookup_stub在汇编中定义,与平台相关,我们用arm64平台代码作为例子

[1509443393232_1560_1509443442069.png]
[1509443393232_1560_1509443442069.png]

可以看到这个函数又跳转到了artFindNativeMethod函数

[1509443405952_980_1509443454866.png]
[1509443405952_980_1509443454866.png]

该函数首先查询native函数的地址,查到后会通过RegisterNative设置给ArtMethod,这样以后就ArtMethod就可以直接跳转到native层的地址,而不用每次都经过该函数,RegisterNative同样调用了SetEntryPointFromJni来设置跳转地址,接下来看FindCodeForNativeMethod函数

[1509443421788_8329_1509443470548.jpg]
[1509443421788_8329_1509443470548.jpg]

这里又看到了熟悉的libraries,前边分析so加载部分已经知道它保存了所有已经加载的so,所以这就是从已经加载的so里查找native函数,如果没找到,则抛出UnsatisfiedLinkError。我们再来看看FindNativeMethod

[1509443437129_4526_1509443485913.jpg]
[1509443437129_4526_1509443485913.jpg]

FindSymbol就是调用dlsym获取native函数的地址,所以到此native函数的地址就真正的找到了,但是我们注意到了其中的一个判断,library->GetClassLoader()==declaring_class_loader,也就是和so关联的ClassLoader要和当前的ClassLoader是同一个才行,不然会放弃查找,到此我们的疑惑也就解开了,因为JAVA层的代码是在主工程的ClassLoader里,而加载so用的是插件的ClassLoader,两个ClassLoader不相等,所以在这里放弃了查找而抛出了异常。

解决方案

知道了原因解决自然也就容易了,只要用同一个ClassLoader加载类和so就行了,因为Java层的ClassLoader是变不了的,所以我们就改变加载so的ClassLoader

1、使用主工程中的类来加载so

2、如果主工程不好添加代码的话,我们也可以在插件里改变Runtime.load()所使用的ClassLoader,但是Runtime的load方法只有一个参数的公开方法,传ClassLoader的方法是私有的,所以我们只能通过反射去传入主工程的ClassLoader

[1509443457387_9843_1509443506168.jpg]
[1509443457387_9843_1509443506168.jpg]

一点思考

通常我们只注意了Java类和ClassLoader的对应关系,JVM通过ClassLoader和类的全路径名来唯一的确定一个class,而忽略了so和ClassLoader也是有对应关系的,具有相同ClassLoader的Java类和JNI方法才能一一对应,ClassLoader其实也起到了类似命名空间的作用。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 前言
  • so加载流程分析
  • native方法执行流程分析
  • 解决方案
  • 一点思考
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档