看完这篇，帮你彻底搞懂Android动态加载so

　　作者：Pika
　　对于一个普通的android应用来说，so库的占比通常都是居高不下的，因为我们无可避免的在开发中遇到各种各样需要用到native的需求，所以so库的动态化可以减少极大的包体积，自从2020腾讯的bugly团队发布关于动态化so的相关文章后，已经过去两年了，经过两年的考验，实际上so动态加载也是非常成熟的一项技术了，但是很遗憾，许多公司都还没有这方面的涉略又或者说不知道从哪里开始进行，因为so动态其实涉及到下载，so版本管理，动态加载实现等多方面，我们不妨抛开这些额外的东西，从最本质的so动态加载出发吧！这里是本次的例子，我把它命名为sillyboy，欢迎pr还有后续点赞呀！
　　https：cloud。tencent。comdeveloperarticle1592672
　　https：github。comTestPlanBSillyBoy一、so动态加载介绍
　　动态加载，其实就是把我们的so库在打包成apk的时候剔除，在合适的时候通过网络包下载的方式，通过一些手段，在运行的时候进行分离加载的过程。这里涉及到下载器，还有下载后的版本管理等等确保一个so库被正确的加载等过程，在这里，我们不讨论这些辅助的流程，我们看下怎么实现一个最简单的加载流程。
　　1、从一个例子出发
　　我们构建一个native工程，然后在里面编入如下内容，下面是cmake。FormoreinformationaboutusingCMakewithAndroidStudio，readthedocumentation：https：d。android。comstudioprojectsaddnativecode。htmlSetstheminimumversionofCMakerequiredtobuildthenativelibrary。cmakeminimumrequired（VERSION3。18。1）Declaresandnamestheproject。project（nativecpp）Createsandnamesalibrary，setsitaseitherSTATICorSHARED，andprovidestherelativepathstoitssourcecode。Youcandefinemultiplelibraries，andCMakebuildsthemforyou。GradleautomaticallypackagessharedlibrarieswithyourAPK。addlibrary（Setsthenameofthelibrary。nativecppSetsthelibraryasasharedlibrary。SHAREDProvidesarelativepathtoyoursourcefile（s）。nativelib。cpp）addlibrary（nativecpptwoSHAREDtest。cpp）Searchesforaspecifiedprebuiltlibraryandstoresthepathasavariable。BecauseCMakeincludessystemlibrariesinthesearchpathbydefault，youonlyneedtospecifythenameofthepublicNDKlibraryyouwanttoadd。CMakeverifiesthatthelibraryexistsbeforecompletingitsbuild。findlibrary（Setsthenameofthepathvariable。loglibSpecifiesthenameoftheNDKlibrarythatyouwantCMaketolocate。log）SpecifieslibrariesCMakeshouldlinktoyourtargetlibrary。Youcanlinkmultiplelibraries，suchaslibrariesyoudefineinthisbuildscript，prebuiltthirdpartylibraries，orsystemlibraries。targetlinklibraries（Specifiesthetargetlibrary。nativecppLinksthetargetlibrarytotheloglibraryincludedintheNDK。｛loglib｝）targetlinklibraries（Specifiesthetargetlibrary。nativecpptwoLinksthetargetlibrarytotheloglibraryincludedintheNDK。nativecpp｛loglib｝）
　　可以看到，我们生成了两个so库一个是nativecpp，还有一个是nativecpptwo（为什么要两个呢？我们可以继续看下文）这里也给出最关键的test。cpp代码。includejni。hincludestringincludeexternCJNIEXPORTvoidJNICALLJavacomexamplenativecppMainActivityclickTest（JNIEnvenv，jobjectthiz）｛在这里打印一句话androidlogprint（ANDROIDLOGINFO，hello，native层方法）；｝
　　很简单，就一个native方法，打印一个log即可，我们就可以在javakotin层进行方法调用了，即：publicnativevoidclickTest（）；
　　2、so库检索与删除
　　要实现so的动态加载，那最起码是要知道本项目过程中涉及到哪些so吧！不用担心，我们gradle构建的时候，就已经提供了相应的构建过程，即构建的task【mergeDebugNativeLibs】，在这个过程中，会把一个project里面的所有native库进行一个收集的过程，紧接着task【stripDebugDebugSymbols】是一个符号表清除过程，如果了解native开发的朋友很容易就知道，这就是一个减少so体积的一个过程，我们不在这里详述。所以我们很容易想到，我们只要在这两个task中插入一个自定义的task，用于遍历和删除就可以实现so的删除化了，所以就很容易写出这样的代码。ext｛deleteSoName〔libnativecpptwo。so，libnativecpp。so〕｝这个是初始化配置执行阶段中，配置阶段执行的任务之一，完成afterEvaluate就可以得到所有的tasks，从而可以在里面插入我们定制化的数据task（dynamicSo）｛｝。doLast｛println（dynamicSoinsert！！！！）projectDir在哪个project下面，projectDir就是哪个路径print（getRootProject（）。findAll（））deffilenewFile（｛projectDir｝buildintermediatesmergednativelibsdebugoutlib）默认删除所有的so库if（file。exists（））｛file。listFiles（）。each｛if（it。isDirectory（））｛it。listFiles（）。each｛targetprint（file｛target。name｝）defcompareNametarget。namedeleteSoName。each｛if（compareName。contains（it））｛target。delete（）｝｝｝｝｝｝else｛print（nil）｝｝afterEvaluate｛print（dynamicSotaskstart）defcustomertasks。findByName（dynamicSo）defmergetasks。findByName（mergeDebugNativeLibs）defstriptasks。findByName（stripDebugDebugSymbols）if（merge！nullstrip！null）｛customer。mustRunAfter（merge）strip。dependsOn（customer）｝｝
　　可以看到，我们定义了一个自定义taskdynamicSo，它的执行是在afterEvaluate中定义的，并且依赖于mergeDebugNativeLibs，而stripDebugDebugSymbols就依赖于我们生成的dynamicSo，达到了一个插入操作。那么为什么要在afterEvaluate中执行呢？那是因为android插件是在配置阶段中才生成的mergeDebugNativeLibs等任务，原本的gradle构建是不存在这样一个任务的，所以我们才需要在配置完所有task之后，才进行的插入，我们可以看一下gradle的生命周期。
　　通过对条件检索，我们就删除掉了我们想要的so，即ibnativecpptwo。so与libnativecpp。so。
　　3、动态加载so
　　根据上文检索出来的两个so，我们就可以在项目中上传到自己的后端中，然后通过网络下载到用户的手机上，这里我们就演示一下即可，我们就直接放在data目录下面吧。
　　真实的项目过程中，应该要有校验操作，比如md5校验或者可以解压等等操作，这里不是重点，我们就直接略过啦！
　　那么，怎么把一个so库加载到我们本来的apk中呢？这里是so原本的加载过程，可以看到，系统是通过classloader检索native目录是否存在so库进行加载的，那我们反射一下，把我们自定义的path加入进行不就可以了吗？这里采用tinker一样的思路，在我们的classloader中加入so的检索路径即可，比如：
　　https：cs。android。comandroidplatformsuperprojectmaster：libcoreojlunisrcmainjavajavalangRuntime。java；l1？qRuntime。javaprivatestaticfinalclassV25｛privatestaticvoidinstall（ClassLoaderclassLoader，Filefolder）throwsThrowable｛finalFieldpathListFieldShareReflectUtil。findField（classLoader，pathList）；finalObjectdexPathListpathListField。get（classLoader）；finalFieldnativeLibraryDirectoriesShareReflectUtil。findField（dexPathList，nativeLibraryDirectories）；ListFileorigLibDirs（ListFile）nativeLibraryDirectories。get（dexPathList）；if（origLibDirsnull）｛origLibDirsnewArrayList（2）；｝finalIteratorFilelibDirItorigLibDirs。iterator（）；while（libDirIt。hasNext（））｛finalFilelibDirlibDirIt。next（）；if（folder。equals（libDir））｛libDirIt。remove（）；break；｝｝origLibDirs。add（0，folder）；finalFieldsystemNativeLibraryDirectoriesShareReflectUtil。findField（dexPathList，systemNativeLibraryDirectories）；ListFileorigSystemLibDirs（ListFile）systemNativeLibraryDirectories。get（dexPathList）；if（origSystemLibDirsnull）｛origSystemLibDirsnewArrayList（2）；｝finalListFilenewLibDirsnewArrayList（origLibDirs。size（）origSystemLibDirs。size（）1）；newLibDirs。addAll（origLibDirs）；newLibDirs。addAll（origSystemLibDirs）；finalMethodmakeElementsShareReflectUtil。findMethod（dexPathList，makePathElements，List。class）；finalObject〔〕elements（Object〔〕）makeElements。invoke（dexPathList，newLibDirs）；finalFieldnativeLibraryPathElementsShareReflectUtil。findField（dexPathList，nativeLibraryPathElements）；nativeLibraryPathElements。set（dexPathList，elements）；｝｝
　　我们在原本的检索路径中，在最前面，即数组为0的位置加入了我们的检索路径，这样一来claaloader在查找我们已经动态化的so库的时候，就能够找到！
　　4、结束了吗？
　　一般的so库，比如不依赖其他的so的时候，直接这样加载就没问题了，但是如果存在着依赖的so库的话，就不行了！相信大家在看其他的博客的时候就能看到，是因为Namespace的问题。具体是我们动态库加载的过程中，如果需要依赖其他的动态库，那么就需要一个链接的过程对吧！这里的实现就是Linker，Linker里检索的路径在创建ClassLoader实例后就被系统通过Namespace机制绑定了，当我们注入新的路径之后，虽然ClassLoader里的路径增加了，但是Linker里Namespace已经绑定的路径集合并没有同步更新，所以出现了libxxx。so文件（当前的so）能找到，而依赖的so找不到的情况。bugly文章。
　　https：cloud。tencent。comdeveloperarticle1592672？fromarticle。detail。1751968
　　很多实现都采用了Tinker的实现，既然我们系统的classloader是这样，那么我们在合适的时候把这个替换掉不就可以了嘛！当然bugly团队就是这样做的，但是笔者认为，替换一个classloader显然对于一个普通应用来说，成本还是太大了，而且兼容性风险也挺高的，当然，还有很多方式，比如采用Relinker这个库自定义我们加载的逻辑。
　　为了不冷饭热炒，嘿嘿，虽然我也喜欢吃炒饭（手动狗头），这里我们就不采用替换classloader的方式，而是采用跟relinker的思想，去进行加载！具体的可以看到sillyboy的实现，其实就不依赖relinker跟tinker，因为我把关键的拷贝过来了，哈哈哈，好啦，我们看下怎么实现吧！不过在此这前，我们需要了解一些前置知识。
　　5、ELF文件
　　我们的so库，本质就是一个elf文件，那么so库也符合elf文件的格式，ELF文件由4部分组成，分别是ELF头（ELFheader）、程序头表（Programheadertable）、节（Section）和节头表（Sectionheadertable）。实际上，一个文件中不一定包含全部内容，而且它们的位置也未必如同所示这样安排，只有ELF头的位置是固定的，其余各部分的位置、大小等信息由ELF头中的各项值来决定。
　　那么我们so中，如果依赖于其他的so，那么这个信息存在哪里呢！？没错，它其实也存在elf文件中，不然链接器怎么找嘛，它其实就存在。dynamic段中，所以我们只要找打dynamic段的偏移，就能到dynamic中，而被依赖的so的信息，其实就存在里面啦我们可以用readelf（ndk中就有toolchains目录后）查看，readelfdnativecpptwo。so这里的d就是查看dynamic段的意思。
　　这里面涉及到动态加载so的知识，可以推荐大家一本书，叫做程序员的自我修养链接装载与库这里就画个初略图。
　　我们再看下本质，dynamic结构体如下，定义在elf。h中。typedefstruct｛Elf32Sworddtag；union｛Elf32Addrdptr；。。。。｝｝
　　当dtag的数值为DTNEEDED的时候，就代表着依赖的共享对象文件，dptr表示所依赖的共享对象的文件名。看到这里读者们已经知道了如果我们知道了文件名，不就可以再用System。load去加载这个不就可以了嘛！不用替换classloader就能够保证被依赖的库先加载！我们可以再总结一下这个方案的原理，如图：
　　比如我们要加载so3，我们就需要先加载so2，如果so2存在依赖，那我们就先加载so1，这个时候so1就不存在依赖项了，就不需要再调用Linker去查找其他so库了。我们最终方案就是，只要能够解析对应的elf文件，然后找偏移，找到需要的目标项（DTNEED）就可以了。publicListStringparseNeededDependencies（）throwsIOException｛channel。position（0）；finalListStringdependenciesnewArrayListString（）；finalHeaderheaderparseHeader（）；finalByteBufferbufferByteBuffer。allocate（8）；buffer。order（header。bigEndian？ByteOrder。BIGENDIAN：ByteOrder。LITTLEENDIAN）；longnumProgramHeaderEntriesheader。phnum；if（numProgramHeaderEntries0xFFFF）｛ExtendedNumberingIftherealnumberofprogramheadertableentriesislargerthanorequaltoPNXNUM（0xffff），itissettoshinfofieldofthesectionheaderatindex0，andPNXNUMissettoephnumfield。Otherwise，thesectionheaderatindex0iszeroinitialized，ifitexists。finalSectionHeadersectionHeaderheader。getSectionHeader（0）；numProgramHeaderEntriessectionHeader。info；｝longdynamicSectionOff0；for（longi0；inumProgramHeaderEntries；i）｛finalProgramHeaderprogramHeaderheader。getProgramHeader（i）；if（programHeader。typeProgramHeader。PTDYNAMIC）｛dynamicSectionOffprogramHeader。offset；break；｝｝if（dynamicSectionOff0）｛Nodynamiclinkinginfo，nothingtoloadreturnCollections。unmodifiableList（dependencies）；｝inti0；finalListLongneededOffsetsnewArrayListLong（）；longvStringTableOff0；DynamicStructuredynStructure；do｛dynStructureheader。getDynamicStructure（dynamicSectionOff，i）；if（dynStructure。tagDynamicStructure。DTNEEDED）｛neededOffsets。add（dynStructure。val）；｝elseif（dynStructure。tagDynamicStructure。DTSTRTAB）｛vStringTableOffdynStructure。val；dptrunion｝i；｝while（dynStructure。tag！DynamicStructure。DTNULL）；if（vStringTableOff0）｛thrownewIllegalStateException（Stringtableoffsetnotfound！）；｝MaptofileoffsetfinallongstringTableOffoffsetFromVma（header，numProgramHeaderEntries，vStringTableOff）；for（finalLongstrOff：neededOffsets）｛dependencies。add（readString（buffer，stringTableOffstrOff））；｝returndependencies；｝
　　6、扩展
　　我们到这里，就能够解决so库的动态加载的相关问题了，那么还有人可能会问，项目中是会存在多处System。load方式的，如果加载的so还不存在怎么办？比如还在下载当中，其实很简单，这个时候我们字节码插桩就派上用场了，只要我们把System。load替换为我们自定义的加载so逻辑，进行一定的逻辑处理就可以了，嘿嘿，因为笔者之前就有写一个字节码插桩的库的介绍，所以在本次就不重复了，可以看Sipder，同时也可以用其他的字节码插桩框架实现，相信这不是一个问题。
　　https：github。comTestPlanBSpider总结
　　看到这里的读者，相信也能够明白动态加载so的步骤了，最后源代码可以在SillyBoy，当然也希望各位点赞呀！当然，有更好的实现也欢迎评论！！
　　https：github。comTestPlanBSillyBoy