▶ ベイジン ウードン ティアンジュン インフォメーション テクノロジー カンパニー，リミテッドの特許一覧 ▶ ベイジン ジンドン センチュリー トレーディング カンパニー，リミテッドの特許一覧
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2024-08-14
(45)【発行日】2024-08-22
(54)【発明の名称】画像処理方法及び装置、並びにコンピュータ可読記憶媒体
(51)【国際特許分類】
G06T 1/00 20060101AFI20240815BHJP
【ＦＩ】
G06T1/00 200D
【請求項の数】
15
(21)【出願番号】P 2023510486
(86)(22)【出願日】2021-03-29
(65)【公表番号】
(43)【公表日】2023-09-05
(86)【国際出願番号】 CN2021083678
(87)【国際公開番号】W WO2022048141
(87)【国際公開日】2022-03-10
【審査請求日】2023-02-13
(31)【優先権主張番号】202010902786.1
(32)【優先日】2020-09-01
(33)【優先権主張国・地域又は機関】CN
(73)【特許権者】
【識別番号】522440407
【氏名又は名称】ベイジン ウードン ティアンジュン インフォメーション テクノロジー カンパニー，リミテッド
【氏名又は名称原語表記】ＢＥＩＪＩＮＧ ＷＯＤＯＮＧ ＴＩＡＮＪＵＮ ＩＮＦＯＲＭＡＴＩＯＮ ＴＥＣＨＮＯＬＯＧＹ ＣＯ．，ＬＴＤ．
【住所又は居所原語表記】Ｒｏｏｍ Ａ４０２，４／ｆ，Ｎｏ．２ Ｂｕｉｌｄｉｎｇ，Ｎｏ．１８ Ｋｅｃｈｕａｎｇ １１ｔｈ Ｓｔｒｅｅｔ，Ｅｃｏｎｏｍｉｃ Ａｎｄ Ｔｅｃｈｎｏｌｏｇｉｃａｌ Ｄｅｖｅｌｏｐｍｅｎｔ Ｚｏｎｅ，Ｂｅｉｊｉｎｇ １００１７６，ＣＨＩＮＡ
(73)【特許権者】
【識別番号】522440670
【氏名又は名称】ベイジン ジンドン センチュリー トレーディング カンパニー，リミテッド
【氏名又は名称原語表記】ＢＥＩＪＩＮＧ ＪＩＮＧＤＯＮＧ ＣＥＮＴＵＲＹ ＴＲＡＤＩＮＧ ＣＯ．，ＬＴＤ．
【住所又は居所原語表記】Ｒｏｏｍ ２０１，２／Ｆ，Ｂｌｏｃｋ Ｃ，Ｎｏ．１８ Ｋｅｃｈｕａｎｇ １１ Ｓｔｒｅｅｔ，Ｅｃｏｎｏｍｉｃ Ａｎｄ Ｔｅｃｈｎｏｌｏｇｉｃａｌ Ｄｅｖｅｌｏｐｍｅｎｔ Ｚｏｎｅ，Ｂｅｉｊｉｎｇ １００１７６，ＣＨＩＮＡ
(74)【代理人】
【識別番号】100102842
【弁理士】
【氏名又は名称】葛和 清司
(72)【発明者】
【氏名】リ，リンセン
(72)【発明者】
【氏名】イエ，ウェンウェン
【審査官】益戸 宏
(56)【参考文献】
【文献】中国特許出願公開第１０７７６６３５９（ＣＮ，Ａ）
【文献】特開２０１１－０４８７０４（ＪＰ，Ａ）
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｇ０６Ｔ １／００
(57)【特許請求の範囲】
【請求項1】
画像処理方法であって、ウェブページアプリケーションにおいて、現在のフルスクリーンページの少なくとも１つのページ画像を取得するステップと、
前記少なくとも１つのページ画像を少なくとも１つのファイルオブジェクトに変換し、前記少なくとも１つのファイルオブジェクトの少なくとも１つのリンクパスを作成するステップであって、前記少なくとも１つのファイルオブジェクトは前記少なくとも１つのリンクパスに1対1で対応する、ステップと、
ウェブページアプリケーションスクリプトの中のピクチャーオブジェクト作成方法を呼び出し、少なくとも１つのピクチャーオブジェクトを作成し、前記少なくとも１つのピクチャーオブジェクトを前記少なくとも１つのリンクパスと関連付けてウェブページアプリケーションキャッシュに保存し、これによって前記現在のフルスクリーンページのスクリーンショットを完成するステップと、を含む、
画像処理方法。
【請求項2】
前記少なくとも１つのページ画像を少なくとも１つのファイルオブジェクトに変換し、前記少なくとも１つのファイルオブジェクトの少なくとも１つのリンクパスを作成するステップは、前記少なくとも１つのページ画像を少なくとも１つのバイナリラージオブジェクトに変換し、前記少なくとも１つのファイルオブジェクトとして使用するステップと、
前記少なくとも１つのバイナリラージオブジェクトの中の各バイナリラージオブジェクトに対して、ウェブページアプリケーションスクリプトの中のオブジェクト場所パス作成方法を呼び出し、前記各バイナリラージオブジェクトのリソースアドレスをリンクパスとして作成し、これによって前記少なくとも１つのリンクパスを取得するステップと、を含む、
請求項１に記載の画像処理方法。
【請求項3】
前記ウェブページアプリケーションスクリプトの中のピクチャーオブジェクト作成方法を呼び出し、少なくとも１つのピクチャーオブジェクトを作成し、前記少なくとも１つのピクチャーオブジェクトを前記少なくとも１つのリンクパスと関連付けてウェブページアプリケーションキャッシュに保存し、これによって前記現在のフルスクリーンページのスクリーンショットを完成するステップは、
各ピクチャーオブジェクトに対して、前記少なくとも１つのリンクパスの中の各リンクパスを前記各ピクチャーオブジェクトの画像ソースパスとして使用し、前記少なくとも１つのピクチャーオブジェクトを前記ウェブページアプリケーションキャッシュに保存するステップであって、前記画像ソースパスは、前記各ピクチャーオブジェクトをロードするときに、コンテンツデータを取得するパスである、ステップと、
セッションデータによって前記少なくとも１つのピクチャーオブジェクトを前記少なくとも１つのリンクパスと関連付けて保存することを実現できるように、前記少なくとも１つのピクチャーオブジェクトのピクチャー名称と画像ソースパスを前記ウェブページアプリケーションキャッシュの前記セッションデータに保存し、これによって前記現在のフルスクリーンページのスクリーンショットを完成するステップと、を含む、
請求項１に記載の画像処理方法。
【請求項4】
前記現在のフルスクリーンページの少なくとも１つのページ画像を取得するステップは、前記ウェブページアプリケーションキャッシュのセッションデータに、前記現在のフルスクリーンページに対応する少なくとも１つのピクチャーオブジェクトが存在するか否かをチェックするステップと、
前記セッションデータに前記少なくとも１つのピクチャーオブジェクトが存在しない場合、前記現在のフルスクリーンページの少なくとも１つのページ画像を取得するステップと、を含む、
請求項１に記載の画像処理方法。
【請求項5】
前記ウェブページアプリケーションキャッシュのセッションデータに、前記現在のフルスクリーンページに対応する少なくとも１つのピクチャーオブジェクトが存在するか否かをチェックするステップの後で、前記画像処理方法はさらに、前記セッションデータに前記少なくとも１つのピクチャーオブジェクトが存在する場合、前記セッションデータから前記少なくとも１つのピクチャーオブジェクトに対応する前記少なくとも１つのリンクパスを取得し、前記現在のフルスクリーンページのスクリーンショットを完成するステップと、を含む、
請求項４に記載の画像処理方法。
【請求項6】
前記現在のフルスクリーンページの少なくとも１つのページ画像を取得するステップは、前記現在のフルスクリーンページのロードを完成した場合、前記現在のフルスクリーンページの中の各場面に対応する画像を取得し、少なくとも１つのページ画像として使用するステップと、を含む、
請求項１ないし４のいずれか一項に記載の画像処理方法。
【請求項7】
前記ウェブページアプリケーションにおいて、現在のフルスクリーンページの少なくとも１つのページ画像を取得するステップは、前記現在のフルスクリーンページでスクリーンショット命令を受信した場合、前記スクリーンショット命令に応答して、前記スクリーンショット命令により指定される少なくとも１つのスクリーンショット待ち場面に対応する画像を前記少なくとも１つのページ画像として使用するステップと、を含む、
請求項１ないし４のいずれか一項に記載の画像処理方法。
【請求項8】
前記現在のフルスクリーンページのスクリーンショットを完成するステップの後で、前記画像処理方法はさらに、前記ウェブページアプリケーションにおいて、前記少なくとも１つのピクチャーオブジェクトの中の少なくとも１つの目標ピクチャーオブジェクトに対するアクセス要求を受信した場合、前記少なくとも１つの目標ピクチャーオブジェクトの画像ソースパスによって、前記少なくとも１つの目標ピクチャーオブジェクトに対応する少なくとも１つの目標ファイルオブジェクトを取得するステップであって、前記目標ファイルオブジェクトのリンクパスは、前記目標ピクチャーオブジェクトの画像ソースパスと同じである、ステップと、
前記少なくとも１つの目標ファイルオブジェクトに基づいて、前記少なくとも１つの目標ピクチャーオブジェクトをロードし、これによって、前記少なくとも１つの目標ピクチャーオブジェクトに対する表示及び保存を実現するステップと、を含む、
請求項３又は５に記載の画像処理方法。
【請求項9】
前記ウェブページアプリケーションにおいて、現在のフルスクリーンページの少なくとも１つのページ画像を取得するステップは、現在のフルスクリーンページから少なくとも１つの場面を分割し、前記少なくとも１つの場面に対して少なくとも１つのノード識別子を設定するステップであって、前記少なくとも１つのノード識別子は、前記現在のフルスクリーンページで、前記少なくとも１つの場面に対応する少なくとも１つのデータ位置を表し、前記少なくとも１つの場面は、前記少なくとも１つのノード識別子に1対1で対応する、ステップと、
前記現在のフルスクリーンページで、少なくとも１つのスクリーンショット待ち場面に対応する少なくとも１つの目標ノード識別子を取得するステップであって、前記少なくとも１つのスクリーンショット待ち場面は、前記少なくとも１つの場面の中の目標スクリーンショット場面である、ステップと、
前記少なくとも１つの目標ノード識別子の中の各目標ノード識別子に基づいて、前記現在のフルスクリーンページのコンテンツデータから各目標ノード識別子に対応するコンテンツデータを読み出し、これによって少なくとも１つの目標ページデータを取得するステップと、
ウェブページレンダリング機能によって、前記少なくとも１つの目標ページデータに基づいて、前記少なくとも１つのページ画像を作成するステップと、を含む、
請求項１に記載の画像処理方法。
【請求項10】
前記少なくとも１つのページ画像を少なくとも１つのバイナリラージオブジェクトに変換し、前記少なくとも１つのファイルオブジェクトとして使用するステップは、ウェブページ描画方法の中のピクチャーからバイナリラージオブジェクトへの変換方法を呼び出し、前記少なくとも１つのページ画像から少なくとも１つのバイナリラージオブジェクトに変換することを実現し、前記少なくとも１つのファイルオブジェクトとして使用するステップと、を含む、
請求項２に記載の画像処理方法。
【請求項11】
前記少なくとも１つのピクチャーオブジェクトのピクチャー名称と画像ソースパスを前記ウェブページアプリケーションキャッシュのセッションデータに保存するステップは、セッションデータ設定方法を呼び出し、前記少なくとも１つのピクチャーオブジェクトのピクチャー名称と画像ソースパスを前記ウェブページアプリケーションキャッシュに保存することを実現するステップと、を含む、
請求項３に記載の画像処理方法。
【請求項12】
前記ウェブページアプリケーションキャッシュのセッションデータに、前記現在のフルスクリーンページに対応する少なくとも１つのピクチャーオブジェクトが存在するか否かをチェックするステップは、前記少なくとも１つのピクチャーオブジェクトのピクチャー名称に基づいて、セッションデータ取得方法を呼び出し、前記セッションデータから前記少なくとも１つのピクチャーオブジェクトを抽出することを実行するステップと、
前記セッションデータ取得方法の呼び出しが成功した場合、前記セッションデータに前記少なくとも１つのピクチャーオブジェクトが存在することを確認するステップと、
前記セッションデータ取得方法の呼び出しが失敗した場合、前記セッションデータに前記少なくとも１つのピクチャーオブジェクトが存在しないことを確認するステップと、を含む、
請求項４に記載の画像処理方法。
【請求項13】
画像処理装置であって、前記画像処理装置は、取得部と、変換部と、保存部と、を含み、前記取得部は、ウェブページアプリケーションにおいて、現在のフルスクリーンページの少なくとも１つのページ画像を取得するように構成され、
前記変換部は、前記少なくとも１つのページ画像を少なくとも１つのファイルオブジェクトに変換し、前記少なくとも１つのファイルオブジェクトの少なくとも１つのリンクパスを作成するように構成され、前記少なくとも１つのファイルオブジェクトは、前記少なくとも１つのリンクパスに1対1で対応し、
前記保存部は、ウェブページアプリケーションスクリプトの中のピクチャーオブジェクト作成方法を呼び出し、少なくとも１つのピクチャーオブジェクトを作成し、前記少なくとも１つのピクチャーオブジェクトを前記少なくとも１つのリンクパスと関連付けてウェブページアプリケーションキャッシュに保存し、これによって前記現在のフルスクリーンページのスクリーンショットを完成するように構成される、画像処理装置。
【請求項14】
画像処理装置であって、前記画像処理装置は、メモリと、プロセッサと、通信バスと、を含み、前記メモリは、前記通信バスによって前記プロセッサと通信し、前記メモリは、前記プロセッサによって実行可能な１つ又は複数のプログラムを記憶し、
前記プロセッサは、前記１つ又は複数のプログラムを実行して、請求項１ないし１２のいずれか一項に記載の画像処理方法を実行する、画像処理装置。
【請求項15】
コンピュータ可読記憶媒体であって、１つ又は複数のプロセッサに、請求項１ないし１２のいずれか一項に記載の画像処理方法を実行させるための１つ又は複数のコンピュータプログラムを記憶した、コンピュータ可読記憶媒体。
【発明の詳細な説明】
【技術分野】
【0001】
（関連出願への相互参照）
本願は、２０２０年０９月０１日に中国特許局に提出された、出願番号が２０２０１０９０２７８６．１であり、発明の名称が「画像処理方法及び装置、並びにコンピュータ可読記憶媒体」である中国特許出願の優先権を主張し、その内容の全てが引用により本願に組み込まれる。
本開示は、端末技術の分野に関し、特に、画像処理方法及び装置、並びにコンピュータ可読記憶媒体に関する。
本願は、２０２０年０９月０１日に中国特許局に提出された、出願番号が２０２０１０９０２７８６．１であり、発明の名称が「画像処理方法及び装置、並びにコンピュータ可読記憶媒体」である中国特許出願の優先権を主張し、その内容の全てが引用により本願に組み込まれる。
本開示は、端末技術の分野に関し、特に、画像処理方法及び装置、並びにコンピュータ可読記憶媒体に関する。
【背景技術】
【0002】
現在、ユーザは、モバイル端末におけるブラウザを使用して、ハイパー・テキスト・マークアップ言語（ＨＴＭＬ：Ｈｙｐｅｒ Ｔｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）のウェブページ全体におけるコンテンツを閲覧することができる。ウェブページ全体の中の１つ又は複数の画面のページに対して、スクリーンショットを保存する必要がある場合、現在のスクリーンショット方式は、一般的に、ＨＴＭＬ仕様のｃａｎｖａｓ方法によって、指定されたページのスクリーンショットを撮り、ブラウザのキャッシュで撮られたＨＴＭＬページをｂａｓｅ６４コーディングフォーマットのピクチャーに変換し、変換されたピクチャーをモバイル端末のローカルに保存する。しかしながら、ｂａｓｅ６４コーディングフォーマットのピクチャーはキャッシュ容量を多く消費し、且つ、ＨＴＭＬページをｂａｓｅ６４ピクチャーへの変換を行う場合、ウェブページ描画の中のレンダリング方法を使用する必要があり、且つ、ページが複雑になればなるほどレンダリングには時間がかかるようになる。したがって、現在のスクリーンショット方式は、ブラウザのキャッシュを大量に消費し、撮るプロセスが長く、これによってブラウザのキャッシュの性能が低下している。
【発明の概要】
【0003】
これを鑑みて、本開示の実施例は、画像処理方法及び装置、並びにコンピュータ可読記憶媒体を提供し、ウェブページアプリケーションのスクリーンショットの性能を向上させることができる。
前記目的を実現するために、本開示の技術案は、以下のように実現される。
本開示の実施例の第１態様において、画像処理方法を提供し、前記画像処理方法は、
ウェブページアプリケーションにおいて、現在のフルスクリーンページの少なくとも１つのページ画像を取得するステップと、
前記少なくとも１つのページ画像を少なくとも１つのファイルオブジェクトに変換し、前記少なくとも１つのファイルオブジェクトの少なくとも１つのリンクパスを作成するステップであって、前記少なくとも１つのファイルオブジェクトは前記少なくとも１つのリンクパスに1対1で対応する、ステップと、
前記目的を実現するために、本開示の技術案は、以下のように実現される。
本開示の実施例の第１態様において、画像処理方法を提供し、前記画像処理方法は、
ウェブページアプリケーションにおいて、現在のフルスクリーンページの少なくとも１つのページ画像を取得するステップと、
前記少なくとも１つのページ画像を少なくとも１つのファイルオブジェクトに変換し、前記少なくとも１つのファイルオブジェクトの少なくとも１つのリンクパスを作成するステップであって、前記少なくとも１つのファイルオブジェクトは前記少なくとも１つのリンクパスに1対1で対応する、ステップと、
【0004】
少なくとも１つのピクチャーオブジェクトを作成し、前記少なくとも１つのピクチャーオブジェクトを前記少なくとも１つのリンクパスと関連付けてウェブページアプリケーションキャッシュに保存し、これによって前記現在のフルスクリーンページのスクリーンショットを完成するステップと、を含む。
本開示の実施例の第２態様において、画像処理装置を提供し、前記画像処理装置は、取得部と、変換部と、保存部と、を含み、
前記取得部は、ウェブページアプリケーションにおいて、現在のフルスクリーンページの少なくとも１つのページ画像を取得するように構成され、
前記変換部は、前記少なくとも１つのページ画像を少なくとも１つのファイルオブジェクトに変換し、前記少なくとも１つのファイルオブジェクトの少なくとも１つのリンクパスを作成するように構成され、前記少なくとも１つのファイルオブジェクトは、前記少なくとも１つのリンクパスに1対1で対応し、
本開示の実施例の第２態様において、画像処理装置を提供し、前記画像処理装置は、取得部と、変換部と、保存部と、を含み、
前記取得部は、ウェブページアプリケーションにおいて、現在のフルスクリーンページの少なくとも１つのページ画像を取得するように構成され、
前記変換部は、前記少なくとも１つのページ画像を少なくとも１つのファイルオブジェクトに変換し、前記少なくとも１つのファイルオブジェクトの少なくとも１つのリンクパスを作成するように構成され、前記少なくとも１つのファイルオブジェクトは、前記少なくとも１つのリンクパスに1対1で対応し、
【0005】
前記保存部は、少なくとも１つのピクチャーオブジェクトを作成し、前記少なくとも１つのピクチャーオブジェクトを前記少なくとも１つのリンクパスと関連付けてウェブページアプリケーションキャッシュに保存し、これによって前記現在のフルスクリーンページのスクリーンショットを完成するように構成される。
本開示の実施例の第３態様において、画像処理装置を提供し、前記画像処理装置は、メモリと、プロセッサと、通信バスと、を含み、前記メモリは、前記通信バスによって前記プロセッサと通信し、前記メモリは、前記プロセッサによって実行可能な１つ又は複数のプログラムを記憶し、前記プロセッサは、前記１つ又は複数のプログラムが実行して、上記のいずれかの画像処理方法を実行する。
本開示の実施例の第４態様において、コンピュータ可読記憶媒体を提供し、前記コンピュータ可読記憶媒体は、１つ又は複数のコンピュータプログラムを記憶し、前記１つ又は複数のコンピュータプログラムは、１つ又は複数のプロセッサに上記のいずれかの画像処理方法を実行させる。
本開示の実施例の第３態様において、画像処理装置を提供し、前記画像処理装置は、メモリと、プロセッサと、通信バスと、を含み、前記メモリは、前記通信バスによって前記プロセッサと通信し、前記メモリは、前記プロセッサによって実行可能な１つ又は複数のプログラムを記憶し、前記プロセッサは、前記１つ又は複数のプログラムが実行して、上記のいずれかの画像処理方法を実行する。
本開示の実施例の第４態様において、コンピュータ可読記憶媒体を提供し、前記コンピュータ可読記憶媒体は、１つ又は複数のコンピュータプログラムを記憶し、前記１つ又は複数のコンピュータプログラムは、１つ又は複数のプロセッサに上記のいずれかの画像処理方法を実行させる。
【発明の効果】
【0006】
本開示の実施例は、画像処理方法及び装置、並びにコンピュータ可読記憶媒体を提供する。該方法は、ウェブページアプリケーションにおいて、現在のフルスクリーンページの少なくとも１つのページ画像を取得するステップと、少なくとも１つのページ画像を少なくとも１つのファイルオブジェクトに変換し、少なくとも１つのファイルオブジェクトの少なくとも１つのリンクパスを作成するステップであって、少なくとも１つのファイルオブジェクトは少なくとも１つのリンクパスに1対1で対応する、ステップと、少なくとも１つのピクチャーオブジェクトを作成し、少なくとも１つのピクチャーオブジェクトを少なくとも１つのリンクパスと関連付けてウェブページアプリケーションキャッシュに保存し、これによって現在のフルスクリーンページのスクリーンショットを完成するステップと、を含む。本開示の実施例の方法によって、画像処理装置は、少なくとも１つのページ画像を取得した後で、少なくとも１つのページ画像を少なくとも１つのファイルオブジェクトに変換し、少なくとも１つのファイルオブジェクトのリンクパスを少なくとも１つのピクチャーオブジェクトと関連付けてキャッシュに保存することができ、これによってスクリーンショットを他のコーディングフォーマットに変換することによりキャッシュ占有率が大きいという技術的問題を克服する。そして、現在のフルスクリーンページの少なくとも１つのピクチャーオブジェクトは、キャッシュに保存されるため、ユーザが現在のフルスクリーンページに再び入ってスクリーンショットを撮りたい場合、画像処理装置は、直接にキャッシュから少なくとも１つのピクチャーオブジェクトを取得し、対応するページのスクリーンショットとすることができ、再びスクリーンショットを撮る必要がなく、ブラウザ処理の作業負荷を軽減し、最終的にウェブページアプリケーションのスクリーンショットの性能を向上させる。
【図面の簡単な説明】
【0007】
【図1】本開示の実施例によって提供される画像処理方法の一例示的なフローチャートである。
【図2】本開示の実施例によって提供される画像処理方法の一例示的なフローチャートである。
【図3】本開示の実施例によって提供される画像処理方法の一例示的なフローチャートである。
【図4】本開示の実施例によって提供される画像処理方法の一例示的なフローチャートである。
【図5】本開示の実施例によって提供される画像処理方法の一例示的なフローチャートである。
【図6】本開示の実施例によって提供される画像処理方法の一例示的なフローチャートである。
【図7A】本開示の実施例によって提供されるウェブページアプリケーションのスクリーンショットを撮るプロセスのインターフェース概略図である。
【図7B】本開示の実施例によって提供されるウェブページアプリケーションのスクリーンショットを撮るプロセスのインターフェース概略図である。
【図7C】本開示の実施例によって提供されるウェブページアプリケーションのスクリーンショットを撮るプロセスのインターフェース概略図である。
【図8】本開示の実施例によって提供される画像処理方法の一例示的なフローチャートである。
【図9】本開示の実施例によって提供される画像処理装置の構造概略図である。
【図10】本開示の実施例によって提供される画像処理装置の構造概略図である。
【発明を実施するための形態】
【0008】
以下では、本開示の実施例の図面を参照して、本開示の実施例の技術案をさらに明確で完全に説明する。
本開示の実施例をさらに詳細に説明する前に、本開示の実施例に関する名詞と用語について説明する。本開示の実施例に関する名詞と用語は、下記のような解釈に適用される。
ｃａｎｖａｓ：ＨＴＭＬの中のｃａｎｖａｓ要素は、ＪａｖａＳｃｒｉｐｔスクリプトによって、ウェブページに画像を描くことができる。ｃａｎｖａｓは、パス、矩形、円形、文字の描画方法及び画像の追加方法など、様々な方法を有する。
＜ａ＞タグ：＜ａ＞はＨＴＭＬタグである。＜ａ＞タグはハイパーリンクを定義し、あるページから別のページにリンクするために用いられる。
＜ｉｍｇ＞タグ：ＨＴＭＬで、＜ｉｍｇ＞タグは、ウェブページに画像を埋め込むために用いられる。＜ｉｍｇ＞タグで組み込まれる画像は、ウェブページに挿入されるのではなく、ウェブページにリンクされる。＜ｉｍｇ＞タグの機能は、参照される画像のプレースホルダーを作成することである。
本開示の実施例をさらに詳細に説明する前に、本開示の実施例に関する名詞と用語について説明する。本開示の実施例に関する名詞と用語は、下記のような解釈に適用される。
ｃａｎｖａｓ：ＨＴＭＬの中のｃａｎｖａｓ要素は、ＪａｖａＳｃｒｉｐｔスクリプトによって、ウェブページに画像を描くことができる。ｃａｎｖａｓは、パス、矩形、円形、文字の描画方法及び画像の追加方法など、様々な方法を有する。
＜ａ＞タグ：＜ａ＞はＨＴＭＬタグである。＜ａ＞タグはハイパーリンクを定義し、あるページから別のページにリンクするために用いられる。
＜ｉｍｇ＞タグ：ＨＴＭＬで、＜ｉｍｇ＞タグは、ウェブページに画像を埋め込むために用いられる。＜ｉｍｇ＞タグで組み込まれる画像は、ウェブページに挿入されるのではなく、ウェブページにリンクされる。＜ｉｍｇ＞タグの機能は、参照される画像のプレースホルダーを作成することである。
【0009】
ｂａｓｅ６４コーディング：ｂａｓｅ６４は、６４個の印刷可能な文字に基づいてバイナリデータを表す方法である。ｂａｓｅ６４は、３つの８ビットバイトごとに４つの６ビットバイトに変換し（３＊８＝４＊６＝２４）、変換された６ビットの上位ビットに２つの０を追加して４つの８ビットバイトを生成し、該４つの８ビットバイトの１０進数に基づいてインデックステーブルに対応する値を探すことを要求し、その結果は、Ｂａｓｅ６４値である。したがって、理論的に、ｂａｓｅ６４エンコードされた文字列の長さは、元の文字列より１／３長いである。
ドキュメント・オブジェクト・モデル（ＤＯＭ：Ｄｏｃｕｍｅｎｔ Ｏｂｊｅｃｔ Ｍｏｄｅｌ）：ＤＯＭは、ドキュメント全体に対するアクセスモデルを提供する。ドキュメントをツリー構造とし、ツリーのノードのそれぞれは、ＨＴＭＬタグ又はタグ内のテキスト項を表す。ＤＯＭツリーのノードのプロパティーは、ページの基本コンテンツと構造情報を表す。
プログレッシブ・ウェブ・アプリケーション（ＰＷＡ：Ｐｒｏｇｒｅｓｓｉｖｅ Ｗｅｂ Ａｐｐ）：モバイル端末で標準化されたフレームワークのｗｏｒｋｂｏｘ－ｓｗを利用して、一部のネイティブ機能をエミュレートし、ウェブページアプリケーションは、ネイティブアプリケーションと似たような体験を提供することができる。
バイナリラージオブジェクト（Ｂｌｏｂ：Ｂｉｎａｒｙ Ｌａｒｇｅ Ｏｂｊｅｃｔ）：Ｂｌｏｂは、ファイルオブジェクトと似たようなバイナリデータであり、ファイルオブジェクトと同じように操作されることができる。
ドキュメント・オブジェクト・モデル（ＤＯＭ：Ｄｏｃｕｍｅｎｔ Ｏｂｊｅｃｔ Ｍｏｄｅｌ）：ＤＯＭは、ドキュメント全体に対するアクセスモデルを提供する。ドキュメントをツリー構造とし、ツリーのノードのそれぞれは、ＨＴＭＬタグ又はタグ内のテキスト項を表す。ＤＯＭツリーのノードのプロパティーは、ページの基本コンテンツと構造情報を表す。
プログレッシブ・ウェブ・アプリケーション（ＰＷＡ：Ｐｒｏｇｒｅｓｓｉｖｅ Ｗｅｂ Ａｐｐ）：モバイル端末で標準化されたフレームワークのｗｏｒｋｂｏｘ－ｓｗを利用して、一部のネイティブ機能をエミュレートし、ウェブページアプリケーションは、ネイティブアプリケーションと似たような体験を提供することができる。
バイナリラージオブジェクト（Ｂｌｏｂ：Ｂｉｎａｒｙ Ｌａｒｇｅ Ｏｂｊｅｃｔ）：Ｂｌｏｂは、ファイルオブジェクトと似たようなバイナリデータであり、ファイルオブジェクトと同じように操作されることができる。
【0010】
現在、一般的に、ウェブアプリケーションの年間勘定書又はアンケートレポートなどのウェブプロモーションページ又はＨＴＭＬ ５アニメーションのフルスクリーンページは、複数の場面を含み、各場面は、複数のピクチャー要素を含み、端末機器にスライド操作によって閲覧する必要がある。ユーザが複数の場面を含むフルスクリーンページを閲覧しているときに、各場面のスクリーンショットを撮り、ピクチャーをローカルに保存したい場合、現在のスクリーンショット方式は、ｃａｎｖａｓ描画方法によって、選択された現在の場面のページのスクリーンショットを撮り、そのピクチャーをｂａｓｅ６４コーディングフォーマットに変換し、それからピクチャーの周りに＜ａ＞タグを巻き、ＪａｖａＳｃｒｉｐｔスクリプトを使用してクリックイベントをシミュレートし、ピクチャーをローカルに保存する。又は、＜ｉｍｇ＞タグによってブラウザのネイティブ方法を呼び起こし、ピクチャーをロングクリックするように提示することで、ピクチャーをローカルに保存する。しかしながら、ローカルのピクチャーが失われ、再び保存したい場合、ユーザは現在の閲覧しているページに移動し、上記の一連の操作を実行する必要がある。
【0011】
現在の方法において、ピクチャーをｂａｓｅ６４コーディングフォーマットに変換するプロセスにｃａｎｖａｓレンダリングが必要であり、ページが複雑になればなるほどｃａｎｖａｓレンダリングには時間がかかる。そして、ｂａｓｅ６４ピクチャーコーディングは、非常に長い文字列であり、エンコーディングのフルサイズは、ピクチャー自体のサイズを超えるが、ブラウザのｃｏｏｋｉｅ又はブラウザのローカルキャッシュは、あまり容量がない。上記から見ると、現在のブラウザのスクリーンショット保存方法は遅く、ブラウザキャッシュへの要求が厳しく、多くのブラウザ性能を消費する。したがって、実際のアプリケーションにおいて、現在のスクリーンショット方式は、キャッシュ容量の制限によりメモリ容量不足のエラーを起こすことが多く、同時に複数のピクチャーのスクリーンショットを保存することができず、一般的にモバイル端末のブラウザは、９枚以上のウェブページのスクリーンショットを同時にキャッシュで処理することができなくなる。そして、現在のスクリーンショット方式で取得したスクリーンショットが失われ、再びスクリーンショットを保存したい場合、ユーザは現在の閲覧しているページに移動し、上記の一連の操作を実行する必要があり、これによってブラウザの性能をさらに消費する。
【0012】
図１を参照すると、図１は、本開示の実施例によって提供される画像処理方法の一例示的なフローチャートであり、図１に示すステップを合わせて説明する。
ステップＳ１０１において、ウェブページアプリケーションにおいて、現在のフルスクリーンページの少なくとも１つのページ画像を取得する。
本開示の実施例によって提供される画像処理方法は、ウェブページアプリケーションにおいて、スクリーンショットを保存する場面に適用される。例示的に、端末におけるブラウザによって、フルスクリーンページの中の各場面にスクリーンショットを保存する場面、又はＨＴＭＬをサポートするアプリケーション又はクライアントによって、１つのリンクの中の複数のスクリーンで表示されるページのコンテンツのスクリーンショットを撮る場面などである。
ステップＳ１０１において、ユーザが、ブラウザなどのウェブページアプリケーションにおいて、複数の場面のフルスクリーンページを閲覧している場合、ページをスライドすることによって、フルスクリーンページの中の複数の場面を閲覧することができる。現在のフルスクリーンページをロードした後で、需要に基づいて、画像処理装置は、現在のフルスクリーンページに含まれる場面のスクリーンショットを撮り、撮られた少なくとも１つの画像を少なくとも１つのページ画像として使用することができる。
ステップＳ１０１において、ウェブページアプリケーションにおいて、現在のフルスクリーンページの少なくとも１つのページ画像を取得する。
本開示の実施例によって提供される画像処理方法は、ウェブページアプリケーションにおいて、スクリーンショットを保存する場面に適用される。例示的に、端末におけるブラウザによって、フルスクリーンページの中の各場面にスクリーンショットを保存する場面、又はＨＴＭＬをサポートするアプリケーション又はクライアントによって、１つのリンクの中の複数のスクリーンで表示されるページのコンテンツのスクリーンショットを撮る場面などである。
ステップＳ１０１において、ユーザが、ブラウザなどのウェブページアプリケーションにおいて、複数の場面のフルスクリーンページを閲覧している場合、ページをスライドすることによって、フルスクリーンページの中の複数の場面を閲覧することができる。現在のフルスクリーンページをロードした後で、需要に基づいて、画像処理装置は、現在のフルスクリーンページに含まれる場面のスクリーンショットを撮り、撮られた少なくとも１つの画像を少なくとも１つのページ画像として使用することができる。
【0013】
本開示の実施例において、画像処理装置が、ウェブページアプリケーションの現在のフルスクリーンページでスクリーンショット命令を受信した場合、スクリーンショット命令に応答して、スクリーンショット命令により指定される少なくとも１つのスクリーンショット待ち場面に対応する画像を少なくとも１つのページ画像として使用することができる。
本開示の実施例において、画像処理装置が、現在のフルスクリーンページのロードを完成した場合、現在のフルスクリーンページの中の各場面に対応する画像を取得し、少なくとも１つのページ画像として使用することができる。こうすると、画像処理装置は、ユーザはスクリーンショット命令を送信する前に、ユーザはスクリーンショット命令を送信した後の待ち時間を短縮するために、バックグラウンドで現在のフルスクリーンページの中の各場面のスクリーンショットを無感に撮る。
いくつかの実施例において、画像処理装置は、ブラウザのｃａｎｖａｓスクリーンショット方法によって、現在のフルスクリーンページの中のすべての場面又は一部の場面のスクリーンショットを撮り、これによって少なくとも１つのページ画像を取得することができる。具体的に、ｈｔｍｌ２ｃａｎｖａｓ（）方法を呼び出し、スクリーンショット待ちの各場面のスタイルとコンテンツ情報を読み出し、スクリーンショット待ちの各場面のスタイルとコンテンツ情報に基づいてレンダリングし、ピクチャー１枚を作成し、これによって少なくとも１つのページ画像を取得することができる。他のいくつかの実施例において、画像処理装置は、Ｆｌａｓｈｃａｎｖａｓ又はＥｘｐｌｏｒｅｒＣａｎｖａｓ方法によって、少なくとも１つのページ画像を取得することができる。具体的に、実際の状況に基づいて選択されるものであり、本開示の実施例はこれに限定されるものではない。
本開示の実施例において、画像処理装置が、現在のフルスクリーンページのロードを完成した場合、現在のフルスクリーンページの中の各場面に対応する画像を取得し、少なくとも１つのページ画像として使用することができる。こうすると、画像処理装置は、ユーザはスクリーンショット命令を送信する前に、ユーザはスクリーンショット命令を送信した後の待ち時間を短縮するために、バックグラウンドで現在のフルスクリーンページの中の各場面のスクリーンショットを無感に撮る。
いくつかの実施例において、画像処理装置は、ブラウザのｃａｎｖａｓスクリーンショット方法によって、現在のフルスクリーンページの中のすべての場面又は一部の場面のスクリーンショットを撮り、これによって少なくとも１つのページ画像を取得することができる。具体的に、ｈｔｍｌ２ｃａｎｖａｓ（）方法を呼び出し、スクリーンショット待ちの各場面のスタイルとコンテンツ情報を読み出し、スクリーンショット待ちの各場面のスタイルとコンテンツ情報に基づいてレンダリングし、ピクチャー１枚を作成し、これによって少なくとも１つのページ画像を取得することができる。他のいくつかの実施例において、画像処理装置は、Ｆｌａｓｈｃａｎｖａｓ又はＥｘｐｌｏｒｅｒＣａｎｖａｓ方法によって、少なくとも１つのページ画像を取得することができる。具体的に、実際の状況に基づいて選択されるものであり、本開示の実施例はこれに限定されるものではない。
【0014】
本開示の実施例において、一般的に、ｃａｎｖａｓスクリーンショット方法で、ｐｎｇフォーマットのピクチャーを取得し、実際の需要に基づいて他のフォーマットのピクチャーを作成することもできる。具体的に、実際の状況に基づいて選択されるものであり、本開示の実施例はこれに限定されるものではない。
説明すべきこととして、本開示の実施例において、少なくとも１つのページ画像は、現在のフルスクリーンページの中のフルスクリーンページコンテンツをすべてロードした後で取得される。したがって、少なくとも１つのページ画像は、すべてウェブページアプリケーションのローカルで作成された画像である。
ステップＳ１０２において、少なくとも１つのページ画像を少なくとも１つのファイルオブジェクトに変換し、少なくとも１つのファイルオブジェクトの少なくとも１つのリンクパスを作成する。少なくとも１つのファイルオブジェクトは少なくとも１つのリンクパスに1対1で対応する。
ステップＳ１０２において、画像処理装置は、少なくとも１つのページ画像を取得した後で、ピクチャーフォーマットの少なくとも１つのページ画像を少なくとも１つのファイルオブジェクトに変換することができ、ＨＴＭＬページでファイルオブジェクトを操作することによって、少なくとも１つのページ画像へのアクセスとコンテンツの読み出しを実現する。
説明すべきこととして、本開示の実施例において、少なくとも１つのページ画像は、現在のフルスクリーンページの中のフルスクリーンページコンテンツをすべてロードした後で取得される。したがって、少なくとも１つのページ画像は、すべてウェブページアプリケーションのローカルで作成された画像である。
ステップＳ１０２において、少なくとも１つのページ画像を少なくとも１つのファイルオブジェクトに変換し、少なくとも１つのファイルオブジェクトの少なくとも１つのリンクパスを作成する。少なくとも１つのファイルオブジェクトは少なくとも１つのリンクパスに1対1で対応する。
ステップＳ１０２において、画像処理装置は、少なくとも１つのページ画像を取得した後で、ピクチャーフォーマットの少なくとも１つのページ画像を少なくとも１つのファイルオブジェクトに変換することができ、ＨＴＭＬページでファイルオブジェクトを操作することによって、少なくとも１つのページ画像へのアクセスとコンテンツの読み出しを実現する。
【0015】
いくつかの実施例において、画像処理装置は、ｃａｎｖａｓ．ｔｏＢｌｏｂ（）方法によって、少なくとも１つのページ画像を少なくとも１つのｂｌｏｂオブジェクトに変換し、少なくとも１つのｂｌｏｂオブジェクトを少なくとも１つのファイルオブジェクトとして使用することができる。他のいくつかの実施例において、画像処理装置は、他の方法によって、少なくとも１つのページ画像を他のファイルタイプのウェブページオブジェクトに変換することができる。具体的に、実際の状況に基づいて選択されるものであり、本開示の実施例はこれに限定されるものではない。
ステップＳ１０２において、画像処理装置は、少なくとも１つのページ画像を少なくとも１つのファイルオブジェクトに変換した後で、ファイルオブジェクトのそれぞれに１つのリンクパスを作成する。
いくつかの実施例において、少なくとも１つのファイルオブジェクトが、少なくとも１つのｂｌｏｂオブジェクトである場合、画像処理装置は、ＵＲＬ．ｃｒｅａｔｅＯｂｊｅｃｔＵＲＬ（）方法によって、ｂｌｏｂオブジェクトのそれぞれにユニフォーム・リソース・ロケータ（ＵＲＬ：Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）を作成し、ｂｌｏｂオブジェクトのそれぞれに対応するリンクパスとすることができ、これによって少なくとも１つのリンクパスを取得する。
ステップＳ１０２において、画像処理装置は、少なくとも１つのページ画像を少なくとも１つのファイルオブジェクトに変換した後で、ファイルオブジェクトのそれぞれに１つのリンクパスを作成する。
いくつかの実施例において、少なくとも１つのファイルオブジェクトが、少なくとも１つのｂｌｏｂオブジェクトである場合、画像処理装置は、ＵＲＬ．ｃｒｅａｔｅＯｂｊｅｃｔＵＲＬ（）方法によって、ｂｌｏｂオブジェクトのそれぞれにユニフォーム・リソース・ロケータ（ＵＲＬ：Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）を作成し、ｂｌｏｂオブジェクトのそれぞれに対応するリンクパスとすることができ、これによって少なくとも１つのリンクパスを取得する。
【0016】
本開示の実施例において、少なくとも１つのリンクパスの中の各リンクパスは、対応するファイルオブジェクトを指す。したがって、画像処理装置は、少なくとも１つのリンクパスによって、少なくとも１つのファイルオブジェクトをピクチャーオブジェクトなどの他のタイプのウェブページオブジェクトと関連付けることができ、リンクパスを指定することによって、他のタイプのウェブページオブジェクトは、少なくとも１つのファイルオブジェクトの中のデータを元データとして引用できるようにし、これによって、他のタイプのウェブページオブジェクトへの操作によって、少なくとも１つのファイルオブジェクトに対して多様な処理方法を取得する。
ステップＳ１０３において、少なくとも１つのピクチャーオブジェクトを作成し、少なくとも１つのピクチャーオブジェクトを少なくとも１つのリンクパスと関連付けてウェブページアプリケーションキャッシュに保存し、これによって現在のフルスクリーンページのスクリーンショットを完成する。
ステップＳ１０３において、少なくとも１つのピクチャーオブジェクトを作成し、少なくとも１つのピクチャーオブジェクトを少なくとも１つのリンクパスと関連付けてウェブページアプリケーションキャッシュに保存し、これによって現在のフルスクリーンページのスクリーンショットを完成する。
【0017】
ステップＳ１０３において、画像処理装置は、ウェブページアプリケーションのローカルキャッシュで少なくとも１つのピクチャータイプのオブジェクト、即ち、少なくとも１つのピクチャーオブジェクトを作成し、少なくとも１つのリンクパスは、少なくとも１つのピクチャーオブジェクトを指すようにし、これによって少なくとも１つのリンクパスを少なくとも１つのピクチャーオブジェクトと関連付ける。画像処理装置は、少なくとも１つのリンクパスと少なくとも１つのピクチャーオブジェクトとともにウェブページアプリケーションキャッシュに保存し、これによって現在のフルスクリーンページのスクリーンショットを完成する。
いくつかの実施例において、画像処理装置は、ｎｅｗ Ｉｍａｇｅ（）方法によって、少なくとも１つのピクチャーオブジェクトを作成することができる。ｎｅｗ Ｉｍａｇｅ（）で作成されたピクチャーオブジェクトに対して、画像処理装置は、該ピクチャーオブジェクトのｓｒｃプロパティーにリンクパスで値を付け、こうすると、該ピクチャーオブジェクトがロードされた場合、対応するリンクパスによって、該リンクパスに対応するファイルオブジェクトにアクセスすることができ、ファイルオブジェクトの中のコンテンツを該ピクチャーオブジェクトでロードするピクチャーのコンテンツデータとし、これによってピクチャーオブジェクト、リンクパス及びファイルオブジェクトの相互関連することを実現する。
いくつかの実施例において、画像処理装置は、ｎｅｗ Ｉｍａｇｅ（）方法によって、少なくとも１つのピクチャーオブジェクトを作成することができる。ｎｅｗ Ｉｍａｇｅ（）で作成されたピクチャーオブジェクトに対して、画像処理装置は、該ピクチャーオブジェクトのｓｒｃプロパティーにリンクパスで値を付け、こうすると、該ピクチャーオブジェクトがロードされた場合、対応するリンクパスによって、該リンクパスに対応するファイルオブジェクトにアクセスすることができ、ファイルオブジェクトの中のコンテンツを該ピクチャーオブジェクトでロードするピクチャーのコンテンツデータとし、これによってピクチャーオブジェクト、リンクパス及びファイルオブジェクトの相互関連することを実現する。
【0018】
ステップＳ１０３において、スクリーンショットを撮る処理の速度をさらに向上させるために、画像処理装置は、少なくとも１つのリンクパスをウェブページアプリケーションのｃｏｏｋｉｅに記憶することができる。これによって、画像処理装置は現在のフルスクリーンページのスクリーンショットを撮る前に、ウェブページアプリケーションのｃｏｏｋｉｅにスクリーンショットを撮りたい少なくとも１つのリンクパスが存在するか否かをチェックすることによって、且つ、少なくとも１つのリンクパスによって、直接にヒストリーキャッシュされた少なくとも１つのピクチャーオブジェクトを取得することができ、同じページの再びスクリーンショットの処理の必要がない。
理解可能なこととして、本開示の実施例において、画像処理装置は、少なくとも１つのページ画像を取得した後で、少なくとも１つのページ画像を少なくとも１つのファイルオブジェクトに変換し、少なくとも１つのファイルオブジェクトのリンクパスを少なくとも１つのピクチャーオブジェクトと関連付けてキャッシュに保存することができ、これによってスクリーンショットを他のコーディングフォーマットに変換することによりキャッシュ占有率が大きいという技術的問題を克服する。そして、現在のフルスクリーンページの少なくとも１つのピクチャーオブジェクトは、キャッシュに保存されるため、ユーザが現在のフルスクリーンページに再び入ってスクリーンショットを撮りたい場合、画像処理装置は、直接にキャッシュから少なくとも１つのピクチャーオブジェクトを取得し、対応するページのスクリーンショットとすることができ、再びスクリーンショットを撮る必要がなく、ブラウザ処理の作業負荷を軽減し、最終的にウェブページアプリケーションのスクリーンショットの性能を向上させる。
理解可能なこととして、本開示の実施例において、画像処理装置は、少なくとも１つのページ画像を取得した後で、少なくとも１つのページ画像を少なくとも１つのファイルオブジェクトに変換し、少なくとも１つのファイルオブジェクトのリンクパスを少なくとも１つのピクチャーオブジェクトと関連付けてキャッシュに保存することができ、これによってスクリーンショットを他のコーディングフォーマットに変換することによりキャッシュ占有率が大きいという技術的問題を克服する。そして、現在のフルスクリーンページの少なくとも１つのピクチャーオブジェクトは、キャッシュに保存されるため、ユーザが現在のフルスクリーンページに再び入ってスクリーンショットを撮りたい場合、画像処理装置は、直接にキャッシュから少なくとも１つのピクチャーオブジェクトを取得し、対応するページのスクリーンショットとすることができ、再びスクリーンショットを撮る必要がなく、ブラウザ処理の作業負荷を軽減し、最終的にウェブページアプリケーションのスクリーンショットの性能を向上させる。
【0019】
図２を参照すると、図２は、本開示の実施例によって提供される画像処理方法の一例示的なフローチャートであり、図１を基づいて、図１に示すステップＳ１０１はステップＳ１０１１－Ｓ１０１４によって実現することができる。各ステップを合わせて説明する。
ステップＳ１０１１において、現在のフルスクリーンページから少なくとも１つの場面を分割し、少なくとも１つの場面に対して少なくとも１つのノード識別子を設定する。少なくとも１つのノード識別子は、少なくとも１つの場面に現在のフルスクリーンページに対応する少なくとも１つのデータ位置を表し、少なくとも１つの場面は少なくとも１つのノード識別子に1対1で対応する。
ステップＳ１０１１において、ロード完成された現在のフルスクリーンページに対して、画像処理装置は、ページに示されるスタイル又はコンテンツに基づいて、少なくとも１つの場面を分割することができ、後で少なくとも１つの場面からスクリーンショットを撮りたい場面を指定するためである。相応的に、画像処理装置は、少なくとも１つの場面に対して少なくとも１つのノード識別子を設定し、少なくとも１つの場面は少なくとも１つのノード識別子に1対1で対応する。
ステップＳ１０１１において、現在のフルスクリーンページから少なくとも１つの場面を分割し、少なくとも１つの場面に対して少なくとも１つのノード識別子を設定する。少なくとも１つのノード識別子は、少なくとも１つの場面に現在のフルスクリーンページに対応する少なくとも１つのデータ位置を表し、少なくとも１つの場面は少なくとも１つのノード識別子に1対1で対応する。
ステップＳ１０１１において、ロード完成された現在のフルスクリーンページに対して、画像処理装置は、ページに示されるスタイル又はコンテンツに基づいて、少なくとも１つの場面を分割することができ、後で少なくとも１つの場面からスクリーンショットを撮りたい場面を指定するためである。相応的に、画像処理装置は、少なくとも１つの場面に対して少なくとも１つのノード識別子を設定し、少なくとも１つの場面は少なくとも１つのノード識別子に1対1で対応する。
【0020】
本開示の実施例において、少なくとも１つの場面は、現在のフルスクリーンページに含まれるページ場面であり、例えば、現在のフルスクリーンページに含まれる異なる場所における画像やテキスト、又は現在のフルスクリーンページに含まれる各スクリーンページなどである。
本開示の実施例において、少なくとも１つのノード識別子は、少なくとも１つの場面に現在のフルスクリーンページに対応する少なくとも１つのデータ位置を表す。即ち、ノード識別子は、現在のフルスクリーンページに対応する全体コンテンツデータに、その対応するウェブページオブジェクトのコンテンツデータの保存場所である。例示的に、現在のフルスクリーンページに対応する全体コンテンツデータは、ＨＴＭＬテキストであることができ、ブラウザが、ＨＴＭＬテキストを解析する場合、ＨＴＭＬテキストの中の各ウェブページオブジェクトの関連関係に基づいてＤＯＭツリーを構築する。ここで、少なくとも１つのノード識別子は、現在のフルスクリーンページのＤＯＭツリーの中のドキュメントノードであることができ、ＤＯＭノードのそれぞれに、ウェブページオブジェクトのそれぞれに対応するコンテンツデータは保存され、ＤＯＭツリーで、ＤＯＭノードのそれぞれは、他のＤＯＭノードと相互関連する。
本開示の実施例において、少なくとも１つのノード識別子は、少なくとも１つの場面に現在のフルスクリーンページに対応する少なくとも１つのデータ位置を表す。即ち、ノード識別子は、現在のフルスクリーンページに対応する全体コンテンツデータに、その対応するウェブページオブジェクトのコンテンツデータの保存場所である。例示的に、現在のフルスクリーンページに対応する全体コンテンツデータは、ＨＴＭＬテキストであることができ、ブラウザが、ＨＴＭＬテキストを解析する場合、ＨＴＭＬテキストの中の各ウェブページオブジェクトの関連関係に基づいてＤＯＭツリーを構築する。ここで、少なくとも１つのノード識別子は、現在のフルスクリーンページのＤＯＭツリーの中のドキュメントノードであることができ、ＤＯＭノードのそれぞれに、ウェブページオブジェクトのそれぞれに対応するコンテンツデータは保存され、ＤＯＭツリーで、ＤＯＭノードのそれぞれは、他のＤＯＭノードと相互関連する。
【0021】
いくつかの実施例において、画像処理装置は、現在のフルスクリーンページで、ＤＯＭスタイルを１画面に表示するように設定することができ、即ち、フルスクリーンページの中の各スクリーンページを１つの場面とする。画像処理装置は、画面のそれぞれに異なるＤＯＭ ＩＤを設置し、少なくとも１つのノード識別子とする。
ステップＳ１０１２において、現在のフルスクリーンページで、少なくとも１つのスクリーンショット待ち場面に対応する少なくとも１つの目標ノード識別子を取得する。少なくとも１つのスクリーンショット待ち場面は、少なくとも１つの場面の中の目標スクリーンショット場面である。
ステップＳ１０１２において、現在のフルスクリーンページで、画像処理装置は、スクリーンショット命令に基づいて少なくとも１つのスクリーンショット待ち場面を決定し、又は、黙認として現在のフルスクリーンページの中のすべての場面を少なくとも１つのスクリーンショット待ち場面とし、少なくとも１つのスクリーンショット待ち場面に対応する少なくとも１つの目標ノード識別子を取得する。
ステップＳ１０１２において、現在のフルスクリーンページで、少なくとも１つのスクリーンショット待ち場面に対応する少なくとも１つの目標ノード識別子を取得する。少なくとも１つのスクリーンショット待ち場面は、少なくとも１つの場面の中の目標スクリーンショット場面である。
ステップＳ１０１２において、現在のフルスクリーンページで、画像処理装置は、スクリーンショット命令に基づいて少なくとも１つのスクリーンショット待ち場面を決定し、又は、黙認として現在のフルスクリーンページの中のすべての場面を少なくとも１つのスクリーンショット待ち場面とし、少なくとも１つのスクリーンショット待ち場面に対応する少なくとも１つの目標ノード識別子を取得する。
【0022】
ステップＳ１０１３において、少なくとも１つの目標ノード識別子の中の各目標ノード識別子に基づいて、現在のフルスクリーンページのコンテンツデータから各目標ノード識別子に対応するコンテンツデータを読み出し、これによって少なくとも１つの目標ページデータを取得する。
本開示の実施例において、少なくとも１つのノード識別子の中のノード識別子のそれぞれに対して、画像処理装置は、ノード識別子のそれぞれに基づいて、現在のフルスクリーンページの全体コンテンツデータに、該ノード識別子が代表するウェブページオブジェクトに対応するコンテンツデータの保存場所を決定する。ノード識別子のそれぞれに対応するデータの保存場所に基づいて、対応するウェブページオブジェクトのそれぞれのコンテンツデータを読み出し、これによって少なくとも１つの目標ページデータを取得する。
ステップＳ１０１４において、ウェブページレンダリング機能によって、少なくとも１つの目標ページデータに基づいて、少なくとも１つのページ画像を作成する。
本開示の実施例において、画像処理装置は、少なくとも１つの目標ページデータを読み出した後で、ｃａｎｖａｓ描画方法などのウェブページレンダリング機能によって、少なくとも１つの目標ページデータに基づいて、少なくとも１つのページ画像を作成する。
理解可能なこととして、本開示の実施例において、異なるスタイルのノード識別子をプリセットすることによって、現在のフルスクリーンページに異なる形態のスクリーンショットの処理を行うことができ、これによってページのスクリーンショットを撮るプロセスの柔軟性を高める。
本開示の実施例において、少なくとも１つのノード識別子の中のノード識別子のそれぞれに対して、画像処理装置は、ノード識別子のそれぞれに基づいて、現在のフルスクリーンページの全体コンテンツデータに、該ノード識別子が代表するウェブページオブジェクトに対応するコンテンツデータの保存場所を決定する。ノード識別子のそれぞれに対応するデータの保存場所に基づいて、対応するウェブページオブジェクトのそれぞれのコンテンツデータを読み出し、これによって少なくとも１つの目標ページデータを取得する。
ステップＳ１０１４において、ウェブページレンダリング機能によって、少なくとも１つの目標ページデータに基づいて、少なくとも１つのページ画像を作成する。
本開示の実施例において、画像処理装置は、少なくとも１つの目標ページデータを読み出した後で、ｃａｎｖａｓ描画方法などのウェブページレンダリング機能によって、少なくとも１つの目標ページデータに基づいて、少なくとも１つのページ画像を作成する。
理解可能なこととして、本開示の実施例において、異なるスタイルのノード識別子をプリセットすることによって、現在のフルスクリーンページに異なる形態のスクリーンショットの処理を行うことができ、これによってページのスクリーンショットを撮るプロセスの柔軟性を高める。
【0023】
本開示の実施例において、図３を参照すると、図３は、本開示の実施例によって提供される画像処理方法の一例示的なフローチャートであり、図１に示すステップＳ１０２はステップＳ１０２１－Ｓ１０２２によって実現することができる。各ステップを合わせて説明する。
ステップＳ１０２１において、少なくとも１つのページ画像を少なくとも１つのバイナリラージオブジェクトに変換し、前記少なくとも１つのファイルオブジェクトとして使用する。
ステップＳ１０２１において、画像処理装置は、少なくとも１つのページ画像を取得した後で、ウェブページ描画方法の中のピクチャーからバイナリラージオブジェクトへの変換方法を呼び出し、少なくとも１つのページ画像から少なくとも１つのバイナリラージオブジェクトに変換することを実現し、少なくとも１つのファイルオブジェクトとして使用することができる。
いくつかの実施例において、画像処理装置は、ｃａｎｖａｓ．ｔｏＢｌｏｂ（）方法によって、少なくとも１つのページ画像にフォーマット変換を実行し、少なくとも１つのｂｌｏｂオブジェクトに変換し、前記少なくとも１つのファイルオブジェクトとして使用する。
ステップＳ１０２１において、現在のスクリーンショット方式と比べると、画像処理装置は、ｃａｎｖａｓ．ｔｏＤａｔａＵＲＬ方法ではなくｃａｎｖａｓ．ｔｏＢｌｏｂ（）を使用してページ画像を変換するのは、ｃａｎｖａｓ．ｔｏＤａｔａＵＲＬで変換されたページ画像はｂａｓｅ６４コーディングフォーマットであり、データサイズは元ピクチャーのデータサイズより大きく、ウェブページアプリケーションキャッシュ占有率が大きく、スクリーンショットの撮るエラーを起こすからである。
ステップＳ１０２２において、少なくとも１つのバイナリラージオブジェクトの中の各バイナリラージオブジェクトに対して、ウェブページアプリケーションスクリプトの中のオブジェクト位置パス作成方法を呼び出し、各バイナリラージオブジェクトのリソースアドレスをリンクパスとして作成し、これによって少なくとも１つのリンクパスを取得する。
ステップＳ１０２１において、少なくとも１つのページ画像を少なくとも１つのバイナリラージオブジェクトに変換し、前記少なくとも１つのファイルオブジェクトとして使用する。
ステップＳ１０２１において、画像処理装置は、少なくとも１つのページ画像を取得した後で、ウェブページ描画方法の中のピクチャーからバイナリラージオブジェクトへの変換方法を呼び出し、少なくとも１つのページ画像から少なくとも１つのバイナリラージオブジェクトに変換することを実現し、少なくとも１つのファイルオブジェクトとして使用することができる。
いくつかの実施例において、画像処理装置は、ｃａｎｖａｓ．ｔｏＢｌｏｂ（）方法によって、少なくとも１つのページ画像にフォーマット変換を実行し、少なくとも１つのｂｌｏｂオブジェクトに変換し、前記少なくとも１つのファイルオブジェクトとして使用する。
ステップＳ１０２１において、現在のスクリーンショット方式と比べると、画像処理装置は、ｃａｎｖａｓ．ｔｏＤａｔａＵＲＬ方法ではなくｃａｎｖａｓ．ｔｏＢｌｏｂ（）を使用してページ画像を変換するのは、ｃａｎｖａｓ．ｔｏＤａｔａＵＲＬで変換されたページ画像はｂａｓｅ６４コーディングフォーマットであり、データサイズは元ピクチャーのデータサイズより大きく、ウェブページアプリケーションキャッシュ占有率が大きく、スクリーンショットの撮るエラーを起こすからである。
ステップＳ１０２２において、少なくとも１つのバイナリラージオブジェクトの中の各バイナリラージオブジェクトに対して、ウェブページアプリケーションスクリプトの中のオブジェクト位置パス作成方法を呼び出し、各バイナリラージオブジェクトのリソースアドレスをリンクパスとして作成し、これによって少なくとも１つのリンクパスを取得する。
【0024】
ステップＳ１０２２において、画像処理装置は、少なくとも１つのページ画像を少なくとも１つのｂｌｏｂオブジェクトに変換した後で、ｂｌｏｂオブジェクトのそれぞれに対して、ＵＲＬ．ｃｒｅａｔｅＯｂｊｅｃｔＵＲＬ（）方法を呼び出し、ｂｌｏｂオブジェクトのそれぞれに対応するＵＲＬアドレスを該ｂｌｏｂオブジェクトのリンクパスとして作成し、これによって少なくとも１つのリンクパスを取得する。
本開示の実施例において、ＵＲＬ．ｃｒｅａｔｅＯｂｊｅｃｔＵＲＬ（）方法を呼び出すと、対応するｂｌｏｂオブジェクトを指定するためのｈａｓｈ付けるｕｒｌ文字列を返す。
理解可能なこととして、本開示の実施例において、画像処理装置は、ｃａｎｖａｓ．ｔｏＢｌｏｂ（）とＵＲＬ．ｃｒｅａｔｅＯｂｊｅｃｔＵＲＬ（）方法によって、少なくとも１つのページ画像をｂｌｏｂオブジェクト及び対応するパスに変換する。変換されたピクチャーとパスのデータサイズが小さく、ウェブページアプリケーションキャッシュ占有率が小さく、メモリ不足などのエラーを起こさなく、これによってウェブページアプリケーションのスクリーンショットの性能を向上させる。
本開示の実施例において、図４を参照すると、図４は、本開示の実施例によって提供される画像処理方法の一例示的なフローチャートであり、図１に示すステップＳ１０３はＳ１０３１－Ｓ１０３３によって実現することができる。各ステップを合わせて説明する。
ステップＳ１０３１において、ウェブページアプリケーションスクリプトの中のピクチャーオブジェクト作成方法を呼び出し、少なくとも１つのピクチャーオブジェクトを作成する。
ステップＳ１０３１において、画像処理装置は、ｎｅｗ ｉｍａｇｅ（）方法などのウェブページアプリケーションスクリプトの中のピクチャーオブジェクト作成方法を呼び出し、ウェブページアプリケーションキャッシュに少なくとも１つのピクチャーオブジェクトを作成する。
本開示の実施例において、ＵＲＬ．ｃｒｅａｔｅＯｂｊｅｃｔＵＲＬ（）方法を呼び出すと、対応するｂｌｏｂオブジェクトを指定するためのｈａｓｈ付けるｕｒｌ文字列を返す。
理解可能なこととして、本開示の実施例において、画像処理装置は、ｃａｎｖａｓ．ｔｏＢｌｏｂ（）とＵＲＬ．ｃｒｅａｔｅＯｂｊｅｃｔＵＲＬ（）方法によって、少なくとも１つのページ画像をｂｌｏｂオブジェクト及び対応するパスに変換する。変換されたピクチャーとパスのデータサイズが小さく、ウェブページアプリケーションキャッシュ占有率が小さく、メモリ不足などのエラーを起こさなく、これによってウェブページアプリケーションのスクリーンショットの性能を向上させる。
本開示の実施例において、図４を参照すると、図４は、本開示の実施例によって提供される画像処理方法の一例示的なフローチャートであり、図１に示すステップＳ１０３はＳ１０３１－Ｓ１０３３によって実現することができる。各ステップを合わせて説明する。
ステップＳ１０３１において、ウェブページアプリケーションスクリプトの中のピクチャーオブジェクト作成方法を呼び出し、少なくとも１つのピクチャーオブジェクトを作成する。
ステップＳ１０３１において、画像処理装置は、ｎｅｗ ｉｍａｇｅ（）方法などのウェブページアプリケーションスクリプトの中のピクチャーオブジェクト作成方法を呼び出し、ウェブページアプリケーションキャッシュに少なくとも１つのピクチャーオブジェクトを作成する。
【0025】
本開示の実施例において、ｎｅｗ ｉｍａｇｅ（）方法で作成されたピクチャーオブジェクトは、ピクチャー名称とｓｒｃプロパティーなどの情報を含む。ここで、ｓｒｃプロパティーは、必要であり、ｓｒｃプロパティーの値は、該ピクチャーオブジェクトのＵＲＬであり、即ち、該ピクチャーオブジェクトを引用するファイルの絶対パス又は相対パスである。
いくつかの実施例において、画像処理装置は、ウェブページアプリケーションがサポートする他の方法によって、少なくとも１つのピクチャーオブジェクトを作成することができる。具体的に、実際の状況に基づいて選択されるものであり、本開示の実施例はこれに限定されるものではない。
ステップＳ１０３２において、各ピクチャーオブジェクトに対して、少なくとも１つのリンクパスの中の各リンクパスを各ピクチャーオブジェクトの画像ソースパスとして使用し、少なくとも１つのピクチャーオブジェクトをウェブページアプリケーションキャッシュに保存する。画像ソースパスは、各ピクチャーオブジェクトがロードされるときに、コンテンツデータが取得されるパスである。
ステップＳ１０３２において、画像処理装置は、少なくとも１つのピクチャーオブジェクトを作成した後で、各ピクチャーオブジェクトに対して、画像処理装置は、対応するリンクパスを該ピクチャーオブジェクトの画像ソースパスとし、即ち、各ピクチャーオブジェクトがウェブページにロードされるときに、コンテンツデータが取得されるパスである。これによって少なくとも１つのファイルオブジェクトを少なくとも１つのピクチャーオブジェクトのコンテンツデータとすることが実現し、両方の関連を実現する。
いくつかの実施例において、画像処理装置は、ウェブページアプリケーションがサポートする他の方法によって、少なくとも１つのピクチャーオブジェクトを作成することができる。具体的に、実際の状況に基づいて選択されるものであり、本開示の実施例はこれに限定されるものではない。
ステップＳ１０３２において、各ピクチャーオブジェクトに対して、少なくとも１つのリンクパスの中の各リンクパスを各ピクチャーオブジェクトの画像ソースパスとして使用し、少なくとも１つのピクチャーオブジェクトをウェブページアプリケーションキャッシュに保存する。画像ソースパスは、各ピクチャーオブジェクトがロードされるときに、コンテンツデータが取得されるパスである。
ステップＳ１０３２において、画像処理装置は、少なくとも１つのピクチャーオブジェクトを作成した後で、各ピクチャーオブジェクトに対して、画像処理装置は、対応するリンクパスを該ピクチャーオブジェクトの画像ソースパスとし、即ち、各ピクチャーオブジェクトがウェブページにロードされるときに、コンテンツデータが取得されるパスである。これによって少なくとも１つのファイルオブジェクトを少なくとも１つのピクチャーオブジェクトのコンテンツデータとすることが実現し、両方の関連を実現する。
【0026】
ステップＳ１０３２において、画像処理装置は、値を付けることによって、リンクパスのそれぞれを各ピクチャーオブジェクトの画像ソースパスとすることができる。
ステップＳ１０３２において、画像処理装置は、少なくとも１つのピクチャーオブジェクトをウェブページアプリケーションキャッシュに保存し、次回のアクセスのときにウェブページアプリケーションのローカルキャッシュから対応するピクチャーオブジェクトを開くことができるためである。
ステップＳ１０３３において、セッションデータによって、少なくとも１つのピクチャーオブジェクトを少なくとも１つのリンクパスと関連付けて保存することを実現できるように、少なくとも１つのピクチャーオブジェクトのピクチャー名称と画像ソースパスをウェブページアプリケーションキャッシュのセッションデータに保存し、これによって現在のフルスクリーンページのスクリーンショットを完成する。
ステップＳ１０３２において、画像処理装置は、少なくとも１つのピクチャーオブジェクトをウェブページアプリケーションキャッシュに保存し、次回のアクセスのときにウェブページアプリケーションのローカルキャッシュから対応するピクチャーオブジェクトを開くことができるためである。
ステップＳ１０３３において、セッションデータによって、少なくとも１つのピクチャーオブジェクトを少なくとも１つのリンクパスと関連付けて保存することを実現できるように、少なくとも１つのピクチャーオブジェクトのピクチャー名称と画像ソースパスをウェブページアプリケーションキャッシュのセッションデータに保存し、これによって現在のフルスクリーンページのスクリーンショットを完成する。
【0027】
ステップＳ１０３３において、画像処理装置は、セッションデータ設置方法を呼び出し、少なくとも１つのピクチャーオブジェクトのピクチャー名称と画像ソースパスをｃｏｏｋｉｅなどのウェブページアプリケーションキャッシュのセッションデータに保存することを実現することができる。これによって、セッションデータから少なくとも１つのリンクパスを取得することを実現し、さらにそれに関連する少なくとも１つのピクチャーオブジェクトを取得し、これによって現在のフルスクリーンページのスクリーンショットを撮ること及びキャッシュに保存することを完成する。
いくつかの実施例において、画像処理装置は、ｓｅｔＣｏｏｋｉｅ（）方法を呼び出すことによって、少なくとも１つのピクチャーオブジェクトのピクチャー名称、ＵＲＬ及び有効時間をｃｏｏｋｉｅに保存することができる。対応するコードは下記のように実現することをできる。
canvas.toBlob(function(blobObj){
let imgs = new Image();//ピクチャーオブジェクトを作成する
let src = window.URL.createObjectURL(blobObj);//blobオブジェクトのリンクパスを作成する
imgs.src = src; //リンクパスを使用してピクチャーオブジェクトの画像ソースパスに値を付ける
screenShotCut[ary[i].component] = src;
//リンクパスをcookieに保存する
setCookie(‘imgSrc’,JSON.stringify(screenShotCut))
})
いくつかの実施例において、下記のコードによって、上記のｓｅｔＣｏｏｋｉｅ（）方法を実現することができる。
setCookie(name,value,iMinutes){
var oDate = new Date();
oDate.setMinutes(oDate.getMinutes()+iMinutes);
document.cookie = name+’=’+encodeURIComponent(value)
+’;expires=’+oDate;
},
いくつかの実施例において、画像処理装置は、ｓｅｔＣｏｏｋｉｅ（）方法を呼び出すことによって、少なくとも１つのピクチャーオブジェクトのピクチャー名称、ＵＲＬ及び有効時間をｃｏｏｋｉｅに保存することができる。対応するコードは下記のように実現することをできる。
canvas.toBlob(function(blobObj){
let imgs = new Image();//ピクチャーオブジェクトを作成する
let src = window.URL.createObjectURL(blobObj);//blobオブジェクトのリンクパスを作成する
imgs.src = src; //リンクパスを使用してピクチャーオブジェクトの画像ソースパスに値を付ける
screenShotCut[ary[i].component] = src;
//リンクパスをcookieに保存する
setCookie(‘imgSrc’,JSON.stringify(screenShotCut))
})
いくつかの実施例において、下記のコードによって、上記のｓｅｔＣｏｏｋｉｅ（）方法を実現することができる。
setCookie(name,value,iMinutes){
var oDate = new Date();
oDate.setMinutes(oDate.getMinutes()+iMinutes);
document.cookie = name+’=’+encodeURIComponent(value)
+’;expires=’+oDate;
},
【0028】
理解可能なこととして、本開示の実施例において、画像処理装置は、少なくとも１つのファイルオブジェクトのリンクパスを少なくとも１つのピクチャーオブジェクトと関連付けてキャッシュに保存し、ウェブページアプリケーションキャッシュのセッションデータに少なくとも１つのリンクパスを保存した後で、ユーザが現在のフルスクリーンページに再び入った場合、画像処理装置は、直接にキャッシュから少なくとも１つのピクチャーオブジェクトを取得し、対応するページのスクリーンショットとすることができ、再びスクリーンショットを撮る必要がなく、ブラウザ処理の作業負荷を軽減し、最終的にウェブページアプリケーションのスクリーンショットの性能を向上させる。
本開示の実施例において、図５を参照すると、図５は、本開示の実施例によって提供される画像処理方法の一例示的なフローチャートであり、図１に示すステップＳ１０１はＳ００２－Ｓ００３によって実現することができる。各ステップを合わせて説明する。
ステップＳ００２において、ウェブページアプリケーションキャッシュのセッションデータに、現在のフルスクリーンページに対応する少なくとも１つのピクチャーオブジェクトが存在するか否かをチェックする。
ステップＳ００２において、画像処理装置は、少なくとも１つのページ画像を取得する前に、ウェブページアプリケーションキャッシュのセッションデータをチェックし、セッションデータに現在のフルスクリーンページに対応する少なくとも１つのピクチャーオブジェクトが存在するか否かを決定する。
本開示の実施例において、図５を参照すると、図５は、本開示の実施例によって提供される画像処理方法の一例示的なフローチャートであり、図１に示すステップＳ１０１はＳ００２－Ｓ００３によって実現することができる。各ステップを合わせて説明する。
ステップＳ００２において、ウェブページアプリケーションキャッシュのセッションデータに、現在のフルスクリーンページに対応する少なくとも１つのピクチャーオブジェクトが存在するか否かをチェックする。
ステップＳ００２において、画像処理装置は、少なくとも１つのページ画像を取得する前に、ウェブページアプリケーションキャッシュのセッションデータをチェックし、セッションデータに現在のフルスクリーンページに対応する少なくとも１つのピクチャーオブジェクトが存在するか否かを決定する。
【0029】
本開示の実施例において、画像処理装置は、ウェブページアプリケーションキャッシュのセッションデータに、現在のフルスクリーンページに対応する少なくとも１つのピクチャーオブジェクトが存在するか否かをチェックするプロセスは、下記のように実現することができる。
ステップＳ００２１において、少なくとも１つのピクチャーオブジェクトのピクチャー名称に基づいて、セッションデータ取得方法を呼び出し、セッションデータから少なくとも１つのピクチャーオブジェクトを抽出することを実行する。
いくつかの実施例において、ユーザが、ウェブページアプリケーションによって、現在のフルスクリーンページをアクセスする場合、画像処理装置は、ｃａｎｖａｓスクリーンショット方式を呼び出して少なくとも１つのページ画像を取得する前に、ｇｅｔＣｏｏｋｉｅ（）方法を呼び出し、ウェブページアプリケーションのｃｏｏｋｉｅデータを取得し、ｎｅｗＩｍｇ．ｌｏａｄ方法によって、ｃｏｏｋｉｅデータに少なくとも１つのピクチャーオブジェクトは既に存在するか否かをチェックすることができる。
いくつかの実施例において、画像処理装置は、ウェブページアプリケーションキャッシュに、少なくとも１つのリンクパスに対応する少なくとも１つのピクチャーオブジェクトが存在するか否かをチェックするプロセスは、下記のように実現することができる。
async canShot(){
let imgsrc = getCookie(‘imgsrc’);
//ピクチャーをチェックする
if(imgSrc){
let imgAys = JSON.pase(imgSrc);
imgAys.map(item=>{
let newImg = new Imgage();
newImg.src = item;
newImg,load = ()=>{
//ピクチャーはキャッシュにまだ存在するか否かをチェックする
}
})
}else{
let ary = this.comps; //切り取りたいページｉｄ
let i = ary,length;
let shotCanvas = async()=>{
…
}
shotCanvas();
}
}
ステップＳ００２１において、少なくとも１つのピクチャーオブジェクトのピクチャー名称に基づいて、セッションデータ取得方法を呼び出し、セッションデータから少なくとも１つのピクチャーオブジェクトを抽出することを実行する。
いくつかの実施例において、ユーザが、ウェブページアプリケーションによって、現在のフルスクリーンページをアクセスする場合、画像処理装置は、ｃａｎｖａｓスクリーンショット方式を呼び出して少なくとも１つのページ画像を取得する前に、ｇｅｔＣｏｏｋｉｅ（）方法を呼び出し、ウェブページアプリケーションのｃｏｏｋｉｅデータを取得し、ｎｅｗＩｍｇ．ｌｏａｄ方法によって、ｃｏｏｋｉｅデータに少なくとも１つのピクチャーオブジェクトは既に存在するか否かをチェックすることができる。
いくつかの実施例において、画像処理装置は、ウェブページアプリケーションキャッシュに、少なくとも１つのリンクパスに対応する少なくとも１つのピクチャーオブジェクトが存在するか否かをチェックするプロセスは、下記のように実現することができる。
async canShot(){
let imgsrc = getCookie(‘imgsrc’);
//ピクチャーをチェックする
if(imgSrc){
let imgAys = JSON.pase(imgSrc);
imgAys.map(item=>{
let newImg = new Imgage();
newImg.src = item;
newImg,load = ()=>{
//ピクチャーはキャッシュにまだ存在するか否かをチェックする
}
})
}else{
let ary = this.comps; //切り取りたいページｉｄ
let i = ary,length;
let shotCanvas = async()=>{
…
}
shotCanvas();
}
}
【0030】
いくつかの実施例において、上記のｇｅｔＣｏｏｋｉｅ（）方法は、下記のコードによって実現することをできる。
getCookie(name){
var arr = document.cookie.split(‘;’);
var i = 0;
for(var i=0;i<arr.length;i++){
var arr2 = arr[i].split(‘=’);
if(arr2[0]==name){
return decodeURIComponent(arr2[1]);
}
}
return ‘’;
},
ステップＳ００２２において、セッションデータ取得方法の呼び出しが成功した場合、セッションデータに少なくとも１つのピクチャーオブジェクトが存在することを確認する。
本開示の実施例において、セッションデータ取得方法の呼び出しが成功した場合、例示的に、上記のｇｅｔＣｏｏｋｉｅ（‘ｉｍｇｓｒｃ’）方法は、ｉｍｇｓｒｃに対応するピクチャーオブジェクトを返すことは、該ピクチャーオブジェクトは、セッションデータに既に存在し、画像処理装置は、セッションデータに少なくとも１つのピクチャーオブジェクトが存在することを確認することを示す。
ステップＳ００２３において、セッションデータ取得方法の呼び出しが失敗した場合、セッションデータに少なくとも１つのピクチャーオブジェクトが存在しないことを確認する。
getCookie(name){
var arr = document.cookie.split(‘;’);
var i = 0;
for(var i=0;i<arr.length;i++){
var arr2 = arr[i].split(‘=’);
if(arr2[0]==name){
return decodeURIComponent(arr2[1]);
}
}
return ‘’;
},
ステップＳ００２２において、セッションデータ取得方法の呼び出しが成功した場合、セッションデータに少なくとも１つのピクチャーオブジェクトが存在することを確認する。
本開示の実施例において、セッションデータ取得方法の呼び出しが成功した場合、例示的に、上記のｇｅｔＣｏｏｋｉｅ（‘ｉｍｇｓｒｃ’）方法は、ｉｍｇｓｒｃに対応するピクチャーオブジェクトを返すことは、該ピクチャーオブジェクトは、セッションデータに既に存在し、画像処理装置は、セッションデータに少なくとも１つのピクチャーオブジェクトが存在することを確認することを示す。
ステップＳ００２３において、セッションデータ取得方法の呼び出しが失敗した場合、セッションデータに少なくとも１つのピクチャーオブジェクトが存在しないことを確認する。
【0031】
本開示の実施例において、セッションデータ取得方法の呼び出しが失敗した場合、画像処理装置はセッションデータに少なくとも１つのピクチャーオブジェクトが存在しないことを確認する。
ステップＳ００３において、セッションデータに少なくとも１つのピクチャーオブジェクトが存在しない場合、現在のフルスクリーンページの少なくとも１つのページ画像を取得する。
本開示の実施例において、セッションデータに少なくとも１つのピクチャーオブジェクトが存在しない場合、画像処理装置は、現在のフルスクリーンページから少なくとも１つのページ画像を取得し、上記のステップＳ１０２－Ｓ１０３の中の方法によって、現在のフルスクリーンページのスクリーンショットを撮ることを実現する。
本開示の実施例において、図５に示すように、ステップＳ００２の後で、ステップＳ００４が含まれることもできる。
ステップＳ００４において、セッションデータに少なくとも１つのピクチャーオブジェクトが存在する場合、セッションデータから少なくとも１つのピクチャーオブジェクトに対応する少なくとも１つのリンクパスを取得し、現在のフルスクリーンページのスクリーンショットを完成する。
ステップＳ００３において、セッションデータに少なくとも１つのピクチャーオブジェクトが存在しない場合、現在のフルスクリーンページの少なくとも１つのページ画像を取得する。
本開示の実施例において、セッションデータに少なくとも１つのピクチャーオブジェクトが存在しない場合、画像処理装置は、現在のフルスクリーンページから少なくとも１つのページ画像を取得し、上記のステップＳ１０２－Ｓ１０３の中の方法によって、現在のフルスクリーンページのスクリーンショットを撮ることを実現する。
本開示の実施例において、図５に示すように、ステップＳ００２の後で、ステップＳ００４が含まれることもできる。
ステップＳ００４において、セッションデータに少なくとも１つのピクチャーオブジェクトが存在する場合、セッションデータから少なくとも１つのピクチャーオブジェクトに対応する少なくとも１つのリンクパスを取得し、現在のフルスクリーンページのスクリーンショットを完成する。
【0032】
ステップＳ００４において、ウェブページアプリケーションキャッシュに少なくとも１つのピクチャーオブジェクトが存在する場合、画像処理装置は、少なくとも１つのページ画像を取得することなく、現在のフルスクリーンページのスクリーンショットを完成する。
理解可能なこととして、本開示の実施例において、画像処理装置は、ウェブページアプリケーションのｃｏｏｋｉｅからスクリーンショットを撮りたい少なくとも１つのピクチャーオブジェクトの場所を迅速に決定することができ、同じページの再びスクリーンショットの処理の必要がなく、キャッシュされたピクチャーの再利用性を向上させ、これによってウェブページアプリケーションのスクリーンショットの撮る作業負荷を軽減し、ウェブページアプリケーションのスクリーンショットの性能を向上させる。
本開示の実施例において、図６を参照すると、図６は、本開示の実施例によって提供される画像処理方法の一例示的なフローチャートであり、図４又は図５に基づいて、ステップＳ１０３３又はステップＳ１０３の後で、ステップＳ１０３４－Ｓ１０３５を実行することができる。各ステップを合わせて説明する。
理解可能なこととして、本開示の実施例において、画像処理装置は、ウェブページアプリケーションのｃｏｏｋｉｅからスクリーンショットを撮りたい少なくとも１つのピクチャーオブジェクトの場所を迅速に決定することができ、同じページの再びスクリーンショットの処理の必要がなく、キャッシュされたピクチャーの再利用性を向上させ、これによってウェブページアプリケーションのスクリーンショットの撮る作業負荷を軽減し、ウェブページアプリケーションのスクリーンショットの性能を向上させる。
本開示の実施例において、図６を参照すると、図６は、本開示の実施例によって提供される画像処理方法の一例示的なフローチャートであり、図４又は図５に基づいて、ステップＳ１０３３又はステップＳ１０３の後で、ステップＳ１０３４－Ｓ１０３５を実行することができる。各ステップを合わせて説明する。
【0033】
ステップＳ１０３４において、ウェブページアプリケーションにおいて、少なくとも１つのピクチャーオブジェクトの中の少なくとも１つの目標ピクチャーに対するアクセス要求を受信した場合、少なくとも１つの目標ピクチャーオブジェクトの画像ソースパスによって、少なくとも１つの目標ピクチャーオブジェクトに対応する少なくとも１つの目標ファイルオブジェクトを取得する。目標ファイルオブジェクトのリンクパスは、目標ピクチャーオブジェクトの画像ソースパスと同じである。
ステップＳ１０３４において、ウェブページアプリケーションにおいて、ウェブページのスクリーンショットを表示し、さらに保存する場合、画像処理装置は、ウェブページアプリケーションにおいて、少なくとも１つのピクチャーオブジェクトの中の少なくとも１つの目標ピクチャーに対するアクセス要求を受信することができる。
本開示の実施例において、少なくとも１つの目標ピクチャーは、少なくとも１つのピクチャーオブジェクトの中の抽出待ちのスクリーンショットを表す。画像処理装置は、アクセス要求が帯びるピクチャー名称に基づいて、抽出待ちの少なくとも１つの目標ピクチャーを決定することができる。
ステップＳ１０３４において、ファイルオブジェクトのリンクパスは、ピクチャーオブジェクトの画像ソースパスと同じであるために、画像処理装置は、対象各ピクチャーオブジェクトの画像ソースパスによって、少なくとも１つのファイルオブジェクトから対応して目標ファイルオブジェクトを読み出すことができる。
ステップＳ１０３４において、ウェブページアプリケーションにおいて、ウェブページのスクリーンショットを表示し、さらに保存する場合、画像処理装置は、ウェブページアプリケーションにおいて、少なくとも１つのピクチャーオブジェクトの中の少なくとも１つの目標ピクチャーに対するアクセス要求を受信することができる。
本開示の実施例において、少なくとも１つの目標ピクチャーは、少なくとも１つのピクチャーオブジェクトの中の抽出待ちのスクリーンショットを表す。画像処理装置は、アクセス要求が帯びるピクチャー名称に基づいて、抽出待ちの少なくとも１つの目標ピクチャーを決定することができる。
ステップＳ１０３４において、ファイルオブジェクトのリンクパスは、ピクチャーオブジェクトの画像ソースパスと同じであるために、画像処理装置は、対象各ピクチャーオブジェクトの画像ソースパスによって、少なくとも１つのファイルオブジェクトから対応して目標ファイルオブジェクトを読み出すことができる。
【0034】
ステップＳ１０３５において、少なくとも１つの目標ファイルオブジェクトに基づいて、少なくとも１つの目標ピクチャーオブジェクトをロードし、これによって、少なくとも１つの目標ピクチャーオブジェクトに対する表示及び保存を実現する。
ステップＳ１０３５において、画像処理装置は、対象各ピクチャーオブジェクトに対応する目標ファイルオブジェクトの中のコンテンツデータに基づいて、ウェブページアプリケーションにおいて、対象各ピクチャーオブジェクトをロードし、これによって、対象各ピクチャーオブジェクトに対する抽出、表示及び保存を実現する。
理解可能なこととして、本開示の実施例において、画像処理装置は、少なくとも１つのリンクパスによって、少なくとも１つのファイルオブジェクトを少なくとも１つのピクチャーオブジェクトのコンテンツデータとすることができる。こうすると、少なくとも１つのリンクパスの中の少なくとも１つの対象リンクパスへのアクセスによって、ロードしたい目標ピクチャーオブジェクトを関連してロードすることができ、これによって、ウェブページアプリケーションのキャッシュでスクリーンショットを撮りたい場面に対する表示及び保存を実現し、ウェブページアプリケーションのスクリーンショットの性能を向上させる。
以下では、本開示の実施例を実際の応用場面に例示的に応用するよう説明する。
ステップＳ１０３５において、画像処理装置は、対象各ピクチャーオブジェクトに対応する目標ファイルオブジェクトの中のコンテンツデータに基づいて、ウェブページアプリケーションにおいて、対象各ピクチャーオブジェクトをロードし、これによって、対象各ピクチャーオブジェクトに対する抽出、表示及び保存を実現する。
理解可能なこととして、本開示の実施例において、画像処理装置は、少なくとも１つのリンクパスによって、少なくとも１つのファイルオブジェクトを少なくとも１つのピクチャーオブジェクトのコンテンツデータとすることができる。こうすると、少なくとも１つのリンクパスの中の少なくとも１つの対象リンクパスへのアクセスによって、ロードしたい目標ピクチャーオブジェクトを関連してロードすることができ、これによって、ウェブページアプリケーションのキャッシュでスクリーンショットを撮りたい場面に対する表示及び保存を実現し、ウェブページアプリケーションのスクリーンショットの性能を向上させる。
以下では、本開示の実施例を実際の応用場面に例示的に応用するよう説明する。
【0035】
本開示のいくつかの実施例において、ユーザが、ブラウザ又はウェブページアプリケーションによって、サマリーレポート又は、活動調査などのページを閲覧する場合、インターフェースのインタラクション効果は図７Ａ－図７Ｃに示すようになることができる。図７Ａにおいて、ユーザは、ページに上下スライド操作によって、ウェブページ全体の中の各スクリーンページに表示する内容を閲覧することができる。最後のページまでスライドした場合、図７Ｂに示すように、ウェブページアプリケーションは、ウェブページ全体の中の少なくとも１つの画面のページをすべてローグスクリーンショットとして作成し、インターフェースに保存ボタンコントロール２－１を表示し、保存ボタンコントロール２－１によって、作成されたウェブページ全体のローグスクリーンショットを保存するように、又は、直接にバックグラウンドで該ローグスクリーンショットをダウンロードして保存するように、ユーザを注意する。図７Ｃに示すように、ウェブページアプリケーションは、ウェブページ全体の中の各スクリーンページに対応するスクリーンショットプレビューピクチャーを作成し、サムネイルの形で当前ページに表示することができる。ユーザは、サムネイルをクリックすることによって、その中の１つ又は複数のスクリーンショットプレビューピクチャーを選択して保存し、確認ボタンコントロール２－２によって選択することを完成することができる。ユーザが、確認ボタンコントロール２－２によって選択することを完成した場合、さらに、保存ボタン２－３をクリックすることによって、選択を確認した１つ又は複数のスクリーンショットプレビューピクチャーに対応するページピクチャーを保存することができる。
本開示の実施例において、ユーザは図７Ｂ又は図７Ｃに示すインターフェースに保存コントロール２－１又は保存コントロール２－３をクリックした後で、画像処理装置は、ウェブページアプリケーションにおいて、スクリーンショット命令を受信することができる。例示的に、ユーザが、図７Ｃで示すインターフェースに複数のページピクチャーを選択し、保存コントロール２－３をクリックした場合、図８に示すように、画像処理装置は、ステップＳ３０１－Ｓ３０７によって、選択された複数のページピクチャーを撮って保存することができる。
本開示の実施例において、ユーザは図７Ｂ又は図７Ｃに示すインターフェースに保存コントロール２－１又は保存コントロール２－３をクリックした後で、画像処理装置は、ウェブページアプリケーションにおいて、スクリーンショット命令を受信することができる。例示的に、ユーザが、図７Ｃで示すインターフェースに複数のページピクチャーを選択し、保存コントロール２－３をクリックした場合、図８に示すように、画像処理装置は、ステップＳ３０１－Ｓ３０７によって、選択された複数のページピクチャーを撮って保存することができる。
【0036】
ステップＳ３０１において、ページをロードする。
ステップＳ３０１において、画像処理装置は、ブラウザにウェブページ全体をロードする。
ステップＳ３０２において、キャッシュにリンクアドレスアレイが存在するか否かを判断する。
ステップＳ３０２において、ウェブページ全体をロードした後で、画像処理装置は、キャッシュにリンクアドレスアレイが存在するか否かを判断し、存在するなら、ステップＳ３０３－Ｓ３０８を実行し、存在しないなら、スキップしてステップＳ３０９を実行する。
ステップＳ３０２において、リンクアドレスアレイは、少なくとも１つのリンクアドレスを含む。少なくとも１つのリンクアドレスは、少なくとも１つのピクチャーオブジェクトの元アドレスであり、少なくとも１つのピクチャーオブジェクトは、ウェブページ全体に対応する少なくとも１つのスクリーンショットピクチャーであることができる。
ステップＳ３０２の実現プロセスは、ステップＳ００２で説明するものと同じであり、ここでは繰り返さない。
ステップＳ３０３において、ウェブページ全体の中の各スクリーンページに対応するＤＯＭ ＩＤを取得する。
ステップＳ３０３において、画像処理装置は、取得した各スクリーンページのＤＯＭ ＩＤからＤＯＭ ＩＤアレイを構成することができる。
ステップＳ３０３において、画像処理装置は、ＤＯＭ ＩＤアレイに含まれる少なくとも１つのＤＯＭ ＩＤを少なくとも１つのノード識別子とする。ステップＳ３０３の実現プロセスは、ステップＳ１０１１で説明するものと同じであり、ここでは繰り返さない。
ステップＳ３０１において、画像処理装置は、ブラウザにウェブページ全体をロードする。
ステップＳ３０２において、キャッシュにリンクアドレスアレイが存在するか否かを判断する。
ステップＳ３０２において、ウェブページ全体をロードした後で、画像処理装置は、キャッシュにリンクアドレスアレイが存在するか否かを判断し、存在するなら、ステップＳ３０３－Ｓ３０８を実行し、存在しないなら、スキップしてステップＳ３０９を実行する。
ステップＳ３０２において、リンクアドレスアレイは、少なくとも１つのリンクアドレスを含む。少なくとも１つのリンクアドレスは、少なくとも１つのピクチャーオブジェクトの元アドレスであり、少なくとも１つのピクチャーオブジェクトは、ウェブページ全体に対応する少なくとも１つのスクリーンショットピクチャーであることができる。
ステップＳ３０２の実現プロセスは、ステップＳ００２で説明するものと同じであり、ここでは繰り返さない。
ステップＳ３０３において、ウェブページ全体の中の各スクリーンページに対応するＤＯＭ ＩＤを取得する。
ステップＳ３０３において、画像処理装置は、取得した各スクリーンページのＤＯＭ ＩＤからＤＯＭ ＩＤアレイを構成することができる。
ステップＳ３０３において、画像処理装置は、ＤＯＭ ＩＤアレイに含まれる少なくとも１つのＤＯＭ ＩＤを少なくとも１つのノード識別子とする。ステップＳ３０３の実現プロセスは、ステップＳ１０１１で説明するものと同じであり、ここでは繰り返さない。
【0037】
ステップＳ３０４において、ＤＯＭ ＩＤごとにＣａｎｖａｓのスクリーンショットを撮り、少なくとも１つのスクリーンショットピクチャーを取得する。
ステップＳ３０４の実現プロセスは、ステップＳ１０１２－１０１４で説明するものと同じであり、ここでは繰り返さない。
ステップＳ３０５において、ｃａｎｖａｓ．ｔｏＢｌｏｂ（）方法によって、少なくとも１つのスクリーンショットピクチャーを少なくとも１つのｂｌｏｂオブジェクトに変換する。
ステップＳ３０５の実現プロセスは、ステップＳ１０２１で説明するものと同じであり、ここでは繰り返さない。
いくつかの実施例において、例示的に、ステップＳ３０３－Ｓ３０５に対応するコードは下記のように実現することをできる。
async canShot(){
let ary = this.comps; //アレイｔｈｉｓ．ｃｏｍｐｓはすべてのスクリーンショット待ちのＤＯＭ ＩＤを記憶する
let i = ary.length;
let shotCanvas = async ()=>{
i--;
if(ary[i]){
//ＤＯＭ ＩＤのそれぞれに対応するページコンテンツのスクリーンショットを撮る
let canvas = await html2canvas
(document.querySelector(‘.${ary[i].component}’)、{useCORS;true})
canvas.toBlob(function(blobObj) {…})
shotCanvas()
}
}
shotCanvas()
}
ステップＳ３０４の実現プロセスは、ステップＳ１０１２－１０１４で説明するものと同じであり、ここでは繰り返さない。
ステップＳ３０５において、ｃａｎｖａｓ．ｔｏＢｌｏｂ（）方法によって、少なくとも１つのスクリーンショットピクチャーを少なくとも１つのｂｌｏｂオブジェクトに変換する。
ステップＳ３０５の実現プロセスは、ステップＳ１０２１で説明するものと同じであり、ここでは繰り返さない。
いくつかの実施例において、例示的に、ステップＳ３０３－Ｓ３０５に対応するコードは下記のように実現することをできる。
async canShot(){
let ary = this.comps; //アレイｔｈｉｓ．ｃｏｍｐｓはすべてのスクリーンショット待ちのＤＯＭ ＩＤを記憶する
let i = ary.length;
let shotCanvas = async ()=>{
i--;
if(ary[i]){
//ＤＯＭ ＩＤのそれぞれに対応するページコンテンツのスクリーンショットを撮る
let canvas = await html2canvas
(document.querySelector(‘.${ary[i].component}’)、{useCORS;true})
canvas.toBlob(function(blobObj) {…})
shotCanvas()
}
}
shotCanvas()
}
【0038】
ステップＳ３０６において、ＵＲＬ．ｃｒｅａｔｅＯｂｊｅｃｔＵＲＬ（）方法によって、少なくとも１つのｂｌｏｂオブジェクトの少なくとも１つのリンクパスを作成する。
ステップＳ３０６の実現プロセスは、ステップＳ１０２２で説明するものと同じであり、ここでは繰り返さない。
ステップＳ３０７において、ｎｅｗ Ｉｍａｇｅ（）方法によって、少なくとも１つのピクチャーオブジェクトｉｍｇを作成し、少なくとも１つのリンクパスを使用して少なくとも１つのｉｍｇ．ｓｒｃに値を付け、少なくとも１つのｉｍｇｓをブラウザキャッシュに保存する。
ステップＳ３０７の実現プロセスは、ステップＳ１０３１－Ｓ１０３２で説明するものと同じであり、ここでは繰り返さない。
ステップＳ３０８において、少なくとも１つのリンクパスをアレイの形でｃｏｏｋｉｅに保存する。
ステップＳ３０８の実現プロセスは、ステップＳ１０３３で説明するものと同じであり、ここでは繰り返さない。
ステップＳ３０９において、キャッシュから少なくとも１つのリンクパスを取得する。
ステップＳ３０６の実現プロセスは、ステップＳ１０２２で説明するものと同じであり、ここでは繰り返さない。
ステップＳ３０７において、ｎｅｗ Ｉｍａｇｅ（）方法によって、少なくとも１つのピクチャーオブジェクトｉｍｇを作成し、少なくとも１つのリンクパスを使用して少なくとも１つのｉｍｇ．ｓｒｃに値を付け、少なくとも１つのｉｍｇｓをブラウザキャッシュに保存する。
ステップＳ３０７の実現プロセスは、ステップＳ１０３１－Ｓ１０３２で説明するものと同じであり、ここでは繰り返さない。
ステップＳ３０８において、少なくとも１つのリンクパスをアレイの形でｃｏｏｋｉｅに保存する。
ステップＳ３０８の実現プロセスは、ステップＳ１０３３で説明するものと同じであり、ここでは繰り返さない。
ステップＳ３０９において、キャッシュから少なくとも１つのリンクパスを取得する。
【0039】
ステップＳ３０９において、キャッシュに少なくとも１つのリンクパスが存在する場合、画像処理装置は、再びスクリーンショットを撮ることなく、直接に少なくとも１つのリンクパスを取得する。
ステップＳ３１０において、少なくとも１つのリンクパスに基づいて、キャッシュから少なくとも１つのピクチャーオブジェクトを抽出し、需要に基づいて少なくとも１つのピクチャーオブジェクトをさらに保存する。
ステップＳ３１０の実現プロセスは、ステップＳ１０３４－Ｓ１０３５で説明するものと同じであり、ここでは繰り返さない。
理解可能なこととして、上記の操作によって、画像処理装置は、多画面スクリーンショット撮ること及びオプショナルスクリーンショット撮ることを実現することができ、ピクチャーを撮ってレンダリングする時間が長いという技術的問題を克服し、キャッシュされたスクリーンショットの再利用性を向上させ、これによってウェブページアプリケーションのスクリーンショットの性能を向上させる。
本開示の実施例において、さらに、画像処理装置は、ＰＷＡ技術によって、指定するタイプのページ画像をキャッシュすることができる。具体的に、ｗｏｒｋｂｏｘ－ｓｗプラグインを導入し、ｂｌｏｂ：ｎｕｌｌ／パスの中のピクチャーを強制的にキャッシュする。例のコードは下記のようになる。
importScripts(‘workbox-sw.prod.v1.1.0.js’);
const workbox = new self.WorkboxSW();
// blob:null/ パスの中の任意の要求をマッチしてキャッシュする
workBox.router.registerRoute(‘blob:null/(.*)’,workbox.stragtegies.cacheFirst())
ステップＳ３１０において、少なくとも１つのリンクパスに基づいて、キャッシュから少なくとも１つのピクチャーオブジェクトを抽出し、需要に基づいて少なくとも１つのピクチャーオブジェクトをさらに保存する。
ステップＳ３１０の実現プロセスは、ステップＳ１０３４－Ｓ１０３５で説明するものと同じであり、ここでは繰り返さない。
理解可能なこととして、上記の操作によって、画像処理装置は、多画面スクリーンショット撮ること及びオプショナルスクリーンショット撮ることを実現することができ、ピクチャーを撮ってレンダリングする時間が長いという技術的問題を克服し、キャッシュされたスクリーンショットの再利用性を向上させ、これによってウェブページアプリケーションのスクリーンショットの性能を向上させる。
本開示の実施例において、さらに、画像処理装置は、ＰＷＡ技術によって、指定するタイプのページ画像をキャッシュすることができる。具体的に、ｗｏｒｋｂｏｘ－ｓｗプラグインを導入し、ｂｌｏｂ：ｎｕｌｌ／パスの中のピクチャーを強制的にキャッシュする。例のコードは下記のようになる。
importScripts(‘workbox-sw.prod.v1.1.0.js’);
const workbox = new self.WorkboxSW();
// blob:null/ パスの中の任意の要求をマッチしてキャッシュする
workBox.router.registerRoute(‘blob:null/(.*)’,workbox.stragtegies.cacheFirst())
【0040】
理解可能なこととして、画像処理装置が、ブラウザキャッシュスペースなどのウェブページアプリケーションキャッシュによって、撮られたピクチャーを保存する場合、時効性又はユーザの行動が予測できないことなどの不安定要素が存在する可能性がある。画像処理装置は、ＰＷＡ技術の中のＳｅｒｖｉｃｅ Ｗｏｒｋｅｒでピクチャーをキャッシュし、安定で制御できるピクチャーキャッシュ効果を実現する。
本開示の実施例は画像処理方法に対応する画像処理装置を提供する。図９は本開示の実施例によって提供される画像処理装置の構造概略図である。図９に示すように、画像処理装置１００は、取得部１０と、変換部２０と、保存部３０と、を含み、
前記取得部１０は、ウェブページアプリケーションにおいて、現在のフルスクリーンページの少なくとも１つのページ画像を取得するように構成され、
前記変換部２０は、前記少なくとも１つのページ画像を少なくとも１つのファイルオブジェクトに変換し、前記少なくとも１つのファイルオブジェクトの少なくとも１つのリンクパスを作成するように構成され、前記少なくとも１つのファイルオブジェクトは、前記少なくとも１つのリンクパスに1対1で対応し、
前記保存部３０は、少なくとも１つのピクチャーオブジェクトを作成し、前記少なくとも１つのピクチャーオブジェクトを前記少なくとも１つのリンクパスと関連付けてウェブページアプリケーションキャッシュに保存し、これによって前記現在のフルスクリーンページのスクリーンショットを完成するように構成される。
本開示の実施例は画像処理方法に対応する画像処理装置を提供する。図９は本開示の実施例によって提供される画像処理装置の構造概略図である。図９に示すように、画像処理装置１００は、取得部１０と、変換部２０と、保存部３０と、を含み、
前記取得部１０は、ウェブページアプリケーションにおいて、現在のフルスクリーンページの少なくとも１つのページ画像を取得するように構成され、
前記変換部２０は、前記少なくとも１つのページ画像を少なくとも１つのファイルオブジェクトに変換し、前記少なくとも１つのファイルオブジェクトの少なくとも１つのリンクパスを作成するように構成され、前記少なくとも１つのファイルオブジェクトは、前記少なくとも１つのリンクパスに1対1で対応し、
前記保存部３０は、少なくとも１つのピクチャーオブジェクトを作成し、前記少なくとも１つのピクチャーオブジェクトを前記少なくとも１つのリンクパスと関連付けてウェブページアプリケーションキャッシュに保存し、これによって前記現在のフルスクリーンページのスクリーンショットを完成するように構成される。
【0041】
本開示のいくつかの実施例において、前記変換部２０はさらに、前記少なくとも１つのページ画像を少なくとも１つのバイナリラージオブジェクトに変換し、前記少なくとも１つのファイルオブジェクトとし、前記少なくとも１つのバイナリラージオブジェクトの中の各バイナリラージオブジェクトに対して、ウェブページアプリケーションスクリプトの中のオブジェクト場所パス作成方法を呼び出し、前記各バイナリラージオブジェクトのリソースアドレスをリンクパスとして作成し、これによって前記少なくとも１つのリンクパスを取得するように構成される。
本開示のいくつかの実施例において、前記保存部３０はさらに、ウェブページアプリケーションスクリプトの中のピクチャーオブジェクト作成方法を呼び出し、少なくとも１つのピクチャーオブジェクトを作成し、各ピクチャーオブジェクトに対して、前記少なくとも１つのリンクパスの中の各リンクパスを前記各ピクチャーオブジェクトの画像ソースパスとして使用し、前記少なくとも１つのピクチャーオブジェクトを前記ウェブページアプリケーションキャッシュに保存し、前記画像ソースパスは、前記各ピクチャーオブジェクトをロードするときに、コンテンツデータを取得するパスであり、前記セッションデータによって前記少なくとも１つのピクチャーオブジェクトを前記少なくとも１つのリンクパスと関連付けて保存することを実現できるように、前記少なくとも１つのピクチャーオブジェクトのピクチャー名称と画像ソースパスを前記ウェブページアプリケーションキャッシュのセッションデータに保存し、これによって前記現在のフルスクリーンページのスクリーンショットを完成するように構成される。
本開示のいくつかの実施例において、前記保存部３０はさらに、ウェブページアプリケーションスクリプトの中のピクチャーオブジェクト作成方法を呼び出し、少なくとも１つのピクチャーオブジェクトを作成し、各ピクチャーオブジェクトに対して、前記少なくとも１つのリンクパスの中の各リンクパスを前記各ピクチャーオブジェクトの画像ソースパスとして使用し、前記少なくとも１つのピクチャーオブジェクトを前記ウェブページアプリケーションキャッシュに保存し、前記画像ソースパスは、前記各ピクチャーオブジェクトをロードするときに、コンテンツデータを取得するパスであり、前記セッションデータによって前記少なくとも１つのピクチャーオブジェクトを前記少なくとも１つのリンクパスと関連付けて保存することを実現できるように、前記少なくとも１つのピクチャーオブジェクトのピクチャー名称と画像ソースパスを前記ウェブページアプリケーションキャッシュのセッションデータに保存し、これによって前記現在のフルスクリーンページのスクリーンショットを完成するように構成される。
【0042】
本開示のいくつかの実施例において、前記画像処理装置１００はさらに、チェック部を含む。前記チェック部は、前記ウェブページアプリケーションキャッシュのセッションデータに、前記現在のフルスクリーンページに対応する少なくとも１つのピクチャーオブジェクトが存在するか否かをチェックするように構成される。前記取得部１０はさらに、前記セッションデータに前記少なくとも１つのピクチャーオブジェクトが存在しない場合、前記現在のフルスクリーンページの少なくとも１つのページ画像を取得するように構成される。
本開示のいくつかの実施例において、前記取得部１０はさらに、前記ウェブページアプリケーションキャッシュのセッションデータに、前記現在のフルスクリーンページに対応する少なくとも１つのピクチャーオブジェクトが存在するか否かをチェックするステップの後で、前記セッションデータに前記少なくとも１つのピクチャーオブジェクトが存在する場合、前記セッションデータから前記少なくとも１つのピクチャーオブジェクトに対応する前記少なくとも１つのリンクパスを取得し、前記現在のフルスクリーンページのスクリーンショットを完成するように構成される。
本開示のいくつかの実施例において、前記取得部１０はさらに、前記ウェブページアプリケーションキャッシュのセッションデータに、前記現在のフルスクリーンページに対応する少なくとも１つのピクチャーオブジェクトが存在するか否かをチェックするステップの後で、前記セッションデータに前記少なくとも１つのピクチャーオブジェクトが存在する場合、前記セッションデータから前記少なくとも１つのピクチャーオブジェクトに対応する前記少なくとも１つのリンクパスを取得し、前記現在のフルスクリーンページのスクリーンショットを完成するように構成される。
【0043】
本開示のいくつかの実施例において、前記取得部１０はさらに、前記現在のフルスクリーンページのロードを完成した場合、前記現在のフルスクリーンページの中の各場面に対応する画像を取得し、少なくとも１つのページ画像として使用するように構成される。
本開示のいくつかの実施例において、前記取得部１０はさらに、前記現在のフルスクリーンページにスクリーンショット命令を受信した場合、前記スクリーンショット命令に応答して、前記スクリーンショット命令により指定される少なくとも１つのスクリーンショット待ち場面に対応する画像を前記少なくとも１つのページ画像として使用するように構成される。
本開示のいくつかの実施例において、前記画像処理装置１００はさらに、抽出部を含む。前記抽出部は、前記現在のフルスクリーンページのスクリーンショットを完成するステップの後で、前記ウェブページアプリケーションにおいて、前記少なくとも１つのピクチャーオブジェクトの中の少なくとも１つの目標ピクチャーに対するアクセス要求を受信した場合、前記少なくとも１つの目標ピクチャーオブジェクトの画像ソースパスによって、前記少なくとも１つの目標ピクチャーオブジェクトに対応する少なくとも１つの目標ファイルオブジェクトを取得し、前記目標ファイルオブジェクトのリンクパスは、前記目標ピクチャーオブジェクトの画像ソースパスと同じであり、前記少なくとも１つの目標ファイルオブジェクトに基づいて、前記少なくとも１つの目標ピクチャーオブジェクトをロードし、これによって、前記少なくとも１つの目標ピクチャーオブジェクトに対する表示及び保存を実現するように構成される。
本開示のいくつかの実施例において、前記取得部１０はさらに、前記現在のフルスクリーンページにスクリーンショット命令を受信した場合、前記スクリーンショット命令に応答して、前記スクリーンショット命令により指定される少なくとも１つのスクリーンショット待ち場面に対応する画像を前記少なくとも１つのページ画像として使用するように構成される。
本開示のいくつかの実施例において、前記画像処理装置１００はさらに、抽出部を含む。前記抽出部は、前記現在のフルスクリーンページのスクリーンショットを完成するステップの後で、前記ウェブページアプリケーションにおいて、前記少なくとも１つのピクチャーオブジェクトの中の少なくとも１つの目標ピクチャーに対するアクセス要求を受信した場合、前記少なくとも１つの目標ピクチャーオブジェクトの画像ソースパスによって、前記少なくとも１つの目標ピクチャーオブジェクトに対応する少なくとも１つの目標ファイルオブジェクトを取得し、前記目標ファイルオブジェクトのリンクパスは、前記目標ピクチャーオブジェクトの画像ソースパスと同じであり、前記少なくとも１つの目標ファイルオブジェクトに基づいて、前記少なくとも１つの目標ピクチャーオブジェクトをロードし、これによって、前記少なくとも１つの目標ピクチャーオブジェクトに対する表示及び保存を実現するように構成される。
【0044】
本開示のいくつかの実施例において、前記画像処理装置１００はさらに、標記部を含む。前記標記部は、前記ウェブページアプリケーションにおいて、現在のフルスクリーンページの少なくとも１つのページ画像を取得するステップの前に、現在のフルスクリーンページから少なくとも１つの場面を分割し、前記少なくとも１つの場面に対して少なくとも１つのノード識別子を設定し、前記少なくとも１つの場面は、前記現在のフルスクリーンページに含まれるページ場面であり、前記少なくとも１つのノード識別子は、前記現在のフルスクリーンページで、前記少なくとも１つの場面に対応する少なくとも１つのデータ位置を表し、前記少なくとも１つの場面は、前記少なくとも１つのノード識別子に1対1で対応するように構成される。
前記取得部１０はさらに、前記現在のフルスクリーンページで、少なくとも１つのスクリーンショット待ち場面に対応する少なくとも１つの目標ノード識別子を取得し、前記少なくとも１つのスクリーンショット待ち場面は、前記少なくとも１つの場面の中の目標スクリーンショット場面であり、前記少なくとも１つの目標ノード識別子の中の各目標ノード識別子に基づいて、前記現在のフルスクリーンページのコンテンツデータから各目標ノード識別子に対応するコンテンツデータを読み出し、これによって少なくとも１つの目標ページデータを取得し、ウェブページレンダリング機能によって、前記少なくとも１つの目標ページデータに基づいて、前記少なくとも１つのページ画像を作成するように構成される。
前記取得部１０はさらに、前記現在のフルスクリーンページで、少なくとも１つのスクリーンショット待ち場面に対応する少なくとも１つの目標ノード識別子を取得し、前記少なくとも１つのスクリーンショット待ち場面は、前記少なくとも１つの場面の中の目標スクリーンショット場面であり、前記少なくとも１つの目標ノード識別子の中の各目標ノード識別子に基づいて、前記現在のフルスクリーンページのコンテンツデータから各目標ノード識別子に対応するコンテンツデータを読み出し、これによって少なくとも１つの目標ページデータを取得し、ウェブページレンダリング機能によって、前記少なくとも１つの目標ページデータに基づいて、前記少なくとも１つのページ画像を作成するように構成される。
【0045】
本開示のいくつかの実施例において、前記変換部２０はさらに、ウェブページ描画方法の中のピクチャーからバイナリラージオブジェクトへの変換方法を呼び出し、前記少なくとも１つのページ画像から少なくとも１つのバイナリラージオブジェクトに変換することを実現し、前記少なくとも１つのファイルオブジェクトとして使用するように構成される。
本開示のいくつかの実施例において、前記保存部３０はさらに、セッションデータ設定方法を呼び出し、前記少なくとも１つのピクチャーオブジェクトのピクチャー名称と画像ソースパスを前記ウェブページアプリケーションキャッシュに保存することを実現するように構成される。
本開示のいくつかの実施例において、前記チェック部はさらに、前記少なくとも１つのピクチャーオブジェクトのピクチャー名称に基づいて、セッションデータ取得方法を呼び出し、前記セッションデータから前記少なくとも１つのピクチャーオブジェクトの抽出を実行し、前記セッションデータ取得方法の呼び出しが成功した場合、前記セッションデータに前記少なくとも１つのピクチャーオブジェクトが存在することを確認し、前記セッションデータ取得方法の呼び出しが失敗した場合、前記セッションデータに前記少なくとも１つのピクチャーオブジェクトが存在しないことを確認するように構成される。
本開示の実施例は、画像処理方法に対応する画像処理装置を提供する。図１０は本開示の実施例によって提供される画像処理装置の構造概略図である。図１０に示すように、画像処理装置２００は、プロセッサ７１５と、メモリ７１６と、通信バス７１７と、を含む。前記メモリ７１６は、前記通信バス７１７によって前記プロセッサ７１５と通信し、前記メモリ７１６は、前記プロセッサ７１５によって実行可能な命令を記憶し、前記命令が実行される場合、前記プロセッサ７１５によって、上記の実施例のいずれかの画像処理方法を実行する。
本開示のいくつかの実施例において、前記保存部３０はさらに、セッションデータ設定方法を呼び出し、前記少なくとも１つのピクチャーオブジェクトのピクチャー名称と画像ソースパスを前記ウェブページアプリケーションキャッシュに保存することを実現するように構成される。
本開示のいくつかの実施例において、前記チェック部はさらに、前記少なくとも１つのピクチャーオブジェクトのピクチャー名称に基づいて、セッションデータ取得方法を呼び出し、前記セッションデータから前記少なくとも１つのピクチャーオブジェクトの抽出を実行し、前記セッションデータ取得方法の呼び出しが成功した場合、前記セッションデータに前記少なくとも１つのピクチャーオブジェクトが存在することを確認し、前記セッションデータ取得方法の呼び出しが失敗した場合、前記セッションデータに前記少なくとも１つのピクチャーオブジェクトが存在しないことを確認するように構成される。
本開示の実施例は、画像処理方法に対応する画像処理装置を提供する。図１０は本開示の実施例によって提供される画像処理装置の構造概略図である。図１０に示すように、画像処理装置２００は、プロセッサ７１５と、メモリ７１６と、通信バス７１７と、を含む。前記メモリ７１６は、前記通信バス７１７によって前記プロセッサ７１５と通信し、前記メモリ７１６は、前記プロセッサ７１５によって実行可能な命令を記憶し、前記命令が実行される場合、前記プロセッサ７１５によって、上記の実施例のいずれかの画像処理方法を実行する。
【0046】
本開示の実施例は、画像処理装置に応用するコンピュータ可読記憶媒体を提供する。記憶媒体は、１つ又は複数のコンピュータプログラムを記憶し、上記の実施例のいずれかの画像処理方法を実現するように、１つ又は複数のコンピュータプログラムは、１つ又は複数のプロセッサによって実行できる。
本開示の実施例は、方法、システム、又はコンピュータプログラム製品として提供できることを、当業者に理解されたい。したがって、本開示は、ハードウェアの実施例、ソフトウェアの実施例、又はソフトウェアとハードウェアを組み合わせる実施例のいずれかの形態をとることができる。さらに、本開示は、コンピュータ使用可能なプログラムコードを含む１つ又は複数のコンピュータ使用可能な記憶媒体（ディスクメモリ、光メモリなどを含むが、これを限定されるものではない）に実行されるコンピュータプログラム製品の形態をとることができる。
本開示は、本開示の実施例に基づく方法、機器（システム）及びコンピュータプログラム製品のフローチャート及び／又はブロック図を参照して説明される。理解可能なこととして、フローチャート及び／又はブロック図におけるフローのそれぞれ及び／又はブロック、そしてフローチャート及び／又はブロック図におけるフロー及び／又はブロックの組み合わせは、コンピュータプログラム命令によって実現できる。該当するコンピュータプログラム命令は、汎用コンピュータ、専用コンピュータ、組み込みプロセッサ、又は他のプログラマブルデータ処理機器のプロセッサに提供され、マシンを生成し、これによって、コンピュータ又は他のプログラマブルデータ処理機器のプロセッサによって実行される命令は、フローチャートにおける１つ又は複数のプロセス及び／又はブロック図における１つ又は複数のブロックで指定される機能を実現するために用いられる装置を生成することができる。
本開示の実施例は、方法、システム、又はコンピュータプログラム製品として提供できることを、当業者に理解されたい。したがって、本開示は、ハードウェアの実施例、ソフトウェアの実施例、又はソフトウェアとハードウェアを組み合わせる実施例のいずれかの形態をとることができる。さらに、本開示は、コンピュータ使用可能なプログラムコードを含む１つ又は複数のコンピュータ使用可能な記憶媒体（ディスクメモリ、光メモリなどを含むが、これを限定されるものではない）に実行されるコンピュータプログラム製品の形態をとることができる。
本開示は、本開示の実施例に基づく方法、機器（システム）及びコンピュータプログラム製品のフローチャート及び／又はブロック図を参照して説明される。理解可能なこととして、フローチャート及び／又はブロック図におけるフローのそれぞれ及び／又はブロック、そしてフローチャート及び／又はブロック図におけるフロー及び／又はブロックの組み合わせは、コンピュータプログラム命令によって実現できる。該当するコンピュータプログラム命令は、汎用コンピュータ、専用コンピュータ、組み込みプロセッサ、又は他のプログラマブルデータ処理機器のプロセッサに提供され、マシンを生成し、これによって、コンピュータ又は他のプログラマブルデータ処理機器のプロセッサによって実行される命令は、フローチャートにおける１つ又は複数のプロセス及び／又はブロック図における１つ又は複数のブロックで指定される機能を実現するために用いられる装置を生成することができる。
【0047】
該当するコンピュータプログラム命令は、コンピュータ又は他のプログラマブルデータ処理機器は特定の方式で動作するように引導できるコンピュータ可読メモリに記憶されてもよく、これによって、該コンピュータ可読メモリに記憶される命令は、命令装置を含む製品を生成し、該命令装置は、フローチャートにおける１つ又は複数のプロセス及び／又はブロック図における１つ又は複数のブロックで指定される機能を実現する。
該当するコンピュータプログラム命令は、コンピュータ又は他のプログラマブルデータ処理機器にロードされてもよく、コンピュータ又は他のプログラマブル機器に一連のステップを実行し、コンピュータで実現する処理を生成するようになる。これによってコンピュータ又は他のプログラマブル機器に実行される命令は、フローチャートにおける１つ又は複数のプロセス及び／又はブロック図における１つ又は複数のブロックで指定される機能を実現するために用いられるステップを提供する。
以上は、本開示の最適的な実施例に過ぎなく、本開示の保護範囲を限定するためのものではない。
該当するコンピュータプログラム命令は、コンピュータ又は他のプログラマブルデータ処理機器にロードされてもよく、コンピュータ又は他のプログラマブル機器に一連のステップを実行し、コンピュータで実現する処理を生成するようになる。これによってコンピュータ又は他のプログラマブル機器に実行される命令は、フローチャートにおける１つ又は複数のプロセス及び／又はブロック図における１つ又は複数のブロックで指定される機能を実現するために用いられるステップを提供する。
以上は、本開示の最適的な実施例に過ぎなく、本開示の保護範囲を限定するためのものではない。
【産業上の利用可能性】
【0048】
本開示の実施例の方法によって、画像処理装置は、少なくとも１つのページ画像を取得した後で、少なくとも１つのページ画像を少なくとも１つのファイルオブジェクトに変換し、少なくとも１つのファイルオブジェクトのリンクパスを少なくとも１つのピクチャーオブジェクトと関連付けてキャッシュに保存することができ、これによってスクリーンショットを他のコーディングフォーマットに変換することによりキャッシュ占有率が大きいという技術的問題を克服する。そして、現在のフルスクリーンページの少なくとも１つのピクチャーオブジェクトは、キャッシュに保存されるため、ユーザが現在のフルスクリーンページに再び入ってスクリーンショットを撮りたい場合、画像処理装置は、直接にキャッシュから少なくとも１つのピクチャーオブジェクトを取得し、対応するページのスクリーンショットとすることができ、再びスクリーンショットを撮る必要がなく、ブラウザ処理の作業負荷を軽減し、最終的にウェブページアプリケーションのスクリーンショットの性能を向上させる。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7A】
【図7B】
【図7C】
【図8】
【図9】
【図10】
