本發(fā)明涉及計算機技術領域，尤其涉及一種共享對象庫加載的方法及裝置。

背景技術：

在安卓(Android)開發(fā)中，可以通過Java本地接口(Java Native Interface，縮寫成JNI)的方式來調用和訪問用C/C++實現(xiàn)的代碼，這些代碼以共享對象(SharedObject，縮寫成SO)文件的方式存在于共享對象庫，即SO庫中。

當Java層在調用本地(Native)層時，有時會存在在預加載的SO庫中沒有找到要調用的SO文件而導致加載失敗的情況，雖然是低概率事件，但一旦加載失敗則會導致整個應用崩潰。

現(xiàn)有技術中當通過JNI接口加載SO庫中的例如以“l(fā)ib*.SO”表示的SO文件時，如果加載不成功，則會采用異常處理try-catch的方式的跳到異常處理部分。

其中try-catch中的try可以保證程序的正常運行，其用于捕獲程序的異常，而catch則用于輸出為什么出錯。

采用try-catch的具體方式為：在try-catch的執(zhí)行過程中，首先逐個從上到下執(zhí)行try塊中的語句，如果沒有發(fā)生異常，則執(zhí)行完try塊后跳過catch塊。如果try塊中某條語句存在異常，則跳到相對應的catch塊中，執(zhí)行完該catch塊中的語句，然后跳過其它的catch塊，接著往下走，其語句后面通常跟著語句finally，以提供一個統(tǒng)一的出口。

例如執(zhí)行下面的try-catch：

try{

int i＝1/0；

}catch(Exception e){

........

}

如果try塊中計算“int i＝1/0”除數(shù)為0，則跳到相對應的catch塊中“Exception e”而報錯，如果沒有try的話，程序直接崩潰。用try的話，則可以讓程序運行下去，并且輸出為什么出錯。

現(xiàn)有技術中通過使用try-catch的方式，雖然可以在SO庫加載失敗時提示加載錯誤，但其僅能夠發(fā)現(xiàn)問題，并不能幫助有效的加載SO庫。

技術實現(xiàn)要素：

本發(fā)明的解決方案主要是保證能成功加載SO庫，確保上層Java層調用本地Native層正常。具體為：

本發(fā)明提供了一種SO庫加載的方法和裝置，。

具體技術方案如下：

一種共享對象SO庫加載的方法，所述方法包括：

確定SO庫加載失敗的原因；

依據(jù)SO庫加載失敗的原因選擇以下加載方式之一加載SO庫：

釋放并重新安裝包含所述SO庫的安裝包；

使用全路徑的方式或者使用文件加載的方式加載SO庫；

使用文件鎖的方式保證僅多個進程之一加載SO庫。

根據(jù)本發(fā)明一優(yōu)選實施例，如果確定SO庫加載失敗的原因是所述SO庫中的SO文件不存在、SO文件不完整、或者SO文件被篡改，則選擇所述釋放并重新安裝包含所述SO庫的安裝包的方式加載SO庫。

根據(jù)本發(fā)明一優(yōu)選實施例，確定SO庫加載失敗的原因為SO文件不完整的方式包括：解析SO庫安裝包，將加載的當前目錄下的SO文件的文件大小 與所述解析SO庫安裝包中解析出的SO文件的文件大小進行比較，如果加載的SO文件的文件大小與安裝包中的SO文件的文件大小不一致，則確定SO庫加載失敗的原因是SO文件不完整。

根據(jù)本發(fā)明一優(yōu)選實施例，確定SO庫加載失敗的原因為SO文件被篡改的方式包括：將加載的當前目錄下的SO文件的更新時間與安裝SO庫安裝包的安裝時間進行比較，如果更新時間和安裝時間不一致，則確定SO庫加載失敗的原因是SO文件被篡改。

根據(jù)本發(fā)明一優(yōu)選實施例，如果確定SO庫加載失敗的原因是找不到SO庫中SO文件的目錄，則選擇所述使用全路徑的方式或者使用文件加載的方式加載SO庫。

根據(jù)本發(fā)明一優(yōu)選實施例，所述使用全路徑的方式具體包括：通過調用定義了SO文件的全路徑名參數(shù)的System.load函數(shù)來尋找SO文件目錄。

根據(jù)本發(fā)明一優(yōu)選實施例，所述使用文件加載的具體方式包括：通過調用定義了SO文件的文件名參數(shù)的System.loadLibrary函數(shù)來尋找SO文件目錄。

根據(jù)本發(fā)明一優(yōu)選實施例，如果確定SO庫加載失敗的原因是多進程加載SO庫導致的加載沖突，則選擇所述使用文件鎖的方式保證僅多個進程之一加載SO庫。

根據(jù)本發(fā)明一優(yōu)選實施例，所述使用文件鎖的方式具體包括：當多個進程之一加載SO庫并對所述SO庫中的SO文件執(zhí)行寫操作時，使用文件鎖對執(zhí)行寫操作的所述SO文件加鎖，當所述寫操作結束后釋放文件鎖。

根據(jù)本發(fā)明一優(yōu)選實施例，在執(zhí)行所述選擇以下加載方式之一加載SO庫后，如果加載仍然失敗，則轉至執(zhí)行所述確定SO庫加載失敗的原因的操作。

一種SO庫加載的裝置，所述裝置包括：

確定單元，用于確定SO庫加載失敗的原因；

加載單元，用于依據(jù)SO庫加載失敗的原因選擇以下加載方式之一加載SO庫：

釋放并重新安裝包含所述SO庫的安裝包；

使用全路徑的方式或者使用文件加載的方式加載SO庫；

使用文件鎖的方式保證僅多個進程之一加載SO庫。

根據(jù)本發(fā)明一優(yōu)選實施例，如果所述確定單元確定SO庫加載失敗的原因是所述SO庫中的SO文件不存在、SO文件不完整、或者SO文件被篡改，則所述加載單元選擇所述釋放并重新安裝包含所述SO庫的安裝包的方式加載SO庫。

根據(jù)本發(fā)明一優(yōu)選實施例，所述確定單元確定SO庫加載失敗的原因為SO文件不完整的方式包括：解析SO庫安裝包，將加載的當前目錄下的SO文件的文件大小與所述解析SO庫安裝包中解析出的SO文件的文件大小進行比較，如果加載的SO文件的文件大小與安裝包中的SO文件的文件大小不一致，則確定SO庫加載失敗的原因是SO文件不完整。

根據(jù)本發(fā)明一優(yōu)選實施例，所述確定單元確定SO庫加載失敗的原因為SO文件被篡改的方式包括：將加載的當前目錄下的SO文件的更新時間與安裝SO庫安裝包的安裝時間進行比較，如果更新時間和安裝時間不一致，則確定SO庫加載失敗的原因是SO文件被篡改。

根據(jù)本發(fā)明一優(yōu)選實施例，如果所述確定單元確定SO庫加載失敗的原因是找不到SO庫中SO文件的目錄，則加載單元選擇所述使用全路徑的方式或者使用文件加載的方式加載SO庫。

根據(jù)本發(fā)明一優(yōu)選實施例，所述使用全路徑的方式具體包括：通過調用定義了SO文件的全路徑名參數(shù)的System.load函數(shù)來尋找SO文件目錄。

根據(jù)本發(fā)明一優(yōu)選實施例，所述使用文件加載的具體方式包括：通過調用定義了SO文件的文件名參數(shù)的System.loadLibrary函數(shù)來尋找SO文件目錄。

根據(jù)本發(fā)明一優(yōu)選實施例，如果所述確定單元確定SO庫加載失敗的原因是多進程加載SO庫導致的加載沖突，則所述加載單元選擇所述使用文件鎖的方式保證僅多個進程之一加載SO庫。

根據(jù)本發(fā)明一優(yōu)選實施例，所述使用文件鎖的方式具體包括：當多個進程之一加載SO庫并對所述SO庫中的SO文件執(zhí)行寫操作時，使用文件鎖對執(zhí)行寫操作的所述SO文件加鎖，當所述寫操作結束后釋放文件鎖。

根據(jù)本發(fā)明一優(yōu)選實施例，在所述加載單元執(zhí)行所述選擇以下加載方式之一加載SO庫后，如果加載仍然失敗，則轉至由確定單元執(zhí)行所述確定SO庫加載失敗的原因的操作。

由以上技術方案可以看出，本發(fā)明提供的方法和裝置，基于SO庫自身的調用邏輯對可能導致SO庫加載失敗的難以捕捉的原因進行排查，并依據(jù)SO庫加載失敗的原因選擇多個加載方式之一加載SO庫，從而保證了SO庫盡量加載成功。

【附圖說明】

圖1為本發(fā)明實施例一提供的一種SO庫加載方法的流程圖；

圖2為本發(fā)明實施例二提供的一種依次確定SO庫加載失敗的原因并選擇對應的加載方式的SO庫加載方法流程圖；

圖3為本發(fā)明實施例三提供的一種SO庫加載裝置的結構示意圖；

圖4為本發(fā)明實施例四提供的一種依次確定SO庫加載失敗的原因并選擇對應的加載方式的SO庫加載裝置的結構示意圖。

【具體實施方式】

為了使本發(fā)明的目的、技術方案和優(yōu)點更加清楚，下面結合附圖和具體實施例對本發(fā)明進行詳細描述。

實施例一、

參照圖1，圖1示出了根據(jù)本發(fā)明實施例一的一種SO庫加載的方法的流程圖，具體流程為：

101、確定SO庫加載失敗的原因。

當應用加載SO庫失敗時，可能會提示沒有文件或目錄，例如會顯示這 樣的提示信息“error while loading shared libraries:libtcmal loc_mininal.SO.4No such file or directory”。

當SO庫中的SO文件不存在、不完整或者被篡改等，該SO文件自身存在的一系列問題可能造成SO庫加載失敗，因此可以先確定SO庫加載失敗是否是由SO文件不存在、不完整或者被篡改等其自身原因導致的。

其中導致SO文件不存在的原因又有很多，例如由于在Android中調用SO文件時，往往都要將對應的SO文件打包進安裝包(apk)。因此提示SO文件不存在的這種情況通常是因為所需要的apk包沒有安裝；除此之外，SO文件拷入不成功、該文件已被第三方應用刪除、文件丟失等，也可能使SO文件不存在，在此不再一一列舉。

本發(fā)明所指的apk是AndroidPacKage的縮寫，即Android安裝包(apk)。apk是類似Symbian Sis或Sisx的文件格式。通過將apk文件直接傳到Android模擬器或Android手機中執(zhí)行即可安裝。apk文件其實是zip格式，但后綴名被修改為apk。Android系統(tǒng)在運行一個程序時首先需要將apk通過UnZip解壓，然后直接執(zhí)行安裝。

而應用找不到SO庫中SO文件的相應目錄、多進程加載沖突也是導致SO庫加載失敗的原因。

因此步驟101中需要首先確定SO庫加載失敗的原因是1011、SO文件不存在，1012、SO文件不完整或被篡改，1013、找不到SO庫中SO文件的目錄，或者1014、多進程加載SO庫導致的加載沖突等等多個原因中的哪一種，從而依據(jù)SO庫加載失敗的原因選擇相應的記載方式來加載SO庫。

102、依據(jù)SO庫加載失敗的原因選擇以下加載方式之一加載SO庫：1021、釋放并重新安裝包含所述SO庫的安裝包，1022、通過使用全路徑的方式加載SO庫，1023、使用文件加載的方式加載SO庫，或者1024、使用文件鎖的方式保證僅多個進程之一加載SO庫。

具體地，可以通過校驗來確定SO庫加載失敗的原因101是否是SO庫中的SO文件不存在1011，SO文件不完整或者被篡改1012，如果確定是上述原 因之一，可以通過釋放并重新安裝apk包的方式1021加載SO庫。

另外，在執(zhí)行了一次釋放并重新安裝apk包加載SO庫后，可以再次嘗試一次校驗來確定是否存在SO文件不存在、不完整、或者被篡改的原因，從而最大限度的排除由SO文件自身原因導致的加載失敗。

當然，也可以再次嘗試一次以上的校驗，其嘗試的任何次數(shù)均在本發(fā)明的保護范圍內。

如果在SO文件的相應目錄下并沒有相應的SO文件，則確定文件不存在。

如果通過解析SO庫安裝包，將加載的當前目錄下的SO文件的文件大小與解析SO庫安裝包中解析出的SO文件的文件大小進行比較，發(fā)現(xiàn)加載的SO文件的文件大小與安裝包中的SO文件的文件大小不一致，則可以確定SO庫加載失敗的原因是SO文件不完整。

如果將加載的當前目錄下的SO文件的更新時間與安裝SO庫安裝包的安裝時間進行比較，發(fā)現(xiàn)更新時間和安裝時間不一致，則可以確定SO庫加載失敗的原因是SO文件被篡改。

以上對確定SO文件是否不存在、不完整或是否被篡改僅舉出了一種示例，但并不限于上述示例，其他確定SO文件是否不存在、不完整或被篡改的具體方式均包含在本發(fā)明所保護的范圍內。

如果確定SO庫加載失敗的原因是找不到SO庫中SO文件的目錄，則選擇所述使用全路徑的方式或者使用文件加載的方式加載SO庫。

其中，可以通過調用定義了SO文件的全路徑名參數(shù)的System.load函數(shù)來使用全路徑方式尋找SO文件目錄。也可以通過調用定義了SO文件的文件名參數(shù)的System.loadLibrary函數(shù)來使用文件加載的方式尋找SO文件目錄。

在通過全路徑方式尋找SO文件目錄失敗后，還可以進一步通過釋放并重新安裝apk包的方式再次加載SO庫。

如果確定SO庫加載失敗的原因是多進程加載SO庫導致的加載沖突，可以在多個進程之一加載SO庫并對SO庫中的SO文件執(zhí)行寫操作時，使用文件 鎖對執(zhí)行寫操作的SO文件加鎖，當寫操作結束后釋放文件鎖，從而使用文件鎖的方式保證僅多個進程之一加載SO庫。

在執(zhí)行所述選擇以下加載方式之一加載SO庫后，如果加載仍然失敗，則轉至執(zhí)行101的步驟，重新確定SO庫加載失敗的原因并有針對性的執(zhí)行相應操作。

本實施例中可以依據(jù)SO庫加載失敗的原因而選擇不同的SO庫加載方式來加載SO庫，多個SO庫加載方式中，其執(zhí)行不分先后順序，一切能夠保證SO庫成功加載的執(zhí)行順序的組合方式均在本發(fā)明的保護范圍內。

雖然多個SO庫加載方式的執(zhí)行不分先后順序，只要能通過各流程而成功加載SO庫文件，則均在本發(fā)明的保護范圍內。但為了便于理解，以下選取了一種執(zhí)行順序的組合，并從依次確定SO庫加載失敗的原因并選擇對應的加載方式加載SO庫的角度，對實施例一描述的SO庫加載方法進行了進一步說明。

實施例二、

參照圖2，圖2示出了根據(jù)本發(fā)明實施例二的一種依次確定SO庫加載失敗的原因并選擇對應的加載方式的SO庫加載方法流程圖，具體流程為：

201、校驗SO文件是否存在，以排除SO文件不存在而導致的SO庫加載失敗。

在步驟201中，如果應用加載SO庫失敗，可以通過校驗的方式確定SO文件是否存在。如果發(fā)現(xiàn)SO文件不存在時，可以通過釋放apk包并重新安裝的方式來解決，并且在重新安裝apk包后，再次嘗試一次SO文件是否存在的校驗，以保證SO文件的真實存在。

如果通過步驟201發(fā)現(xiàn)系統(tǒng)要加載的SO庫中SO文件已經(jīng)存在于相應的目錄下面，但仍然提示無法加載SO庫，則有可能是SO文件由于不完整或被篡改而導致其加載失敗，因此可以通過流程202對SO文件進行進一步校驗。

202、校驗SO文件是否完整或是否被篡改。

當SO文件已經(jīng)存在，但加載SO庫仍然失敗時，其加載失敗有可能是由 已經(jīng)存在的SO文件不完整、被篡改等原因導致的。而SO文件缺少字節(jié)、被損壞、被修改均可以引起SO文件不完整或被篡改。

第一種：校驗SO文件的大小。

校驗SO文件大小的方式可以為，解析apk包，將當前位于SO文件目錄下的SO文件與所解析的apk包中的相應文件進行比較，以確定加載的SO文件的大小與apk包中的文件大小是否一致。如果一致，說明文件是完整的，則繼續(xù)校驗SO文件是否給篡改；反之，則校驗失敗，由此表明SO文件不完整。

在通過校驗發(fā)現(xiàn)SO文件不完整時，可以通過釋放apk包并重新安裝的方式來解決，并且在重新安裝apk包后，再次嘗試一次SO完整性的校驗，以保證SO文件的準確性。

第二種，校驗SO文件的更新時間。

如果加載的SO文件相比于安裝apk的安裝時間，該SO文件的更新時間發(fā)生改變，則有可能SO文件遭到過篡改或破壞，從而導致加載失敗。

優(yōu)選地，可以通過檢查時間戳的方式來校驗SO文件的更新時間，具體地：

當安裝apk包時，基于安裝apk的時間設置時間戳，優(yōu)選地，可以基于首次安裝的apk包設置時間戳，將當前目錄下的SO文件更新時間與時間戳進行比較，如果一致，說明文件是原始文件，沒有被篡改，該原因排查后，可以進行全路徑方式加載；反之，SO文件在安裝apk包以后的時間被進行過修改，則校驗失敗，由此表明SO文件被篡改。

在校驗SO文件發(fā)現(xiàn)其被篡改時，可以通過釋放apk包并重新安裝的方式來解決，并且在重新安裝apk包后，再次嘗試一次SO是否被篡改的校驗，以保證SO文件的準確性。

如果通過201發(fā)現(xiàn)系統(tǒng)要加載的SO文件已經(jīng)存在，通過202校驗確定SO文件完整且沒有被篡改，即校驗成功，但SO庫仍然加載失敗時，則還有可能是系統(tǒng)沒有找到已有SO文件的加載目錄而導致其加載失敗，因此可以進 入203，通過全路徑加載SO文件的方式尋找目錄。

如果在201和202中經(jīng)過有限次的校驗發(fā)現(xiàn)SO文件仍然不存在、不完整或被篡改，則校驗失敗，不再繼續(xù)嘗試SO庫加載。

203、通過全路徑的方式加載SO庫。

全路徑是指從根目錄開始的路徑，使用全路徑可以唯一定位一個文件或者文件夾。

本實施例可以使用System.load函數(shù)加載SO文件，此函數(shù)的參數(shù)為SO文件全路徑名。

例如System.load("/usr/lib/TestJNI.SO")，其中l(wèi)ibTestJNI.SO是java.library.path所指向的路徑。

當系統(tǒng)本身發(fā)生讀取失敗、解碼操作失敗等錯誤時，可以導致通過路徑加載SO庫失敗，上述失敗的概率雖然相比于SO文件不存在、不完整或被篡改的概率小，但若存在問題則會產(chǎn)生較大的影響。因此如果全路徑加載失敗時，可以通過釋放apk包并重新安裝的方式來解決，并且在重新安裝apk包后，再次嘗試一次全路徑加載SO文件，以確保加載成功。

本實施例中僅以再次嘗試一次校驗或者再次嘗試一次全路徑加載進行了描述，然而并不限于此，其他有限次數(shù)的嘗試加載均在本發(fā)明保護的范圍內。

由于系統(tǒng)中通過全路徑加載的方式是在固定的幾個路徑下去查找，加載的是路徑而不是文件，該方式排除了其路徑之外的所有查找SO文件的手段，因此在通過釋放并重新安裝apk包，或者再次嘗試全路徑加載仍然失敗時，可以通過204來嘗試使用除全路徑外的其他查找手段來加載SO文件。

204、通過加載文件的方式加載SO庫。

本實施例可以通過使用System.loadLibrary函數(shù)來加載SO庫，System.loadLibrary的功能是查找并加載某個庫文件，其參數(shù)為庫文件名，使用此方法可加載系統(tǒng)目錄中的SO文件。

例如

System.loadLibrary("data/data/xxx.xxx.xxx/lib/xx.SO")或者

System.loadLibrary("xx")。

通過加載文件的方式，可以在通過全路徑加載SO庫失敗時，以另一種方式再次嘗試查找SO文件從而實現(xiàn)SO庫的加載，以此確保加載成功。

當嘗試完所有查找手段加載SO庫時，仍然可能出現(xiàn)SO庫加載失敗的問題，而多進程加載SO庫所引起的沖突，也會成為導致加載失敗的原因，因此可以通過205來解決多進程加載失敗的問題。

205、如果是多個進程加載SO庫，則使用文件鎖。

具體地，若多個進程加載SO庫，例如一個進程未釋放SO庫而另一個進程在寫過程，上述操作同樣會引起SO庫的加載錯誤，因此當多個進程加載SO庫時，可以使用文件鎖(filelock)在寫操作時對其中一個可寫文件(w)加鎖(trylock)，保證同時只有一個進程可以拿到文件鎖，這個進程從而可以對文件做訪問，直到該進程的操作完成時再通過FileLock.release()語句釋放文件鎖。

通過文件鎖可以控制不同程序對同一文件的并發(fā)訪問，這樣的機制保證了某進程獲得文件鎖后，操作系統(tǒng)將保證其它進程無法對文件做操作，這樣，進程就可以通過FileLock來實現(xiàn)進程間的互斥運行。從而避免由于多個進程同時對SO庫的操作而引起SO庫加載失敗。

實施例三、

參照圖3，圖3示出了根據(jù)本發(fā)明實施例三的一種SO庫加載裝置的結構示意圖，該SO庫加載裝置可以包括：確定單元301和加載單元302，以下對各個單元的構成和功能進行詳細描述：

確定單元301，用于確定SO庫加載失敗的原因。

當SO庫中的SO文件不存在、不完整或者被篡改等，該SO文件自身存在的一系列問題可能造成SO庫加載失敗，因此可以先確定SO庫加載失敗是否是由SO文件不存在、不完整或者被篡改等其自身原因導致的。

其中導致SO文件不存在的原因又有很多，例如由于在Android中調用 SO文件時，往往都要將對應的SO文件打包進安裝包(apk)。因此提示SO文件不存在的這種情況通常是因為所需要的apk包沒有安裝；除此之外，SO文件拷入不成功、該文件已被第三方應用刪除、文件丟失等，也可能使SO文件不存在，在此不再一一列舉。

而應用找不到SO庫中SO文件的相應目錄、多進程加載沖突也是導致SO庫加載失敗的原因。

因此需要首先通過確定單元301確定SO庫加載失敗的原因是SO文件不存在，SO文件不完整或被篡改，找不到SO庫中SO文件的目錄，或者多進程加載SO庫導致的加載沖突等等多個原因中的哪一種，從而依據(jù)SO庫加載失敗的原因選擇相應的記載方式來加載SO庫。

加載單元302，用于依據(jù)SO庫加載失敗的原因選擇以下加載方式之一加載SO庫：釋放并重新安裝包含所述SO庫的安裝包，通過使用全路徑的方式加載SO庫，使用文件加載的方式加載SO庫，或者使用文件鎖的方式保證僅多個進程之一加載SO庫。

具體地，確定單元可以通過校驗來確定SO庫加載失敗的原因是否是SO庫中的SO文件不存在，SO文件不完整或者被篡改，如果確定是上述原因之一，則可以使加載單元執(zhí)行釋放并重新安裝apk包的操作加載SO庫。

另外，在執(zhí)行了一次釋放并重新安裝apk包加載SO庫后，可以再次嘗試一次校驗來確定是否存在SO文件不存在、不完整、或者被篡改的原因，從而最大限度的排除由SO文件自身原因導致的加載失敗。

當然，也可以再次嘗試一次以上的校驗，其嘗試的任何次數(shù)均在本發(fā)明的保護范圍內。

如果確定單元在SO文件的相應目錄下并沒有相應的SO文件，則確定文件不存在。

如果確定單元通過解析SO庫安裝包，將加載的當前目錄下的SO文件的文件大小與解析SO庫安裝包中解析出的SO文件的文件大小進行比較，發(fā)現(xiàn)加載的SO文件的文件大小與安裝包中的SO文件的文件大小不一致，則可以 確定SO庫加載失敗的原因是SO文件不完整。

如果確定單元將加載的當前目錄下的SO文件的更新時間與安裝SO庫安裝包的安裝時間進行比較，發(fā)現(xiàn)更新時間和安裝時間不一致，則可以確定SO庫加載失敗的原因是SO文件被篡改。

以上對確定SO文件是否不存在、不完整或是否被篡改僅舉出了一種示例，但并不限于上述示例，其他確定SO文件是否不存在、不完整或被篡改的具體方式均包含在本發(fā)明所保護的范圍內。

如果確定SO庫加載失敗的原因是找不到SO庫中SO文件的目錄，則加載單元選擇使用全路徑的方式或者使用文件加載的方式加載SO庫。

其中，加載單元302可以通過調用定義了SO文件的全路徑名參數(shù)的System.load函數(shù)來使用全路徑方式尋找SO文件目錄。也可以通過調用定義了SO文件的文件名參數(shù)的System.loadLibrary函數(shù)來使用文件加載的方式尋找SO文件目錄。

在通過全路徑方式尋找SO文件目錄失敗后，還可以進一步通過釋放并重新安裝apk包的方式再次加載SO庫。

如果確定SO庫加載失敗的原因是多進程加載SO庫導致的加載沖突，加載單元可以在多個進程之一加載SO庫并對SO庫中的SO文件執(zhí)行寫操作時，使用文件鎖對執(zhí)行寫操作的SO文件加鎖，當寫操作結束后釋放文件鎖，從而使用文件鎖的方式保證僅多個進程之一加載SO庫。

在執(zhí)行所述選擇以下加載方式之一加載SO庫后，如果加載仍然失敗，則轉至由確定單元301重新確定SO庫加載失敗的原因并有針對性的執(zhí)行相應操作。

本實施例中可以依據(jù)SO庫加載失敗的原因而選擇不同的SO庫加載方式來加載SO庫，多個SO庫加載方式中，其執(zhí)行不分先后順序，一切能夠保證SO庫成功加載的執(zhí)行順序的組合方式均在本發(fā)明的保護范圍內。

雖然加載單元加載SO庫的順序不分先后，只要其能夠成功加載SO庫文件就均在本發(fā)明的保護范圍內，但為了便于理解，以下選取了一種加載單元 加載SO庫的執(zhí)行順序的組合，并從依次確定SO庫加載失敗的原因并選擇對應的加載方式加載SO庫的角度，對實施例三描述的SO庫加載裝置進行了進一步說明。

實施例四、

參照圖4，圖4示出了根據(jù)本發(fā)明實施例三的一種依次確定SO庫加載失敗的原因并選擇對應的加載方式的SO庫加載裝置的結構示意圖，該裝置具體包括：

校驗單元401，用于校驗SO文件是否存在、是否完整或是否被篡改，以排除SO文件不存在而導致的SO庫加載失敗。

具體地，如果應用加載SO庫失敗，可以通過校驗單元401來確定SO文件是否存在。如果發(fā)現(xiàn)SO文件不存在時，可以通過第一安裝單元4012執(zhí)行釋放apk包并重新安裝的操作來解決SO文件不存在的問題，并且在重新安裝apk包后，再次嘗試一次SO文件是否存在的校驗，以保證SO文件的真實存在。

如果經(jīng)校驗發(fā)現(xiàn)系統(tǒng)要加載的SO庫中SO文件已經(jīng)存在于相應的目錄下面，但仍然提示無法加載SO庫，則有可能是SO文件由于不完整或被篡改而導致其加載失敗，因此可以通過校驗裝置401繼續(xù)對SO文件進行不完整或被篡改的校驗。

其中，SO文件缺少字節(jié)、被損壞、被修改均可以引起SO文件不完整或被篡改。

校驗單元401可以通過以下方式對SO文件是否不完整或是否被篡改進行校驗

第一種：校驗SO文件的大小。

校驗SO文件大小的方式可以為，解析apk包，將當前位于SO文件目錄下的SO文件與所解析的apk包中的相應文件進行比較，以確定加載的SO文件的大小與apk包中的文件大小是否一致。如果一致，說明文件是完整的，則繼續(xù)校驗SO文件是否給篡改；反之，則校驗失敗，由此表明SO文件不完 整。

在通過校驗發(fā)現(xiàn)SO文件不完整時，可以通過釋放apk包并重新安裝的方式來解決，并且在重新安裝apk包后，再次嘗試一次SO完整性的校驗，以保證SO文件的準確性。

第二種，校驗SO文件的更新時間。

如果加載的SO文件相比于安裝apk的安裝時間，該SO文件的更新時間發(fā)生改變，則有可能SO文件遭到過篡改或破壞，從而導致加載失敗。

優(yōu)選地，可以通過檢查時間戳的方式來校驗SO文件的更新時間，具體地：

當安裝apk包時，基于安裝apk的時間設置時間戳，優(yōu)選地，可以基于首次安裝的apk包設置時間戳，將當前目錄下的SO文件更新時間與時間戳進行比較，如果一致，說明文件是原始文件，沒有被篡改，該原因排查后，可以進行全路徑方式加載；反之，SO文件在安裝apk包以后的時間被進行過修改，則校驗失敗，由此表明SO文件被篡改。

在校驗SO文件發(fā)現(xiàn)其被篡改的問題時，可以通過第二安裝單元4022執(zhí)行釋放apk包并重新安裝的操作來解決，并且在重新安裝apk包后，再次嘗試一次SO文件是否被篡改的校驗，以保證SO文件的準確性。

如果通過校驗裝置401的校驗發(fā)現(xiàn)系統(tǒng)要加載的SO文件已經(jīng)存在，且其完整和沒有被篡改，即校驗成功，但SO庫仍然加載失敗時，則還有可能是系統(tǒng)沒有找到已有SO文件的加載目錄而導致其加載失敗，因此可以通過全路徑加載單元402執(zhí)行全路徑加載SO文件，以尋找SO文件的目錄。

如果校驗單元401經(jīng)過有限次的校驗發(fā)現(xiàn)SO文件仍然不存在、不完整或被篡改，則校驗失敗，不再繼續(xù)嘗試SO庫加載。

全路徑加載單元402，用于通過全路徑的方式加載SO庫。

全路徑是指從根目錄開始的路徑，使用全路徑可以唯一定位一個文件或者文件夾。

本實施例可以使用System.load函數(shù)加載SO文件，此函數(shù)的參數(shù)為SO 文件全路徑名。

當系統(tǒng)本身發(fā)生讀取失敗、解碼操作失敗等錯誤時，可以導致通過路徑加載SO庫失敗，上述失敗的概率雖然相比于SO文件不存在、不完整或被篡改的概率小，但若存在問題則會產(chǎn)生較大的影響。因此如果全路徑加載失敗時，可以通過釋放apk包并重新安裝的方式來解決，并且在重新安裝apk包后，再次嘗試一次全路徑加載SO文件，以確保加載成功。

本實施例中僅以再次嘗試一次校驗或者再次嘗試一次全路徑加載進行了描述，然而并不限于此，其他有限次數(shù)的嘗試加載均在本發(fā)明保護的范圍內。

由于系統(tǒng)中通過全路徑加載的方式是在固定的幾個路徑下去查找，加載的是路徑而不是文件，該方式排除了其路徑之外的所有查找SO文件的手段，因此在通過釋放并重新安裝apk包，或者再次嘗試全路徑加載仍然失敗時，可以通過加載文件單元403來嘗試使用除全路徑外的其他查找手段來加載SO文件。

加載文件單元403，用于通過加載文件的方式加載SO庫。

本實施例可以通過使用System.loadLibrary函數(shù)來加載SO庫，System.loadLibrary的功能是查找并加載某個庫文件，其參數(shù)為庫文件名，使用此方法可加載系統(tǒng)目錄中的SO文件。

通過加載文件的方式，可以在通過全路徑加載SO庫失敗時，以另一種方式再次嘗試查找SO文件從而實現(xiàn)SO庫的加載，以此確保加載成功。

當嘗試完所有查找手段加載SO庫時，仍然可能出現(xiàn)SO庫加載失敗的問題，而多進程加載SO庫所引起的沖突，也會成為導致加載失敗的原因，因此可以通過多進程加載單元404來解決多進程加載失敗的問題。

多進程加載單元404，用于當多個進程加載SO庫時，使用文件鎖鎖定進程。

具體地，若多個進程加載SO庫，例如一個進程未釋放SO庫而另一個進程在寫過程，上述操作同樣會引起SO庫的加載錯誤，因此當多個進程加載 SO庫時，可以使用文件鎖(filelock)在寫操作時對其中一個可寫文件(w)加鎖(trylock)，保證同時只有一個進程可以拿到文件鎖，這個進程從而可以對文件做訪問，直到該進程的操作完成時再通過FileLock.release()語句釋放文件鎖。

通過文件鎖可以控制不同程序對同一文件的并發(fā)訪問，這樣的機制保證了某進程獲得文件鎖后，操作系統(tǒng)將保證其它進程無法對文件做操作，這樣，進程就可以通過FileLock來實現(xiàn)進程間的互斥運行。從而避免由于多個進程同時對SO庫的操作而引起SO庫加載失敗。

基于本發(fā)明實施例所提供的SO庫加載的方法和裝置，當在SO庫加載中遇到加載失敗的問題時，提出了一種解決加載失敗的具體解決方案，即從SO庫加載中可能導致加載失敗的可能原因入手，基于不同的原因給出相對應的解決手段，通過在當前目錄下釋放、安裝apk包的形式重新加載SO庫，或者采用其他加載方式嘗試加載SO庫，從而保證加載SO庫的成功率。

結合實施例三和實施例四不難看出，確定單元301中可以包含校驗單元401，而加載單元302中可以包含第一安裝單元4012、第二安裝單元4022、全路徑加載單元402、加載文件單元403，或多進程加載單元404。

在本發(fā)明所提供的幾個實施例中，應該理解到，所揭露的系統(tǒng)，裝置和方法，可以通過其它的方式實現(xiàn)。例如，以上所描述的裝置實施例僅僅是示意性的，例如，所述單元的劃分，僅僅為一種邏輯功能劃分，實際實現(xiàn)時可以有另外的劃分方式。

所述作為分離部件說明的單元可以是或者也可以不是物理上分開的，作為單元顯示的部件可以是或者也可以不是物理單元，即可以位于一個地方，或者也可以分布到多個網(wǎng)絡單元上?？梢愿鶕?jù)實際的需要選擇其中的部分或者全部單元來實現(xiàn)本實施例方案的目的。

另外，在本發(fā)明各個實施例中的各功能單元可以集成在一個處理單元中，也可以是各個單元單獨物理存在，也可以兩個或兩個以上單元集成在一個單元中。上述集成的單元既可以采用硬件的形式實現(xiàn)，也可以采用硬件加 軟件功能單元的形式實現(xiàn)。

以上所述僅為本發(fā)明的較佳實施例而已，并不用以限制本發(fā)明，凡在本發(fā)明的精神和原則之內，所做的任何修改、等同替換、改進等，均應包含在本發(fā)明保護的范圍之內。