最新国产好看的视频,伊人天堂AV在线,国产Aaaaaa视频,蜜臀视频在线观看一区,人妻av色图,密臀久久久精品影片,青青视频免费观看毛片,久草在线观看视,国产三级精品色情在线

Android?動態(tài)加載?so實現(xiàn)示例詳解

 更新時間:2022年09月02日 17:00:21   作者:Android社區(qū)  
這篇文章主要為大家介紹了Android?動態(tài)加載?so實現(xiàn)示例詳解,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進步,早日升職加薪

背景

對于一個普通的android應用來說,so庫的占比通常都是巨高不下的,因為我們無可避免的在開發(fā)中遇到各種各樣需要用到native的需求,所以so庫的動態(tài)化可以減少極大的包體積,自從2020騰訊的bugly團隊發(fā)部關于動態(tài)化so的相關文章后,已經(jīng)過去兩年了,相關文章,經(jīng)過兩年的考驗,實際上so動態(tài)加載也是非常成熟的一項技術了。

但是很遺憾,許多公司都還沒有這方面的涉略又或者說不知道從哪里開始進行,因為so動態(tài)其實涉及到下載,so版本管理,動態(tài)加載實現(xiàn)等多方面,我們不妨拋開這些額外的東西,從最本質(zhì)的so動態(tài)加載出發(fā)吧!這里是本次的例子,我把它命名為sillyboy,歡迎pr還有后續(xù)點贊呀!

so動態(tài)加載介紹

動態(tài)加載,其實就是把我們的so庫在打包成apk的時候剔除,在合適的時候通過網(wǎng)絡包下載的方式,通過一些手段,在運行的時候進行分離加載的過程。

這里涉及到下載器,還有下載后的版本管理等等確保一個so庫被正確的加載等過程,在這里,我們不討論這些輔助的流程,我們看下怎么實現(xiàn)一個最簡單的加載流程。

從一個例子出發(fā)

我們構建一個native工程,然后在里面編入如下內(nèi)容,下面是cmake

# For more information about using CMake with Android Studio, read the
# documentation: https://d.android.com/studio/projects/add-native-code.html
# Sets the minimum version of CMake required to build the native library.
cmake_minimum_required(VERSION 3.18.1)
# Declares and names the project.
project("nativecpp")
# Creates and names a library, sets it as either STATIC
# or SHARED, and provides the relative paths to its source code.
# You can define multiple libraries, and CMake builds them for you.
# Gradle automatically packages shared libraries with your APK.
add_library( # Sets the name of the library.
        nativecpp
        # Sets the library as a shared library.
        SHARED
        # Provides a relative path to your source file(s).
        native-lib.cpp)
add_library(
        nativecpptwo
        SHARED
        test.cpp
)
# Searches for a specified prebuilt library and stores the path as a
# variable. Because CMake includes system libraries in the search path by
# default, you only need to specify the name of the public NDK library
# you want to add. CMake verifies that the library exists before
# completing its build.
find_libHrary( # Sets the name of the path variable.
        log-lib
        # Specifies the name of the NDK library that
        # you want CMake to locate.
        log)
# Specifies libraries CMake should link to your target library. You
# can link multiple libraries, such as libraries you define in this
# build script, prebuilt third-party libraries, or system libraries.
target_link_libraries( # Specifies the target library.
        nativecpp
        # Links the target library to the log library
        # included in the NDK.
        ${log-lib})
target_link_libraries( # Specifies the target library.
        nativecpptwo
        # Links the target library to the log library
        # included in the NDK.
        nativecpp
        ${log-lib})

可以看到,我們生成了兩個so庫一個是nativecpp,還有一個是nativecpptwo(為什么要兩個呢?我們可以繼續(xù)看下文) 這里也給出最關鍵的test.cpp代碼

#include <jni.h>
#include <string>
#include<android/log.h>
extern "C"
JNIEXPORT void JNICALL
Java_com_example_nativecpp_MainActivity_clickTest(JNIEnv *env, jobject thiz) {
    // 在這里打印一句話
    __android_log_print(ANDROID_LOG_INFO,"hello"," native 層方法");
}

很簡單,就一個native方法,打印一個log即可,我們就可以在java/kotin層進行方法調(diào)用了,即

public native void clickTest();

so庫檢索與刪除

要實現(xiàn)so的動態(tài)加載,那最起碼是要知道本項目過程中涉及到哪些so吧!不用擔心,我們gradle構建的時候,就已經(jīng)提供了相應的構建過程,即構建的task【 mergeDebugNativeLibs】,在這個過程中,會把一個project里面的所有native庫進行一個收集的過程,緊接著task【stripDebugDebugSymbols】是一個符號表清除過程,如果了解native開發(fā)的朋友很容易就知道,這就是一個減少so體積的一個過程,我們不在這里詳述。

所以我們很容易想到,我們只要在這兩個task中插入一個自定義的task,用于遍歷和刪除就可以實現(xiàn)so的刪除化了,所以就很容易寫出這樣的代碼

ext {
    deleteSoName = ["libnativecpptwo.so","libnativecpp.so"]
}
// 這個是初始化 -配置 -執(zhí)行階段中,配置階段執(zhí)行的任務之一,完成afterEvaluate就可以得到所有的tasks,從而可以在里面插入我們定制化的數(shù)據(jù)
task(dynamicSo) {
}.doLast {
    println("dynamicSo insert!!!! ")
    //projectDir 在哪個project下面,projectDir就是哪個路徑
    print(getRootProject().findAll())
    def file = new File("${projectDir}/build/intermediates/merged_native_libs/debug/out/lib")
    //默認刪除所有的so庫
    if (file.exists()) {
        file.listFiles().each {
            if (it.isDirectory()) {
                it.listFiles().each {
                    target ->
                        print("file ${target.name}")
                        def compareName = target.name
                        deleteSoName.each {
                            if (compareName.contains(it)) {
                                target.delete()
                            }
                        }
                }
            }
        }
    } else {
        print("nil")
    }
}
afterEvaluate {
    print("dynamicSo task start")
    def customer = tasks.findByName("dynamicSo")
    def merge = tasks.findByName("mergeDebugNativeLibs")
    def strip = tasks.findByName("stripDebugDebugSymbols")
    if (merge != null || strip != null) {
        customer.mustRunAfter(merge)
        strip.dependsOn(customer)
    }
}

可以看到,我們定義了一個自定義task dynamicSo,它的執(zhí)行是在afterEvaluate中定義的,并且依賴于mergeDebugNativeLibs,而stripDebugDebugSymbols就依賴于我們生成的dynamicSo,達到了一個插入操作。

那么為什么要在afterEvaluate中執(zhí)行呢?那是因為android插件是在配置階段中才生成的mergeDebugNativeLibs等任務,原本的gradle構建是不存在這樣一個任務的,所以我們才需要在配置完所有task之后,才進行的插入,我們可以看一下gradle的生命周期

通過對條件檢索,我們就刪除掉了我們想要的so,即ibnativecpptwo.so與libnativecpp.so。

動態(tài)加載so

根據(jù)上文檢索出來的兩個so,我們就可以在項目中上傳到自己的后端中,然后通過網(wǎng)絡下載到用戶的手機上,這里我們就演示一下即可,我們就直接放在data目錄下面吧

真實的項目過程中,應該要有校驗操作,比如md5校驗或者可以解壓等等操作,這里不是重點,我們就直接略過啦!

那么,怎么把一個so庫加載到我們本來的apk中呢?這里是so原本的加載過程,可以看到,系統(tǒng)是通過classloader檢索native目錄是否存在so庫進行加載的,那我們反射一下,把我們自定義的path加入進行不就可以了嗎?這里采用tinker一樣的思路,在我們的classloader中加入so的檢索路徑即可,比如

private static final class V25 {
    private static void install(ClassLoader classLoader, File folder)  throws Throwable {
        final Field pathListField = ShareReflectUtil.findField(classLoader, "pathList");
        final Object dexPathList = pathListField.get(classLoader);
        final Field nativeLibraryDirectories = ShareReflectUtil.findField(dexPathList, "nativeLibraryDirectories");
        List<File> origLibDirs = (List<File>) nativeLibraryDirectories.get(dexPathList);
        if (origLibDirs == null) {
            origLibDirs = new ArrayList<>(2);
        }
        final Iterator<File> libDirIt = origLibDirs.iterator();
        while (libDirIt.hasNext()) {
            final File libDir = libDirIt.next();
            if (folder.equals(libDir)) {
                libDirIt.remove();
                break;
            }
        }
        origLibDirs.add(0, folder);
        final Field systemNativeLibraryDirectories = ShareReflectUtil.findField(dexPathList, "systemNativeLibraryDirectories");
        List<File> origSystemLibDirs = (List<File>) systemNativeLibraryDirectories.get(dexPathList);
        if (origSystemLibDirs == null) {
            origSystemLibDirs = new ArrayList<>(2);
        }
        final List<File> newLibDirs = new ArrayList<>(origLibDirs.size() + origSystemLibDirs.size() + 1);
        newLibDirs.addAll(origLibDirs);
        newLibDirs.addAll(origSystemLibDirs);
        final Method makeElements = ShareReflectUtil.findMethod(dexPathList, "makePathElements", List.class);
        final Object[] elements = (Object[]) makeElements.invoke(dexPathList, newLibDirs);
        final Field nativeLibraryPathElements = ShareReflectUtil.findField(dexPathList, "nativeLibraryPathElements");
        nativeLibraryPathElements.set(dexPathList, elements);
    }
}

我們在原本的檢索路徑中,在最前面,即數(shù)組為0的位置加入了我們的檢索路徑,這樣一來classloader在查找我們已經(jīng)動態(tài)化的so庫的時候,就能夠找到!

結束了嗎?

一般的so庫,比如不依賴其他的so的時候,直接這樣加載就沒問題了,但是如果存在著依賴的so庫的話,就不行了!相信大家在看其他的博客的時候就能看到,是因為Namespace的問題。具體是我們動態(tài)庫加載的過程中,如果需要依賴其他的動態(tài)庫,那么就需要一個鏈接的過程對吧!

這里的實現(xiàn)就是Linker,Linker 里檢索的路徑在創(chuàng)建 ClassLoader 實例后就被系統(tǒng)通過 Namespace 機制綁定了,當我們注入新的路徑之后,雖然 ClassLoader 里的路徑增加了,但是 Linker 里 Namespace 已經(jīng)綁定的路徑集合并沒有同步更新,所以出現(xiàn)了 libxxx.so 文件(當前的so)能找到,而依賴的so 找不到的情況。bugly文章

很多實現(xiàn)都采用了Tinker的實現(xiàn),既然我們系統(tǒng)的classloader是這樣,那么我們在合適的時候把這個替換掉不就可以了嘛!當然bugly團隊就是這樣做的,但是筆者認為,替換一個classloader顯然對于一個普通應用來說,成本還是太大了,而且兼容性風險也挺高的,當然,還有很多方式,比如采用Relinker這個庫自定義我們加載的邏輯。

為了不冷飯熱炒,嘿嘿,雖然我也喜歡吃炒飯(手動狗頭),這里我們就不采用替換classloader的方式,而是采用跟relinker的思想,去進行加載!

具體的可以看到sillyboy的實現(xiàn),其實就不依賴relinker跟tinker,因為我把關鍵的拷貝過來了,哈哈哈,好啦,我們看下怎么實現(xiàn)吧!不過在此這前,我們需要了解一些前置知識

ELF文件

我們的so庫,本質(zhì)就是一個elf文件,那么so庫也符合elf文件的格式,ELF文件由4部分組成,分別是ELF頭(ELF header)、程序頭表(Program header table)、節(jié)(Section)和節(jié)頭表(Section header table)。

實際上,一個文件中不一定包含全部內(nèi)容,而且它們的位置也未必如同所示這樣安排,只有ELF頭的位置是固定的,其余各部分的位置、大小等信息由ELF頭中的各項值來決定。

那么我們so中,如果依賴于其他的so,那么這個信息存在哪里呢???沒錯,它其實也存在elf文件中,不然鏈接器怎么找嘛,它其實就存在.dynamic段中,所以我們只要找打dynamic段的偏移,就能到dynamic中,而被依賴的so的信息,其實就存在里面啦 我們可以用readelf(ndk中就有toolchains目錄后) 查看,readelf -d nativecpptwo.so 這里的 -d 就是查看dynamic段的意思

這里面涉及到動態(tài)加載so的知識,可以推薦大家一本書,叫做程序員的自我修養(yǎng)-鏈接裝載與庫這里就畫個初略圖

我們再看下本質(zhì),dynamic結構體如下,定義在elf.h中

typedef struct{
Elf32_Sword d_tag;
union{
Elf32_Addr d_ptr;
....
}
}

當d_tag的數(shù)值為DT_NEEDED的時候,就代表著依賴的共享對象文件,d_ptr表示所依賴的共享對象的文件名??吹竭@里讀者們已經(jīng)知道了,如果我們知道了文件名,不就可以再用System.loadLibrary去加載這個文件名確定的so了嘛!不用替換classloader就能夠保證被依賴的庫先加載!我們可以再總結一下這個方案的原理,如圖

比如我們要加載so3,我們就需要先加載so2,如果so2存在依賴,那我們就調(diào)用System.loadLibrary先加載so1,這個時候so1就不存在依賴項了,就不需要再調(diào)用Linker去查找其他so庫了。我們最終方案就是,只要能夠解析對應的elf文件,然后找偏移,找到需要的目標項(DT_NEED)所對應的數(shù)值(即被依賴的so文件名)就可以了

public List<String> parseNeededDependencies() throws IOException {
    channel.position(0);
    final List<String> dependencies = new ArrayList<String>();
    final Header header = parseHeader();
    final ByteBuffer buffer = ByteBuffer.allocate(8);
    buffer.order(header.bigEndian ? ByteOrder.BIG_ENDIAN : ByteOrder.LITTLE_ENDIAN);
    long numProgramHeaderEntries = header.phnum;
    if (numProgramHeaderEntries == 0xFFFF) {
        /**
         * Extended Numbering
         *
         * If the real number of program header table entries is larger than
         * or equal to PN_XNUM(0xffff), it is set to sh_info field of the
         * section header at index 0, and PN_XNUM is set to e_phnum
         * field. Otherwise, the section header at index 0 is zero
         * initialized, if it exists.
         **/
        final SectionHeader sectionHeader = header.getSectionHeader(0);
        numProgramHeaderEntries = sectionHeader.info;
    }
    long dynamicSectionOff = 0;
    for (long i = 0; i < numProgramHeaderEntries; ++i) {
        final ProgramHeader programHeader = header.getProgramHeader(i);
        if (programHeader.type == ProgramHeader.PT_DYNAMIC) {
            dynamicSectionOff = programHeader.offset;
            break;
        }
    }
    if (dynamicSectionOff == 0) {
        // No dynamic linking info, nothing to load
        return Collections.unmodifiableList(dependencies);
    }
    int i = 0;
    final List<Long> neededOffsets = new ArrayList<Long>();
    long vStringTableOff = 0;
    DynamicStructure dynStructure;
    do {
        dynStructure = header.getDynamicStructure(dynamicSectionOff, i);
        if (dynStructure.tag == DynamicStructure.DT_NEEDED) {
            neededOffsets.add(dynStructure.val);
        } else if (dynStructure.tag == DynamicStructure.DT_STRTAB) {
            vStringTableOff = dynStructure.val; // d_ptr union
        }
        ++i;
    } while (dynStructure.tag != DynamicStructure.DT_NULL);
    if (vStringTableOff == 0) {
        throw new IllegalStateException("String table offset not found!");
    }
    // Map to file offset
    final long stringTableOff = offsetFromVma(header, numProgramHeaderEntries, vStringTableOff);
    for (final Long strOff : neededOffsets) {
        dependencies.add(readString(buffer, stringTableOff + strOff));
    }
    return dependencies;
}

擴展

我們到這里,就能夠解決so庫的動態(tài)加載的相關問題了,那么還有人可能會問,項目中是會存在多處System.load方式的,如果加載的so還不存在怎么辦?

比如還在下載當中,其實很簡單,這個時候我們字節(jié)碼插樁就派上用場了,只要我們把System.load替換為我們自定義的加載so邏輯,進行一定的邏輯處理就可以了,嘿嘿,因為筆者之前就有寫一個字節(jié)碼插樁的庫的介紹,所以在本次就不重復了,可以看 https://github.com/TestPlanB/Spider ,同時也可以用其他的字節(jié)碼插樁框架實現(xiàn),相信這不是一個問題。

總結

看到這里的讀者,相信也能夠明白動態(tài)加載so的步驟了

源代碼 https://github.com/TestPlanB/SillyBoy

以上就是Android 動態(tài)加載 so實現(xiàn)示例詳解的詳細內(nèi)容,更多關于Android 動態(tài)加載 so的資料請關注腳本之家其它相關文章!

相關文章

  • Android中GIF動圖的播放控制和監(jiān)聽詳解

    Android中GIF動圖的播放控制和監(jiān)聽詳解

    android下播放gif圖片功能似乎并不常用,很多時候還是以展示靜態(tài)圖片為主,可能是由于gif圖體積比較大吧。不過像表情動畫什么的,可能還是需要gif圖的。本文主要給大家介紹了關于Android中GIF動圖的播放控制和監(jiān)聽的相關資料,需要的朋友可以參考下。
    2017-05-05
  • Android自定義view仿QQ的Tab按鈕動畫效果(示例代碼)

    Android自定義view仿QQ的Tab按鈕動畫效果(示例代碼)

    這篇文章主要介紹了Android自定義view仿QQ的Tab按鈕動畫效果(示例代碼),本文給大家介紹的非常詳細,對大家的學習或工作具有一定的參考價值,需要的朋友可以參考下
    2021-01-01
  • Android中刪除Preference詳解

    Android中刪除Preference詳解

    這篇文章主要介紹了Android中刪除Preference詳解,很多時候刪除Preference總會失敗,本文著重分析刪除失敗的原因,需要的朋友可以參考下
    2015-01-01
  • 詳解Android沉浸式實現(xiàn)兼容解決辦法

    詳解Android沉浸式實現(xiàn)兼容解決辦法

    本篇文章主要介紹了詳解Android沉浸式實現(xiàn)兼容解決辦法,小編覺得挺不錯的,現(xiàn)在分享給大家,也給大家做個參考。一起跟隨小編過來看看吧
    2017-11-11
  • Android wifi 調(diào)試詳解及簡單實例

    Android wifi 調(diào)試詳解及簡單實例

    這篇文章主要介紹了Android wifi 調(diào)試詳解及簡單實例的相關資料,需要的朋友可以參考下
    2017-02-02
  • Android使用ViewPager實現(xiàn)自動輪播

    Android使用ViewPager實現(xiàn)自動輪播

    這篇文章主要介紹了Android使用ViewPager實現(xiàn)自動輪播的相關資料,具有一定的參考價值,感興趣的小伙伴們可以參考一下
    2016-07-07
  • Android同時安裝Release和Debug版本的方法

    Android同時安裝Release和Debug版本的方法

    這篇文章主要介紹了Android同時安裝Release和Debug版本的方法,小編覺得挺不錯的,現(xiàn)在分享給大家,也給大家做個參考。一起跟隨小編過來看看吧
    2018-12-12
  • Android第三方開源下拉框NiceSpinner使用詳解

    Android第三方開源下拉框NiceSpinner使用詳解

    這篇文章主要為大家詳細介紹了Android第三方開源下拉框NiceSpinner的使用方法,具有一定的參考價值,感興趣的小伙伴們可以參考一下
    2017-07-07
  • 理解Android硬件加速原理(小白文)

    理解Android硬件加速原理(小白文)

    這篇文章主要介紹了理解Android硬件加速原理(小白文),詳細的介紹了硬件加速的概念和原理,具有一定的參考價值,感興趣的小伙伴們可以參考一下
    2018-07-07
  • 記錄Android微信分享功能的吐槽與思考

    記錄Android微信分享功能的吐槽與思考

    Android 記錄一次開發(fā)微信分享功能的吐槽與思考,感興趣的小伙伴們可以參考一下
    2016-07-07

最新評論

积石山| 巴彦淖尔市| 广南县| 濉溪县| 云梦县| 尖扎县| 交口县| 门源| 长白| 遂溪县| 名山县| 鲁甸县| 南乐县| 海林市| 女性| 洛浦县| 榆中县| 安康市| 祁东县| 大荔县| 克山县| 吉安县| 罗江县| 囊谦县| 南投市| 张家口市| 新泰市| 格尔木市| 达尔| 临泽县| 丘北县| 五指山市| 四会市| 漠河县| 宁安市| 成安县| 镇康县| 柘荣县| 兰坪| 瓮安县| 吉安市|