JP2023539879A - 共有ライブラリを再利用するための方法および電子デバイス - Google Patents

Abstract

本出願の実施形態は、電子デバイス技術の分野に関し、電子製品の記憶空間の利用を改善するために、異なるアプリケーションAPPが実行中に同じ共有ライブラリを呼び出すことを可能にするために、共有ライブラリおよび電子デバイスを再利用するための方法を提供する。具体的な解決策は、電子デバイスが、第1のAPPの第1の共有ライブラリと同じファイルデータを有する第2の共有ライブラリが電子デバイス内に存在するかどうかを判定することを含む。第2の共有ライブラリが電子デバイス内に存在する場合には、第1のインデックスノード（inode）と第1の共有ライブラリのファイル名との間の対応関係が記憶され、第1の共有ライブラリのファイルデータが電子デバイスから削除される。次いで、電子デバイスが第1のAPPを実行して第1の共有ライブラリを呼び出すときに、電子デバイスは、第1の共有ライブラリのファイル名に対応する第1のinodeを検索して、第1のinodeによって示される記憶領域に記憶されている第2の共有ライブラリのファイルデータを読み出すことができる。

Description

本出願は、2020年8月31日付で中国国家知識産権局に出願された、「METHOD FOR REUSING SHARED LIBRARY AND ELECTRONIC DEVICE」という名称の中国特許出願第202010899468．4号の優先権を主張するものであり、参照によりその全体が本明細書に組み込まれる、

本出願の実施形態は、電子デバイス技術の分野に関し、特に、共有ライブラリを再利用するための方法および電子デバイスに関する。

科学および技術の発展に伴い、ユーザは、携帯電話またはインテリジェント・ウェアラブル・デバイスなどの電子製品の機能に対する要求が高まっている。電子製品を使用するためのユーザの要求を満たすために、電子製品におけるアプリケーション（Application、APP）が徐々に増加している。現在、各APPは、実行可能プログラムおよび複数の共有ライブラリを含む。共有ライブラリには、Windowsオペレーティングシステムにおけるダイナミック・リンク・ライブラリ、Linux(登録商標)オペレーティングシステムにおける共有ターゲットなどが含まれる。具体的には、ユーザが電子製品にAPPをインストールした後に、APPの実行可能プログラムおよび複数の共有ライブラリが電子製品に記憶される。

しかしながら、オープンソースのコードおよびプラットフォーム技術の開発に伴い、異なるAPPが開発中に同じ共有ライブラリを使用する場合がある。したがって、電子製品内のAPPの数が増加すると、電子製品は複数の同じ共有ライブラリを記憶し、電子製品の記憶スペースの浪費を引き起こす可能性がある。

本出願の実施形態は、電子製品の記憶空間の利用を改善するために、異なるAPPが実行中に同じ共有ライブラリを呼び出すことを可能にするために、共有ライブラリを再使用するための方法を提供する。

第1の態様によれば、本出願の一実施形態は、共有ライブラリを再利用するための方法を提供する。本方法は電子デバイスに適用され得、複数のAPPが電子デバイスにインストールされ、複数のAPPの各々は少なくとも1つの共有ライブラリを含む。例えば、少なくとも1つの共有ライブラリは、第2の共有ライブラリを含むことができる。

共有ライブラリを再利用するための方法によれば、電子デバイスは、第1のAPPの第1の共有ライブラリと同じファイルデータを有する第2の共有ライブラリが電子デバイス内に存在するかどうかを判定することができる。第1の共有ライブラリは、第1のAPP内の任意の共有ライブラリである。第2の共有ライブラリが電子デバイス内に存在する場合には、第1のインデックスノード（inode）と第1の共有ライブラリのファイル名との間の対応関係が記憶され、第1の共有ライブラリのファイルデータが電子デバイスから削除される。第1のinodeは、電子デバイスによって第2の共有ライブラリに割り当てられ、第1のinodeは、第2の共有ライブラリのファイルデータを記憶するために使用される第1の記憶領域を示すことができる。言い換えれば、電子デバイスは、第1のinodeに基づいて、電子デバイス内にあって、第2の共有ライブラリのファイルデータを記憶する第1の記憶領域を決定することができる。次いで、電子デバイスが第1のAPPを実行して第1の共有ライブラリを呼び出すときに、電子デバイスは、第1の共有ライブラリのファイル名に対応する第1のinodeを検索して、第1のinodeによって示される記憶領域に記憶されている第2の共有ライブラリのファイルデータを読み出すことができる。

上記の技術的解決策に基づいて、第1のAPPの第1の共有ライブラリと同じファイルデータを有する第2の共有ライブラリが電子デバイス内に存在する場合には、電子デバイスは、第2の共有ライブラリのファイルデータを記憶するだけでなく、第1の共有ライブラリのファイルデータも記憶するので、電子デバイスの記憶空間が浪費される。したがって、第1のAPPの第1の共有ライブラリと同じファイルデータを有する第2の共有ライブラリが電子デバイス内に存在する場合、電子デバイスは、第1の共有ライブラリのファイルデータを削除することができる。このようにして、電子デバイスの記憶空間の利用率が向上され得る。

さらに、電子デバイスが第1のAPPを正常に実行することを保証するために、電子デバイスは、第1のinodeと第1の共有ライブラリのファイル名との間の対応関係をさらに記憶することができる。このようにして、電子デバイスが第1の共有ライブラリを呼び出すために第1のAPPを実行するとき、電子デバイスは、第1の共有ライブラリのファイルデータを呼び出す必要がなく、第2の共有ライブラリのファイルデータを読み出すために第1の共有ライブラリのファイル名を使用して第1のinodeを検索するだけでよいので、APPの正常な実行を保証する。

第1の態様に関して、可能な設計方式では、APPを実行して共有ライブラリを呼び出すときに、電子デバイスは、共有ライブラリをメモリにマッピングし、次いでメモリから共有ライブラリを呼び出すことができる。これにより、電子デバイスの性能が向上され得る。従来の技術では、複数のAPP（例えば、第1のAPPおよび第2の共有ライブラリを含む第2のAPP）を実行するとき、電子デバイスは、第1の共有ライブラリおよび第2の共有ライブラリをメモリに別々にマッピングする。マッピングされたデータ量が多いため、I／O性能に影響を与えるだけでなく、メモリ空間の無駄が生じる。しかしながら、本出願のこの実施形態では、電子デバイスは、第2の共有ライブラリのみをメモリにマッピングし、第1のAPPおよび第2のAPPの両方は、実行中にメモリから第2の共有ライブラリのファイルデータを呼び出すことができる。このようにして、メモリにマッピングされるデータ量が削減され、I／O性能が向上されるだけでなく、メモリの占有空間が削減され得、メモリの利用率が向上される。

第1の態様に関して、別の可能な設計方式では、「電子デバイスは、第1のAPPの第1の共有ライブラリと同じファイルデータを有する第2の共有ライブラリが電子デバイス内に存在するかどうかを判定する」方法は、電子デバイスが第1のAPPのインストールを完了すると、電子デバイスが、第1のAPPの第1の共有ライブラリと同じファイルデータを有する第2の共有ライブラリが電子デバイス内に存在するかどうかを判定すること、または、電子デバイスが第1のAPPの実行を完了すると、電子デバイスが、第1のAPPの第1の共有ライブラリと同じファイルデータを有する第2の共有ライブラリが電子デバイス内に存在するかどうかを判定することを含む。

前述の技術的解決策に基づいて、電子デバイス内のAPP（例えば、第1のAPP）がプラットフォームから電子デバイスにダウンロードされると、電子デバイスは、第1のAPPのインストールプロセスを監視することができ、第1のAPPのインストールを完了すると、電子デバイスは、電子デバイスが第1の共有ライブラリと同じファイルデータを有する第2の共有ライブラリを記憶しているかどうかを検出し、その結果、電子デバイスは、同じ共有ライブラリが記憶されているかどうかを適時に発見することができる。加えて、電子デバイスは、第1のAPPの動作に影響を与えることを回避するために、第1のAPPのインストールを完了するときに検出を実行する。

しかしながら、電子デバイス内のAPP（例えば、第1のAPP）が別の取り外し可能な記憶装置から電子デバイスにコピーされると、電子デバイスは、第1のAPPのコピープロセスを監視することができない。したがって、コピーされた第1のAPPが実行されるときにのみ、電子デバイスは、第1のAPPを監視し、電子デバイスが第1の共有ライブラリと同じファイルデータを有する第2の共有ライブラリを記憶しているかどうかを検出することができ、その結果、電子デバイスは、同じ共有ライブラリが記憶されているかどうかを適時に発見する。加えて、電子デバイスは、APPの実行に影響を与えることを回避するために、第1のAPPの実行を完了するときに検出を実行する。

第1の態様に関して、別の可能な設計方式では、「電子デバイスが第1のAPPの実行を完了すると、電子デバイスは、第1のAPPの第1の共有ライブラリと同じファイルデータを有する第2の共有ライブラリが電子デバイス内に存在するかどうかを判定する」ことは、電子デバイスが第1のAPPの実行を初めて完了するときに、電子デバイスは、第1のAPPの第1の共有ライブラリと同じファイルデータを有する第2の共有ライブラリが電子デバイス内に存在するかどうかを判定することを含むことができる。

前述の解決策によれば、電子デバイスが、第1のAPPの第1の共有ライブラリと同じファイルデータを有する第2の共有ライブラリが電子デバイス内に存在すると判定した場合には、電子デバイスは、第1の共有ライブラリのファイルデータを削除できることが理解されよう。この場合、電子デバイスが最初に第1のAPPの実行を完了した後に、電子デバイスは、第1の共有ライブラリのファイルデータを削除することができる。したがって、第1のAPPを再び実行した後に、電子デバイスは、第1のAPPの第1の共有ライブラリと同じファイルデータを有する第2の共有ライブラリが電子デバイス内に存在するかどうかを判定する必要がない。このようにして、電子デバイスの計算圧力が低減され得る。

第1の態様に関して、別の可能な設計方式では、本方法は、第2の共有ライブラリが電子デバイス内に存在しない場合には、電子デバイスが第1の共有ライブラリに第2のinodeを割り当て、第2のinodeと第1の共有ライブラリのファイル名との間の対応関係を記憶することをさらに含む。第2のinodeは、第1の共有ライブラリのファイルデータを記憶するための第2の記憶領域を示す。次いで、電子デバイスは、第1のAPPを実行して第1の共有ライブラリを呼び出すときに、第1の共有ライブラリのファイル名に対応する第2のinodeを検索し、第2のinodeによって示される第2の記憶領域に記憶された第1の共有ライブラリのファイルデータを読み出す。

この場合に基づいて、第1のAPPの第1の共有ライブラリと同じファイルデータを有する第2の共有ライブラリが電子デバイス内に存在しない場合には、それは、電子デバイス内に第1の共有ライブラリを置き換えることができる共有ライブラリがないことを示す。したがって、電子デバイスは、第1の共有ライブラリを記憶してもよい。このようにして、電子デバイスが第1の共有ライブラリを呼び出すために第1のAPPを実行するとき、電子デバイスは、第1の共有ライブラリのファイルデータを読み出すために、第1の共有ライブラリのファイル名を使用して第2のinodeを検索することができるので、APPの正常な実行を保証することができる。

第1の態様に関して、別の可能な設計方式では、本方法は、さらに以下を含む。第2の共有ライブラリが電子デバイス内に存在する場合には、電子デバイスが第1のinodeのリンク数に1を加算し、第1のinodeのリンク数が第1のinodeに対応する共有ライブラリの数であるか、または、第2の共有ライブラリが電子デバイス内に存在しない場合には、電子デバイスは、第2のinodeのリンク数に1を加算し、第2のinodeのリンク数が第2のinodeに対応する共有ライブラリの数であり、各inodeのリンク数の初期値は0である。

具体的には、第2の共有ライブラリが電子デバイス内に存在する場合には、第1の共有ライブラリが第2の共有ライブラリで置き換えられ得ることを示す。加えて、第1のinodeは電子デバイスによって第2の共有ライブラリに割り当てられるので、電子デバイスは、第1のinodeに対応する共有ライブラリの数を更新するために、第1のinodeのリンク数に1を加算するように第1のinodeのリンク数を変更する。したがって、電子デバイスは、第1のinodeのリンク数に基づいて、第2の共有ライブラリによって置き換えられる共有ライブラリの数を決定することができる。

第2の共有ライブラリが電子デバイス内に存在しない場合には、電子デバイスに第1の共有ライブラリを置き換えることができる共有ライブラリがないことを示す。したがって、電子デバイスは、第2のinodeに対応する共有ライブラリの数を更新するために、第2のinodeのリンク数に1を加算するように第2のinodeのリンク数を変更する。したがって、電子デバイスは、第2のinodeのリンク数に基づいて、第1の共有ライブラリによって置き換えられる共有ライブラリの数を決定することができる。

第1の態様に関して、別の可能な設計方式では、本方法はさらに以下を含む。第2のAPPを削除するときに、電子デバイスが、第3の共有ライブラリのファイル名に対応する第3のinodeを検索し、第3のinodeのリンク数が1に等しい場合には、電子デバイスは、電子デバイスから、第3の共有ライブラリのファイルデータ、第3のinode、および第3の共有ライブラリのファイル名と第3のinodeとの間の対応関係を削除するか、または、第3のinodeのリンク数が1より大きい場合には、電子デバイスは、第3のinodeのリンク数から1を減算する。

第3のinodeのリンク数が1に等しい場合には、それは、第3の共有ライブラリが別の共有ライブラリを置き換える必要がないこと、すなわち、第2のAPP以外のAPPが実行中に第3の共有ライブラリを呼び出さないことを示すことが理解されよう。加えて、電子デバイスが第2のAPPを削除した後に、電子デバイス内のいずれのAPPも第3の共有ライブラリを呼び出さない。したがって、電子デバイスが第2のAPPを削除するとき、電子デバイスは、第3の共有ライブラリのファイルデータ、第3のinode、および第3の共有ライブラリのファイル名と第3のinodeとの間の対応関係を削除して、電子デバイスの記憶空間を節約することができる。

第3のinodeのリンク数が1より大きい場合には、それは、第3の共有ライブラリが別の共有ライブラリを置き換える必要があること、すなわち、第2のAPP以外のAPPが実行中に第3の共有ライブラリを呼び出す必要があり得ることを示す。したがって、別のAPPの正常な実行を保証するために、電子デバイスは、第3の共有ライブラリを削除することができない。加えて、電子デバイスは第2のAPPを削除するので、すなわち、第3の共有ライブラリを呼び出すAPPの数が減少するので、電子デバイスは、第3のinodeに対応する共有ライブラリの数を更新するために、第3のinodeのリンク数を変更する。したがって、電子デバイスは、第3のinodeのリンク数に基づいて、第3の共有ライブラリによって置き換えられる共有ライブラリの数を決定することができる。

第1の態様に関して、別の可能な設計方式では、「電子デバイスは、第1のAPPの第1の共有ライブラリと同じファイルデータを有する第2の共有ライブラリが電子デバイス内に存在するかどうかを判定する」方法は、以下を含む。電子デバイスが、事前設定されたアルゴリズムを用いて第1の共有ライブラリのファイルデータに基づいて第1の共有ライブラリの第1の識別情報を生成し、第1の識別情報が第2の識別情報と同じであるかどうかを判定し、第2の識別情報は、事前設定されたアルゴリズムを用いて電子デバイス内の任意の共有ライブラリのファイルデータに基づいて電子デバイスによって生成される。

具体的には、第1の識別情報と第2の識別情報とが同じである場合には、第1の共有ライブラリと同じファイルデータを有する第2の共有ライブラリが電子デバイス内に存在すると判定されるか、または、第1の識別情報と第2の識別情報とが異なる場合には、第1の共有ライブラリと同一のファイルデータを有する第2の共有ライブラリが電子デバイス内に存在しないと判定される。

第1の態様に関して、別の可能な設計方式では、本方法は、第1の識別情報が第2の識別情報と異なるときに、電子デバイスが第1の識別情報と第2のinodeとの間の対応関係を記憶すること、をさらに含む。

第1の識別情報が第2の識別情報と異なる場合、第1の共有ライブラリと同じファイルデータを有する第2の共有ライブラリが電子デバイス内に存在しないことを示すことが理解されよう。したがって、電子デバイスは、第1の識別情報と第2のinodeとの間の対応関係を記憶する必要があり、その結果、第1の共有ライブラリを記憶した後に、電子デバイスは、第1の識別情報に基づいて、電子デバイスに記憶されている別の共有ライブラリのファイルデータが第1の共有ライブラリと同じであるかどうかを判定することができる。

第1の態様に関して、別の可能な設計方式では、本方法はさらに以下を含む。第3のinodeのリンク数が1に等しい場合には、第3のinodeと第3の識別情報との間の対応関係が電子デバイスから削除され、第3の識別情報は、事前設定されたアルゴリズムを用いて第3の共有ライブラリのファイルデータに基づいて電子デバイスによって生成される。

第3のinodeのリンク数が1に等しい場合には、それは、第3の共有ライブラリが別の共有ライブラリを置き換える必要がないこと、すなわち、第2のAPP以外のAPPが実行中に第3の共有ライブラリを呼び出さないことを示すことが理解されよう。加えて、電子デバイスが第2のAPPを削除した後に、電子デバイス内のいずれのAPPも第3の共有ライブラリを呼び出さない。したがって、電子デバイスが第2のAPPを削除するとき、電子デバイスは、電子デバイスの記憶空間を節約するために、第3のinodeと第3の識別情報との間の対応関係を削除する。

第1の態様に関して、別の可能な設計方式では、本方法は、電子デバイスが、第1の共有ライブラリのファイルデータを電子デバイス内の各共有ライブラリのファイルデータと比較し、第1の共有ライブラリと同じファイルデータを有する第2の共有ライブラリが電子デバイス内に存在するかどうかを判定することをさらに含む。

第2の態様によれば、本出願の一実施形態は電子デバイスを提供する。電子デバイスには、複数のアプリケーションがインストールされており、複数のAPPの各々は少なくとも1つの共有ライブラリを含む。電子デバイスは、処理ユニットおよび記憶ユニットを含む。

記憶ユニットは、少なくとも1つの共有ライブラリを記憶するように構成される。処理ユニットは、第1のAPPの第1の共有ライブラリと同じファイルデータを有する第2の共有ライブラリが記憶ユニット内に存在するかどうかを判定するように構成され、第1の共有ライブラリは第1のAPP内の任意の共有ライブラリである。記憶ユニットは、第2の共有ライブラリが記憶ユニット内に存在する場合には、第1のインデックスノードinodeと第1の共有ライブラリのファイル名との間の対応関係を記憶するようにさらに構成され、第1のinodeは、処理ユニットによって第2の共有ライブラリに割り当てられ、第1のinodeは、第2の共有ライブラリのファイルデータを記憶するために使用される第1の記憶領域を示す。処理ユニットは、記憶ユニットから第1の共有ライブラリのファイルデータを削除するようにさらに構成される。処理ユニットは、第1のAPPを実行して第1の共有ライブラリを呼び出すときに、第1の共有ライブラリのファイル名に対応する第1のinodeを検索し、第1のinodeによって示される記憶領域に記憶された第2の共有ライブラリのファイルデータを読み出すようにさらに構成される。

第2の態様に関して、可能な設計方式では、処理ユニットは、第1のAPPのインストールを完了するときに、第1のAPPの第1の共有ライブラリと同じファイルデータを有する第2の共有ライブラリが記憶ユニット内に存在するかどうかを判定するか、あるいは、第1のAPPの実行を完了するときに、第1のAPPの第1の共有ライブラリと同じファイルデータを有する第2の共有ライブラリが記憶ユニット内に存在するかどうかを判定する、ように具体的に構成される。

第2の態様に関して、別の可能な設計方式では、処理ユニットは、第1のAPPの実行を初めて完了するときに、第1のAPPの第1の共有ライブラリと同じファイルデータを有する第2の共有ライブラリが記憶ユニット内に存在するかどうかを判定するように具体的に構成される。

第2の態様に関して、別の可能な設計方式では、処理ユニットは、第2の共有ライブラリが記憶ユニット内に存在しない場合には、第2のinodeを第1の共有ライブラリに割り当てるようにさらに構成され、第2のinodeは、第1の共有ライブラリのファイルデータを記憶するために使用される第2の記憶領域を示し、記憶ユニットは、第2のinodeと第1の共有ライブラリのファイル名との間の対応関係を記憶するようにさらに構成される。

処理ユニットは、第1のAPPを実行して第1の共有ライブラリを呼び出すときに、第1の共有ライブラリのファイル名に対応する第2のinodeを検索し、第2のinodeによって示される第2の記憶領域に記憶された第1の共有ライブラリのファイルデータを読み出すようにさらに構成される。

第2の態様に関して、別の可能な設計方式では、処理ユニットは、第2の共有ライブラリが記憶ユニット内に存在する場合には、第1のinodeのリンク数に1を加算し、第1のinodeのリンク数は、第1のinodeに対応する共有ライブラリの数であるか、または、第2の共有ライブラリが記憶ユニット内に存在しない場合には、第2のinodeのリンク数に1を加算し、第2のinodeのリンク数は第2のinodeに対応する共有ライブラリの数であり、各inodeのリンク数の初期値は0である、ようにさらに構成される。

第2の態様に関して、別の可能な設計方式では、処理ユニットは、第2のAPPを削除するときに、第3の共有ライブラリのファイル名に対応する第3のinodeを検索し、第3のinodeのリンク数が1に等しい場合には、第3の共有ライブラリのファイルデータ、第3のinode、および第3の共有ライブラリのファイル名と第3のinodeとの間の対応関係を記憶ユニットから削除するか、または、第3のinodeのリンク数が1より大きい場合には、第3のinodeのリンク数から1を減算する、ようにさらに構成される。

第2の態様に関して、別の可能な設計方式では、処理ユニットは、事前設定されたアルゴリズムを用いて第1の共有ライブラリのファイルデータに基づいて第1の共有ライブラリの第1の識別情報を生成し、第1の識別情報が第2の識別情報と同じであるかどうかを判定し、第2の識別情報は、事前設定されたアルゴリズムを用いて記憶ユニット内の任意の共有ライブラリのファイルデータに基づいて処理ユニットによって生成され、第1の識別情報が第2の識別情報と同じである場合には、第1の共有ライブラリと同じファイルデータを有する第2の共有ライブラリが記憶ユニット内に存在すると判定するか、または第1の識別情報と第2の識別情報とが異なる場合には、第1の共有ライブラリと同じファイルデータを有する第2の共有ライブラリが記憶ユニット内に存在しないと判定する、ように具体的に構成される。

第2の態様に関して、別の可能な設計方式では、記憶ユニットは、第1の識別情報が第2の識別情報と異なる場合には、第1の識別情報と第2のinodeとの間の対応関係を記憶する、ようにさらに構成される。

第2の態様に関して、別の可能な設計方式では、処理ユニットは、第3のinodeのリンク数が1に等しい場合には、第3のinodeと第3の識別情報との間の対応関係を記憶ユニットから削除し、第3の識別情報は、事前設定されたアルゴリズムを用いて第3の共有ライブラリのファイルデータに基づいて処理ユニットによって生成される、ようにさらに構成される。

第2の態様に関して、別の可能な設計方式では、処理ユニットは、第1の共有ライブラリのファイルデータを記憶ユニット内の各共有ライブラリのファイルデータと比較し、第1の共有ライブラリと同じファイルデータを有する第2の共有ライブラリが記憶ユニット内に存在するかどうかを判定するように具体的に構成される。

第3の態様によれば、本出願の一実施形態は、電子デバイスを提供する。電子デバイスには、複数のアプリケーションAPPがインストールされており、複数のAPPの各々は、少なくとも1つの共有ライブラリを含む。電子デバイスはメモリおよびプロセッサを含み、メモリはプロセッサに結合される。少なくとも1つの共有ライブラリがメモリに記憶され、メモリはコンピュータプログラムコードを記憶するようにさらに構成され、コンピュータプログラムコードはコンピュータ命令を含む。コンピュータ命令がプロセッサによって実行されると、電子デバイスは、第1の態様または第1の態様の可能な設計方式のいずれか1つによる方法を実行することを可能にされる。

第4の態様によれば、本出願の一実施形態は、チップシステムを提供する。チップシステムは、電子デバイスに適用され、電子デバイスには複数のAPPがインストールされ、複数のAPPの各々は、少なくとも1つの共有ライブラリを含む。チップシステムは、1つまたは複数のインターフェース回路と、1つまたは複数のプロセッサと、を含む。インターフェース回路とプロセッサとは、回線を介して相互接続される。インターフェース回路は、電子デバイスのメモリから信号を受信し、信号をプロセッサに送信するように構成され、信号はメモリに記憶されたコンピュータ命令を含む。プロセッサがコンピュータ命令を実行すると、電子デバイスは、第1の態様および第1の態様の可能な設計方式のいずれか1つによる方法を実行する。

第5の態様によれば、本出願の一実施形態は、コンピュータ記憶媒体を提供する。コンピュータ記憶媒体はコンピュータ命令を含み、コンピュータ命令が電子デバイス上で実行されると、電子デバイスは、第1の態様および第1の態様の可能な設計方式のいずれか1つによる方法を実行することを可能にされる。

第6の態様によれば、本出願の一実施形態は、コンピュータプログラム製品を提供する。コンピュータプログラム製品がコンピュータ上で実行されると、コンピュータは、第1の態様および第1の態様の可能な設計方式のいずれか1つによる方法を実行することを可能にされる。

第2の態様および第2の態様の可能な設計方式のいずれか1つによる電子デバイス、第3の態様による電子デバイス、第4の態様によるチップシステム、第5の態様によるコンピュータ記憶媒体、ならびに第6の態様によるコンピュータプログラム製品によって達成され得る有益な効果については、第1の態様および第1の態様の可能な設計方式のいずれか1つで達成される有益な効果を参照することが理解されよう。ここでは詳細を繰り返さない。

本出願の一実施形態による電子デバイスのハードウェア構造の概略図である。 本出願の一実施形態による電子デバイスのシステムフレームワーク図である。 本出願の一実施形態による別の電子デバイスのシステムフレームワーク図である。 本出願の一実施形態による共有ライブラリを再利用するための方法のフローチャートである。 本出願の一実施形態によるさらに別の電子デバイスのシステムフレームワーク図である。 本出願の一実施形態による共有ライブラリを再利用するための別の方法のフローチャートである。 本出願の一実施形態による共有ライブラリを再利用するためのさらに別の方法のフローチャートである。 本出願の一実施形態による、APPと、共有ライブラリと、inodeと、記憶領域との間の関係の概略図である。 本出願の一実施形態による、APPと、共有ライブラリと、inodeと、記憶領域との間の関係の別の概略図である。 本出願の一実施形態による共有ライブラリを再利用するための装置の概略構成図である。 本出願の一実施形態によるチップシステムの構造の概略構成図である。

以下で言及される用語「第1の」および「第2の」は、単に説明の目的のために意図されており、相対的な重要性の指示もしくは暗示、または示された技術的特徴の量の暗示的な指示として理解されるべきではない。したがって、「第1の」または「第2の」によって限定されている特徴は、1つまたは複数のこのような特徴を明示的または暗黙的に含んでもよい。実施形態の説明において、特に明記しない限り、「複数の」は2つまたは3つ以上を意味する。

本出願の実施形態は、共有ライブラリを再利用するための方法を提供する。本方法は、複数のAPPがインストールされ、複数のAPP（例えば、第1のAPPおよび第2のAPP）の各々が少なくとも1つの共有ライブラリを含む電子デバイスに適用され得る。

本出願の実施形態におけるAPPは、電子デバイスにインストールされたダウンロード可能なアプリケーションであってもよい。ダウンロード可能なアプリケーションは、ダウンロード可能なアプリケーションのインターネットプロトコルマルチメディアサブシステム（Internet Protocol Multimedia Subsystem，IMS）接続を提供することができるアプリケーションである。ダウンロード可能なアプリケーションは、電子デバイスに予めインストールされたアプリケーション、またはユーザによってダウンロードされ、電子デバイスにインストールされ得る第三者アプリケーション（例えば、第1のAPPおよび第2のAPP）であってもよい。

例えば、第1のAPPは、「カレンダー」または「ノートパッド」などの電子デバイスに予めインストールされたアプリケーションであってもよく、第2のAPPは、ユーザによってダウンロードされて電子デバイスにインストールされた決済アプリケーションまたはビデオアプリケーションなどの第三者アプリケーションであってもよい。

可能な設計では、第1のAPPのインストールを完了した後に、電子デバイスは、本出願の実施形態で提供される共有ライブラリを再利用するための方法を実行することができる。

例えば、電子デバイスは、そのオペレーティングシステムがアンドロイド（登録商標）（Android（登録商標））である携帯電話であってもよく、第1のAPPはショッピングアプリケーションであってもよい。携帯電話がショッピングアプリケーションのインストールを完了すると、すなわち、携帯電話は、アンドロイド（登録商標）アプリケーションパッケージ（Android（登録商標）application package、APK）を解凍するプロセスを完了し、ショッピングアプリケーションの実行可能プログラムを携帯電話に記憶する。実行可能プログラムが第1の共有ライブラリおよび第3の共有ライブラリを呼び出す必要がある場合、本方法が実行され得る。

電子デバイス内のAPP（例えば、第1のAPP）のインストールパッケージがネットワークプラットフォームから電子デバイスにダウンロードされるとき、または電子デバイスが第1のAPPのインストールパッケージを予め記憶するとき、電子デバイスは、第1のAPPのインストールプロセスを監視し、電子デバイスが第1のAPPのインストールを完了するときに本方法を実行することができ、その結果、電子デバイスは、同じ共有ライブラリが記憶されているかどうかを適時に検出することができることが理解されよう。

別の可能な設計では、第1のAPPの実行を完了した後に、電子デバイスは、本出願の実施形態で提供される共有ライブラリを再利用するための方法を実行することができる。

例えば、電子デバイスは、そのオペレーティングシステムがAndroid（登録商標）である携帯電話であってもよく、第1のAPPはショッピングアプリケーションであってもよい。携帯電話は、ショッピングアプリケーションのプロセスが終了するまで、すなわち携帯電話が初めてショッピングアプリケーションの実行を停止するまで、ショッピングアプリケーションを実行するときに方法を実行することができる。

電子デバイス内のAPP（例えば、第1のAPP）が別の取り外し可能な記憶装置から電子デバイスにコピーされるとき、電子デバイスは、第1のAPPのコピープロセスを監視することができないことが理解されよう。したがって、コピーされた第1のAPPが実行されるときにのみ、電子デバイスは、第1のAPPを監視し、電子デバイスが第1の共有ライブラリと同じファイルデータを有する第2の共有ライブラリを記憶しているかどうかを検出することができ、その結果、電子デバイスは、同じ共有ライブラリが記憶されているかどうかを適時に発見する。加えて、電子デバイスは、APPの実行に影響を与えることを回避するために、第1のAPPの実行を完了するときに検出を実行する。

任意選択で、第1のAPPの実行を初めて完了するとき、電子デバイスは、本出願の実施形態で提供される共有ライブラリを再利用するための方法を実行することができる。

電子デバイスが、第1のAPPの第1の共有ライブラリと同じファイルデータを有する第2の共有ライブラリが電子デバイス内に存在すると判定した場合には、電子デバイスは、第1の共有ライブラリのファイルデータを削除し得ることが理解されよう。この場合、電子デバイスが最初に第1のAPPの実行を完了した後に、電子デバイスは、第1の共有ライブラリのファイルデータを削除することができる。したがって、第1のAPPを再び実行した後に、電子デバイスは、第1のAPPの第1の共有ライブラリと同じファイルデータを有する第2の共有ライブラリが電子デバイス内に存在するかどうかを判定する必要がない。このようにして、電子デバイスの計算圧力が低減され得る。

本方法を実行することにより、電子デバイスは、電子デバイスに記憶された共有ライブラリ（例えば、第1の共有ライブラリ）と同じファイルデータを有する共有ライブラリ（例えば、第2の共有ライブラリ）を削除することができ、電子デバイスの記憶空間の利用率を向上させることができる。加えて、第2の共有ライブラリが第1の共有ライブラリを置き換えるので、異なるAPPが同じ共有ライブラリを呼び出してAPPの正常な実行を保証することができる。

例えば、本出願の実施形態における電子デバイスは、複数のAPP（複数のAPPのそれぞれは少なくとも1つの共有ライブラリを含む）がインストールされているデバイス、例えば、タブレットコンピュータ、携帯電話、デスクトップ、ラップトップ、ハンドヘルドコンピュータ、ノートブックコンピュータ、ウルトラモバイルパーソナルコンピュータ（ultra－mobile personal computer、UMPC）、ネットブック、携帯電話、携帯情報端末（personal digital assistant、PDA）、拡張現実（augmented reality、AR）／仮想現実（virtual reality、VR）デバイス、または車載デバイスであってもよい。電子デバイスの特定の形態については本出願の実施形態では特に限定されない。

本出願で提供される共有ライブラリを再利用するための方法は、共有ライブラリを再利用するための装置（以下、「再利用装置」と呼ぶ）によって実行されてもよく、再利用装置は図1に示す電子デバイスであってもよい。加えて、再利用装置は、代替的に、電子デバイスの中央処理装置（Central Processing Unit、CPU）、または電子デバイス内の共有ライブラリを再利用するように構成された制御モジュールであってもよい。本出願の実施形態では、本出願の実施形態で提供される共有ライブラリを再利用するための方法は、電子デバイスが共有ライブラリを再利用するための方法を実行する例を使用して説明される。

図1に示すように、本出願では、電子デバイスが図1に示す携帯電話100である例を本明細書で使用して、本出願で提供される電子デバイスを説明する。図1に示す携帯電話100は、単に電子デバイスの一例であり、携帯電話100は、図に示すものよりも多いまたは少ない構成要素を有してもよく、2つ以上の構成要素を組み合わせてもよく、または異なる構成要素構成を有してもよい。図1に示す様々な構成要素は、1つまたは複数の信号処理および／または特定用途向け集積回路を含むハードウェア、ソフトウェア、またはハードウェアとソフトウェアとの組み合わせで実装されてもよい。

図1に示すように、携帯電話100は、プロセッサ110、外部メモリインターフェース120、内部メモリ121、ユニバーサルシリアルバス（universal serial bus、USB）インターフェース130、充電管理モジュール140、電力管理モジュール141、バッテリ142、アンテナ1、アンテナ2、移動通信モジュール150、無線通信モジュール160、オーディオモジュール170、スピーカ170A、受信機170B、マイクロフォン170C、ヘッドセットジャック170D、センサモジュール180、ボタン190、モータ191、インジケータ192、カメラ193、ディスプレイ194、加入者識別モジュール（subscriber identification module、SIM）カードインターフェース195などを含んでもよい。

センサモジュール180は、圧力センサ、ジャイロセンサ、気圧センサ、磁気センサ、加速度センサ、距離センサ、光近接センサ、指紋センサ、温度センサ、タッチセンサ、周囲光センサ、骨伝導センサなどを含んでもよい。

この実施形態に示す構造は、携帯電話100に対する特定の制限を構成しないことが理解されよう。いくつかの他の実施形態では、携帯電話100は、図に示すものよりも多いまたは少ない構成要素を含んでもよく、またはいくつかの構成要素が組み合わされてもよく、またはいくつかの構成要素が分割されてもよく、または異なる構成要素レイアウトがあってもよい。図に示す構成要素は、ハードウェア、ソフトウェア、またはソフトウェアとハードウェアの組み合わせによって実装されてもよい。

プロセッサ110は、携帯電話100の制御センタであり、様々なインターフェースおよび回線を介して携帯電話100の様々な部分に接続される。プロセッサ110は、携帯電話100の様々な機能を実行し、内部メモリ121に記憶されたアプリケーションプログラムを実行し、内部メモリ121に記憶されたデータを呼び出すことによってデータを処理する。いくつかの実施形態では、プロセッサ110は、1つまたは複数の処理ユニットを含んでもよい。本出願のいくつかの実施形態では、プロセッサ110は、実行可能プログラムおよびAPPの共有ライブラリを実行するように構成されたプログラム実行チップをさらに含んでもよい。

プロセッサ110は、1つまたは複数の処理ユニットを含んでもよい。例えば、プロセッサ110は、アプリケーションプロセッサ（application processor、AP）、モデムプロセッサ、グラフィック処理ユニット（graphics processing unit、GPU）、画像信号プロセッサ（image signal processor、ISP）、コントローラ、メモリ、ビデオコーデック、デジタル信号プロセッサ（digital signal processor、DSP）、ベースバンドプロセッサ、および／またはニューラルネットワーク処理ユニット（neural－network processing unit、NPU）を含んでもよい。異なる処理ユニットは、独立した構成要素であってもよいし、1つまたは複数のプロセッサに統合されてもよい。

コントローラは、携帯電話100の中枢およびコマンドセンタであってもよい。コントローラは、命令フェッチおよび命令実行の制御を完了するために、命令動作コードおよび時系列信号に基づいて動作制御信号を生成することができる。

メモリは、プロセッサ110にさらに配置されてもよく、命令およびデータを記憶するように構成される。いくつかの実施形態では、プロセッサ110内のメモリはキャッシュメモリである。メモリは、プロセッサ110によって単に使用されるか、または周期的に使用される命令もしくはデータを記憶してもよい。プロセッサ110が命令またはデータを再び使用する必要がある場合には、プロセッサは、メモリから命令またはデータを直接呼び出してもよい。これにより、度重なるアクセスが回避され、プロセッサ110の待ち時間が低減され、それによってシステム効率が改善される。

いくつかの実施形態では、プロセッサ110は、1つまたは複数のインターフェースを含んでもよい。インターフェースは、集積回路間（inter－integrated circuit、I2C）インターフェース、集積回路間サウンド（inter－integrated circuit sound、I2S）インターフェース、パルスコード変調（pulse code modulation、PCM）インターフェース、汎用非同期送受信機（universal asynchronous receiver／transmitter、UART）インターフェース、モバイル・インダストリ・プロセッサ・インターフェース（mobile industry processor interface、MIPI）、汎用入出力（general－purpose input／output、GPIO）インターフェース、加入者識別モジュール（subscriber identity module、SIM）インターフェース、ユニバーサルシリアルバス（universal serial bus、USB）インターフェースなどを含んでもよい。

この実施形態に示されているモジュール間のインターフェース接続関係は、説明のための単なる例であり、携帯電話100の構造に対する限定を構成するものではないことが理解されよう。いくつかの他の実施形態では、携帯電話100は、代替的に、前述の実施形態とは異なるインターフェース接続方式、または複数のインターフェース接続方式の組み合わせを使用してもよい。

充電管理モジュール140は、充電器から充電入力を受信するように構成される。充電器は、無線充電器であっても有線充電器であってもよい。充電管理モジュール140は、バッテリ142に充電しながら、電力管理モジュール141を使用して電子デバイスに給電する。

電力管理モジュール141は、バッテリ142、充電管理モジュール140、およびプロセッサ110に接続するように構成される。電力管理モジュール141は、バッテリ142および／または充電管理モジュール140から入力を受信して、プロセッサ110、内部メモリ121、外部メモリ、ディスプレイ194、カメラ193、無線通信モジュール160などに電力を供給する。いくつかの実施形態では、電力管理モジュール141および充電管理モジュール140は、代替的に同じデバイス内に配置されてもよい。

携帯電話100の無線通信機能は、アンテナ1、アンテナ2、移動通信モジュール150、無線通信モジュール160、モデムプロセッサ、ベースバンドプロセッサなどにより実装されてもよい。いくつかの実施形態では、携帯電話100において、アンテナ1と移動通信モジュール150とが結合され、アンテナ2と無線通信モジュール160とが結合され、その結果、携帯電話100が、無線通信技術を使用してネットワークおよび別の電子デバイスと通信することができる。例えば、本出願のこの実施形態では、携帯電話100は、無線通信技術を使用して、第1のアカウントおよびログインパスワードを別のデバイスに送信してもよい。

アンテナ1とアンテナ2とは、電磁波信号を送信および受信するように構成される。携帯電話100の各アンテナは、1つまたは複数の通信周波数帯域をカバーするように構成されてもよい。アンテナ利用率を向上させるために、異なるアンテナがさらに多重化されてもよい。例えば、アンテナ1は、無線ローカルエリアネットワークのダイバーシチアンテナとして多重化されてもよい。いくつかの他の実施形態では、アンテナはチューニングスイッチと組み合わせて使用されてもよい。

移動通信モジュール150は、携帯電話100に適用され、2G、3G、4G、および5Gなどの無線通信を含む解決策を提供することができる。移動通信モジュール150は、少なくとも1つのフィルタ、スイッチ、電力増幅器、低雑音増幅器（low noise amplifier、LNA）などを含んでもよい。移動通信モジュール150は、アンテナ1を介して電磁波を受信し、受信された電磁波に対してフィルタリングや増幅などの処理を行い、電磁波を復調のためにモデムプロセッサに送信することができる。

移動通信モジュール150は、モデムプロセッサによって変調された信号をさらに増幅し、その信号を、アンテナ1を通して放射するための電磁波に変換し得る。いくつかの実施形態では、移動通信モジュール150の少なくともいくつかの機能モジュールは、プロセッサ110に配置されてもよい。いくつかの実施形態において、移動通信モジュール150の少なくともいくつかの機能モジュールは、プロセッサ110の少なくともいくつかのモジュールとして同じデバイス内に配置されてもよい。

無線通信モジュール160は、携帯電話100に適用され、無線ローカルエリアネットワーク（wireless local area networks、WLAN）（例えば、ワイヤレスフィデリティ（wireless fidelity、Wi－Fi）ネットワーク）、ブルートゥース(登録商標)（bluetooth(登録商標)、BT）、全地球航法衛星システム（global navigation satellite system、GNSS）、周波数変調（frequency modulation、FM）、近距離通信（near field communication、NFC）、および赤外線（infrared、IR）技術などの無線通信を含む解決策を提供することができる。例えば、本出願のこの実施形態では、携帯電話100（例えば、第1のデバイス110）は、無線通信モジュール160を使用してWi－Fiネットワークにアクセスすることができる。

無線通信モジュール160は、少なくとも1つの通信プロセッサモジュールを組み込む1つまたは複数の構成要素であってもよい。無線通信モジュール160は、アンテナ2を介して電磁波を受信し、電磁波信号に対して周波数変調およびフィルタリング処理を行い、処理された信号をプロセッサ110に送信する。無線通信モジュール160は、プロセッサ110から送信されるべき信号をさらに受信し、信号に対して周波数変調および増幅を実行し、処理された信号をアンテナ2を介して放射するための電磁波に変換することができる。

携帯電話100は、GPU、ディスプレイ194、アプリケーションプロセッサ、などを使用することによって表示機能を実現する。GPUは、画像処理用のマイクロプロセッサであり、ディスプレイ194およびアプリケーションプロセッサに接続される。GPUは、数学的および幾何学的計算を実行するように構成され、画像をレンダリングするように構成される。プロセッサ110は、プログラム命令を実行して表示情報を生成または変更する1つまたは複数のGPUを含んでもよい。

ディスプレイ194は、画像、ビデオなどを表示するように構成される。ディスプレイ194は、表示パネルを含む。例えば、本出願のこの実施形態では、ディスプレイ194は、デバイス共有インターフェース、デバイス検索インターフェース、または2次元コード走査インターフェースなどの第1のAPPのアプリケーションインターフェースを表示するように構成されてもよい。

携帯電話100は、ISP、カメラ193、ビデオコーデック、GPU、ディスプレイ194、アプリケーションプロセッサなどを使用して写真撮影機能を実施することができる。ISPは、カメラ193によってフィードバックされるデータを処理するように構成される。カメラ193は、静止画像またはビデオをキャプチャするように構成される。一部の実施形態では、携帯電話100は、1個またはN個のカメラ193を含んでもよく、Nは1よりも大きい正の整数である。

外部メモリインターフェース120は、携帯電話100の記憶能力を拡張するために、外部記憶カード、例えばMicro SDカードに接続するように構成されてもよい。外部記憶カードは、データ記憶機能を実装するために、外部メモリインターフェース120を通してプロセッサ110と通信する。外部記憶カードには、例えば、音楽や動画などのファイルが記憶されている。

内部メモリ121は、アプリケーションおよびデータを記憶するように構成される。プロセッサ110は、内部メモリ121に記憶されたアプリケーションおよびデータを実行することにより、携帯電話100の様々な機能およびデータ処理を実行する。内部メモリ121は、プログラム記憶領域およびデータ記憶領域を主に含む。プログラム記憶領域は、オペレーティングシステム、実行可能プログラム、および共有ライブラリなどのバイナリファイルを記憶することができる。データ記憶領域は、データ間の対応関係を記憶することができる。

加えて、内部メモリ121は、高速ランダム・アクセス・メモリ（Random Access Memory、RAM）を含んでもよく、磁気ディスク記憶装置、フラッシュメモリ装置、または別の揮発性固体記憶装置などの不揮発性メモリをさらに含んでもよい。内部メモリ121は、様々なオペレーティングシステムを記憶することができる。内部メモリ121は、独立していてもよく、通信バスを介してプロセッサ110に接続されるか、あるいは、内部メモリ121は、プロセッサ110と統合されてもよい。

携帯電話100は、オーディオモジュール170、スピーカ170A、受信機170B、マイクロフォン170C、ヘッドセットジャック170D、アプリケーションプロセッサなどを使用して、オーディオ機能、例えば、音楽再生や録音を実施することができる。

ボタン190は、電源ボタン、音量ボタンなどを含む。ボタン190は、機械的ボタンであってもよいし、タッチボタンであってもよい。モータ191は、振動プロンプトを生成することができる。モータ191は、着信振動プロンプトおよびタッチ振動フィードバックを提供するように構成されてもよい。インジケータ192は、インジケータライトであってもよく、充電状態および電源変化を示すように構成されてもよく、あるいは、メッセージ、不在着信、通知などを示すように構成されてもよい。SIMカードインターフェース195は、SIMカードに接続するように構成される。SIMカードは、携帯電話100との接触または分離を実施するために、SIMカードインターフェース195に挿入されてもよいし、SIMカードインターフェース195から取り外されてもよい。携帯電話100は、1個またはN個のSIMカードインターフェースをサポートすることができ、Nは1よりも大きい正の整数である。SIMカードインターフェース195は、Nano SIMカード、Micro SIMカード、SIMカードなどをサポートすることができる。

図1には示されていないが、携帯電話100は、フラッシュ、マイクロプロジェクション装置、近距離無線通信（Near Field Communication，NFC）装置などをさらに含んでもよい。ここでは詳細は説明されない。

電子デバイスのハードウェア構造が説明された後に、電子デバイスが携帯電話100である例は、本出願で提供される電子デバイスのシステムアーキテクチャを説明するために本出願で使用される。図2Aに示すように、携帯電話100のシステムアーキテクチャは、アプリケーション層、オペレーティングシステム（Operating System、OS）（例えば、アンドロイド(登録商標)Android（登録商標）システム）、カーネル（kernel）層、およびハードウェア層を含むことができる。

アプリケーション層は、一連のアプリケーションパッケージ、例えば、APP（A）およびAPP（B）を含んでもよい。Android（登録商標）システムを例に取る。Android（登録商標）システムの共有ライブラリファイルはすべてsoファイル（＊．so）である。図2Aに示すように、APP（A）はA1．so、A2．so、A3．soなどを含み、APP（B）はB1．so、B2．so、B3．soなどを含む。

Android（登録商標）システムは、携帯電話100のハードウェアおよびソフトウェアリソースを管理するコンピュータプログラムである。Android（登録商標）システムは、メモリの管理および構成、システムリソースの供給および需要の優先度の決定、入力デバイスおよび出力デバイスの制御、ネットワークの操作、ならびにファイルシステムの管理などの基本的なトランザクションを処理する必要がある。Android（登録商標）システムはまた、ユーザがシステムと対話することを可能にする操作インターフェースを提供することができる。本出願の本実施形態では、Android（登録商標）システムは、インストール・パッケージ・マネージャ・サービス（Package Manager Service、PMS）を含む。PMSは、Android（登録商標）システムのサービスの1つであり、主に、Android（登録商標）システムのアプリケーションの管理と、様々なAPKファイルのインストール、アンインストール、最適化、およびクエリサービスの提供を担当する。具体的には、PMSはAPP監視構成要素を含む。APP監視構成要素はPMS内で動作し、APPのインストール、更新、および削除を監視し、再利用構成要素に通知メッセージを送信することができる。例えば、APP（A）が携帯電話100にインストールされた後に、APP監視構成要素は、APP（A）のインストールが完了したことを再利用構成要素に通知するために、再利用構成要素に通知メッセージを送信する。

カーネル層はハードウェアとソフトウェアとの間の層である。カーネル層は、少なくともディスプレイドライバ、カメラドライバ、オーディオドライバ、およびセンサドライバを含む。本出願のこの実施形態では、カーネル層は、ファイルシステムおよびメモリ・オペレーティング・システムをさらに含む。ファイルシステムは、内部メモリ121に記憶されたデータを管理するように構成される。具体的には、ファイルシステムは、内部メモリ121に記憶されたデータを特定のファイルに抽象化し、ファイルの追加、削除、および変更などの動作を提供することができる。例えば、図2Bに示すように、ファイルシステムは、実行可能プログラムA、第1の共有ライブラリおよび第2の共有ライブラリを第1のAPPに記憶し、実行可能プログラムBおよび第2のAPPの第3の共有ライブラリを内部メモリ121に記憶してもよい。任意選択で、プロセッサ110は、ファイルシステムを使用して共有ライブラリを呼び出す。メモリ・オペレーティング・システム（RAM OS）は、メモリを管理するために使用される。ハードウェア層と比較して、メモリアクセス速度はより速い。したがって、APPを実行するとき、プロセッサ110は、APPの実行速度を改善するために、APPの共有ライブラリをメモリ・オペレーティング・システムにロードする必要がある。ファイルシステムは再利用構成要素を含み、再利用構成要素はファイルシステム内の共有ライブラリの再利用を実現することができる。例えば、A1．soのファイルデータとB1．soのファイルデータとは同じであり、A2．soのファイルデータはB2．soのファイルデータと同じであり、再利用構成要素は、APP（A）およびAPP（B）がB1．soおよびB2．soを共同で呼び出すことを可能にすることができる。

ハードウェア層はメモリ（例えば、flashメモリ）を含む。flashメモリは、電流供給なしにデータを長期間維持することができ、フラッシュメモリの記憶機能はハードディスクの記憶機能と同等である。例えば、Flashメモリは、S1．so，S2．so，S3．soなどを記憶する。

図2Aに示す電子デバイスのシステムアーキテクチャは、電子デバイスが第1のAPPのインストールを完了するときに、本出願の実施形態において提供される共有ライブラリを再利用するための方法を実行する際に電子デバイスをサポートすることができることに留意されたい。図2Cは、本出願の一実施形態による共有ライブラリを再利用するための方法のフローチャートである。

具体的には、APP（A）のインストール完了時点がAPP（B）のインストール完了時点よりも遅い例を使用して、本出願の実施形態における共有ライブラリを再利用するための方法を説明する。A1．soのファイルデータは、B1．soのファイルデータと同じであり、A2．soのファイルデータは、B2．soのファイルデータと同じである。APP（A）のインストールが完了すると、APP監視構成要素は、再利用構成要素に通知メッセージを送信する。再利用構成要素は、A1．soと同じファイルデータを有するB1．soおよびA2．soと同じファイルデータを有するB2．soがハードウェア層（例えば、内部メモリ121）に存在することを検出し、A1．soおよびA2．soを削除する。携帯電話100がAPP（A）またはAPP（B）を実行して共有ライブラリ（例えば、B1．so）を呼び出すと、メモリ・オペレーティング・システムはB1．soをメモリにマッピングし、その結果、プロセッサ110はメモリからB1．soを呼び出す。

任意選択で、本出願では、電子デバイスが携帯電話100である例は、本明細書では、本出願で提供される電子デバイスの別のシステムアーキテクチャを説明するために使用される。図2Dに示すように、携帯電話100のシステムアーキテクチャは、アプリケーション層、カーネル（kernel）層、およびハードウェア層を含む。

アプリケーション層の説明については、図2Aのアプリケーション層の前述の説明を参照されたい。ここでは詳細を繰り返さない。

カーネル層の説明については、図2Aのカーネル層の前述の説明を参照されたい。カーネル層のメモリ・オペレーティング・システムは、監視構成要素をさらに含む。監視構成要素は、メモリ・オペレーティング・システムで動作し、携帯電話100による共有ライブラリの呼び出しを監視し、再利用構成要素に通知メッセージを送信することができる。例えば、携帯電話100がAPP（A）の実行を停止すると、再利用構成要素は、携帯電話100がB1．soの呼び出しを停止したことを検出し、再利用構成要素に通知メッセージを送信して、APP（A）のプロセスが閉じられたことを再利用構成要素に通知する。

ハードウェア層の説明については、図2Aのハードウェア層の前述の説明を参照されたい。ここでは詳細を繰り返さない。

図2Dに示す電子デバイスのシステムアーキテクチャは、電子デバイスが第1のAPPを実行するときに本出願の実施形態で提供される共有ライブラリを再利用するための方法を実行する際に電子デバイスをサポートし得ることに留意されたい。

具体的には、APP（A）の実行完了時点がAPP（B）の実行完了時点よりも遅い例を使用して、本出願の実施形態における共有ライブラリを再利用するための方法を説明する。A1．soのファイルデータは、B1．soのファイルデータと同じであり、A2．soのファイルデータは、B2．soのファイルデータと同じである。APP（A）の実行が完了すると、APP監視構成要素は、再利用構成要素に通知メッセージを送信する。再利用構成要素は、A1．soと同じファイルデータを有するB1．soおよびA2．soと同じファイルデータを有するB2．soがハードウェア層（例えば、内部メモリ121）に存在することを検出し、A1．soおよびA2．soを削除する。携帯電話100がAPP（A）またはAPP（B）を実行して共有ライブラリ（例えば、B1．so）を呼び出すと、メモリ・オペレーティング・システムはB1．soをメモリにマッピングし、その結果、プロセッサ110はメモリからB1．soを呼び出す。

以下の実施形態におけるすべての方法は、前述のハードウェア構造および前述のシステムアーキテクチャを有する電子デバイスにおいて実施され得る。以下の実施形態では、電子デバイスが携帯電話100である例を使用して、本出願の実施形態における方法を説明する。

本出願の実施形態では、複数のAPP（例えば、第1のAPP、第2のAPP、および第3のAPP）が携帯電話100にインストールされ、複数のAPPの各々は少なくとも1つの共有ライブラリを含む。例えば、第1のAPPはショッピングアプリケーション1であってもよく、ショッピングアプリケーション1は共有ライブラリaおよび共有ライブラリbを含む。第2のAPPはショッピングアプリケーション2であってもよく、ショッピングアプリケーション2は共有ライブラリcを含む。第3のAPPは、決済アプリケーションであってもよく、決済アプリケーションは、共有ライブラリd、共有ライブラリe、および共有ライブラリfを含む。

携帯電話100内の各APPは、1つの実行可能プログラムと、少なくとも1つの共有ライブラリとを含む。各共有ライブラリのファイルデータは、複数のライブラリ関数を含む。このようにして、APPが実行されると、実行可能プログラムは、APPの機能を完了するために共有ライブラリ内のライブラリ関数を呼び出す。例えば、第1のAPPは、ショッピングアプリケーションであり、ショッピングアプリケーションは、実行可能プログラムa、共有ライブラリb、および共有ライブラリcを含む。ショッピングアプリケーションを実行するとき、携帯電話100は最初に実行可能プログラムaを実行することができる。実行可能プログラムaが共有ライブラリb内のライブラリ関数および共有ライブラリc内のライブラリ関数を呼び出す必要があるとき、携帯電話100は、共有ライブラリbおよび共有ライブラリcをメモリにマッピングし、その結果、実行可能プログラムaはメモリからライブラリ関数にアクセスすることができる。

本出願の実施形態では、第1のAPP内の任意の共有ライブラリと第2のAPP内の任意の共有ライブラリとの間に以下の3つの関係があり得る。第1のAPPおよび第2のAPPは、携帯電話100内の任意の共有ライブラリである。

関係1：2つの共有ライブラリは異なる。

2つの共有ライブラリが異なることは、具体的には、2つの共有ライブラリのファイルデータが異なることを意味する。2つの共有ライブラリのファイルデータが異なることは、具体的には、2つの共有ライブラリのバイナリファイルが異なることを意味する。例えば、2つの共有ライブラリは異なるライブラリ機能を含み、携帯電話100は、2つの異なるバイナリファイルを取得するために、2つの共有ライブラリのファイルデータを別々にコンパイルする。

なお、異なる2つの共有ライブラリのライブラリ機能は異なり、以下の2つの場合が含まれてもよい。ケース（1）：2つの異なる共有ライブラリのライブラリ機能が全く異なる。ケース（2）：2つの異なる共有ライブラリのライブラリ機能が部分的に同一であり、他の機能が異なる。

例えば、第1のAPP内の共有ライブラリaがライブラリ関数1、ライブラリ関数2およびライブラリ関数3を含み、第2のAPP内の共有ライブラリbがライブラリ関数4およびライブラリ関数5を含むと仮定する。ライブラリ関数1、ライブラリ関数2、ライブラリ関数3、ライブラリ関数4およびライブラリ関数5は互いに異なる。したがって、共有ライブラリaは、共有ライブラリbとは全く異なる。

別の例として、第1のAPP内の共有ライブラリaはライブラリ関数1、ライブラリ関数2、およびライブラリ関数3を含み、第2のAPP内の共有ライブラリbはライブラリ関数3、ライブラリ関数4、およびライブラリ関数5を含むと仮定する。ライブラリ関数1、ライブラリ関数2、ライブラリ関数3、ライブラリ関数4およびライブラリ関数5は互いに異なる。そのため、共有ライブラリaと共有ライブラリbとは一部異なる。

なお、異なる2つの共有ライブラリ（すなわち、異なるファイルデータを有する2つの共有ライブラリ）のファイル名は、同一であってもよいし、異なっていてもよい。

関係2：2つの共有ライブラリは同じである。

2つの共有ライブラリが同じであることは、具体的には、2つの共有ライブラリがファイルデータにおいて同じであることを意味する。2つの共有ライブラリがファイルデータにおいて同じであることは、具体的には、2つの共有ライブラリのバイナリファイルが同じであることを意味する。例えば、2つの共有ライブラリは同じライブラリ機能を含み、携帯電話100は、2つの同じバイナリファイルを取得するために、2つの共有ライブラリのファイルデータを別々にコンパイルする。

なお、同一の2つの共有ライブラリ（すなわち、同じファイルデータを有する2つの共有ライブラリ）のファイル名は、同一であってもよいし、異なっていてもよい。

本出願の実施形態では、1つのAPP内の共有ライブラリは互いに異なる。例えば、第1のAPPは、共有ライブラリa、共有ライブラリb、および共有ライブラリcを含む。共有ライブラリaは第1のライブラリ関数を含み、共有ライブラリbは第2のライブラリ関数および第3のライブラリ関数を含み、共有ライブラリcは第4のライブラリ関数を含む。共有ライブラリaのファイル名は「共有ライブラリa」であり、共有ライブラリaのファイルデータは第1のライブラリ関数である。共有ライブラリbのファイル名は「共有ライブラリb」であり、共有ライブラリbのファイルデータは第2のライブラリ関数および第3のライブラリ関数である。共有ライブラリcのファイル名は「共有ライブラリc」であり、共有ライブラリcのファイルデータは第4のライブラリ関数である。すなわち、共有ライブラリa、共有ライブラリb、および共有ライブラリcのファイル名およびファイルデータが異なる。このため、共有ライブラリa、共有ライブラリb、および共有ライブラリcは異なる。

本出願の一実施形態は、共有ライブラリを再利用するための方法を提供する。図3に示すように、共有ライブラリを再利用するための方法は、S301～S304を含むことができる。

S301：携帯電話100は、第1のAPPの第1の共有ライブラリと同じファイルデータを有する第2の共有ライブラリが携帯電話100内に存在するか否かを判定する。

第1のAPPは少なくとも1つの共有ライブラリを含み、第1の共有ライブラリは第1のAPP内の任意の共有ライブラリである。例えば、第1のAPPは3つの共有ライブラリを含み、3つの共有ライブラリはそれぞれ共有ライブラリa、共有ライブラリb、および共有ライブラリcである。第1の共有ライブラリは、共有ライブラリaであってもよいし、共有ライブラリbであってもよいし、共有ライブラリcであってもよい。本出願のこの実施形態では、携帯電話100は、第1のAPPの各共有ライブラリに対して本出願のこの実施形態における方法を実行することができる。

本出願のこの実施形態では、携帯電話100は、以下の2つの方式で、第1のAPPの第1の共有ライブラリと同じファイルデータを有する第2の共有ライブラリが携帯電話100内に存在するかどうかを判定することができる。

方式1：携帯電話100は、事前設定されたアルゴリズムを用いて、第1の共有ライブラリのファイルデータに基づいて第1の共有ライブラリの第1の識別情報を生成する。事前設定されたアルゴリズムは、セキュア・ハッシュ・アルゴリズム1（Secure Hash Algorithm 1、SHA－1）、MD5メッセージ・ダイジェスト・アルゴリズム（MD5 Message－Digest Algorithm、MD5）、データ暗号化標準（Data Encryption Standard、DES）アルゴリズムなどであってもよい。これは、本出願のこの実施形態では限定されない。

例えば、携帯電話100は、第1の共有ライブラリのファイルデータに基づくSHA－1を用いて、第1の共有ライブラリのファイルデータのハッシュ値、すなわち6cd7aを生成してもよい。携帯電話100は、第1の識別情報が第2の識別情報と同じであるかどうかを判定する。第2の識別情報は、携帯電話100の任意の共有ライブラリのファイルデータに基づいて携帯電話100によって事前設定されたアルゴリズムを用いて生成される。

可能な実施態様では、携帯電話100によって、第1の識別情報が第2の識別情報と同じであるかどうかを判定するための方法は、携帯電話100が、第1の識別情報と同じ識別情報があるかどうかについて第1のデータ表を検索することを含んでもよい。第1のデータ表は、共有ライブラリの識別情報とinodeの番号（Number）との間の対応関係を記憶するために使用される。第1のデータ表では、すべての識別情報が異なる。共有ライブラリの識別情報に対応するinodeは、携帯電話100によって共有ライブラリに割り当てられる。具体的な割り当てプロセスについては、S302の説明を参照されたい。ここでは詳細を繰り返さない。

例えば、表1は、携帯電話100によって共有ライブラリに割り当てられたinodeと共有ライブラリの識別情報（Identification）との間の対応関係を示す。第1のinodeと共有ライブラリaの識別情報aとの間には対応関係があり、第1のinodeの番号は01であり、識別情報aはe908であり、第2のinodeと共有ライブラリbの識別情報bとの間には対応関係があり、第2のinodeの番号は02であり、識別情報bは6cd7aであり、第1のデータ表はShareMap表と呼ばれてもよい。

携帯電話100は、inodeの番号と共有ライブラリの識別情報との間の対応関係を第1のデータ表に記憶し、inodeと共有ライブラリの識別情報との間の対応関係を記憶することができることに留意されたい。携帯電話100が、inodeの番号と共有ライブラリの識別情報との間の対応関係を第1のデータ表に記憶することに加えて、携帯電話100は、inodeの番号と共有ライブラリの識別情報との間の対応関係を別のデータ表にさらに記憶してもよい。これは、本出願のこの実施形態では限定されない。加えて、携帯電話100は、inodeの番号と共有ライブラリの識別情報との間の対応関係をツリー構造でさらに記憶することができる。これは、本出願のこの実施形態では限定されない。本出願のこの実施形態では、本出願のこの実施形態における方法は、携帯電話100が、inodeの番号と共有ライブラリの識別情報との間の対応関係を第1のデータ表に記憶する例を使用して説明される。

第1の識別情報が第2の識別情報と同じである場合には、携帯電話100は、第1の共有ライブラリと同じファイルデータを有する第2の共有ライブラリが携帯電話100内に存在すると判定する。例えば、携帯電話100は、共有ライブラリcのファイルデータに基づいてSHA－1を使用し、共有ライブラリcの識別情報cがe908であると判定する。表1を参照すると、携帯電話100は、第1のデータ表内の識別情報をトラバースし、識別情報aがe908であると判定する。したがって、識別情報cは識別情報aと同じである。

第1の識別情報と第2の識別情報との両方が、事前設定されたアルゴリズムを用いて共有ライブラリのファイルデータに基づいて携帯電話100によって生成されるので、第1の識別情報が第2の識別情報と同じであるとき、携帯電話100は、第1の共有ライブラリと同じファイルデータを有する第2の共有ライブラリが携帯電話100内に存在すると判定することが理解されよう。

携帯電話100は、第1の識別情報と第2の識別情報とが異なる場合には、第1の共有ライブラリと同じファイルデータを有する第2の共有ライブラリが携帯電話100内に存在しないと判定する。第1の識別情報と第2の識別情報の両方が携帯電話100によって事前設定されたアルゴリズムを用いて共有ライブラリのファイルデータに基づいて生成されるので、第1の識別情報が第2の識別情報と異なるとき、携帯電話100は、第1の共有ライブラリと同じファイルデータを有する第2の共有ライブラリが携帯電話100内に存在しないと判定することが理解されよう。

任意選択で、第1の識別情報が第2の識別情報と異なる場合には、携帯電話100は、第1の識別情報と第2のinodeとの間の対応関係を記憶する。携帯電話100による第1の識別情報と第2のinodeとの間の対応関係を記憶する具体的な説明については、S401の説明を参照されたい。ここでは詳細を繰り返さない。

第1の識別情報が第2の識別情報と異なる場合、第1の共有ライブラリと同じファイルデータを有する第2の共有ライブラリが電子デバイス内に存在しないことを示すことが理解されよう。したがって、電子デバイスは、第1の識別情報と第2のinodeとの間の対応関係を記憶する必要があり、その結果、第1の共有ライブラリを記憶した後に、電子デバイスは、第1の識別情報に基づいて、電子デバイスに記憶されている別の共有ライブラリのファイルデータが第1の共有ライブラリと同じであるかどうかを判定することができる。

方式2：携帯電話100は、第1の共有ライブラリのファイルデータを携帯電話100内の各共有ライブラリのファイルデータと比較して、第1の共有ライブラリと同じファイルデータを有する第2の共有ライブラリが携帯電話100内に存在するかどうかを判定する。

可能な実施態様では、携帯電話100は、事前設定された比較アルゴリズムまたは事前設定された比較ツールを使用して、第1の共有ライブラリのファイルデータを携帯電話100内の各共有ライブラリのファイルデータと比較して、第1の共有ライブラリと同じファイルデータを有する第2の共有ライブラリが携帯電話100内に存在するかどうかを判定する。

可能な設計では、携帯電話100は、第1の共有ライブラリのファイルデータを携帯電話100内の1つの共有ライブラリのファイルデータと一度に比較してもよい。例えば、携帯電話100は、共有ライブラリa、共有ライブラリb、共有ライブラリc、および共有ライブラリdを含む。携帯電話100は、事前設定された比較ツールを用いて、第1の共有ライブラリのファイルデータと共有ライブラリaのファイルデータとを比較し、第1の共有ライブラリのファイルデータと共有ライブラリaのファイルデータとが異なると判定する。そして、携帯電話100は、第1の共有ライブラリのファイルデータと共有ライブラリbのファイルデータとを比較し、第1の共有ライブラリのファイルデータと共有ライブラリbのファイルデータとが異なると判定する。その後に、携帯電話100は、第1の共有ライブラリのファイルデータと共有ライブラリcのファイルデータとを比較し、第1の共有ライブラリのファイルデータは共有ライブラリcのファイルデータと同じであると判定する。携帯電話100は、第1の共有ライブラリのファイルデータと携帯電話100の共有ライブラリのファイルデータとの比較を停止する、すなわち、携帯電話100は、第1の共有ライブラリのファイルデータを共有ライブラリdのファイルデータと比較しない。

別の可能な設計では、携帯電話100は、第1の共有ライブラリのファイルデータを携帯電話100内の複数の共有ライブラリのファイルデータと同時に比較してもよい。例えば、携帯電話100は、共有ライブラリa、共有ライブラリb、共有ライブラリc、および共有ライブラリdを含む。携帯電話100は、事前設定された比較ツールを用いて、第1の共有ライブラリのファイルデータと、共有ライブラリaのファイルデータ、共有ライブラリbのファイルデータ、および共有ライブラリcのファイルデータとを同時に比較し、第1の共有ライブラリのファイルデータと共有ライブラリcのファイルデータとが同じであると判定する。その後に、携帯電話100は、第1の共有ライブラリのファイルデータと携帯電話100の共有ライブラリのファイルデータとの比較を停止する、すなわち、携帯電話100は、第1の共有ライブラリのファイルデータを共有ライブラリdのファイルデータと比較しない。

任意選択で、第2の共有ライブラリが携帯電話100内に存在する場合には、携帯電話100はS302を実行するか、または、携帯電話100に第2の共有ライブラリが存在しない場合には、携帯電話100はS401を実行する。

S302：第2の共有ライブラリが携帯電話100内に存在する場合には、携帯電話100は、第1のインデックスノードinodeと第1の共有ライブラリのファイル名との間の対応関係を記憶する。

第1のinodeは、携帯電話100によって第2の共有ライブラリに割り当てられる。第2の共有ライブラリが携帯電話100に記憶される場合、携帯電話100は、第1のinodeと第2の共有ライブラリのファイル名との間の対応関係を記憶してもよい。具体的には、携帯電話100は、第1のinodeの番号と第2の共有ライブラリのファイル名との間の対応関係を記憶することによって、第1のinodeと第2の共有ライブラリのファイル名との間の対応関係を記憶する。

可能な設計では、携帯電話100は、第1のinodeの番号と第2の共有ライブラリのファイル名との間の対応関係を第2のデータ表に記憶する。例えば、表2は、携帯電話100が共有ライブラリに割り当てられたinodeの番号と、共有ライブラリのファイル名（File name）との間の対応関係を示している。第1のinodeの番号は01であり、第2の共有ライブラリのファイル名は共有ライブラリaと呼ばれ、第2のデータ表はDirectory表である。

携帯電話100は、inodeの番号と共有ライブラリのファイル名との間の対応関係を第2のデータ表に記憶することに加えて、携帯電話100は、inodeの番号と共有ライブラリのファイル名との間の対応関係を別のデータ表にさらに記憶してもよいことに留意されたい。これは、本出願のこの実施形態では限定されない。加えて、携帯電話100は、inodeの番号と共有ライブラリのファイル名との間の対応関係をさらにツリー構造で記憶してもよい。これは、本出願のこの実施形態では限定されない。本出願のこの実施形態では、本出願のこの実施形態における方法は、携帯電話100が、第2のデータ表内の共有ライブラリのinode番号とファイル名との間の対応関係を記憶する例を使用して説明される。

可能な設計では、第1のinodeは、第2の共有ライブラリのファイルデータを記憶するために使用される第1の記憶領域を示す。

携帯電話100が第2の共有ライブラリを記憶した後に、携帯電話100は第1のinodeに第2の共有ライブラリのメタ情報を記憶してもよいことに留意されたい。各共有ライブラリのメタ情報には、作成時刻（Creation time）、ファイルサイズ（File size）、記憶場所（Storage location）などが含まれる。例えば、第1のinodeの番号は01であり、第2の共有ライブラリのファイル名は共有ライブラリaと呼ばれ、第2の共有ライブラリの作成日は「2020－08－10 09：00」であり、第2の共有ライブラリのファイルサイズは「100キロバイト（Kilobyte、kb）」であり、第2の共有ライブラリの記憶場所は「／data／app1／」である。この場合、第1のinodeは「Number：01，File name：共有ライブラリa、Creation time：2020－08－10 09：00、File size：100、Storage location：／data／app1／」であってもよい。

携帯電話100が第2の共有ライブラリを呼び出す必要があるとき、携帯電話100は、共有ライブラリのファイル名を用いて、ファイル名に対応するinodeを決定してもよいことが理解されよう。このようにして、携帯電話100は、inodeから共有ライブラリの記憶場所を取得し、記憶場所から共有ライブラリのファイルデータを読み出すことができる。

本出願のこの実施形態では、携帯電話100が、第1のAPPの第1の共有ライブラリと同じファイルデータを有する第2の共有ライブラリが携帯電話100内に存在すると決定したとき、第1のAPPは携帯電話100に記憶されている。すなわち、携帯電話100には、第1の共有ライブラリのファイルデータが記憶されている。加えて、携帯電話100は、第1の共有ライブラリに第2のinodeを割り当て、携帯電話100は、第1の共有ライブラリのファイル名と第2のinodeとの間の対応関係を記憶し、第2のinodeは、第1の共有ライブラリのメタ情報を記憶する。例えば、表2を参照すると、表3は、携帯電話100によって共有ライブラリに割り当てられたinodeの番号と、共有ライブラリのファイル名（File name）との間の対応関係を示す。第2のinodeの番号は02であり、第1の共有ライブラリのファイル名は共有ライブラリbと呼ばれ、第2のデータ表はDirectory表である。

可能な実施態様では、第2の共有ライブラリが携帯電話100内に存在する場合には、携帯電話100は、第2の共有ライブラリの第2の識別情報に基づいて第1のデータ表から、第2の識別情報に対応する第1のinodeの番号、すなわち第2の共有ライブラリに対応する第1のinodeの番号を決定し、第1のinodeの番号と第1の共有ライブラリのファイル名との間の対応関係を記憶し、第2のinodeの番号と第1の共有ライブラリのファイル名との間の対応関係を削除する。例えば、表3を参照して、表4は、inodeの番号と共有ライブラリのファイル名（File name）との間の対応関係を示す。第1のinodeの番号は01であり、第2の共有ライブラリのファイル名は共有ライブラリaと呼ばれ、第1の共有ライブラリのファイル名は共有ライブラリbと呼ばれ、第2のデータ表はDirectory表である。

別の可能な実施態様では、第2の共有ライブラリが携帯電話100内に存在する場合には、携帯電話100は、第2の共有ライブラリのファイルデータに基づいて、第2の共有ライブラリに対応する第1のinodeの番号を決定し、第1の共有ライブラリのファイル名と第2のinodeの番号との間の対応関係を、第1の共有ライブラリのファイル名と第1のinodeの番号との間の対応関係に変更する。

携帯電話100は、第1のinodeと第1の共有ライブラリのファイル名との間の対応関係を記憶していることが理解されよう。したがって、第1の共有ライブラリを呼び出すために第1のAPPを実行するとき、携帯電話100は第1の共有ライブラリのファイル名に基づいて第1のinodeを見つけることができる。加えて、第1のinodeは第2の共有ライブラリのファイルデータを記憶するのに用いられる第1の記憶領域を指示するので、携帯電話100は第1のinodeに基づいて第2の共有ライブラリのファイルデータを読み出すことができ、すなわち、この場合、携帯電話100によって実際に呼び出される共有ライブラリは第2の共有ライブラリである。加えて、第2の共有ライブラリのファイルデータは第1の共有ライブラリのファイルデータと同じであるので、携帯電話100が第2の共有ライブラリを呼び出すときに第1のAPPの正常動作を依然として保証することができる。

S303：携帯電話100が、第1の共有ライブラリのファイルデータを削除する。

可能な実施態様では、第2の共有ライブラリが携帯電話100内に存在する場合には、携帯電話100は、第2のデータ表を用いて第1の共有ライブラリのファイル名に基づいて、第1の共有ライブラリに対応する第2のinodeを検索する。携帯電話100は、第2のinodeに基づいて、第1の共有ライブラリのファイルデータを記憶するのに用いられる第2の記憶領域を決定する。携帯電話100は、第2の記憶領域に基づいて、第1の共有ライブラリのファイルデータを削除する。

任意選択で、携帯電話100は、第1の共有ライブラリに対応する第2のinodeのツリー構造をさらに検索してもよい。これは、本出願のこの実施形態では限定されない。

携帯電話100が第1の共有ライブラリのファイルデータを削除するとき、第1のAPPの通常の実行は影響を受けないだけでなく、電子デバイスの記憶空間も節約され得、それによって電子デバイス内の複数の同じ共有ライブラリの記憶を回避し、電子デバイスの記憶空間の利用を改善することが理解されよう。

本出願のこの実施形態では、携帯電話100は、第1の共有ライブラリのファイル名と第2のinodeとの間の対応関係に基づいて第1の共有ライブラリのファイルデータを削除する必要があることに留意されたい。したがって、携帯電話100は、第1の共有ライブラリのファイル名と第2のinodeとの間の対応関係を削除または変更する前に、第1の共有ライブラリのファイルデータを削除する必要がある。条件が満たされる場合、携帯電話100がS302およびS303を実行するシーケンスは、本出願の本実施形態では限定されない。言い換えれば、携帯電話100は、まずS302を実行し、次いでS303を実行してもよいし、または、携帯電話100は、まずS303を実行し、次いでS302を実行してもよいし、または、携帯電話100は、S302およびS303を同時に実行してもよい。

S304：携帯電話100が第1のAPPを実行して第1の共有ライブラリを呼び出すと、携帯電話100は、第1の共有ライブラリのファイル名に対応する第1のinodeを検索し、第1のinodeにより示される記憶領域に記憶されている第2の共有ライブラリのファイルデータを読み出す。

可能な実施態様では、携帯電話100が第1の共有ライブラリを呼び出すために第1のAPPを実行すると、携帯電話100は、第2のデータ表を用いて第1の共有ライブラリのファイル名に基づいて、第1の共有ライブラリに対応する第1のinodeを検索する。携帯電話100は、第1のinodeに基づいて、第2の共有ライブラリのファイルデータを記憶するのに用いられる第1の記憶領域を決定する。次いで、携帯電話100は、第1の記憶領域に基づいて、第1の記憶領域内の第2の共有ライブラリのファイルデータを読み出す。

例えば、第1のinodeは「Number：01，File name：共有ライブラリa、Creation time：2020－08－10 09：00、File size：100、Storage location：／data／app1／」である。表4を参照すると、共有ライブラリbを呼び出すとき、携帯電話100は、第2のデータ表を用いて、共有ライブラリbに対応するinodeの番号、すなわち01を検索し、番号が01である第1のinodeを決定する。次に携帯電話100は、第1のinodeに基づいて記憶場所が「／data／app1／」であると判定し、「／data／app1／」から第2の共有ライブラリのファイルデータを読み出す。

任意選択で、携帯電話100は、ツリー構造を使用して、第1の共有ライブラリに対応する第1のinodeをさらに検索してもよい。これは、本出願のこの実施形態では限定されない。

携帯電話100が第1の共有ライブラリを呼び出すために第1のAPPを実行するとき、携帯電話100は実際に第2の共有ライブラリを呼び出すことが理解されよう。このようにして、第1のAPPおよび第2の共有ライブラリを含む第2のAPPが動作するとき、電子デバイスは、第2の共有ライブラリのみをメモリにマッピングし、第1のAPPおよび第2のAPPの両方は、メモリの占有空間を削減し、メモリの利用を改善するために、メモリから第2の共有ライブラリのファイルデータを呼び出すことができる。

上記の技術的解決策に基づいて、第1のAPPの第1の共有ライブラリと同じファイルデータを有する第2の共有ライブラリが電子デバイス内に存在する場合には、電子デバイスは、第2の共有ライブラリのファイルデータを記憶するだけでなく、第1の共有ライブラリのファイルデータも記憶するので、電子デバイスの記憶空間が浪費される。したがって、第1のAPPの第1の共有ライブラリと同じファイルデータを有する第2の共有ライブラリが電子デバイス内に存在する場合、電子デバイスは、第1の共有ライブラリのファイルデータを削除することができる。このようにして、電子デバイスの記憶空間の利用率が向上され得る。

さらに、電子デバイスが第1のAPPを正常に実行することを保証するために、電子デバイスは、第1のinodeと第1の共有ライブラリのファイル名との間の対応関係をさらに記憶することができる。このようにして、電子デバイスが第1の共有ライブラリを呼び出すために第1のAPPを実行するとき、電子デバイスは、第1の共有ライブラリのファイルデータを呼び出す必要がなく、第2の共有ライブラリのファイルデータを読み出すために第1の共有ライブラリのファイル名を使用して第1のinodeを検索するだけでよいので、APPの正常な実行を保証する。

加えて、APPを実行して共有ライブラリを呼び出すとき、電子デバイスは、共有ライブラリをメモリにマッピングし、次いでメモリから共有ライブラリを呼び出すことができる。これにより、電子デバイスの性能が向上され得る。従来の技術では、複数のAPP（例えば、第1のAPPおよび第2のAPPは、第2の共有ライブラリを含む）を実行するとき、電子デバイスは、第1の共有ライブラリおよび第2の共有ライブラリをメモリに別々にマッピングする。マッピングされたデータ量が多いため、I／O性能に影響を与えるだけでなく、メモリ空間の無駄が生じる。しかしながら、本出願のこの実施形態では、電子デバイスは、第2の共有ライブラリのみをメモリにマッピングし、第1のAPPおよび第2のAPPの両方は、実行中にメモリから第2の共有ライブラリのファイルデータを呼び出すことができる。このようにして、メモリにマッピングされるデータ量が削減され、I／O性能が向上されるだけでなく、メモリの占有空間が削減され得、メモリの利用率が向上される。

任意選択で、本出願の一実施形態は、共有ライブラリを再利用するための方法を提供する。図4に示すように、S301の後に、共有ライブラリを再利用するための方法は、S401～S403をさらに含んでもよい。

S401：携帯電話100に第2の共有ライブラリが存在しない場合には、携帯電話100は第1の共有ライブラリに第2のinodeを割り当てる。

第2のinodeは、第1の共有ライブラリのファイルデータを記憶するための第2の記憶領域を示す。

第2の共有ライブラリが携帯電話100内に存在しない場合には、それは携帯電話100に第1の共有ライブラリを置き換えることができる共有ライブラリがないことを示すことが理解されよう。したがって、第1の共有ライブラリを記憶した後に、携帯電話100は、第1の共有ライブラリに第2のinodeを割り当て、その結果、第1の共有ライブラリを呼び出すために第1のAPPを実行するとき、携帯電話100は、第1のAPPの正常な実行を保証するために、第2のinodeに基づいて第1の共有ライブラリのファイルデータを読み出すことができる。

任意選択で、携帯電話100に第2の共有ライブラリが存在しない場合には、携帯電話100が第1の共有ライブラリに第2のinodeを割り当てた後に、携帯電話100は第1の識別情報と第2のinodeとの間の対応関係を記憶する。具体的には、携帯電話100は、第1の共有ライブラリに割り当てられた第2のinodeの番号を決定し、第1の識別情報および第2のinodeの番号を第1のデータ表に記憶する。

S402：携帯電話100は、第2のinodeと第1の共有ライブラリのファイル名との間の対応関係を記憶する。

詳細については、S302における携帯電話100による第2のinodeと第1の共有ライブラリのファイル名との間の対応関係の記憶の説明を参照されたい。詳細は本出願のこの実施形態では再度説明されない。

携帯電話100は、第2のinodeと第1の共有ライブラリのファイル名との間の対応関係を記憶し、そのため、第1のAPPを実行して第1の共有ライブラリを呼び出すときに、携帯電話100は、第1の共有ライブラリのファイル名に基づいて第1の共有ライブラリのファイル名に対応する第2のinodeを検索し、第1のAPPの正常な実行を保証するために、第2のinodeに基づいて第1の共有ライブラリのファイルデータを読み出すことができることが理解されよう。

S403：携帯電話100は、第1のAPPを実行して第1の共有ライブラリを呼び出すときに、第1の共有ライブラリのファイル名に対応する第2のinodeを検索し、第2のinodeにより示される記憶領域に記憶されている第1の共有ライブラリのファイルデータを読み出す。

可能な実施態様では、携帯電話100が第1の共有ライブラリを呼び出すために第1のAPPを実行すると、携帯電話100は、第2のデータ表を用いて第1の共有ライブラリのファイル名に基づいて、第1の共有ライブラリに対応する第2のinodeを検索する。携帯電話100は、第2のinodeに基づいて、第1の共有ライブラリのファイルデータを記憶するのに用いられる第2の記憶領域を決定する。次いで、携帯電話は、第2の記憶領域に基づいて、第2の記憶領域内の第1の共有ライブラリのファイルデータを読み出す。

図4に示す技術的解決策に基づいて、第1のAPPの第1の共有ライブラリと同じファイルデータを有する第2の共有ライブラリが電子デバイス内に存在しないとき、それは電子デバイス内に第1の共有ライブラリを置き換えることができる共有ライブラリがないことを示す。したがって、電子デバイスは、第1の共有ライブラリを記憶する必要がある。このようにして、電子デバイスが第1の共有ライブラリを呼び出すために第1のAPPを実行するとき、電子デバイスは、第1の共有ライブラリのファイルデータを読み出すために、第1の共有ライブラリのファイル名を使用して第2のinodeを検索することができるので、APPの正常な実行を保証することができる。

任意選択で、inodeは、inodeに対応する共有ライブラリのメタ情報を記憶することに加えて、リンク（Link）数をさらに含む。inodeのリンク数は、inodeに対応する共有ライブラリの数である。例えば、表3を参照すると、第1のinodeに対応する共有ライブラリは第2の共有ライブラリを含み、第1のinodeに対応する共有ライブラリの数は1であり、第1のinodeのリンク数は1である。第2のinodeに対応する共有ライブラリは第1の共有ライブラリを含み、第2のinodeに対応する共有ライブラリの数は1であり、第2のinodeのリンク数は1である。表4を参照すると、第1のinodeに対応する共有ライブラリは、第1の共有ライブラリおよび第2の共有ライブラリを含み、第1のinodeに対応する共有ライブラリの数は2であり、第1のinodeのリンク数は2である。

各inodeのリンク数の初期値は0である。言い換えれば、携帯電話100が共有ライブラリにinodeを割り当てていない場合、inodeに対応する共有ライブラリの数は0である。したがって、inodeのリンク数の初期値は0である。

可能な設計では、第2の共有ライブラリが携帯電話100内に存在する場合には、携帯電話100は、第1のinodeのリンク数に1を加算する。第1のinodeのリンク数は、第1のinodeに対応する共有ライブラリの数である。例えば、表3および表4を参照すると、第1の共有ライブラリのファイル名と第1のinodeとの間の対応関係が確立される前には、第1のinodeのリンク数は1であり、第1の共有ライブラリのファイル名と第1のinodeとの間の対応関係が確立された後では、第1のinodeのリンク数は2である。

可能な実施態様では、第2の共有ライブラリが携帯電話100内に存在する場合には、携帯電話100は、第2の共有ライブラリの第2の識別情報に対応する第1のinodeを決定する。携帯電話100は、第1の共有ライブラリのファイル名および第1のinodeに基づいて、第1の共有ライブラリのファイル名および第1のinodeの番号を第2のデータ表に記憶し、第1のinodeのリンク数に1を加算する。

具体的には、図5Aは、APP（A）と、A．so（共有ライブラリのファイル名）と、inode Aと、記憶領域Aとの間の対応関係、および携帯電話100が第1のinodeと第1の共有ライブラリのファイル名との間の対応関係を記憶する前のAPP（B）と、B．so（共有ライブラリのファイル名）と、inode Bと、記憶領域Bとの間の対応関係を示す。図5Aを参照すると、図5Bは、APP（A）と、A．so（共有ライブラリのファイル名）と、inode Aと、記憶領域Aとの間の対応関係、および携帯電話100が第1のinodeと第1の共有ライブラリのファイル名との間の対応関係を記憶した後のAPP（B）と、B．so（共有ライブラリのファイル名）と、inode Aと、記憶領域Aとの間の対応関係を示す。

第2の共有ライブラリが携帯電話100内に存在する場合には、それは第1の共有ライブラリが第2の共有ライブラリで置き換えられ得ることを示すことが理解されよう。加えて、第1のinodeは携帯電話100によって第2の共有ライブラリに割り当てられるので、携帯電話100は、第1のinodeに対応する共有ライブラリの数を更新するために、第1のinodeのリンク数に1を加算するように第1のinodeのリンク数を変更する。したがって、携帯電話100は、第1のinodeのリンク数に基づいて、第2の共有ライブラリによって置き換えられる共有ライブラリの数を決定することができる。

別の可能な設計では、第2の共有ライブラリが携帯電話100内に存在しない場合には、携帯電話100は、第2のinodeのリンク数に1を加算する。第2のinodeのリンク数は、第2のinodeに対応する共有ライブラリの数である。例えば、表3を参照すると、携帯電話100は第2のinodeを作成する。この場合、第2のinodeは対応する共有ライブラリを有しておらず、第2のinodeのリンク数は0である。携帯電話100が第2のデータ表に第2のinodeの番号と第1の共有ライブラリのファイル名との間の対応関係を記憶した後で、第2のinodeに対応する共有ライブラリは第1の共有ライブラリを含み、第2のinodeのリンク数は1である。

第2の共有ライブラリが携帯電話100内に存在しない場合には、それは携帯電話100に第1の共有ライブラリを置き換えることができる共有ライブラリがないことを示すことが理解されよう。したがって、携帯電話100は、第2のinodeに対応する共有ライブラリの数を更新するために、第2のinodeのリンク数に1を加算するように第2のinodeのリンク数を変更する。したがって、携帯電話100は、第2のinodeのリンク数に基づいて、第1の共有ライブラリによって置き換えられる共有ライブラリの数を決定することができる。

前述の実施形態は、APP（例えば、第1のAPPは第1の共有ライブラリを含む）が携帯電話100に新たに追加されたときに、すなわち、第1の共有ライブラリが携帯電話100に新たに追加されたときに携帯電話100によって実行される関連するステップのみを説明している。本出願の一実施形態は、共有ライブラリを再利用するための方法を提供する。以下では、携帯電話100がAPPを削除する適用シナリオを参照して、共有ライブラリを再利用するための方法を説明する。本出願のこの実施形態における方法は、S601～S604をさらに含むことができる。携帯電話100は、前述の方法手順を実行する前に、または前述の方法手順を実行するプロセスにおいて、または前述の方法手順を実行した後に、S601～S604を実行することができる。

S601：携帯電話100が第2のAPPを削除すると、携帯電話100は、第3の共有ライブラリのファイル名に対応する第3のinodeを検索する。

第3の共有ライブラリは、第2のAPPに含まれる少なくとも1つの共有ライブラリのいずれかである。例えば、第2のAPPは、共有ライブラリa、共有ライブラリb、および共有ライブラリcを含み、第3の共有ライブラリは、共有ライブラリa、共有ライブラリb、または共有ライブラリcであってもよい。本出願のこの実施形態では、携帯電話100は、第2のAPPの各共有ライブラリに対して本出願のこの実施形態における方法を実行することができる。可能な実施態様では、携帯電話100が第2のAPPを削除するとき、携帯電話100は第2のAPPの第3の共有ライブラリのファイル名を決定し、第2のデータ表を用いて、第3の共有ライブラリのファイル名に対応する第3のinodeを検索する。例えば、表5は、携帯電話100によって共有ライブラリに割り当てられたinodeの番号と、共有ライブラリのファイル名との間の対応関係を示す。第3のinodeの番号は03であり、第3の共有ライブラリのファイル名は共有ライブラリcと呼ばれ、第2のデータ表はDirectory表である。携帯電話100が、共有ライブラリのファイル名は共有ライブラリcであると決定したとき、携帯電話100は、表5を用いて、共有ライブラリcに対応する第3のinodeの番号が03であることを見つけることができる。

携帯電話100は、第3のinodeの番号に基づいて、第3のinodeの番号に対応する第3のinodeを決定する。

S602：携帯電話100が、第3のinodeのリンク数が1に等しいかどうかを判定する。

第3のinodeへのリンク数が1に等しい場合には、携帯電話100はS503を実行するか、または、第3のinodeへのリンク数が1より大きい場合には、携帯電話100はS504を実行する。

この場合、携帯電話100は第3のinodeと共有ライブラリとの間の対応関係を記憶しているので、第3のinodeは少なくとも1つの共有ライブラリに対応することに留意されたい。したがって、第3のinodeのリンク数は1以上であり、すなわち、第3のinodeのリンク数は0に等しくない。

S603：第3のinodeのリンク数が1に等しい場合には、携帯電話100が、第3の共有ライブラリのファイルデータ、第3のinode、および第3の共有ライブラリのファイル名と第3のinodeとの間の対応関係を携帯電話100から削除する。

可能な実施態様では、第3のinodeのリンク数が1に等しい場合には、携帯電話100は、inode内の第3の共有ライブラリの記憶位置に基づいて第3の共有ライブラリのファイルデータの記憶領域を決定し、第3の共有ライブラリのファイルデータを削除する。携帯電話100は、第3の共有ライブラリのファイル名に基づいて、第3の共有ライブラリのファイル名と第3のinodeとの間の対応関係を第2のデータ表から削除するか、または、携帯電話100は、第3のinodeの番号に基づいて、第3の共有ライブラリのファイル名と第3のinodeとの間の対応関係を第2のデータ表から削除する。携帯電話100は、第3のinodeの番号に基づいて第3のinodeを削除する。

別の可能な実施態様では、第3のinodeのリンク数が1に等しい場合には、携帯電話100は、第3のinodeの番号に基づいて、第1のデータ表から第3のinodeの番号と第3の識別情報との間の対応関係を削除する。

任意選択で、第3のinodeのリンク数が1に等しい場合には、携帯電話100は、第3のinodeと第3の識別情報との間の対応関係を携帯電話100から削除する。

第3のinodeのリンク数が1に等しい場合には、それは、第3のinodeに対応する共有ライブラリが第3の共有ライブラリのみを含むことを示すことが理解されよう。言い換えると、第3の共有ライブラリは別の共有ライブラリを置き換える必要がない、すなわち、第2のAPP以外のAPPは実行中に第3の共有ライブラリを呼び出さない。加えて、携帯電話100が第2のAPPを削除した後に、携帯電話100内のいかなるAPPも第3の共有ライブラリを呼び出さない。したがって、携帯電話100が第2のAPPを削除すると、携帯電話100は、携帯電話100の記憶スペースを節約するために、第3の共有ライブラリのファイルデータ、第3のinode、第3の共有ライブラリのファイル名と第3のinodeとの間の対応関係、および第3のinodeと第3の識別情報との間の対応関係を削除する。

S604：第3のinodeへのリンク数が1より大きい場合には、携帯電話100が第3のinodeへのリンク数から1を減算する。

例えば、APP（A）は共有ライブラリaを含み、APP（B）は共有ライブラリbを含み、APP（C）は共有ライブラリcを含み、共有ライブラリaのファイルデータ、共有ライブラリbのファイルデータ、および共有ライブラリcのファイルデータは同じである。第3のinodeに対応する共有ライブラリは、共有ライブラリaと、共有ライブラリbと、共有ライブラリcと、を含む。したがって、第3のinodeのリンク数は3である。携帯電話100が共有ライブラリa、共有ライブラリb、または共有ライブラリcを呼び出すと、携帯電話100は共有ライブラリaのファイルデータを呼び出す。携帯電話100がAPP（C）を削除する場合には、携帯電話100は共有ライブラリcのファイルデータを削除せず、第3のinodeのリンク数から1だけ減算する。第3のinodeに対応する共有ライブラリは共有ライブラリaおよび共有ライブラリbを含み、第3のinodeのリンク数は2である。

第3のinodeのリンク数が1より大きい場合には、それは、第3の共有ライブラリが別の共有ライブラリを置き換える必要があること、すなわち、第2のAPP以外のAPPが実行中に第3の共有ライブラリを呼び出す必要があることを示すことが理解されよう。したがって、別のAPPの正常な実行を保証するために、携帯電話100は、第3の共有ライブラリを削除することができない。加えて、携帯電話100は第2のAPPを削除するので、すなわち、第3の共有ライブラリを呼び出すAPPの数が減るので、携帯電話100は、第3のinodeに対応する共有ライブラリの数を更新するために、第3のinodeのリンク数を変更する。したがって、携帯電話100は、第3のinodeのリンク数に基づいて、第3の共有ライブラリによって置き換えられる共有ライブラリの数を決定することができる。

前述の技術的解決策に基づいて、電子デバイスは、inode（例えば、第3のinode）のリンク数に基づいて、電子デバイス内のAPPが共有ライブラリ（例えば、第3の共有ライブラリ）のファイルデータを呼び出す必要があるかどうかを判定して、第3のinode、第3のinode、および第3の共有ライブラリのファイル名と第3のinodeとの間の対応関係に対応する共有ライブラリのファイルデータが削除され得るかどうかを判定することができる。これは、記憶空間の無駄を減らすことができるだけでなく、共有ライブラリが欠落しても電子デバイス内のAPPが適切な動作に失敗しないことを保証することもできる。

APPが電子デバイスにインストールされると、電子デバイスは、実行可能プログラムおよびAPPの少なくとも1つの共有ライブラリを記憶するだけでなく、テキストファイル、画像、および音声などの情報データをAPPに記憶してもよいことに留意されたい。このようにして、APPが実行されると、実行可能プログラムは、APP内の情報データを呼び出し、情報データ（例えば、画像）をユーザに表示することができる。しかしながら、電子デバイス内の異なるAPPが同じ情報データを含む場合には、例えば、第1のAPPが画像aを含み、第2のAPPも画像aを含む場合、電子デバイスは画像aを繰り返し記憶する。これは、記憶空間の浪費のみを引き起こす。加えて、第1のAPPおよび第2のAPPが動作するとき、メモリ・オペレーティング・システムは、画像aをメモリにマッピングする。これはI／O性能に影響するだけでなく、メモリ空間の浪費を引き起こす。したがって、本出願のこの実施形態で提供される共有ライブラリを再利用するための方法は、電子デバイスにおける共有ライブラリの管理に適用可能であるだけでなく、電子デバイスにおけるAPP内の情報データの管理にも適用可能である。これは、本出願のこの実施形態では限定されない。情報データを再利用するための具体的な方法については、前述の実施形態の説明を参照されたく、ここでは詳細を繰り返さない。

電子デバイスにおける情報データの属性は、読み出し専用の属性である。このようにして、APP内の情報データが変化しないことを保証するために、情報データが改ざんされることが防止され得る。

上記は、電子デバイスの観点から本出願の実施形態で提供される解決策を主に説明している。上記の機能を実施するために、電子デバイスが機能を実行するための対応するハードウェア構成および／またはソフトウェアモジュールを含むことが理解されよう。当業者は、本出願で開示された実施形態に記載された例と組み合わせて、共有ライブラリを再利用するための方法のステップが、本出願におけるハードウェアまたはハードウェアとコンピュータソフトウェアとの組み合わせによって実施され得ることを容易に認識すべきである。機能がハードウェアによって実施されるか、電子デバイスのソフトウェアによって駆動されるハードウェアによって実施されるかは、技術的解決策の特定の用途および設計制約に依存する。当業者は、説明された機能を特定の用途ごとに実施するために異なる方法を使用し得るが、実施態様が本出願の範囲を超えると考えられてはならない。

本出願の実施形態では、共有ライブラリを再利用するための装置は、前述の方法例に基づいて機能モジュールまたは機能ユニットに分割されてもよい。例えば、各機能モジュールまたは機能ユニットは、対応する各機能に基づく分割によって取得されてもよく、または2つ以上の機能が1つの処理モジュールに統合されてもよい。前述の統合モジュールは、ハードウェアの形態で実装されてもよいし、あるいはソフトウェア機能モジュールまたはソフトウェア機能ユニットの形態で実装されてもよい。本出願の実施形態では、モジュールまたはユニット分割は一例であり、論理的な機能分割にすぎない。実際の実装では、別の分割方式が使用されてもよい。

図6は、本出願の一実施形態による共有ライブラリを再利用するための装置の概略図である。共有ライブラリを再利用するための装置は、前述の電子デバイス（例えば、携帯電話100）内にあり、本出願の実施形態における方法を実施するように構成された機能モジュールであってもよい。図6に示すように、共有ライブラリを再利用するための装置は、処理ユニット601および記憶ユニット602を含むことができる。

記憶ユニット602は、少なくとも1つの共有ライブラリを記憶するように構成されている。例えば、携帯電話100が第1のAPPを含む場合、第1のAPPは共有ライブラリaを含み、記憶ユニットは共有ライブラリaを記憶するように構成されてもよい。

処理ユニット601は、第1のAPPの第1の共有ライブラリと同じファイルデータを有する第2の共有ライブラリが記憶ユニット602内に存在するかどうかを判定するように構成されており、第1の共有ライブラリは第1のAPP内の任意の共有ライブラリである。例えば、図3を参照すると、処理ユニット601は、S301を実行するように構成されてもよい。

記憶ユニット602は、第2の共有ライブラリが記憶ユニット内に存在する場合には、第1のインデックスノードinodeと第1の共有ライブラリのファイル名との間の対応関係を記憶するようにさらに構成されており、第1のinodeは処理ユニットによって第2の共有ライブラリに割り当てられ、第1のinodeは第2の共有ライブラリのファイルデータを記憶するために使用される第1の記憶領域を示す。例えば、図3を参照すると、処理ユニット601は、S302を実行するように構成されてもよい。

処理ユニット601は、記憶ユニットから第1の共有ライブラリのファイルデータを削除するようにさらに構成されている。

処理ユニット601は、第1のAPPを実行して第1の共有ライブラリを呼び出すときに、第1の共有ライブラリのファイル名に対応する第1のinodeを検索し、第1のinodeによって示される記憶領域に記憶されている第2の共有ライブラリのファイルデータを読み出すようにさらに構成されている。例えば、図3を参照すると、処理ユニット601は、S304を実行するようにさらに構成されてもよい。

任意選択で、処理ユニット601は、第1のAPPのインストールを完了するときに、第1のAPPの第1の共有ライブラリと同じファイルデータを有する第2の共有ライブラリが記憶ユニット内に存在するかどうかを判定するか、あるいは、第1のAPPの実行を完了するときに、第1のAPPの第1の共有ライブラリと同じファイルデータを有する第2の共有ライブラリが記憶ユニット内に存在するかどうかを判定する、ように具体的に構成される。例えば、携帯電話100は、ネットワークを用いて第1のAPPのAPKをダウンロードし、記憶ユニット602に記憶する。第1のAPPのAPKの解凍が完了すると、すなわち第1のAPPのインストールが完了すると、処理ユニット601は、第1のAPPの第1の共有ライブラリと同じファイルデータを有する第2の共有ライブラリが記憶ユニット内に存在するかどうかを判定する。

任意選択で、処理ユニット601は、第1のAPPの最初の実行を完了するときに、第1のAPPの第1の共有ライブラリと同じファイルデータを有する第2の共有ライブラリが記憶ユニット内に存在するかどうかを判定するようにさらに特に構成されている。

任意選択で、処理ユニット601は、第2の共有ライブラリが記憶ユニット602内に存在しない場合には、第1の共有ライブラリに第2のinodeを割り当て、第2のinodeは、第1の共有ライブラリのファイルデータを記憶するために使用される第2の記憶領域を示す、ようにさらに構成される。例えば、図4を参照すると、処理ユニット601は、S401を実行するようにさらに構成されてもよい。

記憶ユニット602は、第2のinodeと第1の共有ライブラリのファイル名との間の対応関係を記憶するようにさらに構成されている。例えば、図4を参照すると、記憶ユニット602は、S402を実行するようにさらに構成されてもよい。

処理ユニット601は、第1のAPPを実行して第1の共有ライブラリを呼び出すときに、第1の共有ライブラリのファイル名に対応する第2のinodeを検索し、第2のinodeによって示される第2の記憶領域に記憶された第1の共有ライブラリのファイルデータを読み出すようにさらに構成される。例えば、図4を参照すると、処理ユニット601は、S403を実行するようにさらに構成されてもよい。

任意選択で、処理ユニット601は、第2の共有ライブラリが記憶ユニット内に存在する場合には、第1のinodeのリンク数に1を加算し、第1のinodeのリンク数は、第1のinodeに対応する共有ライブラリの数であるか、または、第2の共有ライブラリが記憶ユニット内に存在しない場合には、第2のinodeのリンク数に1を加算し、第2のinodeのリンク数は第2のinodeに対応する共有ライブラリの数であり、各inodeのリンク数の初期値は0である、ようにさらに構成される。

任意選択で、処理ユニット601は、第2のAPPを削除するときに、第3の共有ライブラリのファイル名に対応する第3のinodeのための記憶ユニット602を検索するようにさらに構成される。例えば、処理ユニット601は、前述の方法実施形態におけるS601を実行することができる。

処理ユニット601は、第3のinodeのリンク数が1に等しいかどうかを判定するようにさらに構成される。例えば、処理ユニット601は、前述の方法実施形態におけるS602を実行することができる。

処理ユニット601は、第3のinodeのリンク数が1に等しい場合には、第3の共有ライブラリのファイルデータ、第3のinode、および第3の共有ライブラリのファイル名と第3のinodeとの間の対応関係を記憶ユニット602から削除するようにさらに構成される。例えば、処理ユニット601は、前述の方法実施形態におけるS603を実行することができる。

処理ユニット601は、第3のinodeのリンク数が1より大きい場合には、第3のinodeのリンク数から1を減算するようにさらに構成される。例えば、処理ユニット601は、前述の方法実施形態におけるS604を実行することができる。

任意選択で、処理ユニット601は、事前設定されたアルゴリズムを用いて第1の共有ライブラリのファイルデータに基づいて第1の共有ライブラリの第1の識別情報を生成し、第1の識別情報が第2の識別情報と同じであるかどうかを判定し、第2の識別情報は、事前設定されたアルゴリズムを用いて記憶ユニット内の任意の共有ライブラリのファイルデータに基づいて処理ユニットによって生成され、第1の識別情報が第2の識別情報と同じである場合には、第1の共有ライブラリと同じファイルデータを有する第2の共有ライブラリが記憶ユニット内に存在すると判定するか、または第1の識別情報と第2の識別情報とが異なる場合には、第1の共有ライブラリと同じファイルデータを有する第2の共有ライブラリが記憶ユニット内に存在しないと判定する、ように具体的に構成される。

任意選択で、記憶ユニット602は、第1の識別情報が第2の識別情報と異なる場合には、第1の識別情報と第2のinodeとの間の対応関係を記憶するようにさらに構成される。

任意選択で、処理ユニット601は、第3のinodeのリンク数が1に等しい場合には、第3のinodeと第3の識別情報との間の対応関係を記憶ユニット602から削除し、第3の識別情報は、事前設定されたアルゴリズムを用いて第3の共有ライブラリのファイルデータに基づいて処理ユニットによって生成される、ようにさらに構成される。

任意選択で、処理ユニット601は、第1の共有ライブラリのファイルデータを記憶ユニット内の各共有ライブラリのファイルデータと比較し、第1の共有ライブラリと同じファイルデータを有する第2の共有ライブラリが記憶ユニット602内に存在するかどうかを判定するようにさらに具体的に構成される。

本出願のいくつかの他の実施形態は、電子デバイス（例えば、図1に示す携帯電話100）を提供する。電子デバイスには、複数のAPPがインストールされており、複数のAPPの各々は、少なくとも1つの共有ライブラリを含む。例えば、少なくとも1つの共有ライブラリは、第2の共有ライブラリを含むことができる。

電子デバイスは、メモリおよび1つもしくは複数のプロセッサを含むことができる。メモリは、プロセッサに結合される。電子デバイスは、カメラをさらに含んでもよい。あるいは、電子デバイスは、外部カメラに接続されてもよい。メモリは、コンピュータプログラムコードを記憶するように構成される。コンピュータプログラムコードは、コンピュータ命令を含む。プロセッサがコンピュータ命令を実行すると、電子デバイスは、前述の方法実施形態において携帯電話によって実行される機能またはステップを実行することができる。電子デバイスの構造については、図1に示す携帯電話100の構造を参照されたい。

本出願の一実施形態は、チップシステムをさらに提供する。図7に示すように、チップシステムは、少なくとも1つのプロセッサ701と、少なくとも1つのインターフェース回路702と、を含む。プロセッサ701およびインターフェース回路702は、回線を介して相互接続されてもよい。例えば、インターフェース回路702は、他の装置（例えば、電子デバイスのメモリ）から信号を受信するように構成されてもよい。別の例として、インターフェース回路702は、別の装置（例えば、プロセッサ701）に信号を送信するように構成されてもよい。例えば、インターフェース回路702は、メモリに記憶された命令を読み出し、その命令をプロセッサ701に送信することができる。命令がプロセッサ701によって実行されると、電子デバイス（例えば、図1に示す携帯電話100）は、前述の実施形態のステップを実行することを可能にされ得る。確かに、チップシステムは、別の個別のデバイスをさらに含むことができる。これは、本出願のこの実施形態では特に限定されない。

本出願の一実施形態は、コンピュータ記憶媒体をさらに提供する。コンピュータ記憶媒体はコンピュータ命令を含む。コンピュータ命令が前述の電子デバイス（例えば、図1に示す携帯電話100）上で実行されると、電子デバイスは、前述の方法実施形態において携帯電話によって実行される機能またはステップを実行することを可能にされる。

本出願の一実施形態は、コンピュータプログラム製品をさらに提供する。コンピュータプログラム製品がコンピュータ上で実行されると、コンピュータは、前述の方法の実施形態において携帯電話によって実行される機能またはステップを実行することを可能にされる。

前述の実施態様の説明に基づいて、説明を簡単かつ簡潔にするために、前述の機能モジュールの分割は単に例示のための例として使用されているにすぎないことが当業者によって明確に理解されよう。実際の応用では、上述の機能の全部または一部を実施するために、前述の機能が異なる機能モジュールに割り当てられ、要件に基づいて実施され得る、すなわち、装置の内部構造が異なる機能モジュールに分割される。

本出願で提供されるいくつかの実施形態では、開示されている装置および方法が他の方式で実装されてもよいことを理解されたい。例えば、説明されている装置実施形態は一例にすぎない。例えば、モジュールまたはユニットの分割は、論理的な機能分割にすぎず、実際の実装における別の分割であってもよい。例えば、複数のユニットまたは構成要素は、別の装置に組み合わされるかまたは統合されてもよく、あるいは一部の特徴は、無視されるかまたは実行されなくてもよい。加えて、表示または議論される相互結合または直接結合または通信接続は、一部のインターフェースを通して実装されてもよい。装置またはユニット間の間接的な結合または通信接続は、電気的な、機械的な、または他の形態で実施されてもよい。

別々の部分として説明されたユニットは物理的に分離している場合もそうでない場合もあり、ユニットとして表示された部分は、1つまたは複数の物理ユニットであってもよいし、一箇所に配置されてもよいし、異なる場所に分散されてもよい。ユニットの一部または全部が、実施形態の解決策の目的を達成するために実際の要件に基づいて選択されてもよい。

加えて、本出願の実施形態における機能ユニットが、1つの処理ユニットに組み込まれてもよいし、あるいは、ユニットの各々が、物理的に単独で存在してもよく、または2つ以上のユニットが1つのユニットに組み込まれてもよい。前述の統合ユニットは、ハードウェアの形態で実装されてもよく、ソフトウェア機能ユニットの形態で実装されてもよい。

統合ユニットがソフトウェア機能ユニットの形態で実装され、独立した製品として販売または使用される場合は、統合ユニットが読み出し可能な記憶媒体に記憶されてもよい。このような理解に基づいて、本質的に本出願の実施形態における技術的解決策、または従来技術に寄与する部分、または技術的解決策の全部もしくは一部は、ソフトウェア製品の形態で実装されてもよい。ソフトウェア製品は、記憶媒体に記憶され、本出願の実施形態における方法のステップのすべてまたは一部を実行するようにデバイス（シングルチップマイクロコンピュータ、チップなどであってもよい）またはプロセッサ（processor）に命令するための複数の命令を含む。前述の記憶媒体は、USBフラッシュドライブ、リムーバブル・ハード・ディスク、リード・オンリー・メモリ（read only memory、ROM）、ランダム・アクセス・メモリ（random access memory、RAM）、磁気ディスク、または光ディスクなどの、プログラムコードを記憶し得る何らかの媒体を含む。

上記の説明は本出願の特定の実施態様にすぎず、本出願の保護範囲を限定することは意図されていない。本出願で開示された技術的範囲内の変更または置換は、本出願の保護範囲に含まれるものとする。したがって、本出願の保護範囲は、特許請求の範囲の保護範囲に従うものとする。

100 携帯電話
110 プロセッサ
120 外部メモリインターフェース
121 内部メモリ
130 ユニバーサルシリアルバス（USB）インターフェース
140 充電管理モジュール
141 電力管理モジュール
142 バッテリ
150 移動通信モジュール
160 無線通信モジュール
170 オーディオモジュール
170A スピーカ
170B 受信機
170C マイクロフォン
170D ヘッドセットジャック
180 センサモジュール
190 ボタン
191 モータ
192 インジケータ
193 カメラ
194 ディスプレイ
195 加入者識別モジュール（SIM）カードインターフェース
601 処理ユニット
602 記憶ユニット
701 プロセッサ
702 インターフェース回路

第3のinodeへのリンク数が1に等しい場合には、携帯電話100はS603を実行するか、または、第3のinodeへのリンク数が1より大きい場合には、携帯電話100はS604を実行する。

Claims (21)

1. 電子デバイスに適用される、共有ライブラリを再利用するための方法であって、複数のアプリケーションAPPが前記電子デバイスにインストールされ、前記複数のAPPの各々が少なくとも1つの共有ライブラリを含み、前記再利用するための方法が、
   第1のAPPの第1の共有ライブラリと同じファイルデータを有する第2の共有ライブラリが前記電子デバイス内に存在するかどうかを判定するステップであって、前記第1の共有ライブラリが前記第1のAPP内の任意の共有ライブラリである、ステップと、
   前記第2の共有ライブラリが前記電子デバイス内に存在する場合には、第1のインデックスノードinodeと前記第1の共有ライブラリのファイル名との間の対応関係を記憶し、前記第1の共有ライブラリの前記ファイルデータを前記電子デバイスから削除するステップであって、前記第1のinodeが、前記電子デバイスによって前記第2の共有ライブラリに割り当てられ、前記第1のinodeが、前記第2の共有ライブラリのファイルデータを記憶するために使用される第1の記憶領域を示す、ステップと、
   前記電子デバイスが前記第1のAPPを実行して前記第1の共有ライブラリを呼び出すときに、前記第1の共有ライブラリの前記ファイル名に対応する前記第1のinodeを検索し、前記第1のinodeによって示される前記記憶領域に記憶された前記第2の共有ライブラリの前記ファイルデータを読み出すステップと、
   を含む、共有ライブラリを再利用するための方法。
2. 第1のAPPの第1の共有ライブラリと同じファイルデータを有する第2の共有ライブラリが前記電子デバイス内に存在するかどうかを判定する前記ステップが、
   前記電子デバイスが前記第1のAPPのインストールを完了するときに、前記第1のAPPの前記第1の共有ライブラリと同じ前記ファイルデータを有する前記第2の共有ライブラリが前記電子デバイス内に存在するかどうかを判定するステップか、または
   前記電子デバイスが前記第1のAPPの実行を完了するときに、前記第1のAPPの前記第1の共有ライブラリと同じ前記ファイルデータを有する前記第2の共有ライブラリが前記電子デバイス内に存在するかどうかを判定するステップ
   を含む、請求項1に記載の共有ライブラリを再利用するための方法。
3. 前記方法が、
   前記第2の共有ライブラリが前記電子デバイス内に存在しない場合には、前記第1の共有ライブラリに第2のinodeを割り当てるステップであって、前記第2のinodeが、前記第1の共有ライブラリの前記ファイルデータを記憶するために使用される第2の記憶領域を示す、ステップと、
   前記第2のinodeと前記第1の共有ライブラリの前記ファイル名との間の対応関係を記憶するステップと、
   前記電子デバイスが前記第1のAPPを実行して前記第1の共有ライブラリを呼び出すときに、前記第1の共有ライブラリの前記ファイル名に対応する前記第2のinodeを検索し、前記第2のinodeによって示される前記第2の記憶領域に記憶された前記第1の共有ライブラリの前記ファイルデータを読み出すステップと、をさらに含む、請求項1または2に記載の共有ライブラリを再利用するための方法。
4. 前記方法が、
   前記第2の共有ライブラリが前記電子デバイス内に存在する場合には、前記第1のinodeのリンク数に1を加算するステップであって、前記第1のinodeの前記リンク数が前記第1のinodeに対応する共有ライブラリの数である、ステップか、または
   前記第2の共有ライブラリが前記電子デバイス内に存在しない場合には、前記第2のinodeのリンク数に1を加算するステップであって、前記第2のinodeの前記リンク数が前記第2のinodeに対応する共有ライブラリの数である、ステップをさらに含み、
   各inodeのリンク数の初期値が0である、請求項3に記載の共有ライブラリを再利用するための方法。
5. 前記方法が、
   前記電子デバイスが第2のAPPを削除するときに、第3の共有ライブラリのファイル名に対応する第3のinodeを検索するステップと、
   前記第3のinodeのリンク数が1に等しい場合には、前記第3の共有ライブラリのファイルデータ、前記第3のinode、および前記第3の共有ライブラリの前記ファイル名と前記第3のinodeとの間の対応関係を前記電子デバイスから削除するステップか、または
   前記第3のinodeのリンク数が1より大きい場合には、前記第3のinodeの前記リンク数から1を減算するステップと、をさらに含む、請求項3または4に記載の共有ライブラリを再利用するための方法。
6. 第1のAPPの第1の共有ライブラリと同じファイルデータを有する第2の共有ライブラリが前記電子デバイス内に存在するかどうかを判定する前記ステップが、
   事前設定されたアルゴリズムを用いて前記第1の共有ライブラリの前記ファイルデータに基づいて前記第1の共有ライブラリの第1の識別情報を生成し、前記第1の識別情報が第2の識別情報と同じであるかどうかを判定するステップであって、前記第2の識別情報は、前記事前設定されたアルゴリズムを用いて前記電子デバイス内の任意の共有ライブラリのファイルデータに基づいて前記電子デバイスによって生成される、ステップと、
   前記第1の識別情報が前記第2の識別情報と同じである場合には、前記第1の共有ライブラリと同じ前記ファイルデータを有する前記第2の共有ライブラリが前記電子デバイス内に存在すると判定するステップか、または
   前記第1の識別情報が前記第2の識別情報と異なる場合には、前記第1の共有ライブラリと同じ前記ファイルデータを有する前記第2の共有ライブラリが前記電子デバイス内に存在しないと判定するステップと、を含む、請求項3から5のいずれか一項に記載の共有ライブラリを再利用するための方法。
7. 前記方法が、
   前記第1の識別情報が前記第2の識別情報と異なる場合には、前記第1の識別情報と前記第2のinodeとの間の対応関係を記憶するステップをさらに含む、請求項6に記載の共有ライブラリを再利用するための方法。
8. 前記方法が、
   前記第3のinodeの前記リンク数が1に等しい場合には、前記第3のinodeと第3の識別情報との間の対応関係を前記電子デバイスから削除するステップをさらに含み、
   前記第3の識別情報は、前記事前設定されたアルゴリズムを用いて前記第3の共有ライブラリの前記ファイルデータに基づいて前記電子デバイスによって生成される、請求項5に記載の共有ライブラリを再利用するための方法。
9. 第1のAPPの第1の共有ライブラリと同じファイルデータを有する第2の共有ライブラリが前記電子デバイス内に存在するかどうかを判定する前記ステップが、
   前記第1の共有ライブラリの前記ファイルデータと前記電子デバイス内の各共有ライブラリのファイルデータとを比較し、前記第1の共有ライブラリと同じ前記ファイルデータを有する前記第2の共有ライブラリが前記電子デバイス内に存在するかどうかを判定するステップを含む、請求項1から5のいずれか一項に記載の共有ライブラリを再利用するための方法。
10. 電子デバイスであって、複数のアプリケーションAPPが前記電子デバイスにインストールされ、前記複数のAPPの各々が少なくとも1つの共有ライブラリを含み、前記電子デバイスがメモリおよびプロセッサを含み、前記メモリが前記プロセッサに結合され、前記少なくとも1つの共有ライブラリが前記メモリに記憶され、前記メモリがコンピュータプログラムコードを記憶するようにさらに構成され、前記コンピュータプログラムコードがコンピュータ命令を含み、前記コンピュータ命令が前記プロセッサによって実行されると、前記電子デバイスが、
    第1のAPPの第1の共有ライブラリと同じファイルデータを有する第2の共有ライブラリが前記メモリ内に存在するかどうかを判定する動作であって、前記第1の共有ライブラリが前記第1のAPP内の任意の共有ライブラリである、動作と、
    前記第2の共有ライブラリが前記メモリ内に存在する場合には、第1のインデックスノードinodeと前記第1の共有ライブラリのファイル名との間の対応関係を記憶し、前記第1の共有ライブラリの前記ファイルデータを前記メモリから削除する動作であって、前記第1のinodeが、前記プロセッサによって前記第2の共有ライブラリに割り当てられ、前記第1のinodeが、前記メモリ内にあって、前記第2の共有ライブラリのファイルデータを記憶するために使用される第1の記憶領域を示す、動作と、
    前記第1のAPPを実行して前記メモリから前記第1の共有ライブラリを呼び出すときに、前記第1の共有ライブラリの前記ファイル名に対応する前記第1のinodeを検索し、前記第1のinodeによって示される前記記憶領域に記憶された前記第2の共有ライブラリの前記ファイルデータを読み出す動作と、を実行することを可能にされる、電子デバイス。
11. 前記コンピュータ命令が前記1つまたは複数のプロセッサによって実行されると、前記電子デバイスが、
    前記第1のAPPのインストールを完了するときに、前記第1のAPPの前記第1の共有ライブラリと同じ前記ファイルデータを有する前記第2の共有ライブラリが前記メモリ内に存在するかどうかを判定するステップか、または
    前記第1のAPPの実行を完了するときに、前記第1のAPPの前記第1の共有ライブラリと同じ前記ファイルデータを有する前記第2の共有ライブラリが前記メモリ内に存在するかどうかを判定するステップをさらに実行することを可能にされる、請求項10に記載の電子デバイス。
12. 前記コンピュータ命令が前記1つまたは複数のプロセッサによって実行されると、前記電子デバイスが、
    前記第2の共有ライブラリが前記メモリ内に存在しない場合には、前記第1の共有ライブラリに第2のinodeを割り当てるステップであって、前記第2のinodeが、前記第1の共有ライブラリの前記ファイルデータを記憶するために使用される第2の記憶領域を示す、ステップと、
    前記第2のinodeと前記第1の共有ライブラリの前記ファイル名との間の対応関係を記憶するステップと、
    前記第1のAPPを実行して前記第1の共有ライブラリを呼び出すときに、前記第1の共有ライブラリの前記ファイル名に対応する前記第2のinodeを検索し、前記第2のinodeによって示される前記第2の記憶領域に記憶された前記第1の共有ライブラリの前記ファイルデータを読み出すステップと、をさらに実行することを可能にされる、請求項10または11に記載の電子デバイス。
13. 前記コンピュータ命令が前記1つまたは複数のプロセッサによって実行されると、前記電子デバイスが、
    前記第2の共有ライブラリが前記メモリ内に存在する場合には、前記第1のinodeのリンク数に1を加算するステップであって、前記第1のinodeの前記リンク数が前記第1のinodeに対応する共有ライブラリの数である、ステップか、または
    前記第2の共有ライブラリが前記メモリ内に存在しない場合には、前記第2のinodeのリンク数に1を加算するステップであって、前記第2のinodeの前記リンク数が前記第2のinodeに対応する共有ライブラリの数である、ステップをさらに実行することを可能にされ、
    各inodeのリンク数の初期値が0である、請求項12に記載の電子デバイス。
14. 前記コンピュータ命令が前記1つまたは複数のプロセッサによって実行されると、前記電子デバイスが、
    第2のAPPを削除するときに、第3の共有ライブラリのファイル名に対応する第3のinodeを検索するステップと、
    前記第3のinodeのリンク数が1に等しい場合には、前記第3の共有ライブラリのファイルデータ、前記第3のinode、および前記第3の共有ライブラリの前記ファイル名と前記第3のinodeとの間の対応関係を前記メモリから削除するステップか、または
    前記第3のinodeのリンク数が1より大きい場合には、前記第3のinodeの前記リンク数から1を減算するステップと、をさらに実行することを可能にされる、請求項12または13に記載の電子デバイス。
15. 前記コンピュータ命令が前記1つまたは複数のプロセッサによって実行されると、前記電子デバイスが、
    事前設定されたアルゴリズムを用いて前記第1の共有ライブラリの前記ファイルデータに基づいて前記第1の共有ライブラリの第1の識別情報を生成し、前記第1の識別情報が第2の識別情報と同じであるかどうかを判定するステップであって、前記第2の識別情報は、前記事前設定されたアルゴリズムを用いて前記メモリ内の任意の共有ライブラリのファイルデータに基づいて前記プロセッサによって生成される、ステップと、
    前記第1の識別情報が前記第2の識別情報と同じである場合には、前記第1の共有ライブラリと同じ前記ファイルデータを有する前記第2の共有ライブラリが前記メモリ内に存在すると判定するステップか、または
    前記第1の識別情報が前記第2の識別情報と異なる場合には、前記第1の共有ライブラリと同じ前記ファイルデータを有する前記第2の共有ライブラリが前記メモリ内に存在しないと判定するステップと、をさらに実行することを可能にされる、請求項12から14のいずれか一項に記載の電子デバイス。
16. 前記コンピュータ命令が前記1つまたは複数のプロセッサによって実行されると、前記電子デバイスが、
    前記第1の識別情報が前記第2の識別情報と異なる場合には、前記第1の識別情報と前記第2のinodeとの間の対応関係を記憶するステップをさらに実行することを可能にされる、請求項15に記載の電子デバイス。
17. 前記コンピュータ命令が前記1つまたは複数のプロセッサによって実行されると、前記電子デバイスが、
    前記第3のinodeのリンク数が1に等しい場合には、前記第3のinodeと第3の識別情報との間の対応関係を前記メモリから削除するステップをさらに実行することを可能にされ、
    前記第3の識別情報は、前記事前設定されたアルゴリズムを用いて前記第3の共有ライブラリの前記ファイルデータに基づいて前記プロセッサによって生成される、請求項16に記載の電子デバイス。
18. 前記コンピュータ命令が前記1つまたは複数のプロセッサによって実行されると、前記電子デバイスが、
    前記第1の共有ライブラリの前記ファイルデータと前記メモリ内の各共有ライブラリのファイルデータとを比較し、前記第1の共有ライブラリと同じ前記ファイルデータを有する前記第2の共有ライブラリが前記メモリ内に存在するかどうかを判定するステップをさらに実行することを可能にされる、請求項17に記載の電子デバイス。
19. チップシステムであって、前記チップシステムは電子デバイスに適用され、複数のAPPが前記電子デバイスにインストールされ、前記複数のAPPの各々が少なくとも1つの共有ライブラリを含み、前記チップシステムが、1つまたは複数のインターフェース回路と、1つまたは複数のプロセッサと、を含み、前記インターフェース回路および前記プロセッサが、回線を介して相互接続され、前記インターフェース回路が、前記電子デバイスのメモリから信号を受信し、前記信号を前記プロセッサに送信するように構成され、前記信号が前記メモリに記憶されたコンピュータ命令を含み、前記プロセッサが前記コンピュータ命令を実行すると、前記電子デバイスが請求項1から9のいずれか一項に記載の方法を実行する、チップシステム。
20. コンピュータ命令を含むコンピュータ記憶媒体であって、前記コンピュータ命令が電子デバイス上で実行されると、前記電子デバイスが請求項1から9のいずれか一項に記載の方法を実行することを可能にされる、コンピュータ記憶媒体。
21. コンピュータプログラム製品であって、前記コンピュータプログラム製品がコンピュータ上で実行されると、前記コンピュータが、請求項1から9のいずれか一項に記載の方法を実行することを可能にされる、コンピュータプログラム製品。