JP2019509567A - アプリケーション（ａｐｐ）のためのリソースロード方法、サービス機能実施方法及び装置 - Google Patents

Abstract

本願は、アプリケーションのためのリソースロード方法並びにサービス機能実施方法及び装置を開示する。アプリケーションのためのリソースロード方法は：アプリケーション内の第1のサービス機能を起動するためのサービス要求を受信する前に、アプリケーション内の第１のサービス機能の基盤フレームワークリソースをロードするステップと；第１のサービスを起動するためのサービス要求を受信した後に、第１のサービス機能が必要とするページリソースをロードするステップと；を含む。したがって、サービス要求を受信した後にロードする必要のあるサービスリソースが減って、第１のサービス機能の起動に要する時間がり短くなる。このように、既存の技術における、ユーザが第１のサービス機能のスタートボタンをトリガした後、第１のサービス機能を起動するには、多くのサービスリソースをロードする必要があるので、長い時間を要する、という問題が解決される。加えて、ユーザエクスペリエンスが向上する。

Description

本願はコンピュータ技術の分野に関し、特に、アプリケーション（アプリ、ＡＰＰ）のためのリソースロード方法、サービス機能実施方法及び装置に関する。

コンピュータ技術の急速な発展に伴い、多数のアプリケーションが登場し、ユーザはこれらのアプリケーションを用いて様々なサービスを処理することができる。実際の適用では、アプリケーションは、アプリケーションに対応するサービスを複数のサブサービスに更に分割できるので、アプリケーションは、通常、複数のサービス機能を含んでいる。ユーザは、これらのサービス機能を用いて、アプリケーション内の対応するサブサービスを処理できる。例えば、インスタントメッセージのためのアプリは、通常、友人の追加と音声チャットとのためのサブサービスを含む。したがって、このようなタイプのアプリケーションは、通常、友人を追加するためのサービス機能と、音声チャットのためのサービス機能とを含み、対応するサブサービスを実施する。

既存の技術では、アプリケーションを実行していて、ユーザが特定のサービス機能を起動する必要がある場合、サービス機能のスタートボタンをトリガすることができる。アプリケーションを実行している端末装置（又はオペレーティングシステム）は、バックエンドでサービス機能を起動するために必要な複数のサービスリソースをロードでき、サービスリソースのロード結果に基づいてサービス機能を起動できる。

先に述べたリソースロード方法は比較的一般的であるが、リアルタイムパフォーマンスに対する要件が低い幾つかのシナリオにおいて実際のニーズを満たすことができる。しかしながら、サービス機能の起動に多くのサービスリソースが必要になると、既存の技術では、ユーザがサービス機能のスタートボタンをトリガした後、端末装置（又はオペレーティングシステム）がロード処理を完了するまでに長い時間がかかる。その結果、サービス機能の起動には、スタートボタンをトリガしてから長い時間がかかるので、ユーザエクスペリエンスが低下する。

本願の実施は、既存の技術上の問題、すなわち、サービス機能の起動に多くのサービスリソースが必要な場合、サービス機能を起動するには、ユーザがサービス機能のスタートボタンをトリガしてから長い時間がかかってしまうという問題を解決するために、アプリケーションのためのリソースロード方法、サービス機能実施方法及び装置を提供する。

本願の実施は、アプリケーションのためのリソースロード方法を提供し、この方法は以下を含む。

本願の実施は、アプリケーションのためのリソースロード方法を提供するものであって、前記アプリケーションのリソースは、基盤フレームワークリソースとページリソースとを含み、この方法は：前記アプリケーション内の第１のサービス機能を起動するためのサービス要求を受信する前に、前記第１のサービス機能の基盤フレームワークリソースをアプリケーションにロードするステップであって、前記第１のサービス機能の前記基盤フレームワークリソースは前記第１のサービス機能を実施するための実行環境を提供するために用いられる、前記ロードするステップと；前記第１のサービス機能を起動するための前記サービス要求を受信した後、前記第１のサービス機能が必要とするページリソースをロードするステップと；を含む。

好ましくは、前記第１のサービス機能が必要とするページリソースをロードする前記ステップの後に、前記第２のサービス機能を起動するためのサービス要求を受信する前に、前記アプリケーション内の第２のサービス機能の基盤フレームワークリソースをロードするステップを更に含む。

好ましくは、前記アプリケーションのエンジンはハイブリッドエンジンであり、前記アプリケーション内の第１のサービス機能の基盤フレームワークリソースをロードする前記ステップは、前記ハイブリッドエンジンを用いて、前記アプリケーション内の前記第１のサービス機能の基盤フレームワークＲＥＡＣＴをロードするステップを含む。

本願の実施は、さらに、アプリケーションのためのサービス機能実施方法を提供するものであって、この方法は：前記アプリケーション内の第１のサービス機能を起動するためのサービス要求を受信するステップと；前記サービス要求に基づいて、前記第１のサービス機能を実施するために必要なページリソースをロードするステップと；前記第１のサービス機能の基盤フレームワークリソースと前記ページリソースとに基づいて前記第１のサービス機能を実施するステップであって、前記第１のサービス機能の前記基盤フレームワークリソースが、前記サービス要求を受信する前に、本願の実施において提供されるアプリケーションのためのリソースロード方法又は本方法の任意の好ましい解決策に基づいてロードされる、前記実施するステップと；を含む。

本願の実施は、さらに、アプリケーションのためのリソースロード装置を提供するものであって、この装置は：前記アプリケーションのリソースは、基盤フレームワークリソースとページリソースとを含み、前記装置は、基盤フレームワークリソースロードユニットとページリソースロードユニットとを含み、前記基盤フレームワークリソースロードユニットは、前記アプリケーション内の第１のサービス機能を起動するためのサービス要求を受信する前に、前記アプリケーション内の前記第１のサービス機能の基盤フレームワークリソースをロードするように構成され、前記第１のサービス機能の前記基盤フレームワークリソースは、前記第１のサービス機能を実施するための実行環境を提供するために用いられ、前記ページリソースロードユニットは、前記第１のサービス機能を起動するための前記サービス要求を受信した後に、前記第１のサービス機能が必要とするページリソースをロードするように構成される。

好ましくは、第２のサービス機能を起動するためのサービス要求を受信する前に、前記アプリケーション内の前記第２のサービス機能の基盤フレームワークリソースをロードするように構成される第２の基盤フレームワークリソースロードユニットを更に含む。

好ましくは、前記基盤フレームワークリソースロードユニットは、前記アプリケーションのエンジンがハイブリッドエンジンである場合、前記ハイブリッドエンジンを用いて前記アプリケーション内の前記第１のサービス機能の基盤フレームワークＲＥＡＣＴをロードするように構成される基盤フレームワークリソースロードサブユニットを含む。

本願の実施は、さらに、受信ユニットと、ロードユニットと、実施ユニットとを備える、アプリケーションのためのサービス機能実施装置を提供するものであって、この装置は：前記受信ユニットは、前記アプリケーション内の第１のサービス機能を起動するためのサービス要求を受信するように構成され、前記ロードユニットは、前記サービス要求に基づいて、前記第１のサービス機能を実施するために必要なページリソースをロードするように構成され、前記実施ユニットは、前記第１のサービス機能の基盤フレームワークリソースと前記ページリソースとに基づいて前記第１のサービス機能を実施するように構成され、前記第１のサービス機能の前記基盤フレームワークリソースは、前記サービス要求を受信する前に、本願の実施において提供されるアプリケーションのためのリソースロード装置又は本装置の任意の好ましい解決策に基づいてロードされる。

本願の実施で採用された先の技術的解決策の少なくとも1つは、以下の有益な効果を奏する。

アプリケーション内の第１のサービス機能の基盤フレームワークリソースは、アプリケーション内の第１のサービス機能を起動するためのサービス要求を受信する前にロードされる。したがって、サービス要求を受信した後にロードする必要があるサービスリソースが減少し、第１のサービス機能の起動に要する時間がより短くなる。このように、既存の技術上の問題、すなわち、ユーザが第１のサービス機能のスタートボタンをトリガした後、第１のサービス機能を起動するには、多くのサービスリソースをロードする必要があるので、長い時間がかかってしまう、という問題が解決される。加えて、ユーザエクスペリエンスが向上する。

ここで説明する添付図面は、本願の更なる理解を提供すること、及び本願の一部を構成することを意図されている。本願の例示である実施及びその説明は、本願を説明することを意図されており、本願に対する限定を構成するものではない。

図１は、本願の実施例１に係る、アプリケーションのためのリソースロード方法の実施を示す概略フローチャートである。

図２は、本願の実施例１に係る、アプリケーションシナリオにおけるリソースロード方法の実施を示す概略フローチャートである。

図３は、本願の実施例１に係る、アプリケーションシナリオにおけるリソースロード方法の実施を示す論理シーケンス図である。

図４は、本願の実施例１に係る、リソースロード方法の実施における３つのフェーズ間の直列及び並列の関係を示す図である。

図５は、本願の実施例２に係る、アプリケーションのためのサービス機能実施方法の実施を示す概略フローチャートである。

図６は、本願の実施例３に係る、アプリケーションのためのリソースロード装置を示す概略構造図である。

図７は、本願の実施例４に係る、アプリケーションのためのサービス機能実施装置を示す概略構造図である。

先の説明で述べたように、日常生活では、通常、携帯電話やタブレットなどの端末装置にインストールされているアプリケーション（アプリ）を用いて様々な事柄を処理できる。異なる種類の事柄を処理するために、様々なアプリケーションを用いることができる。例えば、一般的に用いられるアプリケーションには、タクシー呼び出しアプリケーション、ショッピングアプリケーション、電子決済アプリケーション、インスタントメッセージアプリケーションなどが挙げられる。アプリケーションは、通常、複数のサービス機能を含んでいる。各サービス機能は、アプリケーション内の対応するサブサービスを完了するために用いられる。例えば、電子決済アプリケーションは、通常、口座残高を見るためのサービス機能、ユーザの個人的な信用度を特定するためのサービス機能、請求書履歴を見るためのサービス機能などを含む。これらのサービス機能を用いて、対応するサブサービスを行うことができる。

既存の技術では、アプリケーションを実行していて、ユーザが特定のサービス機能を起動する必要がある場合、ユーザはサービス機能のスタートボタンをトリガすることができ、アプリケーションを実行している端末装置（又はオペレーティングシステム）は、このサービス機能を起動するために必要な様々なサービスリソースをロードできる。これらのサービスリソースは、通常、表示されるページのページリソース（ページコードなどを含む）と、サービス機能を実施するための実行環境を提供する基盤フレームワークリソースとを含む。例えば、ユーザがインスタントメッセージアプリケーション内に友人を追加するためのサービス機能をトリガするとき、アプリケーションは、友人検索ページをユーザにフィードバックすることができる。この場合、ロードする必要があるサービスリソースには、友人検索ページのページコードリソースと、サービス機能を実施するために必要な基盤フレームワークリソースとが含まれる。

実際のアプリケーション（適用）では、リソースロード方法が一般的であるが、リアルタイムパフォーマンスの要件が高いシナリオによっては、ユーザのニーズを満たすことができない。例えば、財務計画アプリケーションの場合、ユーザは通常、口座資金の変更に細心の注意を払う。この場合、もしアプリケーション内の対応するサービス機能を用いて口座残高をリアルタイムで照会し、且つアプリケーションを実行している端末装置がサービスリソースをロードしていると、多くのサービスリソースをロードする必要があるためリアルタイムでサービス機能を実施することはできない。その結果、ユーザエクスペリエンスが影響を受けることになる。

本発明では、これらのサービス機能を実行するために必要なサービスリソース内の実行環境を提供するために用いられる基盤フレームワークリソースが事前にロードされることで、問題を解決する。したがって、既存の技術に比べて本発明では、ユーザがこれらのサービス機能のスタートボタンをトリガした後、ロードする必要があるリソースが少なくなり、これらのサービス機能の起動は加速される。

本願の目的、技術的解決策、及び利点をより明確にするために、本願の実施及び対応する添付図面を参照して、本願の技術的解決策を明確且つ完全に以下説明する。明らかに、説明される実施は、本願のすべての実施ではなく、そのうちの幾つかに過ぎない。創造的な努力なしに本願の実施に基づいて当業者によって得られる他の全ての実施は、本願の保護範囲内に入るものとする。

本願の実施において提供される技術的解決策は、添付図面を参照して詳細に以下説明する。

実施例１は、アプリケーションのためのリソースロード方法を提供する。アプリケーションのリソースには、基盤フレームワークリソースとページリソースとが含まれる。本方法を用いることで、既存の技術における、サービス機能の起動にユーザがサービス機能のスタートボタンをトリガしてから長い時間がかかってしまうという問題を解決する。図１は、以下のステップを含む本方法の概略フローチャートを示す。

ステップＳ１１：アプリケーション内の第１のサービス機能を起動するためのサービス要求を受信する前に、アプリケーション内の第１のサービス機能の基盤フレームワークリソースをロードする。

アプリケーションのリソースには、基盤フレームワークリソースとページリソースとが含まれる。

ここで、第１のサービス機能の基盤フレームワークリソースは、第１のサービス機能を実施するための実行環境を提供するために用いられる。実際の適用では、アプリケーションは、通常、複数のサービス機能を有する。これらのサービス機能は、通常、それぞれの実行環境に基づいて実施される。これらの実行環境は、通常、それぞれの基盤フレームワークリソースによって提供される。基盤フレームワークリソースは、複数の命令セット、データスタック等を含むことができる。実際の適用では、アプリケーション内の複数のサービス機能も同じ実行環境に基づいて実施できる点に特に留意すべきである。換言すれば、これらのサービス機能は、同じ基盤フレームワークリソースに対応することができる。あるいは、アプリケーションのサービス機能Ａは実行環境Ａに基づいて実施でき、アプリケーションのサービス機能Ｂは実行環境Ｂに基づいて実施できる。換言すれば、アプリケーションのサービス機能Ａは一つの基盤フレームワークリソースに対応し、アプリケーションのサービス機能Ｂは、別の基盤フレームワークリソースに対応する。

さらに、アプリケーション内の第１のサービス機能の基盤フレームワークリソースは、アプリケーション内の第１のサービス機能を起動するためのサービス要求を受信する前にロードされる。換言すると、アプリケーション内の第１のサービス機能の基盤フレームワークリソースは、アプリケーション内の第１のサービス機能を起動するためのサービス要求を受信するときには、既にロードされている。実際には、アプリケーション内の第１のサービス機能の基盤フレームワークリソースは、通常、アプリケーションの起動時にロードすることができる。あるいは、アプリケーション内の第１のサービス機能の基盤フレームワークリソースを、指定された時点（例えば、午前９時又は午前１０時）にロードすることができる。アプリケーション内の第１のサービス機能の基盤フレームワークリソースを、ユーザがアプリケーション内の第１のサービス機能を起動する前に、ユーザのアプリケーションを使用する習慣に基づいてロードすることさえできる。アプリケーション内の第１のサービス機能の基盤フレームワークリソースは、アプリケーション内の第１のサービス機能を起動するためのサービス要求を受信する前にロードされる限り、ロードの時点は限定されない。

ステップＳ１２：第１のサービス機能を起動するためのサービス要求を受信した後、第１のサービス機能が必要とするページリソースをロードする。

サービス機能を起動するには、通常、対応するページリソースが更に必要である。端末装置は、通常、ユーザが第１のサービス機能をトリガした後に、第１のサービス機能のためのページをユーザに表示できる。したがって、ページに対応しているページリソースが必要である。ページリソースは、ページコード、ページスクリプト等を含むことができる。

例えば、インスタントメッセージアプリケーションでは、ユーザが友人を追加するために友人追加のサービス機能を用いると、友人検索ページがユーザに表示される。したがって、サービス機能を起動すると、検索ページに関連するページリソースが必要となる。ページリソースには、ページコード、テキスト、画像、スクリプト等が含まれる。

本ステップでは、第１のサービス機能を起動するために必要なページリソースが、第１のサービス機能を起動するためのサービス要求を受信した後にロードされ、第１のサービス機能を起動するための基礎を提供する。

本願の実施例１のステップＳ１１及びステップＳ１２によれば、アプリケーション内の第１のサービス機能を起動するサービス要求を受信する前に、アプリケーション内の第１のサービス機能の基盤フレームワークリソースをロードするので、アプリケーション内の第１のサービス機能を起動するためのサービス要求を受信した後にロードが必要なサービスリソースが減る。このようにして、ユーザが第１のサービス機能のスタートボタンをトリガした後、第１のサービス機能を起動するには多くのサービスリソースをロードする必要があるので長い時間がかかってしまう、という既存の技術における問題が解決される。さらに、ユーザエクスペリエンスが向上する。

加えて、実際の適用では、アプリケーションは複数のサービス機能を提供する。したがって、特定のサービス機能を用いるとき、ユーザは、通常、別のサービス機能を同時に用いることができる。例えば、電子決済アプリケーションを用いて口座残高を見る場合、ユーザは、通常、請求履歴もチェックする。したがって、請求履歴を確認するためのサービス機能もこの場合に迅速に起動する必要がある。この問題を解決するために、第１のサービス機能が必要とするページリソースをロードした後に、第２のサービス機能に対応する基盤フレームワークリソースをロードすることができる。このようにして、本実施におけるステップＳ１３が形成される。

ステップＳ１３：アプリケーション内の第２のサービス機能の基盤フレームワークリソースを、第２のサービス機能を起動するためのサービス要求を受信する前にロードする。

第１のサービス機能の起動に必要なページリソースをロードした後に、ロードされた基盤フレームワークリソースとページリソースとを用いて、第１のサービス機能を起動できる。この場合、第２のサービス機能の基盤フレームワークリソースをロードでき、第２のサービス機能の起動を準備できる。第２のサービス機能は、第１のサービス機能以外のサービス機能である。

第１のサービス機能の実施は、第２のサービス機能の基盤フレームワークリソースではなく、第１のサービス機能のロードされた基盤フレームワークリソースとページリソースとに依存することに特に留意すべきである。したがって、ページリソースがロードされた後に第２のサービス機能の基盤フレームワークリソースをロードしても、第１のサービス機能の起動には影響しない。このように、第２のサービス機能の基盤フレームワークリソースを、第１のサービス機能を起動した後にロードできる、又は、ページリソースをロードした後に直接的にロードできる。

さらに、実際の適用では、アプリケーションの様々なサービス機能は、通常、同じ実行環境に基づいて実施できる。換言すれば、アプリケーションの様々なサービス機能は、同じ基盤フレームワークリソースに対応する。この場合、第１のサービス機能のページリソースがロードされた後、第１のサービス機能の基盤フレームワークリソースは、アプリケーション内の第２のサービス機能を起動するためのサービス要求を受信する前にリロードされる必要がある。

ステップＳ１３によれば、アプリケーション内の第２のサービス機能を起動するためのサービス要求を受信する前に、第２のサービスリソースの基盤フレームワークリソースがロードされる。これにより、第２のサービス機能が起動されているときには、ロードする必要のあるリソースが減少し、第２のサービス機能の起動が加速される。

実施例１で提供される方法のステップを、同じ装置又は異なる装置で実行できることに特に留意すべきである。例えば、ステップＳ１１及びステップＳ１２を、装置１によって実行できる。別の実施例では、ステップＳ１１を装置１によって実行でき、ステップＳ１２を装置２によって実行できる。

本願の実施において提供されるアプリケーションのリソースロード方法は、上記で説明される。理解を容易にするために、本願の実施は、実際のアプリケーションシナリオにおいて実施される方法の説明を更に提供する。図２に示すように、アプリケーションシナリオにおいて、アプリケーションは、ネイティブ技術とフロントエンド技術との組み合わせ（以下、ハイブリッドアプリケーションと称する）に基づいて開発されたアプリケーションである。ハイブリッドアプリケーションのエンジンは、通常、ハイブリッドエンジンである。第１のサービス機能の基盤フレームワークリソースと第２のサービス機能の基盤フレームワークリソースとはいずれも基盤フレームワークＲＥＡＣＴである。基盤フレームワークＲＥＡＣＴとは、ＲＥＡＣＴ仕様に基づいてＦａｃｅｂｏｏｋ（登録商標）によって立ち上げられたハイブリッド技術ソリューションのセットである。ＲＥＡＣＴ仕様とは、フロントエンドの開発を標準化するためにＦａｃｅｂｏｏｋ（登録商標）によって開発されたスクリプト言語（ＪａｖａＳｃｒｉｐｔ（登録商標）、ＪＳ）である。ページリソースは、主にページコードである。

ステップＳ２１：アプリケーション内の基盤フレームワークＲＥＡＣＴを、アプリケーション内の第１のサービス機能を起動するためのサービス要求を受信する前にハイブリッドエンジンを用いてロードする。

ここで、アプリケーションはハイブリッドアプリケーションである。ハイブリッドアプリケーションのエンジンはハイブリッドエンジンである。ハイブリッドエンジンは、フロントエンド言語を解析し、ネイティブ及びフロントエンドハイブリッド開発中に言語をネイティブ論理コードに変換するために用いられる。実際の適用では、多くのタイプのハイブリッドエンジンが存在する。例えば、一般的に使われるハイブリッドエンジンはブリッジエンジンである。

実際の適用では、基盤フレームワークＲＥＡＣＴをロードした後、この方法はハイブリッドエンジンの初期化をさらに含むことができる。

ステップＳ２２：第１のサービス機能を起動するためのサービス要求を受信した後、第１のサービス機能を起動するために必要なページコードをロードする。

実際の適用では、基盤フレームワークＲＥＡＣＴが占めるバイト数は、通常は、ページコードが占めるバイト数よりも大きい。例えば、第１のサービス機能を起動するために必要なすべてのサービスリソースが１００ＫＢを占める場合、ページコードは、通常、５ＫＢ未満を占める。したがって、第１のサービス機能を起動する命令を受信する前に基盤フレームワークＲＥＡＣＴをロードすると、第１のサービス機能を起動する命令を受信した後にロードが必要なリソースを大幅に減らすことができ、第１のサービス機能を起動するための時間を短縮できる。

ページコードをロードした後、本方法はロードされたページコードの実行を更に含むことができる。

ステップＳ２３：基盤フレームワークＲＥＡＣＴを、アプリケーション内の第２のサービス機能を起動するためのサービス要求を受信する前にリロードする。

図３のサービス機能の論理的シーケンス図と、図４の方法の実施における３つのフェーズ間の直列及び並列関係を示す図とを参照して、ステップＳ２１をステップＳ２３へ統合する。図４において、ハイブリッドアプリケーションにおけるサービス機能の起動処理は、３つのフェーズに分割される。第１のフェーズ（図４のＰ１）では、ハイブリッドエンジンは、第１のサービス機能を起動するためのサービス要求を受信する前に、第１のサービス機能に対応する基盤フレームワークＲＥＡＣＴをロードする。このフェーズでは、更に、ハイブリッドエンジンを初期化できる。第２のフェーズ（図４のＰ２）では、第１のサービス機能を起動するためのサービス要求を受信した後、第１のサービス機能に対応するページコードをロードして実行する。第３のフェーズ（図４のＰ３）では、新しいハイブリッドエンジンインスタンスが基盤フレームワークＲＥＡＣＴをロードする。３つのフェーズでは、第１のフェーズと第２のフェーズとを直列に実行でき、第２のフェーズと第３のフェーズとを並列に実行できる。このような実行方法を、通常、「ダブルエンジン」モードと称する。

実施例２は、既存の技術における、サービス機能の起動には、ユーザがサービス機能のスタートボタンをトリガしてから長い時間がかかってしまう、という問題を解決するために、アプリケーションのためのサービス機能実施方法を提供する。図５は、以下のステップを含む方法の概略フローチャートを示す。

Ｓ３１：アプリケーション内の第１のサービス機能を起動するためのサービス要求を受信する。

ここで、第１のサービス機能は対応するアプリケーションに含まれるいずれか一つのサービス機能であってもよい。例えば、オンラインショッピングアプリケーションは、通常、検索サービス機能、注文サービス機能等を含むことができる。このアプリケーションでは、第１のサービス機能を、検索サービス機能と注文サービス機能のうちのいずれか一方にすることができる。

ユーザは、通常、スマートフォン、タブレット、及びスマートテレビなどの端末装置にアプリケーションをインストールする。実際の適用では、ユーザが第１のサービス機能のスタートボタンをトリガすると、端末装置は、第１のサービス機能を起動するためのサービス要求を受信できる。端末装置には様々な種類があり、同じ端末装置内の起動方法が異なる場合がある。したがって、ユーザは、例えば、マウスを用いて第１のサービス機能のスタートボタンをクリックする方法、及び／又は第１のサービス機能のタッチ画面ボタンをタップする方法、及び／又はシェーキング、ジェスチャ認識若しくは表情認識を介して第１のサービス機能をトリガする方法など、複数の方法を用いて第１のサービス機能のスタートボタンをトリガすることができる。アプリケーション内の第１のサービス機能を起動する方法は、ここでは限定されない。

Ｓ３２：サービス要求に基づいて、第１のサービス機能を実施するために必要なページリソースをロードする。

第１のサービス機能を実施するために必要なページリソースは、アプリケーション内の第１のサービス機能を起動するためのサービス要求を受信した後にロードされる。

Ｓ３３：第１のサービス機能の基盤フレームワークリソースとページリソースとに基づいて、第１のサービス機能を実施する。

実際の適用では、ページリソースがロードされた後、ページリソースを、基盤フレームワークリソースによって提供される実行環境で呼び出すことができ、第１のサービス機能を実施できる。第１のサービス機能の基盤フレームワークリソースは、サービス要求を受信する前に実施例１の方法に基づいてロードされている。第１のサービス機能の基盤フレームワークリソースは、第１のサービス機能を実施するための実行環境を提供するために用いられる。

基盤フレームワークリソースは、ページリソースが呼び出された後に起動される。しかし、いくつかの場合、例えばページリソースを欠いている場合には、ページリソースは通常呼び出されない。実際の適用では、通常、第１のサービス機能はページリソースが無事に呼び出された後に起動される。

本願の実施例２で提供されるサービス処理方法によれば、ページリソースは、アプリケーション内の第１のサービス機能を起動するためのサービス要求を受信した後にロードされる。第１のサービス機能の基盤フレームワークリソース及びページリソースに基づいて、第１のサービス機能が実施される。第１のサービス機能の基盤フレームワークリソースは、サービス要求を受信する前に実施例１の方法に基づいてロードされている。したがって、既存の技術と比較して、本願では、サービス要求を受信した後に、第１のサービス機能を起動するためにロードする必要があるリソースがより少なくなり、第１のサービス機能の起動に要する時間が短くなる。

実際の適用では、アプリケーションのサービス機能実施方法は、ステップＳ３４を更に含むことができる。

Ｓ３４：第１のサービス機能の実施状況に基づいてサービス要求に応答する。

第１のサービス機能のために表示される必要があるページは、第１のサービス機能が実施された後にユーザに表示される。しかし、実際の適用では、特定のサービス機能が実施されないことがある。例えば、友人検索サービスは、ネットワーク接続の障害により失敗する。この場合、通常、障害の種類に対応するページをユーザへ返すことができる。換言すれば、第１のサービス機能の実施に失敗した場合には、第１のサービス機能の起動の失敗を表示するページをユーザへ返すことができる。ステップＳ３４によれば、第１のサービス機能の実施状況に基づいて対応する情報がユーザへ返され、それによってユーザエクスペリエンスが更に向上する。

実施例２で提供される方法のステップが同じ装置又は異なる装置で実行できる点は特に留意すべきである。例えば、ステップＳ３１及びステップＳ３２を装置１によって実行できる。別の例では、ステップＳ３１を装置１によって実行でき、ステップＳ３２を装置２によって実行できる。

実施例１と同じ発明概念に基づいて、実施例３は、アプリケーションのリソースロード装置を提供する。アプリケーションのリソースには、基盤フレームワークリソースとページリソースとが含まれる。図６に示すように、装置６０には、基盤フレームワークリソースロードユニット６０１と、ページリソースロードユニット６０２とが含まれる。

基盤フレームワークリソースロードユニット６０１は、アプリケーション内の第１サービス機能を起動するためのサービス要求を受信する前に、アプリケーション内の第１サービス機能の基盤フレームワークリソースをロードするように構成され、第１のサービス機能の基盤フレームワークリソースは第１のサービス機能を実施するための実行環境を提供するために用いられる。

ページリソースロードユニット６０２は、第１のサービス機能が必要とするページリソースを、第１のサービス機能を起動するためのサービス要求を受信した後にロードするように構成される。

本装置の発明概念は実施例１の発明概念と同じであるため、実施例３で提供される装置を採用することで、実施例１と同じ実施効果を奏することができる。加えて、実際の適用では、実際のハードウェア装置と組み合わせて別の実施効果を更に奏することができる。例えば、ハードウェア装置のメモリが少ない場合、既存の技術では多くのリソースを同時にロードする必要があるため、応答なし等の現象が発生する可能性がある。実施例３の装置によれば、スタートボタンがトリガされた後にロードされるリソースが少なくなるので、応答なしを減らすことができる。

好ましくは、装置６０は、アプリケーション内の第２のサービス機能を起動するためのサービス要求を受信する前に、第２のサービス機能の基盤フレームワークリソースをロードするように構成される第２の基盤フレームワークリソースロードユニット６０３を更に含むことができる。実際の適用では、基盤フレームワークリソースとページリソースとに基づいて第１のサービス機能を起動した後、第２のサービス機能の基盤フレームワークリソースを予めロードして第２のサービス機能の起動に備えることができる。このようにして、第２のサービス機能の起動が加速される。

好ましくは、基盤フレームワークリソースロードユニット６０１は、アプリケーションのエンジンがハイブリッドである場合、ハイブリッドエンジンを用いてアプリケーション内の第１のサービス機能の基盤フレームワークＲＥＡＣＴをロードするように構成される基盤フレームワークリソースロードサブユニット６０１１を含む。実際の適用では、アプリケーションのエンジンがハイブリッドエンジンである場合、ハイブリッドエンジンを用いて基盤フレームワークＲＥＡＣＴをロードできる。

実施例２と同じ発明概念に基づいて、実施例４は、アプリケーションのためのサービス機能実施装置を提供する。図７に示すように、装置７０は受信ユニット７０１と、ロードユニット７０２と、実施ユニット７０３とを含む。

受信ユニット７０１は、アプリケーション内の第１のサービス機能を起動するためのサービス要求を受信するように構成される。

ロードユニット７０２は、サービス要求に基づいて、第１のサービス機能を実施するために必要なページリソースをロードするように構成される。

実施ユニット７０３は、第１のサービス機能の基盤フレームワークリソースとページリソースとに基づいて第１のサービス機能を実施するように構成され、ここで、第１のサービス機能の基盤フレームワークリソースは、サービス要求を受信する前に本願の実施で提供されるアプリケーションのためのリソースロード装置に基づいてロードされる。

本願の実施例４で提供される装置によれば、呼び出しユニットが、基盤フレームワークリソースによって提供される実施環境において、ロードされたページリソースを呼び出すとき、基盤フレームワークリソースは、受信ユニットがサービス要求を受信する前に、ロードされている。したがって、既存の技術と比較して、本願では、サービス要求を受信した後に、第１のサービス機能を起動するためにロードが必要なリソースが減り、第１のサービス機能の起動に要する時間が短くなる。

実際の適用では、装置７０は、第１のサービス機能の起動状態に基づいてサービス要求に応答するように構成される応答ユニット７０４を更に含むことができる。応答ユニット７０４は、第１のサービス機能の実施状態に基づいて対応する情報をユーザへ返送し、それによってユーザエクスペリエンスが更に向上する。

当業者は、本願の実施は、方法、システム、又はコンピュータプログラム製品として提供できることを理解するはずである。そのため、本願は、ハードウェアのみの実施、ソフトウェアのみの実施、又は、ソフトウェアとハードウェアとの組み合わせによる実施を用いることができる。さらに、本願は、コンピュータで使用可能なプログラムコードを含んだ１台以上のコンピュータで使用可能な記憶媒体（ディスクメモリ、ＣＤ−ＲＯＭ、光学メモリ等を含むがこれに限定されない）上で実施されるコンピュータプログラム製品を使用できる。

本願は、本願の実施に係る方法、デバイス（システム）、コンピュータプログラム製品のフローチャート及び／又はブロック図を参照して説明されている。コンピュータプログラム命令は、各工程、及び／又はフローチャート内の各ブロック、及び／又はブロック図を実施するために用いることができ、さらに、工程、及び／又はフローチャート内の１つのブロック、及び／又はブロック図、の組み合わせを実施するために用いることができる点が理解されるはずである。これらのコンピュータプログラム命令は、汎用コンピュータ、専用コンピュータ、組み込みプロセッサ、又はあらゆるその他のプログラム可能なデータ処理デバイスに、マシンを生成するために提供されることができ、これにより、コンピュータ、又は、あらゆるその他のプログラム可能なデータ処理デバイスのプロセッサが、フローチャートの１つ以上の工程において、及び／又は、ブロック図の１つ以上のブロックにおいて、特定の機能を実施するデバイスを生成できるようになる。

これらのコンピュータプログラム命令を、コンピュータ又はあらゆるその他のプログラム可能なデータ処理デバイスに特定の方法で機能するように命令することができるコンピュータ読取可能なメモリに記憶して、これらのコンピュータ読取可能なメモリに記憶された命令が、命令装置を含む加工品を作り出すようにすることができる。この命令装置は、フローチャート内の１つ以上の工程における、及び／又はブロック図内の１つ以上のブロックにおける特定の機能を実施する。

これらのコンピュータプログラム命令をコンピュータ又はその他のプログラム可能なデータ処理デバイスにロードして、コンピュータ又はその他のプログラム可能なデバイス上で一連の操作及びステップが実行されるようにし、コンピュータで実施される処理を生成することができる。これにより、コンピュータ又はその他のプログラム可能なデバイス上で実行される命令が、フローチャート内の１つ以上のステップ及び／又はブロック図内の１つ以上のブロックにおける特定の機能を実施するデバイスを提供することを可能とする。

典型的な構成では、計算デバイスは１つ以上のプロセッサ（ＣＰＵｓ）、入出力インターフェース、ネットワークインターフェース、及びメモリを含む。

メモリは揮発性メモリ、ランダムアクセスメモリ（ＲＡＭ）、及び／又は、読み取り専用メモリ（ＲＯＭ）やフラッシュメモリ（フラッシュＲＡＭ）のようなコンピュータ読取可能な不揮発性メモリとすることができる。メモリはコンピュータ読取可能な媒体の一例である。

コンピュータで読取可能な媒体には、任意の方法又は技術を用いて情報を記憶できる、永続的、非永続的、移動可能な、移動不能な媒体が含まれる。この情報はコンピュータ読取可能な命令、データ構造、プログラムモジュール、又はその他のデータであってよい。コンピュータの記憶媒体の例として、計算デバイスによってアクセスできる情報を記憶するために用いることが可能な、相変化ランダムアクセスメモリ（ＰＲＡＭ）、スタティックランダムアクセスメモリ（ＳＲＡＭ）、ダイナミックランダムアクセスメモリ（ＤＲＡＭ）、別タイプのランダムアクセスメモリ、リードオンリーメモリ（ＲＯＭ）、電気的に消去可能でプログラム可能なＲＯＭ（ＥＥＰＲＯＭ）、フラッシュメモリ、又は別のメモリ技術、コンパクトディスクＲＯＭ（ＣＤ−ＲＯＭ）、デジタル多用途ディスク（ＤＶＤ）、又は別の光学記憶装置、磁気カセットテープ、テープ及びディスク記憶装置、又は別の磁気記憶デバイス、若しくはその他任意の非一時的媒体があるが、それらに限定されない。本願で定義しているように、コンピュータ読取可能な媒体は、変調されたデータ信号及び搬送波のような一時的な媒体を含まない。

さらに、用語「含む」、「含有する」、又はこれらのその他任意の応用形は、非限定的な包含を網羅するものであるため、一連の要素を含んだ工程、方法、物品、デバイスはこれらの要素を含むだけでなく、ここで明確に挙げていないその他の要素をも含む、あるいは、このような工程、方法、物品、デバイスに固有の要素をさらに含むことができる点に留意することが重要である。「１つの〜を含む」との用語を付けて示された要素は、それ以上の制約がなければ、その要素を含んだ工程、方法、物品、デバイス内に別の同一の要素をさらに含むことを排除しない。

当業者は、本願の実施が方法、システム、コンピュータプログラム製品として提供され得ることを理解するはずである。そのため、本願は、ハードウェアのみの実施、ソフトウェアのみの実施、又は、ソフトウェアとハードウェアの組み合わせによる実施を用いることができる。さらに、本願は、コンピュータで用いることができるプログラムコードを含んだ、１つ以上のコンピュータで使用可能な記憶媒体（磁気ディスクストレージ、ＣＤ−ＲＯＭ、光学ディスク等を非限定的に含む）上で実施されるコンピュータプログラム製品の形態を用いることが可能である。

上述のものは本願の一実施形態であるが、本願を限定するものではない。当業者は、本願に様々な修正及び変更を加えることができる。本願の主旨及び原理から逸脱せずに為されるあらゆる修正、均等物による代替、改善は、本願の特許請求の範囲に含まれるものである。

６０ アプリケーションのリソースロード装置
６０１ 基盤フレームワークリソースロードユニット
６０２ ページリソースロードユニット
７０ アプリケーションのサービス機能実施装置
７０１ 受信ユニット
７０２ ロードユニット
７０３ 実施ユニット
Ｐ１ 第１のフェーズ
Ｐ２ 第２のフェーズ
Ｐ３ 第３のフェーズ

Claims (8)

1. アプリケーションのためのリソースロード方法であって、前記アプリケーションのリソースは、基盤フレームワークリソースとページリソースとを備え：
   前記アプリケーション内の第１のサービス機能を起動するためのサービス要求を受信する前に、前記第１のサービス機能の基盤フレームワークリソースをアプリケーションにロードするステップであって、前記第１のサービス機能の前記基盤フレームワークリソースは前記第１のサービス機能を実施するための実行環境を提供するために用いられる、前記ロードするステップと；
   前記第１のサービス機能を起動するための前記サービス要求を受信した後、前記第１のサービス機能が必要とするページリソースをロードするステップと；を備える、
   アプリケーションのためのリソースロード方法。
2. 前記第１のサービス機能が必要とするページリソースをロードする前記ステップの後に、
   前記第２のサービス機能を起動するためのサービス要求を受信する前に、前記アプリケーション内の第２のサービス機能の基盤フレームワークリソースをロードするステップを更に備える、
   請求項１に記載のリソースロード方法。
3. 前記アプリケーションのエンジンはハイブリッドエンジンであり、
   前記アプリケーション内の第１のサービス機能の基盤フレームワークリソースをロードする前記ステップは、前記ハイブリッドエンジンを用いて、前記アプリケーション内の前記第１のサービス機能の基盤フレームワークＲＥＡＣＴをロードするステップを備える、
   請求項１に記載のリソースロード方法。
4. アプリケーションのためのサービス機能実施方法であって：
   前記アプリケーション内の第１のサービス機能を起動するためのサービス要求を受信するステップと；
   前記サービス要求に基づいて、前記第１のサービス機能を実施するために必要なページリソースをロードするステップと；
   前記第１のサービス機能の基盤フレームワークリソースと前記ページリソースとに基づいて前記第１のサービス機能を実施するステップであって、前記第１のサービス機能の前記基盤フレームワークリソースが、前記サービス要求を受信する前に、請求項１乃至請求項３のいずれか１項に記載のリソースロード方法に基づいてロードされる、前記実施するステップと；を備える、
   アプリケーションのためのサービス機能実施方法。
5. アプリケーションのためのリソースロード装置であって、前記アプリケーションのリソースは、基盤フレームワークリソースとページリソースとを含み、
   前記装置は、基盤フレームワークリソースロードユニットとページリソースロードユニットとを含み、
   前記基盤フレームワークリソースロードユニットは、前記アプリケーション内の第１のサービス機能を起動するためのサービス要求を受信する前に、前記アプリケーション内の前記第１のサービス機能の基盤フレームワークリソースをロードするように構成され、前記第１のサービス機能の前記基盤フレームワークリソースは、前記第１のサービス機能を実施するための実行環境を提供するために用いられ、
   前記ページリソースロードユニットは、前記第１のサービス機能を起動するための前記サービス要求を受信した後に、前記第１のサービス機能が必要とするページリソースをロードするように構成される、
   アプリケーションのためのリソースロード装置。
6. 第２のサービス機能を起動するためのサービス要求を受信する前に、前記アプリケーション内の前記第２のサービス機能の基盤フレームワークリソースをロードするように構成される第２の基盤フレームワークリソースロードユニットを更に備える、
   請求項５に記載のリソースロード装置。
7. 前記基盤フレームワークリソースロードユニットは、前記アプリケーションのエンジンがハイブリッドエンジンである場合、前記ハイブリッドエンジンを用いて前記アプリケーション内の前記第１のサービス機能の基盤フレームワークＲＥＡＣＴをロードするように構成される基盤フレームワークリソースロードサブユニットを備える、
   請求項５に記載のリソースロード装置。
8. 受信ユニットと、ロードユニットと、実施ユニットとを備える、アプリケーションのためのサービス機能実施装置であって：
   前記受信ユニットは、前記アプリケーション内の第１のサービス機能を起動するためのサービス要求を受信するように構成され、
   前記ロードユニットは、前記サービス要求に基づいて、前記第１のサービス機能を実施するために必要なページリソースをロードするように構成され、
   前記実施ユニットは、前記第１のサービス機能の基盤フレームワークリソースと前記ページリソースとに基づいて前記第１のサービス機能を実施するように構成され、前記第１のサービス機能の前記基盤フレームワークリソースは、前記サービス要求を受信する前に、請求項５乃至請求項７のいずれか１項に記載のリソースロード装置に基づいてロードされる、
   アプリケーションのためのサービス機能実施装置。
   

Images