本發(fā)明涉及計算機技術領域，尤其涉及一種安卓(Android)系統so文件的加載方法及電子設備。

背景技術：

在常規(guī)Android應用開發(fā)時，我們采用的是java語言，運行在虛擬機之上，但是在開發(fā)Android應用時，單單只使用java的應用程序編程接口(Application Programming Interface，API)往往并不能滿足要求，需要本地(Native)語言支持，因為Android系統是基于linux內核，其Native語言為C/C++語言。

Native語言與java語言相比有這幾點好處：1，C/C++相對java而言有著更高的運行效率，因為java語言是先通過虛擬機將java字節(jié)碼轉換成本地二進制，所以效率比本地語言低；2，Native語言內存管理更加方便，C/C++都是自己申請釋放內存，能更靈活的控制內存，而java的內存回收是通過虛擬機的垃圾回收機制實現的，垃圾回收器進行一次內存回收的時間是不確定的，而且因為一些垃圾回收算法，會容易出現內存泄漏；3，由于java語言的特點，非常容易被逆向破解，與之相比，應用將自己的核心代碼放在Native層面，能更好的保護自身算法。

在Android中使用Native語言，需要用到java本地調用技術(Java Native Interface，JNI)，流程大致如下：

先通過C/C++語言編寫好需要在Native層實現的代碼以及與java通訊的接口代碼；

通過本地軟件開發(fā)工具包(Native Development Kit，NDK)將C/C++代碼編譯成Android對應CPU型號的so文件，其中，所述so文件是C/C++代碼所編譯出來的二進制文件，在Android系統中可通過JNI技術使java代碼與so文件進行通訊，所述so文件為linux系統中的動態(tài)鏈接庫文件，類似于windows系統中后綴為.dll的文件；

通過Java編寫與C/C++語言通訊的接口代碼；

Java調用System.loadLibrary()函數加載指定的so文件，其中，System是java標準庫中一個類，此類提供了許多java系統級的函數調用；

Java通過接口文件來實現與Native層的C/C++通訊。

然而，Android中加載so文件并不是可靠的，即使在打包好的Apk中帶有so文件，且so文件里面也肯定有需要的函數的情況下，由于系統運行環(huán)境復雜等因素，在通過System.loadLibrary()函數加載so文件時，還常常會報出“UnsatisfiedLinkError”的加載異常，而出現此異常時，系統會默認加載失敗，導致應用閃退。

可見，現有技術中Android系統加載so文件時，存在容易出錯和容易閃退的技術問題。

技術實現要素：

本發(fā)明提供一種Android系統so文件的加載方法及電子設備，用以解決現有技術中Android系統加載so文件時，存在的容易出錯和容易閃退的技術問題。

第一方面，本發(fā)明實施例提供了一種Android系統so文件的加載方法，包括：

在Android系統加載應用時，檢測所述應用的so文件的加載狀態(tài)；

當檢測到所述so文件加載錯誤時，判斷所述應用的私有目錄下是否存在所述so文件；

當所述私有目錄下存在所述so文件時，更新所述so文件為最新版本的so文件；

當所述私有目錄下不存在所述so文件時，拷貝最新版本的so文件至所述私有目錄；

加載所述最新版本的so文件。

可選的，所述更新所述so文件為最新版本的so文件，包括：獲取所述so文件的版本信息；根據所述版本信息，判斷所述so文件的版本是否是最新版本；當所述so文件的版本是所述最新版本時，確定所述so文件為最新版本的so文件；當所述so文件的版本不是所述最新版本時，刪除所述so文件，并拷貝最新版本的so文件至所述私有目錄。

可選的，所述拷貝最新版本的so文件至所述私有目錄，包括：獲取所述應用的安裝包的源路徑和需要加載所述應用的電子設備的應用二進制接口型號；根據所述源路徑和所述應用二進制接口型號，從所述安裝包中抽取出與所述應用二進制接口型號對應的最新版本的so文件；拷貝所述最新版本的so文件至所述私有目錄。

可選的，所述檢測所述應用的so文件的加載狀態(tài)，包括：檢測是否出現預設的加載異常語句；所述檢測到所述so文件加載錯誤，包括：捕獲到所述加載異常語句。

可選的，所述判斷所述應用的私有目錄下是否存在所述so文件，包括：獲取所述so文件的文件名信息和所述私有目錄下預設用于存儲so文件的目錄的路徑；根據所述路徑和所述文件名信息，判斷所述應用的私有目錄下是否存在所述so文件。

第二方面，本發(fā)明實施例提供了一種電子設備，包括：

檢測模塊，用于在Android系統加載應用時，檢測所述應用的so文件的加載狀態(tài)；

判斷模塊，用于當檢測到所述so文件加載錯誤時，判斷所述應用的私有目錄下是否存在所述so文件；

第一處理模塊，用于當所述私有目錄下存在所述so文件時，更新所述so文件為最新版本的so文件；

第二處理模塊，用于當所述私有目錄下不存在所述so文件時，拷貝最新版本的so文件至所述私有目錄；

加載模塊，用于加載所述最新版本的so文件。

可選的，所述第一處理模塊包括：第一獲取單元，用于獲取所述so文件的版本信息；第一判斷單元，用于根據所述版本信息，判斷所述so文件的版本是否是最新版本；確定單元，用于當所述so文件的版本是所述最新版本時，確定所述so文件為最新版本的so文件；處理單元，用于當所述so文件的版本不是所述最新版本時，刪除所述so文件，并拷貝最新版本的so文件至所述私有目錄。

可選的，所述第二處理模塊包括：第二獲取單元，用于獲取所述應用的安裝包的源路徑和需要加載所述應用的電子設備的應用二進制接口型號；抽取單元，用于根據所述源路徑和所述應用二進制接口型號，從所述安裝包中抽取出與所述應用二進制接口型號對應的最新版本的so文件；拷貝單元，用于拷貝所述最新版本的so文件至所述私有目錄。

可選的，所述檢測模塊還用于，檢測是否出現預設的加載異常語句；所述判斷模塊還用于，用于當捕獲到所述加載異常語句時，判斷所述應用的私有目錄下是否存在所述so文件。

可選的，所述判斷模塊，包括：第三獲取單元，用于獲取所述so文件的文件名信息和所述私有目錄下預設用于存儲so文件的目錄的路徑；第二判斷單元，用于根據所述路徑和所述文件名信息，判斷所述應用的私有目錄下是否存在所述so文件。

本發(fā)明實施例中提供的一個或多個技術方案，至少具有如下技術效果或優(yōu)點：

本申請實施例提供的方法及電子設備，在Android系統加載應用時，增加了對so文件加載錯誤的檢測，在捕獲到錯誤時主動判斷和確保私有目錄下存在最新的最新版本的so文件，并主動重新加載所述最新版本的so文件，一方面解決了當前so文件加載錯誤時閃退的問題，另一方面，能主動修復so文件加載錯誤，提高了so文件加載成功率。

上述說明僅是本發(fā)明技術方案的概述，為了能夠更清楚了解本發(fā)明的技術手段，而可依照說明書的內容予以實施，并且為了讓本發(fā)明的上述和其它目的、特征和優(yōu)點能夠更明顯易懂，以下特舉本發(fā)明的具體實施方式。

附圖說明

為了更清楚地說明本發(fā)明實施例或現有技術中的技術方案，下面將對實施例或現有技術描述中所需要使用的附圖作一簡單地介紹，顯而易見地，下面描述中的附圖是本發(fā)明的一些實施例，對于本領域普通技術人員來講，在不付出創(chuàng)造性勞動的前提下，還可以根據這些附圖獲得其他的附圖。

圖1為本發(fā)明實施例中Android系統so文件的加載方法的流程圖；

圖2為本發(fā)明實施例中Android系統so文件的加載方法的具體邏輯流程圖；

圖3為本發(fā)明實施例中電子設備的結構示意圖。

具體實施方式

本申請實施例通過提供一種Android系統so文件的加載方法及電子設備，解決了現有技術中Android系統加載so文件時，存在的容易出錯和容易閃退的技術問題，實現了提高so文件加載成功率的技術效果。

本申請實施例中的技術方案，總體思路如下：

在Android系統加載應用時，檢測所述應用的so文件的加載狀態(tài)，在捕獲到所述so文件加載錯誤時，先判斷所述應用的私有目錄下是否存在所述so文件；當所述私有目錄下存在所述so文件時，更新所述so文件為最新版本的so文件；當所述私有目錄下不存在所述so文件時，拷貝最新版本的so文件至所述私有目錄，并重新加載所述最新版本的so文件。

上述方法增加了加載過程中對so文件加載錯誤的檢測，在捕獲到加載錯誤時，主動判斷和確保私有目錄下存在最新的最新版本的so文件，并主動重新加載所述最新版本的so文件，解決了當前so文件加載錯誤時閃退的問題，且能主動修復so文件加載錯誤，提高了so文件加載成功率。

為使本發(fā)明實施例的目的、技術方案和優(yōu)點更加清楚，下面將結合本發(fā)明實施例中的附圖，對本發(fā)明實施例中的技術方案進行清楚、完整地描述，顯然，所描述的實施例是本發(fā)明一部分實施例，而不是全部的實施例?；诒景l(fā)明中的實施例，本領域普通技術人員在沒有作出創(chuàng)造性勞動前提下所獲得的所有其他實施例，都屬于本發(fā)明保護的范圍。

實施例一

本實施例提供一種Android系統so文件的加載方法，請參考圖1，所述方法包括：

步驟S101，在Android系統加載應用時，檢測所述應用的so文件的加載狀態(tài)；

步驟S102，當檢測到所述so文件加載錯誤時，判斷所述應用的私有目錄下是否存在所述so文件；

步驟S103，當所述私有目錄下存在所述so文件時，更新所述so文件為最新版本的so文件；

步驟S104，當所述私有目錄下不存在所述so文件時，拷貝最新版本的so文件至所述私有目錄；

步驟S105，加載所述最新版本的so文件。

舉例來說，所述方法可以應用于具有計算功能的電子設備，該電子設備例如為：智能手機、智能手表、筆記本電腦或平板電腦等。

具體來講，Android中使用Native語言，需要通過JNI技術加載Native語言編寫的so文件，而Android中加載so文件并不是可靠的，運行具有so文件的Apk時，常常會出現UnsatisfiedLinkError異常，此時，系統默認加載失敗，應用崩潰退出。據發(fā)明人研究發(fā)現，在打包好的Apk當中，一般會帶有so文件，so文件里面也有需要的函數，但即使是這樣，還是會出現加載異常的原因有：so文件加載出錯、so文件拷貝出錯或在Android應用升級時，新的so文件覆蓋替換老的so文件出錯。本發(fā)明提供的方法，增加了對so文件加載異常的檢測，并在捕獲到異常時，不默認加載失敗，而是主動判斷并確保私有目錄下存在最新版本的so文件，并重新加載所述最新版本的so文件，從而避免出現閃退，自動修復了so文件加載錯誤，提高了加載成功率。

下面，結合圖1對本申請?zhí)峁┑腁ndroid系統so文件的加載方法進行詳細介紹：

首先，執(zhí)行步驟S101，在Android系統加載應用時，檢測所述應用的so文件的加載狀態(tài)。

具體來講，Android系統是通過java調用System.loadLibrary()函數來加載應用中的so文件的，在加載出錯時，會報出“UnsatisfiedLinkError”等異常，故檢測所述應用的so文件的加載狀態(tài)，可以通過檢測是否出現預設的加載異常語句來實現，所述加載異常語句可以為“UnsatisfiedLinkError”。

在具體實施過程中，檢測是否出現預設的加載異常語句可以是，通過try catch語句來捕獲UnsatisfiedLinkError等加載異常語句，從而判斷是否出現so加載錯誤，當捕獲到UnsatisfiedLinkError等加載異常語句時，表明so文件的加載出現問題需要修復。

具體來講，通過檢測預設的加載異常語句來檢測so文件的加載狀態(tài)，需要的檢測計算量較小，且漏檢率低。

當然，在具體實施過程中，檢測所述so文件的加載狀態(tài)，除了上述檢測加載異常語句，還可以有多種實現策略：例如，還可以是監(jiān)測so文件的加載進度，當出現so文件加載進度停滯時，認為出現加載錯誤，本發(fā)明對此并沒有限制。

接下來，執(zhí)行步驟S102，當檢測到所述so文件加載錯誤時，判斷所述應用的私有目錄下是否存在所述so文件。

需要說明的是，在Android中加載安裝帶有so文件的Apk時，系統會將Apk下的相應的so文件先拷貝到該應用的私有目錄下，再進行加載，故在檢測到所述so文件加載錯誤時，先判斷所述應用的私有目錄下是否存在所述so文件，能識別出該加載錯誤的原因是否是so文件拷貝出錯，導致私有目錄下沒有該so文件。

具體來講，所述應用的私有目錄為該應用默認的安裝目錄，例如，某殺毒應用abc的私有目錄為電子設備本地存儲上的命名為abc的文件夾，當電子設備上安裝abc應用時，會先將abc應用Apk下的相應的so文件先拷貝到命名為abc的私有目錄下。

在具體實施過程中，判斷所述應用的私有目錄下是否存在所述so文件的方法可以有多種，下面列舉兩種為例：

第一種，根據文件名和路徑判斷。

即所述判斷所述應用的私有目錄下是否存在所述so文件，包括：

獲取所述so文件的文件名信息和所述私有目錄下預設用于存儲so文件的目錄的路徑；

根據所述路徑和所述文件名信息，判斷所述應用的私有目錄下是否存在所述so文件。

具體來講，其詳細判斷步驟可以如下，其中，步驟1)和步驟2)可以互換：

1)獲取所述so文件的文件名信息，具體可以通過java的System.mapLibraryName()函數來獲得so文件的完整的文件名，其中，mapLibraryName()函數可以在接受so文件的文件名參數后，返回so文件的完整文件名；

2)獲取so文件在所述私有目錄下默認的具體存儲路徑，具體可以通過Android提供的context.getDir()函數得到so存放的目錄路徑；

3)接下來，根據所述文件名和所述目錄路徑可以拼接出so文件的完整路徑鏈接，通過所述路徑鏈接創(chuàng)建一File類對象，其中，所述File類是java中接口操作的一個工具類，用來處理文件操作，File類包含文件的創(chuàng)建刪除等功能；

4)最后通過File類中的函數exists()來判斷so是否存在。

第二種，搜索so文件來判斷。

即可以先獲取所述so文件的文件名信息；再根據所述文件名信息，通過電子設備的搜索功能在本地存儲中搜索該so文件；根據搜索結果判斷所述應用的私有目錄下是否存在所述so文件。

具體來講，當搜索結果為不存在so文件時，確定所述私有目錄下不存在所述so文件；當搜索結果存在so文件時，比對搜索出的so文件的存儲路徑是否是默認的所述私有目錄，如果是，則確定所述私有目錄下存在所述so文件，如果不是，則確定所述私有目錄下不存在所述so文件。

當然，在具體實施過程中，判斷所述應用的私有目錄下是否存在所述so文件不限于以上幾種判斷方法，基于不同的需求可以確定出不同的判斷方法，對此本發(fā)明實施例不再詳細列舉，并且不作限制。

再下來，根據步驟S102的判斷結果，選擇執(zhí)行步驟S103或步驟S104：

步驟S103，當所述私有目錄下存在所述so文件時，更新所述so文件為最新版本的so文件；

步驟S104，當所述私有目錄下不存在所述so文件時，拷貝最新版本的so文件至所述私有目錄。

具體來講，由于造成UnsatisfiedLinkError等異常的原因可能是so文件加載出錯、so文件拷貝出錯或升級覆蓋出錯，故，如果步驟S102判斷出應用的私有目錄下沒有so文件，則確定是so文件的拷貝出現問題，可以執(zhí)行步驟S104，重新拷貝最新版本的so文件至所述私有目錄；如果步驟S102判斷出所述私有目錄下存在所述so文件時，則還需要辨別是so文件加載出錯，還是升級覆蓋出錯，即執(zhí)行步驟S103以確定所述私有目錄下存在最新版本的so文件。

也就是說，當所述私有目錄下存在所述so文件時，還可以分為兩種情況：一是，目錄下的so文件版本低于最新版本，則表明Apk覆蓋升級時so文件的覆蓋出現問題，需要刪除老的so文件，拷貝新的so文件到當前私有目錄；二是，私有目錄下so文件版本與當前需要的版本相同，則表明確定是so文件加載過程出現問題，僅需要重新加載。

在具體實施過程中，更新所述so文件為最新版本的so文件的方法可以有多種，下面列舉兩種為例：

第一種，根據版本信息更新。

即獲取所述so文件的版本信息；

根據所述版本信息，判斷所述so文件的版本是否是最新版本；

當所述so文件的版本是所述最新版本時，確定所述so文件為最新版本的so文件；

當所述so文件的版本不是所述最新版本時，刪除所述so文件，并拷貝最新版本的so文件至所述私有目錄。

在具體實施過程中，可以將so文件的版本號在so文件名上以約定好的格式寫入，以便于根據所述so文件的文件名獲取所述so文件的版本信息。判斷所述so文件的版本是否是最新版本，可以先從Apk中提取出最新版本so文件的信息，再與獲取的所述版本信息比對。

第二種，根據文件大小更新。

考慮到升級后的文件往往文件大小會發(fā)生改變，則可以判斷所述so文件的文件大小是否與最新版本的so文件的文件大小相同，來確定所述so文件的版本是否是最新版本；

當所述so文件的版本是所述最新版本時，確定所述so文件為最新版本的so文件；

當所述so文件的版本不是所述最新版本時，刪除所述so文件，并拷貝最新版本的so文件至所述私有目錄。

在具體實施過程中，所述最新版本的so文件的文件大小信息可以從Apk中提取獲得。

當然，在具體實施過程中，確定所述私有目錄下存在最新版本的so文件不限于以上幾種確定方法，基于不同的需求可以確定出不同的確定方法，對此本發(fā)明實施例不再詳細列舉，并且不作限制。

在具體實施過程中，刪除版本較低的so文件的方法可以有多種，下面列舉兩種為例：

第一種，過濾出低版本文件，再刪除。

具體來講，可以先用Android提供的context.getDir()函數得到so存放的目錄路徑，再通過獲得的目錄路徑創(chuàng)建File對象，通過File類的函數listFiles()可以得到當前File對象所代表的當前目錄所有文件的數組，listFiles()函數支持傳遞文件過濾器FilenameFilter作為參數，其中，FilenameFilter是接口類，實現一FilenameFilter的接口后，可以自定義需要的返回的文件，故可以實現一過濾所有低于最新版本的so文件的文件過濾器，當得到過低so文件列表后可以遍歷該列表，然后調用File類中的delete()函數進行刪除操作。

第二種，直接刪除目錄中所述so文件。

具體來講，由于是在判斷所述so文件的版本不是所述最新版本后，才刪除的so文件，故可以先通過java的System.mapLibraryName()函數來獲得so文件的完整的文件名，再刪除該文件名的所有so文件。

當然，在具體實施過程中，刪除版本較低的so文件不限于以上幾種刪除方法，基于不同的需求可以確定出不同的刪除方法，對此本發(fā)明實施例不再詳細列舉，并且不作限制。

在本申請實施例中，所述拷貝最新版本的so文件至所述私有目錄的方法可以有多種，下面列舉兩種為例：

第一種，根據Apk路徑拷貝。

即先獲取所述應用的Apk的源路徑，再根據所述源路徑，從所述安裝包中抽取出最新版本的so文件，并拷貝所述最新版本的so文件至所述私有目錄。

具體來講，獲得Apk源路徑可以是，通過context.getApplicationInfo()函數實現，其中，getApplicationInfo()函數是Android提供用戶獲取應用屬性的類，getApplicationInfo()函數返回一ApplicationInfo類的對象，得到ApplicationInfo類的對象后通過ApplicationInfo類的sourceDir屬性可以獲取Apk的源路徑。

具體來講，從Apk中抽取出最新版本的so文件，并拷貝到私有目錄的方法可以是，通過Android提供用于操作Zip包的工具類ZipFile類抽取出對應的so文件。其實實現邏輯為：通過Apk源路徑作為參數創(chuàng)建一個ZipFile對象，將so文件目錄路徑作為參數傳入ZipFile類的getEntry()函數，其中，getEntry()函數用于獲取zip包下子文件節(jié)點，以得到對應so文件的文件節(jié)點，通過so文件的文件節(jié)點創(chuàng)建Java提供的IO操作的輸入工具類，即文件輸入流InputStream對象，然后，通過之前獲取的so文件存儲的私有目錄創(chuàng)建文件輸出流OutputStream對象，將輸入流寫入輸出流即完成so文件的拷貝操作。

第二種，根據Apk路徑和應用二進制接口(Application Binary Interface，ABI)型號拷貝。

考慮到在不同的電子設備上安裝應用，由于處理器不同，所以有不同的ABI型號，從而需要加載不同ABI型號對應的so文件，而Apk中是通過目錄名來區(qū)分對應ABI的so文件的，故拷貝so文件時，還需要加入ABI型號的考量，即所述拷貝最新版本的so文件至所述私有目錄，包括：

獲取所述應用的Apk的源路徑和需要加載所述應用的電子設備的應用二進制接口型號；

根據所述源路徑和所述應用二進制接口型號，從所述Apk中抽取出與所述應用二進制接口型號對應的最新版本的so文件；

拷貝所述最新版本的so文件至所述私有目錄。

需要說明的是，獲取Apk路徑的方法與前述第一種根據Apk路徑拷貝中獲取Apk路徑的方法相同，為了說明書的簡潔，在此不再累述。

具體來講，在Android當中處理器的類型不止一種，包括arm，arm-v7，x86，x86_64等等，而應用程序為了要適應多種處理器，往往在Apk中預先設置不止一種處理器的so文件，但是拷貝so文件到私有目錄時只需要對應當前處理器的so文件就行，所以需要先判斷當前電子設備支持的ABI型號，在Android5.0以上的版本中，系統提供Build.SUPPORTED_ABIS常量來供開發(fā)者讀取當前支持的ABI型號，在5.0以下的版本中可以通過Build.CPU_ABI常量來獲取ABI型號。

具體來講，從Apk中抽取出ABI型號對應的最新版本的so文件，并拷貝到私有目錄的方法可以是，通過Android提供用于操作Zip包的工具類ZipFile類抽取出對應的so文件。其實實現邏輯為：通過Apk源路徑作為參數創(chuàng)建一個ZipFile對象，通過當前獲得的ABI型號拼接對應的so目錄，并將其作為參數傳入ZipFile類的getEntry()函數，其中，getEntry()函數用于獲取zip包下子文件節(jié)點，以得到對應so文件的文件節(jié)點，通過so文件的文件節(jié)點創(chuàng)建Java提供的IO操作的輸入工具類，即文件輸入流InputStream對象，然后，通過之前獲取的so文件存儲的私有目錄創(chuàng)建文件輸出流OutputStream對象，將輸入流寫入輸出流即完成so文件的拷貝操作。

最后，執(zhí)行步驟S105，加載所述最新版本的so文件。

在具體實施過程中，可以通過System類的load()函數實現加載，具體可以將之前獲取的so文件存儲的私有目錄路徑作為參數傳入System.load函數，以完成對拷貝好的最新版本so文件進行重新加載。

在介紹了本實施例提供的方法的詳細流程后，為了便于理解本實施例提供的方法的完整邏輯過程，下面，將結合圖2提供所述方法的一完整實施邏輯例子：

首先，執(zhí)行步驟S201，在Android系統通過System.loadLibrary()加載包括so文件的應用；

接下來，執(zhí)行步驟S202，檢測是否拋出UnsatisfiedLinkError異常；

當步驟S202的檢測結果為否時，表示加載成功，加載邏輯結束，直接執(zhí)行步驟S210運行加載的應用程序；

當步驟S202的檢測結果為是時，表示出錯，執(zhí)行步驟S203，判斷所述應用默認的私有目錄下是否有so文件；

當步驟S203的判斷結果為否時，表示拷貝出錯，執(zhí)行步驟S206～S210，拷貝最新版本的so文件至私有目錄，并通過System.load函數重新加載最新版本so文件，加載邏輯結束后直接運行加載的應用程序；其中，圖2中的當前版本即指所述最新版本。

當步驟S203的判斷結果為是時，執(zhí)行步驟S204，判斷私有目錄下so文件版本是否低于最新版本；

當步驟S204的判斷結果為否時，表示為加載出錯，直接執(zhí)行步驟S209和步驟S210，通過System.load函數重新加載最新版本so文件，加載邏輯結束后直接運行加載的應用程序；

當步驟S204的判斷結果為是時，表示升級時覆蓋出錯，執(zhí)行步驟S205～S210，刪除低版本so文件，拷貝最新版本的so文件至私有目錄，并通過System.load函數重新加載最新版本so文件，加載邏輯結束后直接運行加載的應用程序。

基于同一發(fā)明構思，本發(fā)明實施例還提供了實施例一中方法對應的設備，見實施例二。

實施例二

本實施例提供了一種電子設備，請參考圖3，所述設備包括：

檢測模塊301，用于在Android系統加載應用時，檢測所述應用的so文件的加載狀態(tài)；

判斷模塊302，用于當檢測到所述so文件加載錯誤時，判斷所述應用的私有目錄下是否存在所述so文件；

第一處理模塊303，用于當所述私有目錄下存在所述so文件時，更新所述so文件為最新版本的so文件；

第二處理模塊304，用于當所述私有目錄下不存在所述so文件時，拷貝最新版本的so文件至所述私有目錄；

加載模塊305，用于加載所述最新版本的so文件。

舉例來說，所述所述電子設備可以為：智能手機、智能手表、筆記本電腦或平板電腦等，在此不作限制。

在本申請實施例中，所述第一處理模塊303包括：

第一獲取單元，用于獲取所述so文件的版本信息；

第一判斷單元，用于根據所述版本信息，判斷所述so文件的版本是否是最新版本；

確定單元，用于當所述so文件的版本是所述最新版本時，確定所述so文件為最新版本的so文件；

處理單元，用于當所述so文件的版本不是所述最新版本時，刪除所述so文件，并拷貝最新版本的so文件至所述私有目錄。

在本申請實施例中，所述第二處理模塊304包括：

第二獲取單元，用于獲取所述應用的安裝包的源路徑和需要加載所述應用的電子設備的應用二進制接口型號；

抽取單元，用于根據所述源路徑和所述應用二進制接口型號，從所述安裝包中抽取出與所述應用二進制接口型號對應的最新版本的so文件；

拷貝單元，用于拷貝所述最新版本的so文件至所述私有目錄。

在本申請實施例中，所述檢測模塊301還用于，檢測是否出現預設的加載異常語句；所述判斷模塊302還用于，用于當捕獲到所述加載異常語句時，判斷所述應用的私有目錄下是否存在所述so文件。

在本申請實施例中，所述判斷模塊302，包括：

第三獲取單元，用于獲取所述so文件的文件名信息和所述私有目錄下預設用于存儲so文件的目錄的路徑；

第二判斷單元，用于根據所述路徑和所述文件名信息，判斷所述應用的私有目錄下是否存在所述so文件。

由于本發(fā)明實施例二所介紹的電子設備，為實施本發(fā)明實施例一的Android系統so文件的加載方法所采用的電子設備，故而基于本發(fā)明實施例一所介紹的方法，本領域所屬人員能夠了解該設備的具體結構及變形，故而在此不再贅述。凡是本發(fā)明實施例一的方法所采用的設備都屬于本發(fā)明所欲保護的范圍。

本申請實施例中提供的技術方案，至少具有如下技術效果或優(yōu)點：

本申請實施例提供的方法及電子設備，在Android系統加載應用時，增加了對so文件加載錯誤的檢測，在捕獲到錯誤時主動判斷和確保私有目錄下存在最新的最新版本的so文件，并主動重新加載所述最新版本的so文件，一方面解決了當前so文件加載錯誤時閃退的問題，另一方面，能主動修復so文件加載錯誤，提高了so文件加載成功率。

本領域內的技術人員應明白，本發(fā)明的實施例可提供為方法、系統、或計算機程序產品。因此，本發(fā)明可采用完全硬件實施例、完全軟件實施例、或結合軟件和硬件方面的實施例的形式。而且，本發(fā)明可采用在一個或多個其中包含有計算機可用程序代碼的計算機可用存儲介質(包括但不限于磁盤存儲器、CD-ROM、光學存儲器等)上實施的計算機程序產品的形式。

本發(fā)明是參照根據本發(fā)明實施例的方法、設備(系統)、和計算機程序產品的流程圖和/或方框圖來描述的。應理解可由計算機程序指令實現流程圖和/或方框圖中的每一流程和/或方框、以及流程圖和/或方框圖中的流程和/或方框的結合?？商峁┻@些計算機程序指令到通用計算機、專用計算機、嵌入式處理機或其他可編程數據處理設備的處理器以產生一個機器，使得通過計算機或其他可編程數據處理設備的處理器執(zhí)行的指令產生用于實現在流程圖一個流程或多個流程和/或方框圖一個方框或多個方框中指定的功能的裝置。

這些計算機程序指令也可存儲在能引導計算機或其他可編程數據處理設備以特定方式工作的計算機可讀存儲器中，使得存儲在該計算機可讀存儲器中的指令產生包括指令裝置的制造品，該指令裝置實現在流程圖一個流程或多個流程和/或方框圖一個方框或多個方框中指定的功能。

這些計算機程序指令也可裝載到計算機或其他可編程數據處理設備上，使得在計算機或其他可編程設備上執(zhí)行一系列操作步驟以產生計算機實現的處理，從而在計算機或其他可編程設備上執(zhí)行的指令提供用于實現在流程圖一個流程或多個流程和/或方框圖一個方框或多個方框中指定的功能的步驟。

盡管已描述了本發(fā)明的優(yōu)選實施例，但本領域內的技術人員一旦得知了基本創(chuàng)造性概念，則可對這些實施例作出另外的變更和修改。所以，所附權利要求意欲解釋為包括優(yōu)選實施例以及落入本發(fā)明范圍的所有變更和修改。

顯然，本領域的技術人員可以對本發(fā)明實施例進行各種改動和變型而不脫離本發(fā)明實施例的精神和范圍。這樣，倘若本發(fā)明實施例的這些修改和變型屬于本發(fā)明權利要求及其等同技術的范圍之內，則本發(fā)明也意圖包含這些改動和變型在內。