特許 6571277 端末アプリケーションをロードする方法及び装置

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6571277

(24)【登録日】2019年8月16日

(45)【発行日】2019年9月4日

(54)【発明の名称】端末アプリケーションをロードする方法及び装置

(51)【国際特許分類】

   G06F 9/445 20180101AFI20190826BHJP

【ＦＩ】

   G06F9/445 130

【請求項の数】11

【全頁数】22

(21)【出願番号】特願2018-514994(P2018-514994)

(86)(22)【出願日】2016年9月13日

(65)【公表番号】特表2018-527683(P2018-527683A)

(43)【公表日】2018年9月20日

(86)【国際出願番号】CN2016098814

(87)【国際公開番号】WO2017050146

(87)【国際公開日】20170330

【審査請求日】2018年5月23日

(31)【優先権主張番号】201510603127.7

(32)【優先日】2015年9月21日

(33)【優先権主張国】CN

(73)【特許権者】

【識別番号】505032849

【氏名又は名称】アリババ グループ ホウルディング リミテッド

(74)【代理人】

【識別番号】100097320

【弁理士】

【氏名又は名称】宮川 貞二

(74)【代理人】

【識別番号】100155192

【弁理士】

【氏名又は名称】金子 美代子

(74)【代理人】

【識別番号】100131820

【弁理士】

【氏名又は名称】金井 俊幸

(74)【代理人】

【識別番号】100100398

【弁理士】

【氏名又は名称】柴田 茂夫

(72)【発明者】

【氏名】リ，リージョン

(72)【発明者】

【氏名】ジョウ，グァンフェイ

【審査官】 塚田 肇

(56)【参考文献】

【文献】 特開２００２−０４９５００（ＪＰ，Ａ）

【文献】 特開２０１４−２２５７２４（ＪＰ，Ａ）

【文献】 特開平０６−３４８５００（ＪＰ，Ａ）

【文献】 韓国登録特許第１０−０５３８７７８（ＫＲ，Ｂ１）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ ９／４４５

(57)【特許請求の範囲】

【請求項1】

デバイスにインストールされたメインアプリケーションを開始する第１の命令を、コンピュータデバイスで受信するステップであって、前記メインアプリケーションは複数のサブアプリケーションを含む、第１の命令を受信するステップと；
前記第１の命令を受信するステップに応答して、前記メインアプリケーションを開始するプロセスにおいてロードする１つ又は複数のサブアプリケーションを、前記コンピュータデバイスにより決定するステップと；
前記メインアプリケーションのためのアプリケーションロード情報を、前記コンピュータデバイスにより取得するステップであって、前記アプリケーションロード情報は、事前設定期間における複数のサブアプリケーションの使用頻度情報に基づいて生成され、前記メインアプリケーションを開始するプロセスにおけるロード対象サブアプリケーションを識別する、取得するステップと；
前記メインアプリケーションを開始するプロセスにおいて、取得した前記アプリケーションロード情報で識別された前記サブアプリケーションを、前記コンピュータデバイスによりロードするステップを備える、
コンピュータ実施方法。

【請求項2】

前記メインアプリケーションのためのアプリケーションロード情報を取得するステップは：
ユーザにより事前に選択されたサブアプリケーションに基づいて生成され、前記事前に選択されたサブアプリケーションを識別するアプリケーションロード情報を取得するステップ；又は、
ｉ）ユーザにより事前に選択されたサブアプリケーションの数、及び、ｉｉ）事前に選択された前記数のサブアプリケーションの事前設定期間における利用頻度情報に基づいて生成されるアプリケーションロード情報を取得するステップであって、前記アプリケーションロード情報は、前記メインアプリケーションを開始するプロセスにおけるロード対象サブアプリケーションを識別する、取得するステップを備える、
請求項１の方法。

【請求項3】

前記事前に選択されたサブアプリケーションは、前記メインアプリケーションを開始するプロセスにおいてユーザにより頻繁にロード対象に用いられるサブアプリケーションを選択するために、前記メインアプリケーションのロード設定機能を介して選択されたサブアプリケーションを備える、
請求項２に記載の方法。

【請求項4】

前記メインアプリケーションのためのアプリケーションロード情報を取得するステップの前に、前記方法は：
利用頻度情報を取得するための要求情報を、前記コンピュータデバイスによりサーバへ送信するステップと；
前記要求情報の送信に応答して、前記メインアプリケーションに含まれるサブアプリケーションの事前設定期間における利用頻度情報を、前記コンピュータデバイスでサーバから受信するステップと；
受信した前記利用頻度情報を、前記コンピュータデバイスにより降順にソートするステップと；
利用頻度情報が先頭にソートされたサブアプリケーションを、前記メインアプリケーションを開始するプロセスにおけるロード対象サブアプリケーションとして前記コンピュータデバイスにより決定するステップと；
前記サブアプリケーションを識別するアプリケーションロード情報を、前記コンピュータデバイスにより生成するステップと；
前記デバイスの指定されたディレクトリに、前記アプリケーションロード情報を保存するステップと；を更に備える、
請求項１に記載の方法。

【請求項5】

前記メインアプリケーションに対応するアプリケーションロード情報を取得するステップは、前記デバイスの前記指定されたディレクトリから、前記メインアプリケーションの前記アプリケーションロード情報を読み出すステップ；を備える、
請求項４に記載の方法。

【請求項6】

前記メインアプリケーションのためのアプリケーションロード情報を取得するステップの前に、前記方法は：
前記デバイスの前記メインアプリケーションのインストールディレクトリから、前記メインアプリケーションに含まれるサブアプリケーションの、事前設定期間における利用頻度情報を取得するステップと；
受信した前記利用頻度情報を降順にソートし、利用頻度情報が先頭にソートされたサブアプリケーションを、前記メインアプリケーションを開始するプロセスにおけるロード対象サブアプリケーションとして決定するステップと；
前記メインアプリケーションを開始するプロセスにおける前記ロード対象サブアプリケーションを識別するアプリケーションロード情報を生成するステップと；
前記デバイスの指定されたディレクトリに、前記アプリケーションロード情報を保存するステップと；を更に備える、
請求項１に記載の方法。

【請求項7】

前記メインアプリケーションのためのアプリケーションロード情報を取得するステップは、前記デバイスの前記指定されたディレクトリから、前記メインアプリケーションのための前記アプリケーションロード情報を読み出すステップ；を備える、
請求項６に記載の方法。

【請求項8】

前記メインアプリケーションを開始するプロセスにおいて、取得した前記アプリケーションロード情報内の識別された前記サブアプリケーションをロードするステップは：
前記メインアプリケーションを開始するプロセスにおける前記サブアプリケーションを識別するステップと；
前記デバイスが、前記サブアプリケーションのインストールディレクトリを有するか否かを決定するステップと；
有する場合、前記サブアプリケーションの前記インストールディレクトリに対応するストレージパス情報を取得するステップと；
取得した前記ストレージパス情報に基づいて、前記メインアプリケーション内の前記サブアプリケーションの前記インストールディレクトリ内のファイルを呼び出し、前記サブアプリケーションをロードするステップと；を備える、
請求項１に記載の方法。

【請求項9】

前記デバイスが、前記メインアプリケーションを開始するプロセスにおける、識別された前記ロード対象サブアプリケーションのインストールディレクトリを有していない場合、前記メインアプリケーションを開始するプロセスにおける、識別された前記ロード対象サブアプリケーションに対応するインストールパッケージを取得し、前記デバイスに前記パッケージをインストールするステップと；
前記メインアプリケーションを開始するプロセスにおける、前記ロード対象サブアプリケーションの前記インストールディレクトリに対応するストレージパス情報を、前記メインアプリケーションのインストールディレクトリ内に保存するステップと；を更に備える、
請求項１〜８のいずれかに記載の方法。

【請求項10】

前記メインアプリケーションに含まれる第１のサブアプリケーションを開始するための第２の命令を受信するステップと；
前記第２の命令の受信に応答して、前記第１のサブアプリケーションが、前記メインアプリケーションを開始するプロセスにおける、ロードされたサブアプリケーションであるか否かを決定するステップと；
前記第１のサブアプリケーションが、前記メインアプリケーションを開始するプロセスにおけるロードされたサブアプリケーションでない場合、前記デバイスが、前記第１のサブアプリケーションのインストールディレクトリを有するか否かを決定するステップと；
前記デバイスが、前記第１のサブアプリケーションの前記インストールディレクトリを有していない場合、前記第１のサブアプリケーションに対応するインストールパッケージを取得し、前記デバイスに前記パッケージをインストールするステップと；
前記メインアプリケーションのインストールディレクトリに、前記第１のサブアプリケーションの前記インストールディレクトリに対応するストレージパス情報を保存するステップと；
前記デバイスが、前記第１のサブアプリケーションの前記インストールディレクトリを有する場合、前記第１のサブアプリケーションの前記インストールディレクトリに対応するストレージパス情報を取得するステップと；
取得した前記ストレージパス情報に基づいて、前記メインアプリケーションにおける前記第１のサブアプリケーションの前記インストールディレクトリ内のファイルを呼び出し、前記第１のサブアプリケーションをロードするステップと；を更に備える、
請求項１〜９のいずれかに記載の方法。

【請求項11】

請求項１〜１０に記載のいずれかの方法を実行するように構成された複数のモジュールを備える、
デバイスアプリケーションをロードする装置。

【発明の詳細な説明】

【技術分野】

【0001】

本願は、ソフトウェア技術の分野に関し、特に、端末アプリケーション（ＡＰＰ、アプリ）をロードする方法及び装置に関する。

【背景技術】

【0002】

現在、端末にインストールされた特定のメインアプリには、一般的に、複数のサブアプリが組み込まれる。そのようなわけで、特定のメインアプリのインターフェースへ複数のサブアプリを選択的にロードすることができる。

【0003】

従来技術では、一般に、複数のサブアプリが組み込まれた特定のメインアプリの開始アクションをユーザがトリガすると、このメインアプリ開始プロセスで、メインアプリに組み込まれた全てのサブアプリがロードされる。ロードプロセスは、端末のハードディスク上のアプリケーションプログラムを端末のメモリ内に呼び出すプロセスである。例えば、特定のメインアプリに含まれている一組のサブアプリが｛サブアプリ１，サブアプリ２，．．．，サブアプリｎ｝であるとすると、ユーザがメインアプリの開始アクションをトリガすると、端末は、サブアプリ１、サブアプリ２、．．．、サブアプリｎを順次にロードすることができる。

【0004】

本発明者は、本願の実施時に、従来技術における少なくとも以下の問題を見出した。
すなわち、メインアプリの開始プロセスにおいて、特定のメインアプリに含まれている全てのサブアプリを順次にロードしなければならないので、ロードプロセスに比較的時間がかかり、メインアプリを開くプロセスが遅くなってしまう。

【発明の概要】

【発明が解決しようとする課題】

【0005】

本願の実施の形態の目的は、ロードプロセスに比較的時間がかかり、メインアプリを開くプロセスが遅いという従来技術の問題を解決するために、端末アプリをロードする方法及び装置を提供することである。

【0006】

上述の技術的問題を解決するために、本願の実施の形態が提供する端末アプリをロードする方法及び装置は以下のように実施される。
端末アプリをロードする方法は：
端末にインストールされ少なくとも１つのサブアプリを含むメインアプリの開始アクションをトリガする第１の命令を受信するステップと；
前記第１の命令に応答して、前記メインアプリに対応し、ロード対象サブアプリについての識別子情報を含むアプリケーションロード情報を取得するステップと；
取得した前記アプリケーションロード情報に含まれる前記ロード対象サブアプリについての前記識別子情報に従って、前記メインアプリ開始プロセスにおける前記ロード対象サブアプリを決定し、ロードするステップと；を備える。

【0007】

端末アプリをロードする装置は：
端末にインストールされ少なくとも１つのサブアプリを含むメインアプリの開始アクションをトリガする命令を受信するように構成された受信モジュールと；
前記命令に応答して、前記メインアプリに対応し、ロード対象サブアプリについての識別子情報を含むアプリケーションロード情報を取得するように構成された取得モジュールと；
取得した前記アプリケーションロード情報に含まれる前記ロード対象サブアプリについての前記識別子情報に従って、前記メインアプリ開始プロセスにおける前記ロード対象サブアプリを決定し、ロードするように構成されたロードモジュールと；を備える。

【0008】

本願の実施の形態で提供される技術的解決策から分かることは、メインアプリの開始アクションをトリガする第１の命令を受信した後に、メインアプリに対応するアプリケーションロード情報を取得し、このアプリケーションロード情報を分析することによってロード対象サブアプリを決定し、続いて、決定したロード対象サブアプリをメインアプリ開始プロセスでロードする。上記プロセスでは、ロード対象サブアプリは取得したアプリケーションロード情報に従って決定されているため、メインアプリに含まれる全てのサブアプリをロードする従来技術に比べ、アプリケーションロードプロセスに費やす時間を短縮でき、メインアプリを開く速度を高速化できる。

【図面の簡単な説明】

【0009】

本願の実施の形態又は先行技術による技術的解決策をより明確に説明するために、実施の形態又は従来技術を説明するための添付図面を以下に簡単に紹介する。以下の説明における添付図面は、本願の一部の実施の形態に過ぎないことは明らかである。当業者であれば、創造的な努力なしに、添付図面に従って他の図面を得ることができる。

【0010】

【図1】本願の実施の形態による、端末上のメインアプリと、メインアプリに含まれるサブアプリとの概略インターフェース図である。

【図2】本願の第１の実施の形態による端末アプリをロードする方法のフローチャートである。

【図3】本願の実施の形態による端末アプリをロードする方法においてメインアプリにサブアプリをロードするフローチャートである。

【図4】本願の第２の実施の形態による端末アプリをロードする方法のフローチャートである。

【図5】本願の第３の実施の形態による端末アプリをロードする方法のフローチャートである。

【図6】本願の第１の実施の形態による端末アプリをロードする装置のモジュール図である。

【図7】本願の第２の実施の形態による端末アプリをロードする装置のモジュール図である。

【図8】本願の第３の実施の形態による端末アプリをロードする装置のモジュール図である。

【図9】本願の第４の実施の形態による端末アプリをロードする装置のモジュール図である。

【発明を実施するための形態】

【0011】

当業者が本願の技術的解決法をより良く理解するために、本願の実施の形態における技術的解決策は、本願の実施の形態における添付図面を参照して、以下に明確かつ完全に記載される。記載された実施の態は、本願のすべての実施の形態ではなくむしろ一部に過ぎないことは明らかである。創造的な努力なしに本願の実施の形態に基づいて当業者によって得られる他のすべての実施の形態は、本願の保護範囲に包含されるべきである。

【0012】

図１は、端末上のメインアプリと、このメインアプリに含まれるサブアプリとを示す概略インターフェース図である。端末１０のメインインターフェース１１は、端末１０にインストールされたアプリのアイコンを含む。アプリのアイコンは、複数のサブアプリを含むメインアプリのアイコンであってもよく、サブアプリを含まない独立アプリのアイコンであってもよい。端末１０を使用するユーザがメインアプリの開始アクションをトリガすると（開始アクションは、ユーザがメインアプリのアイコン１１０に指で触れてトリガすることができる）、端末がメインインターフェース１１からメインアプリのインターフェース１２に切り替わる。メインアプリ（つまり、アイコン１１０に対応するアプリ）のインターフェース１２が、メインアプリで実行できる複数のサブアプリのアイコン１１２、１１３、１１４、１１５、１１６、及び１１７を含んでいることが分かる。ユーザは、サブアプリのアイコンをタップすることで、サブアプリをメインアプリのインターフェース１２へロードできる。ここで、図１はいくつかのサブアプリの単なる例示であり、メインアプリに含まれるサブアプリの数は、図１に示す数に限定されないことは触れるに値する。

【0013】

端末デバイスは、タブレットコンピュータ、スマートフォン、スマートウォッチ、又はその他コンピュータ装置及び通信装置であってよい。全ての端末デバイス（又はクライアントデバイスとも呼ばれる）は、アーキテクチャ面でいくつかの基本的コンポーネント、例えば、バス、処理装置、記憶装置、１つ以上の入出力装置、通信インターフェース等を含む。バスは、サーバと、端末の様々なコンポーネントとの間で行う通信のための配線を１本以上含んでもよい。処理装置は、命令を実行するように、及び、ステップ又はスレッドを処理するように構成された様々なタイプのプロセッサ又はマイクロプロセッサを含んでよい。記憶装置は、動的情報を記憶するように構成された、例えばランダムアクセスメモリ（ＲＡＭ）のようなダイナミックメモリ、又は、静的情報を記憶するように構成されたスタティックメモリ、例えば読み出し専用メモリ（ＲＯＭ）、及び、磁気又は光学記憶媒体や対応するドライバを含む大容量メモリを含んでよい。入力装置は、キーボード、マウス、スタイラス、タッチ画面、音声認識装置、生体認識装置等であってよい。出力装置は、情報を出力するように構成されたディスプレイ、プリンタ、スピーカ等であってよい。通信インターフェースを用いることにより、サーバ又はクライアントデバイスは別のシステム及び装置との間で通信できるようになる。通信インターフェースは、有線接続、無線接続、又は光学接続によってネットワークに接続できる。各ネットワークは、ローカルエリアネットワーク（ＬＡＮ）、広域ネットワーク（ＷＡＮ）、イントラネット、インターネット、モバイルフォンネットワーク、仮想プライベートネットワーク（ＶＰＮ）、セルラーモバイル通信ネットワーク、他のモバイル通信ネットワーク、Ｂｌｕｅｔｏｏｔｈ（登録商標）、ＮＦＣ、又はこれらの任意の組み合わせを含んでよい。端末デバイスは、システムリソースを管理し、その他のプログラムの実行を制御するために用いられるオペレーティングシステムソフトウェアと、特定の機能を実行するために用いられるアプリケーションソフトウェア又はプログラム命令とを含む。

【0014】

図２は、本願の第１の実施の形態による、端末アプリをロードする方法のフローチャートである。図１及び図２を参照すると、この実施の形態における端末アプリをロードする本方法は以下を含む。
Ｓ１０１：端末にインストールされており、少なくとも１つのサブアプリを含むメインアプリの開始アクションをトリガするための第１の命令が受信される。
詳細には、ユーザは、端末のタッチ画面上の指定された範囲を指で触れてもよい。指定された範囲とは、メインアプリのアイコン１１０の場所である。端末は、ユーザからのメインアプリ開始アクションをトリガするための第１の命令を、ユーザによるメインアプリのアイコン１１０のタップ動作を感知することにより受信する。

【0015】

Ｓ１０２：第１の命令に応答して、アプリケーションロード情報が取得される。このアプリケーションロード情報は、事前設定期間におけるサブアプリの使用頻度情報に基づいて生成され、ロード対象サブアプリについての識別子情報を含む。
この実施の形態では、ユーザが特定のメインアプリ上での開始アクションをトリガした後に、このメインアプリを開始するプロセスにおけるロード対象サブアプリを決定する必要がある。この実施の形態において、端末は、第１の命令を受信した後に、端末の特定のディレクトリからアプリケーションロード情報を読み出すことができる。アプリケーションロード情報は、メインアプリの開始プロセスにおいてどのサブアプリをロードするかを示してよい。

【0016】

アプリケーションロード情報は、事前設定期間におけるサブアプリの使用頻度情報に基づいて生成されてよい。使用頻度情報を用いて、サブアプリの使用がどの程度の頻度かを表す。例えば、特定のメインアプリ（アイコン１１０に対応するアプリ）のインターフェース１２に含まれる一組のサブアプリは、｛第１のサブアプリ、第２のサブアプリ、第３のサブアプリ、第４のサブアプリ、第５のサブアプリ、第６のサブアプリ｝である。第１のサブアプリはアイコン１１２に対応し、第２のサブアプリはアイコン１１３に対応し、第３のサブアプリはアイコン１１４に対応し、第４のサブアプリはアイコン１１５に対応し、第５のサブアプリはアイコン１１６に対応し、第６のサブアプリはアイコン１１７に対応する。上で述べたように、使用頻度情報に関する統計を実施するための事前設定期間は１週間であり、統計分析によって以下の情報が得られる：
過去１週間の第１のサブアプリの使用頻度情報は、３．２回／日であった。
過去１週間の第２のサブアプリの使用頻度情報は、８．５回／日であった。
過去１週間の第３のサブアプリの使用頻度情報は、４．３回／日であった。
過去１週間の第４のサブアプリの使用頻度情報は、５．５回／日であった。
過去１週間の第５のサブアプリの使用頻度情報は、１．２回／日であった。
過去１週間の第６のサブアプリの使用頻度情報は、０．５回／日であった。

【0017】

次に、上記統計分析に基づく、事前設定期間（例えば、１週間）におけるサブアプリの使用頻度の情報を降順にソートし、相対的に頻繁に使用される１つ以上のサブアプリを、メインアプリ開始プロセスにおける１つ又は複数のロード対象サブアプリとして決定する。１つ又は複数のロード対象サブアプリは、定期的に取得した使用頻度情報に基づき端末上で事前に決定されてよく、これに対応して、端末が読み出せるアプリケーションロード情報が生成されてよいことは明らかである。

【0018】

本願のこの実施の形態では、アプリケーションロード情報は、ロード対象サブアプリについての識別子情報を含んでよい。例えば、ロード対象サブアプリが第２のサブアプリ（アイコン１１３に対応するアプリ）と第４のサブアプリ（アイコン１１５に対応するアプリ）であると決定された場合に、アプリケーションロード情報は、第２のサブアプリについての識別子情報と第４のサブアプリについての識別子情報とを含むことができる。識別子情報はアプリ名、アプリの数等であってよい。

【0019】

本願の実施の形態によっては、アプリケーションロード情報を取得する前に、以下のステップを実行してアプリケーションロード情報を生成してもよい。
ａ１）使用頻度情報を取得するための要求情報がサーバ側へ送信される。
端末（クライアント側）にインストールされたサブアプリでは、事前設定期間においてユーザがどのくらい頻繁にサブアプリを使用したかを表す使用頻度情報についての統計を、そのサブアプリのサーバ側で実施してよい。これに対応して、サーバ側は、ユーザがアプリアカウントにログインする回数を記録してもよい。又は、ユーザがサーバ側のデータへアクセスする回数を記録してもよい。通常は、特定のメインアプリに含まれるサブアプリの使用頻度情報の取得を要求する要求情報を、端末がサーバ側へ送信してもよい。この要求情報は、ユーザＩＤ、事前設定期間、メインアプリについての識別子情報等を含んでよい。実施の形態によっては、端末が要求情報をメインアプリのサーバ側へ送信できることは触れるに値する。次に、メインアプリのサーバが、サブアプリのサーバ側から使用頻度情報を集める。
ａ２）要求情報に応答して、事前設定期間における、メインアプリに含まれたサブアプリの使用頻度情報がサーバ側から受信される。
サーバ側は、統計によって得られ、過去の事前設定期間においてユーザがサブアプリをどのくらい頻繁に使用したかを表す使用頻度情報を、端末へフィードバックする。
ａ３）受信した使用頻度情報は降順にソートされ、使用頻度情報が先頭にソートされたサブアプリが、ロード対象サブアプリとして決定される。
上で述べたように、使用頻度情報に基づいてソートすることができ、先頭にソートされたサブアプリを（そのサブアプリが相対的に頻繁に使用されていることを表す）ロード対象サブアプリとみなす。ロード対象サブアプリとして決定すべき数を、ユーザが選択又は決定してもよく、メインアプリに含まれているサブアプリの総数に基づいて、端末が決定してもよい（例えば、ロード対象サブアプリの数を総数の半分と決める）。
ａ４）ロード対象サブアプリについての識別子情報を含むアプリケーションロード情報が生成され、端末の指定されたディレクトリに保存される。
アプリケーションロード情報を特定の読み出しできるファイルに書き込むことができ、このファイルをメインアプリの指定されたディレクトリに保存する。

【0020】

本願の別の実施の形態では、アプリケーションロード情報を取得する前に、以下のステップを実行してアプリケーションロード情報を生成してもよい。
ｂ１）メインアプリに含まれるサブアプリの、事前設定期間における使用頻度情報が、端末のメインアプリのインストールディレクトリから取得される。
ｂ２）受信した使用頻度情報が降順にソートされ、使用頻度情報が先頭にソートされたサブアプリがロード対象サブアプリとして決定される。
ｂ３）ロード対象サブアプリについての識別子情報を含むアプリケーションロード情報が生成され、それが、端末の指定されたディレクトリに保存される。

【0021】

前出のプロセスでは、端末は、メインアプリとメインアプリに含まれているサブアプリとを使用するユーザ行動のデータを監視し、ユーザがサブアプリをどのくらい頻繁に使用するかを示す使用頻度情報を得るべく統計を取り、この使用頻度情報を端末のローカル記憶域に保存できる。端末はローカル記憶域から使用頻度情報を定期的に読み出し、アプリケーションロード情報を含む、読み取り可能ファイルを生成できる。

【0022】

Ｓ１０３：メインアプリ開始プロセスにおいて、取得したアプリケーションロード情報に含まれるロード対象サブアプリについての識別子情報に従って、ロード対象サブアプリが決定されて、ロードされる。
ステップＳ１０３では、メインアプリ開始プロセスにおいて、端末は、取得した、アプリケーションロード情報に事前に書き込まれているファイルに基づき、分析によってロード対象サブアプリを入手し、決定したサブアプリをロードすることができる。例えば、決定したロード対象サブアプリが第２のアプリと第４のアプリである場合に、メインアプリ開始プロセスにおいて、これら２つのアプリのみをロードすればよい。これにより、メインアプリ開始プロセス内で特定のメインアプリに含まれる全てのサブアプリを一度にロードしなければならない点に起因する、ロード時間が長くなり、メインアプリを開く速度が遅くなるという従来技術の欠点を回避できる。

【0023】

図３は、本願の実施の形態による端末アプリをロードする方法において、メインアプリ内の１つのサブアプリをロードするフローチャートである。この実施の形態では、メインアプリ内の１つのサブアプリをロードするプロセスは具体的に以下を含む。
Ｓ１０３１：メインアプリ開始プロセスにおいて、取得したアプリケーションロード情報に含まれるロード対象サブアプリについての識別子情報に従って、ロード対象サブアプリが決定される。

【0024】

Ｓ１０３２：端末がロード対象サブアプリのインストールディレクトリを持っているかどうかが判断される。
本願のこの実施の形態では、メインアプリに含まれているサブアプリを独立アプリにパッケージングし、これを端末へインストールしてもよい。引き続き、図１を参照すると、メインアプリのアイコン１１０に加え、端末のメインインターフェース１１は、更に、メインアプリに含まれるサブアプリのアイコン１１２、１１３、１１４、１１５、１１６を含む。すなわち、サブアプリを端末１０へ個別にインストールできる。インストールが完了すると、端末１０が、各サブアプリにそれぞれ対応するインストールディレクトリを持つようになり、サブアプリのインストールファイルがインストールディレクトリに保存される。最後に、端末の記憶域がロード対象サブアプリに対応するインストールディレクトリを持っているかどうかを決定するために、端末は記憶域を走査することができる。

【0025】

Ｓ１０３３：端末の記憶域が、ロード対象サブアプリに対応するインストールディレクトリを持っている場合に、ロード対象サブアプリのインストールディレクトリに対応するストレージパス情報（storage path information、記憶パス情報）が取得される。
この実施の形態では、特定のサブアプリのインストールに成功した後に、このサブアプリに対応するメインアプリのインストールディレクトリ下の特定の指定されたパスにファイルを保存できる。このファイルを、ロード対象サブアプリのインストールディレクトリに対応するストレージパス情報に書き込むことができる。因って、メインアプリの開始アクションがトリガされた後に、メインアプリが、ロード対象サブアプリのインストールディレクトリに対応するストレージパス情報に書き込まれているファイルを読み出すことで、現在ロード対象であるサブアプリのインストールディレクトリに対応するストレージパス情報を取得する。例えば、第１のサブアプリ（アイコン１１２に対応）のインストールディレクトリに対応するストレージパス情報はＰｒｏｇｒａｍ Ｆｉｌｅｓ／ａｐｐ１／ａであり、メインアプリのインストールディレクトリはＰｒｏｇｒａｍ Ｆｉｌｅｓ／ａｐｐであり、ストレージパス情報は特定のファイルに書き込むことができ、ファイルはメインアプリのインストールディレクトリＰｒｏｇｒａｍ Ｆｉｌｅｓ／ａｐｐに記憶される。

【0026】

Ｓ１０３４：取得したストレージパス情報に基づいて、ロード対象サブアプリのインストールディレクトリ内のファイルがメインアプリ内に呼び出され、ロード対象のサブアプリがロードされる。
本願のこの実施の形態では、ロード対象サブアプリのストレージパスを取得した後に、メインアプリがストレージパスを介してロード対象サブアプリのリソースを呼び出す。つまり、端末が現在のメインアプリのフレームワーク内において特定のサブアプリのインストールディレクトリ内のインストールファイルを再使用することで、メインアプリ内のロード対象サブアプリのロードを実施できる。メインアプリが開始しない場合は、ユーザがメインインターフェース１１内でサブアプリのアイコンをタップしてサブアプリを個別に実行することもできることは明白である。

【0027】

Ｓ１０４：端末がロード対象サブアプリのインストールディレクトリを持っていない場合は、ロード対象サブアプリに対応するインストールパッケージが取得され、端末へインストールされる。
例えば、ロード対象サブアプリが第６のサブアプリ（アイコン１１７に対応するアプリ）を含むことが最終的に決定され、端末のメインインターフェース１１内に第６のサブアプリのアイコンがないと仮定した場合に、現在、第６のサブアプリが端末にインストールされていない（つまり、ロード対象サブアプリのインストールディレクトリが存在しない）ことを示す。この場合、端末は、第６のサブアプリをダウンロード及びインストールする必要があるかどうかを問う要求情報をユーザに促すことができる。ユーザが第６のサブアプリをダウンロード及びインストールすることに同意した場合に、端末はインターネットから第６のサブアプリのインストールパッケージを取得し、このパッケージを端末へインストールすることができる。

【0028】

Ｓ１０５：ロード対象サブアプリのインストールディレクトリに対応するストレージパス情報が、メインアプリのインストールディレクトリに保存される。
上で述べたように、特定のサブアプリのインストールが完了すると、サブアプリのインストールディレクトリに対応するストレージパス情報を特定のファイルに書き込むことができ、このファイルをメインアプリのインストールディレクトリに保存できる。こうすることで、この後にユーザがメインアプリの開始アクションをトリガするプロセスにおいて、サブアプリに対応するストレージパス情報を見つけることができ、このストレージパス情報に従ってサブアプリのインストールディレクトリ内のリソースが呼び出される。

【0029】

本願の実施の形態では、この方法は更に以下を含む。
メインアプリに含まれる第１のサブアプリの開始アクションをトリガする第２の命令が受信される。
第２の命令に応答して、第１のサブアプリは、メインアプリ開始プロセスにおいてロードされたサブアプリであるかどうかが判断される。

【0030】

第１のサブアプリがメインアプリ開始プロセスにおいてロードされたサブアプリでない場合に、端末が、第１のサブアプリのインストールディレクトリを持っているかどうか判断される。

【0031】

端末が第１のサブアプリに対応するインストールディレクトリを持っていない場合は、第１のサブアプリに対応するインストールパッケージが取得され、端末にインストールされる。そして、ロード対象の第１のサブアプリのインストールディレクトリに対応するストレージパス情報がメインアプリのインストールディレクトリに保存される。

【0032】

端末が第１のサブアプリに対応するインストールディレクトリを持っている場合は、ロード対象の第１のサブアプリのインストールディレクトリに対応するストレージパス情報が取得され、取得したストレージパス情報に基づいて、ロード対象の第１のサブアプリのインストールディレクトリ内のファイルがメインアプリ内に呼び出され、ロード対象の第１のサブアプリがロードされる。

【0033】

前出のプロセスは、具体的なアプリケーションシナリオと組み合わせて、以下であってよい。すなわち、ユーザが特定のメインアプリのインターフェースを開いた後に、メインアプリのインターフェース内の特定のサブアプリのアイコンをタップすることで、この特定のサブアプリの開始アクションをトリガする。その後、端末が自己の記憶域を走査して、開始対象サブアプリのインストールディレクトリが記憶域内にあるかどうかを判断し（つまり、このサブアプリがインストールされているかどうかを判断し）、記憶域内にインストールディレクトリがない場合に、サブアプリのインストールパッケージをインターネット経由でダウンロードして、サブアプリを独立アプリとしてインストールし、同時に、サブアプリのストレージパス情報を特定のファイルに書き込む。この特定のファイルは、メインアプリのインストールディレクトリ下に記憶されている。一方、走査によって開始対象サプアプリのインストールディレクトリが記憶域内にあることが分かった場合に、メインアプリ内のサブアプリがリソース再利用によって開始されるようにするために、メインアプリのインストールディレクトリ内のサブアプリのストレージパス情報を読み出して、サブアプリのインストールディレクトリ下のインストールファイルを呼び出す。

【0034】

図４は、本願の第２の実施の形態による端末アプリをロードする方法のフローチャートである。この実施の形態における端末アプリをロードする方法は以下を含む。
Ｓ２０１：端末にインストールされ少なくとも１つのサプアプリを含むメインアプリの開始アクションをトリガする第１の命令が受信される。
図２のステップＳ１０１の内容を参照できる。

【0035】

Ｓ２０２：第１の命令に応答して、メインアプリに対応しており、ロード対象サブアプリについての識別子情報を含むアプリケーションロード情報が取得される。
この実施の形態では、ステップＳ２０２は、ユーザが選択したロード対象サブアプリに基づいてアプリケーションロード情報が生成される点において、先の実施の形態のステップＳ１０２と異なる。例えば、ユーザは、メインアプリ開始プロセスにおいてロードが必要なオブジェクトとして作用させるべくロードする必要があるいくつかのサブアプリを選択するために、メインアプリのロード設定機能を用いることができる。例えば、ユーザは、日常生活において比較的頻繁に使用される第１のサブアプリと第２のサブアプリとをロード対象サブアプリとして選択できる。

【0036】

Ｓ２０３：メインアプリ開始プロセスにおいて、取得したアプリケーションロード情報に含まれるロード対象サブアプリについての識別子情報に従って、ロード対象サブアプリが決定され、ロードされる。
図２のステップＳ１０３の内容を参照できる。

【0037】

図５は、本願の第３の実施の形態による端末アプリをロードする方法のフローチャートである。この実施の形態における端末アプリをロードする方法は以下を含む。
Ｓ３０１：端末にインストールされ少なくとも１つのサブアプリを含むメインアプリの開始アクションをトリガする第１の命令が受信される。
図２のステップＳ１０１の内容を参照できる。

【0038】

Ｓ３０２：第１の命令に応答して、アプリケーションロード情報が取得される。アプリケーションロード情報は、ユーザが予め決定したロード対象サブアプリの数と、事前設定期間におけるサブアプリの使用頻度情報とに基づいて生成され、ロード対象サブアプリについての識別子情報を含む。
この実施の形態におけるステップＳ３０２は、ユーザがメインアプリの設定機能を用いてロード対象サブアプリの数（例えば、３つ）を決定でき、端末がサブアプリの使用頻度情報を定期的に取得することが、上で述べた実施の形態とは異なる。サブアプリが使用頻度情報に従ってソートされるとすると、サブアプリは最終的に次のようにランク付けされる。第２のサブアプリ＞第４のサブアプリ＞第１のサブアプリ＞第５のサブアプリ＞第３のサブアプリ＞第６のサブアプリ。最終的に得られた３つのロード対象サブアプリはそれぞれ第２のサブアプリ、第４のサブアプリ、第１のサブアプリである。次に、アプリケーションロード情報が生成され、端末の記憶域に保存される。

【0039】

Ｓ３０３：メインアプリ開始プロセスにおいて、取得したアプリケーションロード情報に含まれるロード対象サブアプリについての識別子情報に従って、ロード対象サブアプリが決定され、ロードされる。
図２のステップＳ１０３の内容を参照できる。

【0040】

本願の実施の形態において提供される技術的解決策から以下のことが分かる。メインアプリの開始アクションをトリガする第１の命令が受信された後に、メインアプリに対応するアプリケーションロード情報が取得され、アプリケーションロード情報を分析することでロード対象サブアプリが決定され、次いで、メインアプリ開始プロセスにおいて決定されたロード対象サブアプリがロードされる。前出のプロセスでは、ロード対象サブアプリは取得したアプリケーションロード情報に従って決定されるため、メインアプリに含まれている全てのサブアプリをロードする従来技術と比べて、アプリケーションのロードプロセスに費やす時間を短縮でき、メインアプリを開く速度を高速化できる。加えて、本願の実施の形態によれば、端末はメインアプリ内のサブアプリのインストールディレクトリ内にあるリソース（ファイル）を呼び出すことができるが、従来技術では、ユーザがメインアプリ内の特定のサブアプリを開くときには、開始対象のサブアプリ（別個にインストールされているアプリ）を直接実行することが一般的である。そのため、本願の実施の形態は、従来技術に比べて、端末のリソースの消費を減らすことができる。

【0041】

本願の実施の形態による、端末アプリをロードする装置の技術的解決策を以下に述べる。この装置は、先に述べた方法の原理に基づくため、その特定の技術的内容については先に述べた方法の実施の形態を参照されたい。

【0042】

図６は、本願の第１の実施の形態による端末アプリをロードする装置のモジュール図である。この装置は以下を含む。
受信モジュール４０１：メインアプリの開始アクションをトリガする命令を受信するように構成される。メインアプリは端末にインストールされ少なくとも１つのサブアプリを含む。
取得モジュール４０２：命令に応答して、メインアプリに対応する、ロード対象サブアプリについての識別子情報を含むアプリケーションロード情報を取得するように構成される。
ロードモジュール４０３：取得したアプリケーションロード情報に含まれるロード対象サブアプリについての識別子情報に従って、メインアプリ開始プロセスにおけるロード対象サブアプリを決定し、ロードするように構成される。

【0043】

本願の実施の形態では、前記取得モジュール４０２は、具体的に：
事前設定期間における前記サブアプリの使用頻度情報に基づいて生成され、ロード対象サブアプリについての識別子情報を含むアプリケーションロード情報を取得するように構成される；又は、
ユーザによって事前に選択されたロード対象サブアプリに基づいて生成され、前記ロード対象サブアプリについての識別子情報を含むアプリケーションロード情報を取得するように構成される；又は、
ユーザによって事前に決定されたロード対象サブアプリの数と、事前設定期間における前記サブアプリの使用頻度情報とに基づいて生成され、前記ロード対象のサブアプリについての識別子情報を含むアプリケーションロード情報を取得するように構成される。

【0044】

図７は、本発明の第２の実施の形態による端末アプリをロードするための装置のモジュール図である。この実施の形態において、前記装置は：
前記使用頻度情報を取得するための要求情報をサーバ側へ送信するように構成された要求送信ユニット４０４と；
前記要求情報に応答して、前記サーバ側から送信され前記メインアプリに含まれる前記サブアプリの、事前設定期間における前記使用頻度情報を受信するように構成された情報受信ユニット４０５と；
前記受信した使用頻度情報を降順にソートし、使用頻度情報が先頭にソートされたサブアプリを、前記ロード対象サブアプリとして決定するように構成された第１の決定ユニット４０６と；
前記ロード対象サブアプリについての前記識別子情報を含むアプリケーションロード情報を生成し、前記アプリケーションロード情報を前記端末の指定されたディレクトリに保存するように構成された第１の生成ユニット４０７と；を更に備え、
前記取得モジュール４０２は、具体的に、前記メインアプリに対応し前記ロード対象サブアプリについての前記識別子情報を含む前記アプリケーションロード情報を、前記端末の前記指定されたディレクトリから読み出すように構成される。

【0045】

図８は、本発明の第３の実施の形態による端末アプリをロードするための装置のモジュール図である。この実施の形態において、前記装置は：
前記事前設定期間における、前記メインアプリに含まれるサブアプリの使用頻度情報を、前記端末の前記メインアプリのインストールディレクトリから取得するように構成された情報取得ユニット５０１と；
前記受信した前記使用頻度情報を降順にソートし、使用頻度情報が先頭にソートされたサブアプリを、前記ロード対象サブアプリとして決定するように構成された第２の決定ユニット５０２と；
前記ロード対象サブアプリについての前記識別子情報を含むアプリケーションロード情報を生成し、前記アプリケーションロード情報を、前記端末の指定されたディレクトリに保存するように構成された第２の生成ユニット５０３と；を更に備え、
前記取得モジュール４０２は、具体的に、前記メインアプリに対応し前記ロード対象サブアプリについての前記識別子情報を含む前記アプリケーションロード情報を、前記端末の前記指定されたディレクトリから読み出すように構成される。

【0046】

図９は、本願の第４の実施の形態に従って端末アプリをロードする装置のモジュール図である。この実施の形態では、ロードモジュール４０３は以下を含む。
第３の決定ユニット４０３１：取得したアプリケーションロード情報に含まれるロード対象サブアプリについての識別子情報に従って、メインアプリ開始プロセスにおけるロード対象サブアプリを決定するように構成される。
判断ユニット４０３２：端末がロード対象サブアプリのインストールディレクトリを持っているかどうかを判断するように構成される。
パス取得ユニット４０３３：端末がロード対象サブアプリのインストールディレクトリを持っている場合に、ロード対象サブアプリのインストールディレクトリに対応するストレージパス情報を取得するように構成される。
アプリケーションロードユニット４０３４：取得したストレージパス情報に基づいて、メインアプリ内のロード対象サブアプリのインストールディレクトリ内にあるファイルを呼び出して、ロード対象サブアプリをロードするように構成される。

【0047】

本願のこの実施の形態では、本装置は更に以下を含む。
インストールモジュール６０４：端末がロード対象サブアプリのインストールディレクトリを持っていない場合に、ロード対象サブアプリに対応するインストールパッケージを取得して、端末にこのパッケージをインストールするように構成される。
パス情報保存ユニット６０５：ロード対象サブアプリのインストールディレクトリに対応するストレージパス情報を、メインアプリのインストールディレクトリに保存するように構成される。

【0048】

説明を容易にするために、装置について述べる場合には、装置を機能ごとの様々なユニットに分割して記述している。本願を実装する際には、ユニットの機能を同一又は複数のソフトウェア及び／又はハードウェアにて実装できることは明白である。

【0049】

当業者は、本発明の実施の形態が、方法、システム、又はコンピュータプログラム製品として提供され得ることを理解すべきである。したがって、本発明は、完全なハードウェアの実施の形態、完全なソフトウェアの実施の形態、又はソフトウェアとハードウェアとを組み合わせた実施の形態の態様で実施されてもよい。更に、本発明は、コンピュータ使用可能プログラムコードを含む、１つ又は複数のコンピュータ使用可能な記憶媒体（磁気ディスクメモリ、ＣＤ−ＲＯＭ、光メモリなどを含むが、これに限定されない）上に実装されたコンピュータプログラム製品の形態であってもよい。

【0050】

本発明は、本発明の実施の形態の方法、デバイス（システム）及びコンピュータプログラム製品のフローチャート及び／又はブロック図を参照して説明される。コンピュータプログラム命令は、各プロセス及び／又はフローチャートにおけるブロック及び／又はブロック図、及び、プロセス及び／又はフローチャートにおけるブロック及び／又はブロック図の組合せを実施するために使用できることを理解されたい。コンピュータプログラム命令は、機械を形成するために、ユニバーサルコンピュータ、専用コンピュータ、組み込みプロセッサ、又は他のプログラム可能データ処理デバイスのプロセッサに提供されて、コンピュータ又は他のプログラム可能なデータ処理デバイスのプロセッサは、フローチャート及び／又はブロック図の１つ又は複数のブロックにおける、１つ又は複数のプロセスで指定された機能を実施するように構成される装置を生成する。

【0051】

コンピュータプログラム命令はまた、コンピュータ可読記憶装置に記憶され、コンピュータ又は他のプログラム可能データ処理デバイスを特定の手段で動作させるようにすることができ、その結果、コンピュータ可読記憶装置に記憶された命令は、命令装置を含む製品を形成する。命令装置は、フローチャートの１つ又は複数のプロセス及び／又はブロック図の１つ又は複数のブロックによって指定される機能を実施する。

【0052】

コンピュータプログラム命令はまた、コンピュータ又は他のプログラマブルデータ処理デバイスにインストールされ、一連の動作ステップがコンピュータ又は他のプログラマブルデバイス上で実行され、コンピュータ実装処理を生成することができる。そのため、コンピュータ又は他のプログラマブルデバイスで実行される命令は、フローチャート及び／又はブロック図の１つ又は複数のブロックにおいて指定される機能を実施するためのステップを提供する。

【0053】

用語「含む」、「備える」、又はこれらの派生形は、非排他的な包含をカバーすることを意図し、一連の要素を含む工程、方法、商品、デバイスは、このような要素を含むだけでなく、明記されていないその他の要素をも含むか、あるいは、その工程、方法、商品、デバイスに固有な要素を更に含む点にも留意されたい。さらなる制限なしに、表現「〜を含む（including a/an…）」によって定義される要素は、その要素を含む工程、方法、商品、又はデバイスが、他の同一の要素を更に有することを除外するものではない。

【0054】

当業者は、本願の実施の形態が、方法、システム、又はコンピュータプログラム製品として提供され得ることを理解すべきである。したがって、本願は、完全なハードウェアの実施の形態、完全なソフトウェアの実施の形態、又はソフトウェアとハードウェアとを組み合わせた実施の形態の態様で実装することができる。更に、本願は、コンピュータで使用可能なプログラムコードを含む、１つ又は複数のコンピュータで使用可能な記憶媒体（磁気ディスクメモリ、ＣＤ−ＲＯＭ、光メモリなどを含むがこれに限定されない）に実装されるコンピュータプログラム製品の形態を採ることができる。

【0055】

本願は、コンピュータによって実行されるコンピュータ実行可能命令、例えばプログラムモジュールの共通の文脈で説明することができる。一般に、プログラムモジュールは、特定のタスクを実行するため、又は特定の抽象データ型を実施するためのルーチン、プログラム、オブジェクト、アセンブリ、データ構造などを含む。本願は、通信ネットワークを介して接続された遠隔処理デバイスを使用することによってタスクが実行される分散コンピューティング環境においても実施することができる。分散型コンピュータ環境では、プログラムモジュールは、記憶デバイスを含むローカル及びリモートのコンピュータ記憶媒体に配置されてもよい。

【0056】

本明細書の実施の形態は、逐次、実施の形態の同一又は類似の部分が互いに参照して得られるように記載されており、各実施の形態は他の実施の形態と異なる部分を強調している。特に、システムの実施の形態は基本的に方法の実施の形態と同様であるので、簡単に記載されている。関連する部分については、方法の実施の形態の部分の説明を参照する。

【0057】

上記の説明は、本願の実施の形態に過ぎず、本願を限定するものではない。当業者にとって、本願は様々な修正及び変更を有することができる。本願の精神及び原理内でなされた変更、均等物の置換、改良などは、すべて本願の特許請求の範囲内に含まれるべきである。
［第１の局面］
端末アプリケーション（アプリ）をロードする方法であって：
端末にインストールされ少なくとも１つのサブアプリを含むメインアプリの開始アクションをトリガする第１の命令を受信するステップと；
前記第１の命令に応答して、前記メインアプリに対応し、ロード対象サブアプリについての識別子情報を含むアプリケーションロード情報を取得するステップと；
取得した前記アプリケーションロード情報に含まれる前記ロード対象サブアプリについての前記識別子情報に従って、前記メインアプリ開始プロセスにおける前記ロード対象サブアプリを決定し、ロードするステップと；を備える、
端末アプリケーションをロードする方法。
［第２の局面］
前記メインアプリに対応し、ロード対象サブアプリについての識別子情報を含むアプリケーションロード情報を取得する前記ステップは：
事前設定期間における前記サブアプリの使用頻度情報に基づいて生成され、前記ロード対象サブアプリについての識別子情報を含むアプリケーションロード情報を取得するステップ；又は、
ユーザによって事前に選択されたロード対象サブアプリに基づいて生成され、前記ロード対象のサブアプリについての識別子情報を含むアプリケーションロード情報を取得するステップ；又は
ユーザによって事前に決定されたロード対象サブアプリの数と、事前設定期間における前記サブアプリの使用頻度情報とに基づいて生成され、前記ロード対象サブアプリについての識別子情報を含むアプリケーションロード情報を取得するステップ；を備える、
第１の局面に記載の方法。
［第３の局面］
前記メインアプリに対応し、ロード対象サブアプリについての識別子情報を含むアプリケーションロード情報を取得する前記ステップの前に、前記方法は：
使用頻度情報を取得するための要求情報をサーバ側へ送信するステップと；
前記要求情報に応答して、事前設定された期間中における、前記サーバ側から送信される、前記メインアプリに含まれる前記サブアプリの使用頻度情報を受信するステップと；
前記受信した使用頻度情報を降順にソートし、使用頻度情報が先頭にソートされたサブアプリを、ロード対象サブアプリとして決定するステップと；
前記ロード対象サブアプリについての前記識別子情報を含むアプリケーションロード情報を生成し、前記アプリケーションロード情報を、前記端末の指定されたディレクトリに保存するステップと；を更に備え、
前記メインアプリに対応し、ロード対象サブアプリについての識別子情報を含むアプリケーションロード情報を取得する前記ステップは：
前記メインアプリに対応し、前記ロード対象サブアプリについての前記識別子情報を含む前記アプリケーションロード情報を、前記端末の前記指定されたディレクトリから読み出すステップを備える、
第１の局面に記載の方法。
［第４の局面］
前記メインアプリに対応し、ロード対象サブアプリについての識別子情報を含むアプリケーションロード情報を取得する前記ステップの前に、前記方法は：
事前設定期間における、前記メインアプリに含まれる前記サブアプリの使用頻度情報を、前記端末の前記メインアプリのインストールディレクトリから取得するステップと；
前記受信した前記使用頻度情報を降順にソートし、前記使用頻度情報が先頭にソートされたサブアプリを、前記ロード対象サブアプリとして決定するステップと；
前記ロード対象サブアプリについての前記識別子情報を含むアプリケーションロード情報を生成し、前記アプリケーションロード情報を前記端末の指定されたディレクトリに保存するステップと；を更に備え、
前記メインアプリに対応し、ロード対象サブアプリについての識別子情報を含むアプリケーションロード情報を取得する前記ステップは、前記端末の前記指定されたディレクトリから、前記メインアプリに対応し前記ロード対象サブアプリについての前記識別子情報を含む前記アプリケーションロード情報を読み出すステップを備える、
第１の局面に記載の方法。
［第５の局面］
前記取得したアプリケーションロード情報に含まれる前記ロード対象サブアプリについての前記識別子情報に従って、前記メインアプリ開始プロセスにおける前記ロード対象サブアプリを決定し、ロードする前記ステップは：
前記取得したアプリケーションロード情報に含まれる前記ロード対象サブアプリについての前記識別子情報に従って、前記メインアプリ開始プロセスにおける前記ロード対象サブアプリを決定するステップと；
前記端末が前記ロード対象サブアプリのインストールディレクトリを持っているかどうかを判断するステップと；
肯定であれば、前記ロード対象サブアプリの前記インストールディレクトリに対応するストレージパス情報を取得するステップと；
前記取得した前記ストレージパス情報に基づいて、前記メインアプリ内の前記ロード対象サブアプリの前記インストールディレクトリ内にあるファイルを呼び出し、前記ロード対象サブアプリをロードするステップと；を備える、
第１の局面に記載の方法。
［第６の局面］
前記方法は：
前記ロード対象サブアプリに対応するインストールパッケージを取得し、更に、前記端末が前記ロード対象サブアプリのインストールディレクトリを持っていない場合に、前記パッケージを前記端末にインストールするステップと；
前記ロード対象サブアプリの前記インストールディレクトリに対応する前記ストレージパス情報を、前記メインアプリのインストールディレクトリに記憶するステップと；を更に備える、
第１の局面に記載の方法。
［第７の局面］
前記方法は：
前記メインアプリに含まれる第１のサブアプリの開始アクションをトリガする第２の命令を受信するステップと；
前記第２の命令に応答して、前記第１のサブアプリが、前記メインアプリ開始プロセスにおいてロードされたサブアプリであると判断するステップと；
前記第１のサブアプリが前記メインアプリ開始プロセスにおいてロードされたサブアプリでない場合に、前記端末が前記第１のサブアプリのインストールディレクトリを持っているかどうかを判断するステップと；
前記端末が前記第１のサブアプリの前記インストールディレクトリを持っていない場合に、前記第１のサブアプリに対応するインストールパッケージを取得し、前記パッケージを前記端末にインストールし、前記ロード対象の第１のサブアプリの前記インストールディレクトリに対応するストレージパス情報を、前記メインアプリのインストールディレクトリに保存するステップと；
前記端末が前記第１のサブアプリの前記インストールディレクトリを持っている場合に、前記ロード対象の第１のサブアプリの前記インストールディレクトリに対応するストレージパス情報を取得し、取得した前記ストレージパス情報に基づいて、前記メインアプリ内の前記ロード対象の第１のサブアプリの前記インストールディレクトリ内にあるファイルを呼び出し、前記ロード対象の第１のサブアプリをロードするステップと；を更に備える、
第１の局面に記載の方法。
［第８の局面］
端末アプリケーション（アプリ）をロードする装置であって：
端末にインストールされ少なくとも１つのサブアプリを含むメインアプリの開始アクションをトリガする命令を受信するように構成された受信モジュールと；
前記命令に応答して、前記メインアプリに対応し、ロード対象サブアプリについての識別子情報を含むアプリケーションロード情報を取得するように構成された取得モジュールと；
取得した前記アプリケーションロード情報に含まれる前記ロード対象サブアプリについての前記識別子情報に従って、前記メインアプリ開始プロセスにおける前記ロード対象サブアプリを決定し、ロードするように構成されたロードモジュールと；を備える、
端末アプリケーションをロードする装置。
［第９の局面］
前記取得モジュールは、具体的に：
事前設定期間における前記サブアプリの使用頻度情報に基づいて生成され、ロード対象サブアプリについての識別子情報を含むアプリケーションロード情報を取得するように構成された；又は、
ユーザによって事前に選択されたロード対象サブアプリに基づいて生成され、前記ロード対象サブアプリについての識別子情報を含むアプリケーションロード情報を取得するように構成された；又は、
ユーザによって事前に決定されたロード対象サブアプリの数と、事前設定期間における前記サブアプリの使用頻度情報とに基づいて生成され、前記ロード対象のサブアプリについての識別子情報を含むアプリケーションロード情報を取得するように構成された、
第８の局面に記載の装置。
［第１０の局面］
前記装置は：
前記使用頻度情報を取得するための要求情報をサーバ側へ送信するように構成された要求送信ユニットと；
前記要求情報に応答して、事前設定期間における、前記サーバ側から送信され前記メインアプリに含まれる前記サブアプリの前記使用頻度情報を受信するように構成された情報受信ユニットと、
前記受信した使用頻度情報を降順にソートし、使用頻度情報が先頭にソートされたサブアプリを、前記ロード対象サブアプリとして決定するように構成された第１の決定ユニットと；
前記ロード対象サブアプリについての前記識別子情報を含むアプリケーションロード情報を生成し、前記アプリケーションロード情報を前記端末の指定されたディレクトリに保存するように構成された第１の生成ユニットと；を更に備え、
前記取得モジュールは、具体的に、前記メインアプリに対応し前記ロード対象サブアプリについての前記識別子情報を含む前記アプリケーションロード情報を、前記端末の前記指定されたディレクトリから読み出すように構成された、
第８の局面に記載の装置。
［第１１の局面］
前記装置は：
前記事前設定期間における、前記メインアプリに含まれるサブアプリの使用頻度情報を、前記端末の前記メインアプリのインストールディレクトリから取得するように構成された情報取得ユニットと；
前記受信した前記使用頻度情報を降順にソートし、使用頻度情報が先頭にソートされたサブアプリを、前記ロード対象サブアプリとして決定するように構成された第２の決定ユニットと；
前記ロード対象サブアプリについての前記識別子情報を含むアプリケーションロード情報を生成し、前記アプリケーションロード情報を、前記端末の指定されたディレクトリに保存するように構成された第２の生成ユニットと；を更に備え、
前記取得モジュールは、具体的に、前記メインアプリに対応し前記ロード対象サブアプリについての前記識別子情報を含む前記アプリケーションロード情報を、前記端末の前記指定されたディレクトリから読み出すように構成された、
第８の局面に記載の装置。
［第１２の局面］
前記ロードモジュールは：
取得した前記アプリケーションロード情報に含まれる前記ロード対象サブアプリについての前記識別子情報に従って、前記メインアプリ開始プロセスにおける前記ロード対象サブアプリを決定するように構成された第３の決定ユニットと；
前記端末が前記ロード対象サブアプリのインストールディレクトリを持っているかどうかを判断するように構成され判断ユニットと；
前記端末が前記ロード対象サブアプリの前記インストールディレクトリを持っている場合に、前記ロード対象サブアプリの前記インストールディレクトリに対応するストレージパス情報を取得するように構成されたパス取得ユニットと；
前記取得したストレージパス情報に基づいて、前記メインアプリ内の前記ロード対象サブアプリの前記インストールディレクトリ内にあるファイルを呼び出し、前記ロード対象サブアプリをロードするように構成されたアプリケーションロードユニットと；を備える、
第８の局面に記載の装置。
［第１３の局面］
前記装置は：、
前記端末が前記ロード対象サブアプリのインストールディレクトリを持っていない場合に、前記ロード対象サブアプリに対応するインストールパッケージを取得し、前記パッケージを前記端末にインストールするように構成されたインストールモジュールと；
前記ロード対象サブアプリの前記インストールディレクトリに対応するストレージパス情報を、前記メインアプリのインストールディレクトリに保存するように構成されたパス情報保存ユニットと；を更に備える、
第８の局面に記載の装置。

【符号の説明】

【0058】

１０ 端末
１１ メインインターフェース
１２ メインアプリのインターフェース
１１０ メインアプリのアイコン
１１２ サブアプリのアイコン
１１３ サブアプリのアイコン
１１４ サブアプリのアイコン
１１５ サブアプリのアイコン
１１６ サブアプリのアイコン
１１７ サブアプリのアイコン

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】