Android JNI SO 加载原理

Android 上 SO 加载原理

要知道,Android本质上还是一个Linux系统,两者加载SO都是一样的套路,这里有篇文章说的很好:Linux 系统加载动态库过程分析。简单点说:Anroid加载SO,最终是通过系统方法dlopen()来完成的。

基本流程是:System.loadLibrary() -> Runtime.loadLibrary0() -> Runtime.nativeLoad() -> ...。

但这里有个地方让我刚开始难以理解,明明是看SO的加载,结果最后却是用到了JNI的方法,那又是谁加载的这个JNI的SO呢?

显然,Runtime的JNI部分已经加载好了,这里就要看Anroid系统本身的加载流程,可以参考安卓进程的启动流程、从源码解析-Android中Zygote进程是如何fork一个APP进程的、Android Zygote进程和app进程fork过程分析1、Android Zygote进程和app进程fork过程分析2,我用的是最新的Android代码,可能会和文章不太一致,但大体思路是没变的。先看一张安卓进程之间的关系图:


image.png

不难看出,每一个android进程都各自独立的虚拟机,那么一个应用在启动时,会加载自己的虚拟机,这个时候,也就会加载到Runtime.nativeLoad()方法,那就要讲讲虚拟机的加载了。

虚拟机加载流程

先挑一个简单的说,就我们平时常用的Context.startActivity()就能拉起一个进程,抛开其中复杂的逻辑判断,调用链是:

Context.startActivity() -> Instrumentation.execStartActivity() -> ActivityTaskManager.getService().startActivity() -> binder访问到ActivityManagerService.startActivity() -> 如果进程未启动 -> ActivityTaskManagerService.startProcessAsync() -> ProcessList.startProcessLocked() -> Process.start() -> ZygoteProcess.start() -> 通过LocalSocket到ZygoteInit.java

这里需要切换到ZygoteInit.java,Zygote进程被启动后,会一直读取通过LocalSocket过来的任务,其流程是:

ZygoteInit.main() -> ZygoteServer.runSelectLoop() 读到前面发来的创建进程请求-> ZygoteConnection.processOneCommand() -> Zygote.forkAndSpecialize() -> Zygote.nativeForkAndSpecialize() -> fork成功后 -> 回到ZygoteConnection.processOneCommand()中,调用ZygoteConnection.handleChildProc() -> ZygoteInit.childZygoteInit() —> RuntimeInit.findStaticMain() -> ActivityThread.main()

到这一步,就是到了拉起APP主线程的时候了,应用的虚拟机早在fork的那一步就被拷贝,其实已经被启动了。

Zygote进程启动来看So加载

手机启动流程:

  • 启动电源以及系统启动:开启电源后,加载引导程序BootLoader到RAM中,执行。

  • BootLoader:Android系统开始运行前的一个小程序,作用是拉起OS并运行。

  • Linxu内存启动:启动后会有一系列初始化动作,接着会调用init.rc(Android Init Langauage脚本语言),并启动init进程。

  • init进程启动:init进程主要用于初始化和启动熟悉服务,也可以用来启动Zygote进程。

  • 执行zygot的rc脚本后,会进入frameworks/base/cmds/app_process/app_main.cpp的main方法。

  • 先看下流程图(来源):

image.png

创建虚拟机后,开始注册JNI方法AndroidRuntime::startReg() -> AndroidRuntime::register_jni_procs()。

扯一个题外话,该注册方法的调用是这样的,register_jni_procs(gRegJNI, NELEM(gRegJNI), env),它的实现是


image.png
  • 如果这里能找到对Runtime.nativeLoad()方法的C++注册,那显然就能解释JNI方法是如何加载的了,遗憾的是,并没有,这里的操作,主要是注册Android特有的JNI方法,于是要回到虚拟机初始化部分。

  • 回到AndroidRuntime::startVm() -> JNI_CreateJavaVM(),看注释有点意思了,大意是说是Android虚拟机预处理的地方,完成后就能使用JNI方法了。


    image.png

接着到JniInvocation.c的JNI_CreateJavaVM() -> 最终是DlSymbol JNI_CreateJavaVM_ = FindSymbol(library, "JNI_CreateJavaVM"); -> libart.so的JNI_CreateJavaVM() -> java_vm_ext.cc的JNI_CreateJavaVM() -> runtime.cc的Runtime::Start() -> runtime.cc的Runtime::InitNativeMethods()
详细看下InitNativeMethods()方法,终于有点戏了:

image.png

接着走,来到java_vm_ext.cc的JavaVMExt::LoadNativeLibrary()方法里有段代码是这样的:

image.png

如果熟悉System.loadLibrary()的同学就会知道,加载SO的时候,就会被调用到JNI_Onload()方法。

  • 根据前面System.loadLibrary()文章,找到nativeLoad()的JNI实现,发现在Runtime.c这个类,看如下代码:
image.png

是不是有点JNI注册方法的感觉了,就是这里!

  • 那么就剩下一件事了,Runtime.c是放到哪个SO里的呢?

其全路径是libcore/ojluni/src/main/native/Runtime.c,发现其代码在libcore/ojluni里(小知识:Android Java API迁移),查看libcore/ojluni/src/main/native/Android.bp:


image.png

里面就有一直心心念念的Runtime.c,接着根据其中name来搜,到libcore/NativeCode.bp,接下来路径是libcore/NativeCode.bp -> libopenjdk_native_defaults -> libopenjdk:

image.png

另一个后缀带d的应该是debug模式下的。

总结

这部分文章,描述是我从疑惑 Android SO 的加载,探究整个问题的思考路径:
1.从System.loadLibrary()源码开始,发现加载会用到Native方法Runtime.nativeLoad(),从而有第一个疑惑点:明明是看SO的加载,结果用到了Native的方法。
2.多方查证资料后,知道了Linux加载SO的方式:dlopen()和dlsym()。从而知道,一定还有另外一个路径去注册C++方法,并串联起Java和C++方法。
3.像这种方法,应该是Android虚拟机需要加载的,所以猜测在Android虚拟机启动时,会初始化这块逻辑。
4.在查资料的同时,也学习了一波Activity拉起进程的逻辑,不过由于进程是fork出来的,所以并不涉及虚拟机的创建。
5.那么就想到去看Android系统的启动流程,进而了解了Zygote进程的启动。
6.在看Zygote进程启动流程代码时,进入了一个误区,一直以为AndroidRuntime.cpp里注册的一票JNI方法就是我要找的Runtime.nativeLoad(),虽然代码流程最后走到了,但这块其实注册的是Android的系统方法,而我需要关系的是Java虚拟机的部分。
7.回到AndroidRuntime::startVm()部分,继续跟流程,在Runtime::initNativeMethods()里,看到了关键注释,描述了System.loadLibrary()是如何被加载的。
8.通过查找Runtime.nativeLoad()方法所在的源码位置,知道Runtime.c所在的仓库,那么只需要验证一个点,就是Runtime::initNativeMethods()加载的SO里头,编译时有这个Runtime.c。

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 214,875评论 6 496
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 91,569评论 3 389
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 160,475评论 0 350
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 57,459评论 1 288
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 66,537评论 6 386
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 50,563评论 1 293
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 39,580评论 3 414
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 38,326评论 0 270
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,773评论 1 307
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,086评论 2 330
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,252评论 1 343
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 34,921评论 5 338
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 40,566评论 3 322
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,190评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,435评论 1 268
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 47,129评论 2 366
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 44,125评论 2 352

推荐阅读更多精彩内容