vlc-for-android的DNK開發簡介

對於VLC-Android的JNI設計，我們從java層開始，一步步分析。

                                                                           libvlc.java文件解讀

libvlc.java解讀（libvlc\src\org\videolan\libvlc\libvlc.java）

一、對java暴露的接口類是LibVLC：

通過它，我們創建一個播放器實例。
public class LibVLC extends VLCObject

libvlc jni static library

include (CLEAR_VARS)  
LOCAL_MODULE    := vlcjni_static  
LOCAL_SRC_FILES := libvlcjni.c  
LOCAL_SRC_FILES += libvlcjni-mediaplayer.c  
LOCAL_SRC_FILES += libvlcjni-vlcobject.c  
LOCAL_SRC_FILES += libvlcjni-media.c libvlcjni-medialist.c libvlcjni-mediadiscoverer.c  
LOCAL_SRC_FILES += libvlcjni-dialog.c  
LOCAL_SRC_FILES += thumbnailer.c  
LOCAL_SRC_FILES += std_logger.c  
LOCAL_C_INCLUDES := (VLC_SRC_DIR)/include (MEDIALIBRARYJNIDIR) (LOCAL_PATH)/loader
LOCAL_CFLAGS := -std=c11
include $(BUILD_STATIC_LIBRARY)

libvlc dynamic library

include (CLEARVARS)LOCALMODULE:=vlcjniLOCALSRCFILES:=libvlcjni−modules.clibvlcjni−symbols.cLOCALLDFLAGS:=−L (VLC_CONTRIB)/lib
LOCAL_LDLIBS := \
(VLCMODULES)  (VLC_BUILD_DIR)/lib/.libs/libvlc.a \
(VLCBUILDDIR)/src/.libs/libvlccore.a  (VLC_BUILD_DIR)/compat/.libs/libcompat.a \
(VLCCONTRIBLDFLAGS) −ldl−lz−lm−llog −lliveMedia−lUsageEnvironment−lBasicUsageEnvironment−lgroupsock −la52−ljpeg −lavcodec−lebml −llua −lgcrypt−lgpg−error  (MEDIALIBRARY_LDLIBS) \
(VLCLDFLAGS) −llogLOCALWHOLESTATICLIBRARIES:=libvlcjnistaticifeq( (BUILD_ML), 1)
LOCAL_WHOLE_STATIC_LIBRARIES += libmla
endif
include (BUILDSHAREDLIBRARY)ifeq( (BUILD_ML), 1)
JNILOADER_INCLUDES := (LOCALPATH)/loader (call import-add-path, (MEDIALIBRARYJNIDIR)) (call import-module, .)
endif
二、解析內容：

1、它編譯兩個庫，靜態庫和動態庫。靜態庫對應的名字是vlcjni_static動態庫對應的名字是vlcjni，同時我們知道動態會使用編譯好的靜態庫。我 們上面使用的是動態庫。
2、動態庫編譯的源文件是：libvlcjni-modules.c libvlcjni-symbols.c
3、傳遞給動態庫編譯器的額外參數：LOCAL_LDFLAGS := -L(VLCCONTRIB)/lib4、編譯過程中需要編譯好的靜態庫和下面的第三方庫：LOCALLDLIBS:=  (VLC_MODULES) \
(VLCBUILDDIR)/lib/.libs/libvlc.a  (VLC_BUILD_DIR)/src/.libs/libvlccore.a \
(VLCBUILDDIR)/compat/.libs/libcompat.a  (VLC_CONTRIB_LDFLAGS) \
-ldl -lz -lm -llog \
-lliveMedia -lUsageEnvironment -lBasicUsageEnvironment -lgroupsock \
-la52 -ljpeg \
-lavcodec -lebml \
-llua \
-lgcrypt -lgpg-error \
(MEDIALIBRARYLDLIBS)  (VLC_LDFLAGS) \
-llog
libvlcjni.c文件解讀

libvlcjin.c文件解讀(libvlc\jni\ilbvlcjin.c)

一、通過源碼可以知道，它是採用靜態註冊方法：由虛擬機完成兩者的匹配。例如：java層調用String version()方法時，它會自動到jni庫中尋找jstring Java_org_videolan_libvlc_LibVLC_version()函數，如果找到，則爲這兩個函數建立關聯關係，以後調用String version()時直接找建立好關係的JNI層對應的函數指針即可。

二、在jstring Java_org_videolan_libvlc_LibVLC_version()中調用函數libvlc_get_version()，libvlc_get_version()函數是在vlc\lib\core.c中定義。

jstring Java_org_videolan_libvlc_LibVLC_version(JNIEnv* env, jobject thiz)
{
return (*env)->NewStringUTF(env, libvlc_get_version());
}
三、通過上面的分析可以知道，ndk層的關係簡單的理解：在libvlcjin.c中封裝需要的功能函數，在libvlc.java中定義本地方法和對本地方法的封裝。
四、源碼分析
源碼主題結構如下：
/* 當一個附屬於java虛擬機的線程取消或者退出時，會調用這個函數*/
static void jni_detach_thread(void *data)
給外部模塊獲取環境變量函數
JNIEnv *jni_get_env(const char *name)
給本庫加載java層類的屬性和方法ID。
int VLCJNI_OnLoad(JavaVM vm, JNIEnv env)
void VLCJNI_OnUnload(JavaVM *vm, JNIEnv *env)
一下是libvlc.java對應的本地方法：
void Java_org_videolan_libvlc_LibVLC_nativeNew(JNIEnv *env, jobject thiz,jobjectArray jstringArray,jstring jhomePath)
void Java_org_videolan_libvlc_LibVLC_nativeRelease(JNIEnv *env, jobject thiz)
jstring Java_org_videolan_libvlc_LibVLC_version(JNIEnv* env, jobject thiz)
jstring Java_org_videolan_libvlc_LibVLC_compiler(JNIEnv* env, jobject thiz)
jstring Java_org_videolan_libvlc_LibVLC_changeset(JNIEnv* env, jobject thiz)
void Java_org_videolan_libvlc_LibVLC_nativeSetUserAgent(JNIEnv* env,jobject thiz,jstring jname,jstring jhttp)

五、VLCJNI_OnLoad函數分析:
int VLCJNI_OnLoad(JavaVM vm, JNIEnv env)
{
myVm = vm;
/* Create a TSD area and setup a destroy callback when a thread that
* previously set the jni_env_key is canceled or exited */
創建一個TSD內存區並在一個線程取消或退出時設置jni_env_key回調預先設置。
因爲vlc是一個多線程的播放器，這是初始化線程的傳遞數據的方法
if (pthread_key_create(&jni_env_key, jni_detach_thread) != 0)
return -1;
jclass Version_clazz;
jfieldID SDK_INT_fieldID;
各種GET_CLASS、GET_ID調用，主要是引用各個模塊
GET_CLASS(Version_clazz, “android/os/Build$VERSION”, false);
GET_ID(GetStaticFieldID, SDK_INT_fieldID, Version_clazz, “SDK_INT”, “I”);
fields.SDK_INT = (*env)->GetStaticIntField(env, Version_clazz,
SDK_INT_fieldID);
return 0;
}
看他對應的卸載函數VLCJNI_OnUnload主要是釋放引用*env)->DeleteGlobalRef(env, fields.IllegalStateException.clazz);
知道VLCJNI_OnLoad函數主要功能就是加載引用。

我們跟蹤動態庫的源文件libvlcjni-modules.c libvlcjni-symbols.c，
打開兩個文件會發現，這個C文件是一些函數指針，指向執行函數：vlc_static_modules函數指針數組包含的加載模塊的入口函數。libvlc_functions函數指針數組包含的是各模塊的功能函數。
int vlc_entry__packetizer_h264 (int ()(void , void , int, …), void );
…………………………
…………………………
const void *vlc_static_modules[] = {
vlc_entry__packetizer_h264,
……………
}
下是libvlcjni-symbols.c文件
int libvlc_add_intf(void);
………….
const void *libvlc_functions[] = {
libvlc_errmsg,
…….
}
小結一下

上面的分析，我們知道java層定義本地方法後調用動態庫。虛擬機自動調用jni_onload函數，此時java層調用的

System.loadLibrary(“vlcjni”);
加載vlcjni動態庫中的jni_onload函數，
java層調用
System.loadLibrary(“jniloader”);

應該加載jniloader動態庫的jni_onload函數。

現在我們知道了，vlcjni.so庫對應的是沒有jni_onload函數的。調用vlcjni.so庫時會直接調用到源碼vlc\src\android.c內定義的jni_onload函數的。java層的環境變量是通過封裝的庫jniloader.so傳遞過去的。

回頭看java層，我們發現源文件目錄下有許多的類：

其中只有LibVLC調用了System.loadLibrary()；其它的類中只有native方法卻沒有System.loadLibrary()。其它類的屬性和方法是通過庫jniloader.so調用jni_onload中加載庫vlcjni.so中的VLCJNI_OnLoad函數和MediaLibraryJNI_OnLoad函數，將我們獲取到類的屬性和方法ID保存在全局變量結構體fields中。

我們知道VLC播放器必須要一個實例做爲句柄，所有的操作都是圍繞這個實例。我們可以看到在jni\libvlcjni.c中的對應的本地方法：
void Java_org_videolan_libvlc_LibVLC_nativeNew(JNIEnv *env, jobject thiz,
jobjectArray jstringArray,
jstring jhomePath)
{
vlcjni_object *p_obj = NULL;
libvlc_instance_t *p_libvlc = NULL;
jstring *strings = NULL;
const char **argv = NULL;
int argc = 0;
忽略部分解析參數

創建一個播放器實例
p_libvlc = libvlc_new(argc, argv);
創建一個vlcobject，這個用於java層封裝vlc播放器，在各個模塊功能中傳遞播放器實例
p_obj = VLCJniObject_newFromLibVlc(env, thiz, NULL);

將新建的播放器實例保存在vlcobject中
p_obj->u.p_libvlc = p_libvlc;

}
現在我們編寫ndk的主要步驟已經清楚：
1、在java層定義自己需要的類和本地方法。
2、我們定義的類和方法對應的C語言編寫在libvlc\Jni下，則在此目錄下的Utils.h的fields中定義結構保存類的屬性和方法ID。
(括號內是在其它庫中的操作方法思路與此相同，下面步驟中不在同樣的如果定義的類和方法對應的C語言編寫在對應的medialibrary\jni\目錄下，則在此目錄下的medialibrary\jni\Utils.h中定義結構體保存類的屬性和本地方法ID。)
我們也可以定義自己的庫來管理VLC內核。不過此時需要在java層來加載庫。
3、我們在libvlc\jni\libvlcjni.c中的VLCJNI_OnLoad函數中添加類的屬性和本地方法ID。
4、做好上面的準備工作之後就可以編寫自己的C語言庫函數。比如定義爲libvlcjni-hello.c
5、在libvlcjni-hello.c中的編寫方法如下：
a、定義自己需要的數據結構。
b、通過VLCJniObject_getInstance（）函數回調java層中的vlcjni_object。
c、如此我們便可以操作java層定義的播放器實例了。可以調用vlc封裝好的函數，也可以是自己封裝的函數。

上面說的是比較大的改動，如果我們僅僅需要某些方法即可，則可以把本地方法封裝在java層對應的類中，在對應的Utils.h中fields變量中添加此類對應的方法ID變量。如果僅僅定義一個不在其它類中，也可以在libvlc\jni\libvlcjni.c中定義對應的函數。
6、如果我們編寫的程序新增源文件也需要在Android.mk中添加相應源文件。

按照上述方法編寫程序後，我們重新編譯即可。當然我們修改的比較深入，比如我們需要填一個全新的模塊時，編寫模塊和添加到庫中的方法見下一篇文章。

    附錄方法

Android.mk語法：
轉載：https://www.cnblogs.com/wainiwann/p/3837936.html
0. Android.mk簡介：
Android.mk文件用來告知NDK Build 系統關於Source的信息。 Android.mk將是GNU Makefile的一部分，且將被Build System解析一次或多次。
所以，請儘量少的在Android.mk中聲明變量，也不要假定任何東西不會在解析過程中定義。
Android.mk文件語法允許我們將Source打包成一個”modules”. modules可以是：
靜態庫
動態庫。
只有動態庫可以被 install/copy到應用程序包(APK). 靜態庫則可以被鏈接入動態庫。
可以在一個Android.mk中定義一個或多個modules. 也可以將同一份source 加進多個modules.
Build System幫我們處理了很多細節而不需要我們再關心。例如：你不需要在Android.mk中列出頭文件和外部依賴文件。
NDK Build System自動幫我們提供這些信息。這也意味着，當用戶升級NDK後，你將可以受益於新的toolchain/platform而不必再去修改Android.mk.
1. Android.mk語法：
首先看一個最簡單的Android.mk的例子：
LOCAL_PATH := $(call my-dir)

include $(CLEAR_VARS)

LOCAL_MODULE := hello-jni
LOCAL_SRC_FILES := hello-jni.c

include (BUILDSHAREDLIBRARY)講解如下：LOCALPATH:= (call my-dir)
每個Android.mk文件必須以定義LOCAL_PATH爲開始。它用於在開發tree中查找源文件。
宏my-dir 則由Build System提供。返回包含Android.mk的目錄路徑。
include (CLEARVARS)CLEARVARS變量由BuildSystem提供。並指向一個指定的GNUMakefile，由它負責清理很多LOCALxxx.例如：LOCALMODULE,LOCALSRCFILES,LOCALSTATICLIBRARIES等等。但不清理LOCALPATH.這個清理動作是必須的，因爲所有的編譯控制文件由同一個GNUMake解析和執行，其變量是全局的。所以清理後才能避免相互影響。LOCALMODULE:=hello−jniLOCALMODULE模塊必須定義，以表示Android.mk中的每一個模塊。名字必須唯一且不包含空格。BuildSystem會自動添加適當的前綴和後綴。例如，foo，要產生動態庫，則生成libfoo.so.但請注意：如果模塊名被定爲：libfoo.則生成libfoo.so.不再加前綴。LOCALSRCFILES:=hello−jni.cLOCALSRCFILES變量必須包含將要打包如模塊的C/C++源碼。不必列出頭文件，buildSystem會自動幫我們找出依賴文件。缺省的C++源碼的擴展名爲.cpp.也可以修改，通過LOCALCPPEXTENSION。include (BUILD_SHARED_LIBRARY)
BUILD_SHARED_LIBRARY：是Build System提供的一個變量，指向一個GNU Makefile Script。
它負責收集自從上次調用 include $(CLEAR_VARS) 後的所有LOCAL_XXX信息。並決定編譯爲什麼。

BUILD_STATIC_LIBRARY：編譯爲靜態庫。
BUILD_SHARED_LIBRARY ：編譯爲動態庫
BUILD_EXECUTABLE：編譯爲Native C可執行程序

1. NDK Build System變量：
   NDK Build System 保留以下變量名：
   以LOCAL_ 爲開頭的
   以PRIVATE_ ,NDK_ 或者APP_ 開頭的名字。
   小寫字母名字：如my-dir
   如果想要定義自己在Android.mk中使用的變量名，建議添加 ＭＹ＿　前綴。
   2.1: NDK提供的變量：
   此類GNU Make變量是NDK Build System在解析Android.mk之前就定義好了的。
   2.1.1：CLEAR_VARS：
   指向一個編譯腳本。必須在新模塊前包含之。
   include (CLEARVARS)2.1.2：BUILDSHAREDLIBRARY：指向一個編譯腳本，它收集自從上次調用include (CLEAR_VARS) 後的所有LOCAL_XXX信息。
   並決定如何將你列出的Source編譯成一個動態庫。 注意，在包含此文件前，至少應該包含：LOCAL_MODULE and LOCAL_SRC_FILES 例如：
   include (BUILDSHAREDLIBRARY)2.1.3：BUILDSTATICLIBRARY：與前面類似，它也指向一個編譯腳本，收集自從上次調用include (CLEAR_VARS) 後的所有LOCAL_XXX信息。
   並決定如何將你列出的Source編譯成一個靜態庫。 靜態庫不能夠加入到Project 或者APK中。但它可以用來生成動態庫。
   LOCAL_STATIC_LIBRARIES and LOCAL_WHOLE_STATIC_LIBRARIES將描述之。
   include (BUILDSTATICLIBRARY)2.1.4:BUILDEXECUTABLE:與前面類似，它也指向一個編譯腳本，收集自從上次調用include (CLEAR_VARS) 後的所有LOCAL_XXX信息。
   並決定如何將你列出的Source編譯成一個可執行Native程序。
   include (BUILDEXECUTABLE)2.1.5：PREBUILTSHAREDLIBRARY：把這個共享庫聲明爲“一個”獨立的模塊。指向一個build腳本，用來指定一個預先編譯好多動態庫。與BUILDSHAREDLIBRARYandBUILDSTATICLIBRARY不同，此時模塊的LOCALSRCFILES應該被指定爲一個預先編譯好的動態庫，而非sourcefile.LOCALPATH:= (call my-dir)

include $(CLEAR_VARS)
LOCAL_MODULE := foo-prebuilt # 模塊名
LOCAL_SRC_FILES := libfoo.so # 模塊的文件路徑（相對於 LOCAL_PATH）

include (PREBUILT_SHARED_LIBRARY) # 注意這裏不是 BUILD_SHARED_LIBRARY  
這個共享庫將被拷貝到 PROJECT/obj/local 和 $PROJECT/libs/ (stripped) 主要是用在將已經編譯好的第三方庫
使用在本Android Project中。爲什麼不直接將其COPY到libs/armabi目錄呢？因爲這樣做缺陷很多。下一節再詳細說明。
2.1.6: PREBUILT_STATIC_LIBRARY: 預先編譯的靜態庫。 同上。
2.1.7: TARGET_ARCH: 目標ＣＰＵ架構名。如果爲　“arm” 則聲稱ARM兼容的指令。與CPU架構版本無關。
2.1.8: TARGET_PLATFORM: 目標平臺的名字。
2.1.9：TARGET_ARCH_ABI
Name of the target CPU+ABI
armeabi For ARMv5TE armeabi-v7a
2.1.10：TARGET_ABI

2.2: NDK提供的功能宏：
GNU　Make 提供的功能宏，只有通過類似： (callfunction)的方式來得到其值，它將返回文本化的信息。2.2.1:my−dir: (call my-dir):
返回最近一次include的Makefile的路徑。通常返回Android.mk所在的路徑。它用來作爲Android.mk的開頭來定義LOCAL_PATH.
LOCAL_PATH := (callmy−dir)請注意：返回的是最近一次include的Makefile的路徑。所以在Include其它Makefile後，再調用 (call my-dir)會返回其它Android.mk 所在路徑。 例如：
LOCAL_PATH := (callmy−dir)...declareonemoduleinclude (LOCAL_PATH)/foo/Android.mk LOCAL_PATH := (callmy−dir)…declareanothermodule則第二次返回的LOCALPATH　爲： PATH/foo。 而非PATH.2.2.2:all−subdir−makefiles:返回一個列表，包含′my−dir′中所有子目錄中的Android.mk。例如：結構如下：sources/foo/Android.mksources/foo/lib1/Android.mksources/foo/lib2/Android.mk在Ifsources/foo/Android.mk中，include (call all-subdir-makefiles) 那則自動include 了sources/foo/lib1/Android.mk and sources/foo/lib2/Android.mk。

2.2.3：this-makefile：
當前Makefile的路徑。
2.2.4：parent-makefile：
返回include tree中父Makefile 路徑。 也就是include 當前Makefile的Makefile Path。

2.2.5：import-module：
允許尋找並inport其它modules到本Android.mk中來。 它會從NDK_MODULE_PATH尋找指定的模塊名。
(callimport−module,)2.3:模塊描述變量：此類變量用來給BuildSystem描述模塊信息。在′include (CLEAR_VARS)' 和 'include (BUILDXXXXX)′之間。必須定義此類變量。include (CLEAR_VARS) script用來清空這些變量。
include $(BUILD_XXXXX)收集和使用這些變量。

2.3.1: LOCAL_PATH:
這個值用來給定當前目錄。必須在Android.mk的開是位置定義之。
例如： LOCAL_PATH := (callmy−dir)LOCALPATH不會被include (CLEAR_VARS) 清理。

2.3.2: LOCAL_MODULE:
modules名。在include $(BUILD_XXXXX)之前，必須定義這個變量。此變量必須唯一且不能有空格。
通常，由此變量名決定最終生成的目標文件名。

2.3.3: LOCAL_MODULE_FILENAME:
可選。用來override LOCAL_MODULE. 即允許用戶重新定義最終生成的目標文件名。
LOCAL_MODULE := foo-version-1 LOCAL_MODULE_FILENAME := libfoo
2.3.4：LOCAL_SRC_FILES：
爲Build Modules而提供的Source 文件列表。不需要列出依賴文件。 注意：文件相對於LOCAL_PATH存放，
且可以提供相對路徑。 例如：
LOCAL_SRC_FILES := foo.c \ toto/bar.c
2.3.5: LOCAL_CPP_EXTENSION:
指出C++ 擴展名。(可選)
LOCAL_CPP_EXTENSION := .cxx 從NDK R7後，可以寫多個：
LOCAL_CPP_EXTENSION := .cxx .cpp .cc
2.3.6：LOCAL_CPP_FEATURES：
可選。用來指定C++ features。
LOCAL_CPP_FEATURES := rtti
LOCAL_CPP_FEATURES := exceptions

2.3.7：LOCAL_C_INCLUDES：
一個可選的path列表。相對於NDK ROOT 目錄。編譯時，將會把這些目錄附上。
LOCAL_C_INCLUDES := sources/foo LOCAL_C_INCLUDES := $(LOCAL_PATH)/../foo
2.3.8: LOCAL_CFLAGS:
一個可選的設置，在編譯C/C++ source 時添加如Flags。
用來附加編譯選項。 注意：不要嘗試在此處修改編譯的優化選項和Debug等級。它會通過您Application.mk中的信息自動指定。
也可以指定include 目錄通過：LOCAL_CFLAGS += -I。 這個方法比使用LOCAL_C_INCLUDES要好。因爲這樣也可以被ndk-debug使用。
2.3.9: LOCAL_CXXFLAGS:
LOCAL_CPPFLAGS的別名。
2.3.10: LOCAL_CPPFLAGS:
C++ Source 編譯時添加的C Flags。這些Flags將出現在LOCAL_CFLAGS flags 的後面。

2.3.11: LOCAL_STATIC_LIBRARIES:
要鏈接到本模塊的靜態庫list。(built with BUILD_STATIC_LIBRARY)

2.3.12: LOCAL_SHARED_LIBRARIES:
要鏈接到本模塊的動態庫。
2.3.13：LOCAL_WHOLE_STATIC_LIBRARIES：
靜態庫全鏈接。 不同於LOCAL_STATIC_LIBRARIES，類似於使用–whole-archive

2.3.14：LOCAL_LDLIBS：
linker flags。 可以用它來添加系統庫。 如 -lz:
LOCAL_LDLIBS := -lz

2.3.15: LOCAL_ALLOW_UNDEFINED_SYMBOLS:
2.3.16: LOCAL_ARM_MODE:
缺省模式下，ARM目標代碼被編譯爲thumb模式。每個指令16位。如果指定此變量爲：arm。 則指令爲32位。
LOCAL_ARM_MODE := arm 其實也可以指定某一個或者某幾個文件的ARM指令模式。
2.3.17: LOCAL_ARM_NEON:
設置爲true時，會講浮點編譯成neon指令。這會極大地加快浮點運算(前提是硬件支持)
只有targeting 爲 ‘armeabi-v7a’時纔可以。

2.3.18：LOCAL_DISABLE_NO_EXECUTE：
2.3.19: LOCAL_EXPORT_CFLAGS:
定義這個變量用來記錄C/C++編譯器標誌集合，
並且會被添加到其他任何以LOCAL_STATIC_LIBRARIES和LOCAL_SHARED_LIBRARIES的模塊的LOCAL_CFLAGS定義中
LOCAL_SRC_FILES := foo.c bar.c.arm
注意：此處NDK版本爲NDK R7C.（不同NDK版本，ndk-build所產生的Makefile並不完全相同）

動態庫和靜態庫的特點：
靜態庫：
靜態庫是obj文件的一個集合，通常靜態庫以”.a”爲後綴。靜態庫由程序ar生成。
2.靜態庫的優點是可以在不用重新編譯程序庫代碼的情況下，進行程序的重新鏈接，這種方法節省了編譯過程的時間（在編譯大型程序的時候，需要花費很長的時間）。靜態庫的另一個優點是開發者可以提供庫文件給使用的人員，不用開放源代碼，這是庫函數提供者經常採用的手段。
動態庫：
1.動態鏈接庫是程序運行時加載的庫，當動態鏈接庫正確安裝後，所有的程序都可以使用動態庫來運行程序。動態鏈接庫是目標文件的集合，目標文件在動態鏈接庫中的組織方式是按照特殊方式形成的。庫中函數和變量的地址是相對地址，不是絕對地址，其真實地址在調用動態庫的程序加載時形成。
2.動態鏈接庫的名稱有別名（soname）, 真名(realname)和鏈接名（linker name）。別名由一個前綴lib,然後是庫的名字，再加上一個後綴“.so”構成。真名是動態鏈接庫真實名稱，一般總是在別名的基礎加上一個小版本號，發佈版本等構成。除此之外，還有一個鏈接名，即程序鏈接時使用的庫的名字。
3.在動態鏈接庫安裝的時候，總是複製文件到某個目錄下，然後用一個軟連接生成別名，在庫文件進行更新的時候，僅僅更新軟鏈接即可。
來源： http://topmanopensource.iteye.com/blog/1752490