著者: JD Retail He Xiao
導入
Jingxi APP の初期開発は、ユーザー エクスペリエンスを向上させるために、原生化元のアプリを迅速に反復して置き換えることが主な目的でしたが、この期間中に多くのパフォーマンスの問題も蓄積されました。H5その後、パフォーマンスの最適化に関連する作業を開始し、この記事では主に、京喜图片库関連する最適化戦略と、画像に関する関連知識を紹介します。
画像パフォーマンスの問題
電子商取引アプリとして、写真はさまざまなビジネスシーンで広く使用されています。网络消耗//を縮小せずに可能な限り削減し、画像を改善し、ユーザーにより良いユーザー エクスペリエンスを提供する必要があります内存消耗。これらのパフォーマンス目標に基づいて、予備的なパフォーマンス評価を通じていくつかのパフォーマンスの問題も整理しました。硬盘消耗图片质量加载速度
画像の読み込みが遅い/トラフィック消費が多い
画像リンクは主にバックグラウンドインターフェースによって発行され、画像は各ビジネスバックグラウンドによって発行格式および尺寸指定されます。一部のサービスでは、たとえばWebP、より小さい画像形式が使用されていないか、画像尺寸が大きすぎるため、画像が大きすぎてネットワーク消費量が多くなります。特にネットワーク状況が悪いシーンでは、写真の読み込みが遅くなり、ユーザーに不快な体験をもたらします。同時に、時間と手間がかかりI/O读写、解码消費電力も増加します。
画像メモリの使用量が多い
予備的な APP メモリ使用量の評価後、APP メモリ消費量全体に対する画像メモリ消費量の比率最高、特にサイズの大きな画像は多くのメモリを消費します。一方で、アプリがメモリを消費しすぎてバックグラウンドに退くと、システムによって簡単に強制終了され、次にアプリを開いて再起動するときにエクスペリエンスに影響を及ぼします。一方、APP は大量のメモリを使用するため、システムによって簡単に強制終了されますOOM。特に現在、ローエンド デバイスのユーザーが多数おり、デバイスのメモリが比較的少ないです。
最適化の方向性
上記で分析したパフォーマンスの問題のいくつかに基づいて、画像フレームワークを全体として再構築し、最適化しました。一方で降低、画像のネットワーク送信により、画像の読み込み速度が向上します。もう 1 つの側面は、减少画像メモリの消費です。
ネットワーク送信を最小限に抑える
Jingdong は、图片服务器写真やその他の機能など、さまざまな処理機能を提供します格式转换，图片降质，图片缩放，图片圆角。これらの機能はURL画像に特定のパラメータを追加することで実現され、画像サーバーはCDNパラメータ設定に従って画像処理を完了し、事前にサーバに保存します。画像処理パラメータを追加することで、画像の送信サイズを削減できます。
背景は事前に実行できますがURL预处理、画像パラメータは配布に追加されています图片URL。ただし、多数のバックグラウンド サービスが接続されているため、各サービスの画像パラメータ設定は大きく異なり、統一することができません。たとえば、画像フォーマットが使用されていない場合、画像フォーマットが大きすぎるなど、パフォーマンスに影響を与える可能性がありwebPます图片尺寸。同時に、さまざまなビジネスの背景変更を推進するコストも非常に高く、フロントエンドモデルが多数あることを考慮すると、モデルごとに異なる画像サイズを使用する必要があります。また、階調ダウングレード機能が不便であり、その後の機能変更も不便である。したがって客户端、URL预处理画一的に管理できる、より良い画像処理方法であり、将来の機能アップデートにも便利です。
画像 URL の前処理
画像ライブラリは、ネットワーク画像をロードする前に、それが京东ドメイン名の画像であるかどうかを確認しますURL。一致する場合、画像フレームワークは最初に域名画像をURL前処理します。前処理には、画像ネットワークの送信サイズを削減するために、、、、域名统一が添加缩放参数含まれます。添加webP参数添加降质参数
ヒント: 背景から返される画像には
URLいくつかの画像処理パラメータが含まれている可能性があるため、たとえばhttps://img11.360buyimg.com/img/pingou-head/25.jpg!webp、画像パラメータを直接追加すると、画像処理パラメータが無効になったり、形式が間違っていて読み込みが失敗したりする可能性があります。したがって、変換時には、すべての画像パラメータが事前に計算され、パラメータの繰り返しの追加を避けるために一緒に処理されます。
ドメイン名の統一
現在、イメージ サーバーは複数のイメージ ドメイン名 (たとえばm.360buyimg.com、img10.360buyimg.comなどの複数のドメイン名) を提供しています。m.360buyimg.com主に移动端使用目的で提供されます。ただし、さまざまなビジネス背景との関係により、インターフェイスは異なるドメイン名の画像を発行します。画像を使用すると、不同域名次の問題が発生する可能性があります。
不利于缓存复用- 画像フレームワークは通常、デフォルトでURL文字列を含む画像を生成し缓存key、異なる域名結果によって異なる画像が生成されます缓存key。硬盘缓存再利用に失敗するとイメージが繰り返しダウンロードされることになり、内存缓存再利用に失敗すると同じイメージがメモリの複数のコピーを占有することになります。不利于HTTP/2连接复用- ほとんどのインターフェイスには大量の画像が含まれており、多くのシーンでは同時に複数の画像が読み込まれます。特に首屏通常は数十枚の画像が読み込まれます。HTTPS複数のイメージをロードする場合、各ドメイン名は接続を再確立してDNS解析/TCP连接/TLS握手プロセスを実行する必要があります (現時点では、HTTPS リクエストの作成プロセスに約時間がかかります50-150ms)。リンクの再利用を使用する場合HTTP/2、リクエストを作成する必要があるのはHTTPS1 回だけであり、その後のイメージリクエストにより、この部分の時間を削減できます。
京东したがって、前処理中に、ドメイン名の画像の場合は、域名画像の URL を に置き換えますm.360buyimg.com。
画像パラメータを追加する
画像ズーム
多くのビジネス バックグラウンドから返される图片URL元のデータはsize、クライアントによって実際に表示されるデータsizeよりも大きくなります。一方で、より多くのネットワーク トラフィックが使用され、無駄が発生します。その一方で、より多くのメモリを消費します。同時に、画像sizeと実際の表示とsizeの間に不一致があるため像素不对齐、GPU追加の補間処理が必要となり、レンダリングのパフォーマンスにもある程度の影響を与えます。したがって、スケーリング パラメータを追加することで、実際に表示される画像サイズを小さくし、よりよく一致させる画像サーバーを指定しますsize。
動的スケール計算サイズ
iOSデバイスは主に解像度を使用するため2x/3x、ビジネス側は API を使用するときに対応する pt サイズを渡す必要があり、画像ライブラリはsizeデバイスに応じてscale実際のピクセルの幅と高さを内部で動的に計算します。
ヒント:
android画面の差が大きいため、固定デバイスを使用する方が適していますscale。画像サイズが大きすぎるとキャッシュに適さないためCDN、キャッシュがない場合は、画像の関連パラメータを処理する必要があり、画像処理自体に時間がかかります。
スケールダウングレード
低端机降级・一部の規模のローエンド端末では、マシン自体のメモリが比較的少ないため、解像度3xから計算3xされる画像のアスペクト比像素が大きくなり、メモリの消費量が多くなり、デコード/レンダリングのパフォーマンスの消費が大きくなります。2xしたがって、幅と高さが一定の要件を超える画像の場合は、解像度を使用して像素幅と高さを計算するようにダウングレードされ、デバイスのパフォーマンスの消費が削減されます。iPad降级- 現在のアプリはiPad特に最適化されていないため、デフォルトでは iPad デバイスでズームインします。これによりiPad、計算される画像サイズが非常に大きくなります。したがって、送信される画像のサイズが大きくなりすぎないように、iPad の画像のサイズにも特定の制限が設定されています。大图片降级- 通常の状況では、画像が宽/高画面を超えないようにしてください宽/高。一部の企業が大きすぎる画像を使用するのを防ぐためにsize、最終的に生成される画像のサイズが像素画面を超えてはいけないという制限が追加されました宽/高。
ダウングレード
画像サーバー0-100がサポートする画質パラメータ設定では、画質を下げることで画像サイズを小さくすることができますが、画質を下げすぎると画像の視聴体験に影響を与えます。画質パラメータを設定して、q70画像サーバーから送信される70%画質を指定します。ほとんどの企業にとって、一方では、画像のダウンロード サイズを大幅に削減でき、閲覧エクスペリエンスも保証されます。少なくともイメージ ダウンスケーラー パラメーターを追加することで縮小できるイメージ サイズ30-40%。
WebP を使用する
Google公式データによると、ロスレス画像のバイト数PNGは. 非可逆画像のバイト数は、同等の画像よりも少なくなります。画像サーバーは、画像サイズを削減できる変換形式をサポートしています。/ picture 形式の場合、パラメータを追加して、ピクチャ サーバーによって送信される形式を指定します。デコード/画像デコードには時間がかかりますが、相対的なネットワーク伝送速度は大幅に向上しています。WebP26％WebPJPG25-34％webPpngjpgwebPwebpwebPpngjpg
注意: 現在の画像サーバーは
GIF転送をサポートしていないためwebP、GIF は処理されません。
URL前処理キャッシュ
軽量キャッシュを追加して、URL変換パフォーマンスを向上させます。URL変換自体に時間がかかり、1 つの画像が複数回ロード/変換される可能性があるためですURL。変換されたものはURLキャッシュに直接保存され、次回使用するために直接返すことができます。キャッシュは+ 関連画像のモザイクkeyで構成されます。URL转换参数
画像APIの設計
画像処理パラメータが設定され、画質と形式optionsがデフォルトで使用されます。ビジネス側は、写真を読み込むメソッドを呼び出すときに渡します。ビジネス側の API は次のとおりです。q70webPiOS
imageView6.jx.setImage(url: URL(string: "https://img11.360buyimg.com/img/pingou-head/25.jpg"),
placeholder: nil, options: [.imageSize(CGSize(width: 40, height: 40))])
ディスクキャッシュの最適化
画像キャッシュ検索の最適化
画像に異なるsizeパラメータを設定すると、画像のダウンロードとディスク キャッシュが増加します。たとえば、サイズが異なるため、同じ画像100px、200px、300pxサイズが3 回ダウンロードされ、キャッシュを変えることはできません。URL画像ライブラリは通常、デフォルトでURL画像キャッシュとして使用されるため、画像を見つけるために画像キャッシュを最適化して変換するkey必要があります。key簡単に言うと、同じ画像の小さな画像はsize大きなキャッシュを使用して直接再利用できるsizeため、大きなサイズの画像がある場合に、画像の直接ダウンロードとディスク キャッシュの再利用を回避できます。
画像メモリの消費量を削減
png/およびその他の画像形式ではjpg、表示する前に解码ビットマップを生成し、そのビットマップに基づいてビットマップを作成し、纹理レンダリングのために GPU に送信する必要があります。ビットマップのメモリ消費量は約像素宽x 像素高xです位深。通常、画像はRGBA32 ビットのビット深度を使用します。シート500px_500pxのおおよそのメモリ1MB。画像の場合GIF、複数のフレームがあるため、最終的なメモリ消費量は单帧内存xになります帧数。
一方で、私たちの最適化の方向性は、画像のスケーリングを通じて画像ビットマップのメモリ消費を削減することです。一方、過剰なキャッシュ使用を避けるために、画像キャッシュの上限を制限します。
画像ズーム
上記のURL前処理プロセスにより、画像サーバーはより小さな画像形式を配信できるようになり、メモリの一部が削減されました。ただし、URL前処理ではjdドメイン名 のjpg/pngイメージのみが処理され、変換後にロードに失敗する一部のイメージなど、GIFまたはドメイン名の京东外部のイメージは処理されません。URLそこで、画像のこの部分では、メモリ消費量を削減するために、端側で画像のスケーリング処理を行います。たとえば、 GIF 画像300px_300pxが含まれる場合100帧、実際の表示領域は 1 つだけです。50px_50px最適化後、総メモリ消費量は30MB+メモリから 500 に削減できます3MB。
GIF ダイナミック フレーム レート再生
尺寸大/帧数多以前、オンライン監視データによると、一部のページ シーンで画像が構成され、メモリ使用量が非常に高くなることが判明しましたGIF。たとえば、 GIF 画像500x400pxの再生はメモリ200帧を消費します100MB+。そこで、このようなシーンのためにGIFフレーム削減再生の修正を行いました。GIF画像の合計メモリ消費量が一定のレベル (たとえば、画像のオンライン メモリ キャッシュの 20%) を超える場合、GIF再生されるフレーム数が適切に減らされ、各フレームの再生時間が増加します。 、メモリを一定の範囲内で制御できるようにします。
ヒント: ここでは、GIF イメージ キャッシュ バッファを通じてメモリの総量を制御することもできますが、デコードの頻度が高くなり、CPU 消費量が増加します。
画像メモリのキャッシュ制限
画像キャッシュは图片解码オーバーヘッドを削減するように設計されています。画像を初めて使用するときは、解码次回使用時に回避できないように、画像後のビットマップがメモリに保存されます重复解码。画像メモリを多くすると、画像の繰り返しデコードをできるだけ避けることができますが、メモリを消費しすぎると、APP バックグラウンドがシステムによって強制終了されたり、問題が発生したりする可能性がありますOOM。したがって、メモリキャッシュを一定の範囲内に制御する必要があります。
たとえばiOS、サードパーティのイメージ ライブラリSDWebImage/Kingfisherデフォルトでは、システム ライブラリを使用してNSCacheメモリ キャッシュを実装します。NSCacheデバイスのメモリが不足している場合、メモリは再利用されますが、保存できるメモリの最大バイト数はデフォルトでは制限されていないため、デバイスのメモリが利用可能な場合にはメモリをいつでも増やすことができます。そのため、画像キャッシュの上限を設定することで、画像キャッシュがメモリを過剰に占有することを防ぎます。画像キャッシュは初期値のデフォルト上限を定義しており、3x大画面デバイスや高端设备（メモリが多い）場合には、メモリの上限が適切に増加します。
最適化の結果
その他の収益・収入
域名统一-10%+重複した画像のダウンロードとメモリ消費量が削減されました。同時に、前のイメージが読み込まれるときにリクエスト多域名を繰り返し作成するプロセスが削減され、イメージの読み込み時間が短縮されます。HTTPS
他の戦略
ロード例外処理
少数の画像をURL前処理して変換しているため、画像が存在しない異常なシーンが存在する可能性があります加载失败。したがって、画像の読み込みエラーが発生した場合でも、元の画像の URL を読み込む必要があります。无网络ただし、 //やその他のエラーなど、不必要なロードを回避するために、一部の特殊なロード エラーをここでシールドする必要があり网络超时ます主动取消加载。その後、間違った写真がURLバックグラウンドに報告されるため、URL後で変換戦略を調整したり、URLビジネスの修正を促進するためにいくつかの間違った写真を見つけたりすることができます。同時に、错误连接次回の前処理とレポートの繰り返しを避けるために、接続のこの部分をキャッシュに追加します。
オンライン構成
URL预处理// use やその他の関数など、現在存在する一部の関数には、グレースケール/ダウングレードを容易にするオンライン構成が追加されています统一域名。WebP1. 問題発生時の一部機能のダウングレードや、新機能の立ち上げ時のグレースケールテストも可能です。
大きな画像の検出
画像が仕様を満たしていないという問題を適時に検出するメカニズムが必要です。一方で、オンライングレースケール検出を通じて、大きな画像が見つかった場合はレポートし、ビジネス側に最適化を促進します。一方、日常のテスト段階では、Debug検出ツールをオンにし、大きな画像が検出された場合は、图片翻转/ を使用し高亮背景颜色て最適化するようにビジネス開発の学生に通知します。
Flutter イメージ ライブラリの最適化
現在、Jingxi APP には開発10+に基づいたセカンダリ インターフェイスがあるFlutterため、Flutter画像の読み込みについてもいくつかの最適化を行っています。
ネイティブイメージライブラリのドッキング
Flutterフレームワークの組み込み画像ライブラリはメモリ画像キャッシュのみを提供し、ハードディスク キャッシュをサポートしていないため、画像の繰り返しダウンロードが発生します。ImageProviderそこで、ネットワーク イメージをロードするときにChannelネイティブ イメージ ライブラリを呼び出すことで、ネイティブ イメージ ライブラリがイメージをローカル ディスクにダウンロードし、イメージ ファイル ディレクトリを返すように書き換えます。次に、Flutterファイル ディレクトリを通じてデコードされた画像表示をロードします。このようにして、一方では、ネイティブ イメージ ライブラリの関連する最適化機能を使用できると同時に、复用イメージ ハードディスク キャッシュを使用して繰り返しダウンロードを回避できます。
メモリ消費量を削減する
Imageコンポーネントを使用する場合、 cacheHeight/を設定するとcacheWidth、画像は像素上部の幅と高さのビットマップ サイズにデコードされ、メモリ消費量が削減されます。同時に、Flutterメモリ消費量が比較的原生多いため、Flutterインターフェイスが閉じられると、imageCacheメモリ消費量を削減するメソッドを呼び出すことで画像のメモリ消費量がクリアされます。
GIFの最適化
动画优化-通常、Flutter混合スタックの仕組みが使用されており原生、Flutterページナビゲーションでインターフェイスが相互にジャンプするため。したがって、Flutterインターフェイスに画像がある場合、アニメーションはGIF元のインターフェイスにジャンプした後も実行され続けます。GIFそのためImage、コンポーネントで送信されたライフサイクル通知をリッスンしFlutter engine、Flutter インターフェイスがスタックの最上位にない場合はGIFアニメーションの実行を停止し、メモリと CPU の消費量を削減します。减少解码次数- Flutterフレームワーク内でのGIFレンダリング方法は、画面のフレームごとに表示する必要があるGIFフレームを判断し、GIFフレームをデコードしてレンダリングします。デコードされたフレームは保存されないため、頻繁にデコードが発生し、メモリの大きな変動が発生します。最適化後、デコードされたフレームは、繰り返しのデコードによる消費とメモリの変動を避けるために保存されます。
最適化前はメモリの変動が顕著ですが、
最適化後はメモリが安定する傾向にあります
ヒント: 各フレームを保存するとメモリの消費量も増加します。現時点では、通常、APP には小さいサイズの GIF が含まれているため、全体的な制御は可能です。過剰なメモリを避けるために、バッファーの上限を設定してキャッシュされたピクチャ フレームの数を制御することを検討できます。
その後の最適化の方向性
キャッシュアルゴリズムの改善
优先移除最大内存- iOS システムNSCacheの実装。最大メモリ数を設定すると、メモリが不足した場合、最大値から削除されます。LRU缓存- 最も長く未使用の画像メモリの削除を優先します。多くの二级界面シナリオでは、ユーザーはインターフェイスを開いた後、再度インターフェイスを開くことはありません。ただし、これらのイメージ キャッシュは最後に使用されるため、メモリがクリアされるときに最後に削除されますが、このシナリオには適していません。界面栈管理-关闭インターフェイスを開くときは、インターフェイスのすべての画像メモリを削除しますが、编解码頻繁に画像が表示される頻繁に開くインターフェイスには適していません。
したがって、ビジネス シナリオごとに異なるリサイクル方法を使用する方が適切な場合があります。
- このタイプのインターフェイスの場合
购物车/我的订单、ユーザーが毎回ロードする画像は基本的に固定されているため、メモリに常駐させ、メモリの消費量が多すぎる場合に再利用する方が適しています。 - このタイプのインターフェイスの場合
商详/搜索商品列表、通常、商品リストに表示される写真が異なり、ユーザーが特定の店舗に頻繁に入ることがないため、优先この部分のメモリを削除する方が適しています。 - 一部のポップアップ機能では、一度表示した画像は再利用されないため、メモリに追加しないことも考えられます。
より良い画像形式を使用する
通常、より優れた画像形式を使用すると、画像のバイト サイズが小さくなります。同時に圧縮率の向上により、サイズを小さくしながら画質を向上させることができます。
ヒント: システムがハード デコーディングをサポートする画像形式を使用する方が有利です。デコードにはハード デコードが使用されます
GPU。これにより、CPUソフト デコードを使用するよりもパフォーマンスが向上し、電力が節約されます。
APNG/动画WebP代替GIF-Google公式声明によると、 64% 小さいバイトと19% 小さいバイトGIFに変換されました。したがって、これを使用すると、より多くのネットワーク トラフィック送信を削減できます。は、開始され完全にサポートされているGIF 形式に基づいており、縮小できる画像サイズと比較します。また、256 色のインデックス カラーと 1 ビットのアルファのみをサポートします (透明度を追加すると、明らかにギザギザのエッジが表示されます)。/ を使用すると、より良い表示効果をもたらすこともできます。有损WebP无损WebP动画WebPAPNGMozillaPNGRGBAGIF20%+GIFAPNGWebPGIF
ヒント: デコード率と比較して
GIF、WebPデコード率はGIFより多くの CPU リソースを消費します。有损WebPのデコード時間は のGIF2.2 倍、 の无损WebPデコード時間はGIFの 1.5 倍です。
HEIC-ビデオコーディングフォーマットに基づいたピクチャーフォーマットです。画像サイズを 20%以上削減でき、コーデックのパフォーマンスが向上します。システム互換性の観点から、上記のシステムは をサポートしています。Apple は上記のシステムではハード デコーディングのみを提供しています。以前のシステムではソフト デコーディングのみが使用でき、後のマシンではハード デコーディングがサポートされていましたが、サポートされていません。HEICH.265HEICWebPAndroid 9.0HEICiOS14WebPHEICiOS11浏览器AVIF-は、エンコード形式に基づいたピクチャ形式です。画像サイズと比較して30% 以上縮小できます。ただし、現在サポートされているのは上記のバージョンのみです。AVIFAV1AVIFWebPAndroid 12
ヒント: ここでは主に
VP8エンコード形式について説明しますWebP。全体的なパフォーマンスとVP9エンコード形式の違いは大きくありません。ただし、これらの画像形式は、使用する前に画像サーバーでサポートされている必要があります。WebPHEIC
フラッター
画像ギャラリーに対していくつかの最適化を行いましたがFlutter、全体的には最適化の余地がまだたくさんあります。業界で使用されている纹理画像ベースのソリューションが含まれます。イメージはネイティブ側でデコードされた後、Flutterエンジンによって作成されます纹理。次に、画像テクスチャがレンダリングのためにidに渡されますFlutter。これにより、画像メモリキャッシュをネイティブ側で均一に管理することができ、最適化Flutter前後で原生メモリキャッシュ方式が分かれます。また、混合スタックのナビゲーション スタック方式では、画像メモリをより適切にリサイクルすることもできます。さらにFlutter、過度のメモリ消費を避けるために、より柔軟な画像メモリ回復戦略を提供する必要があります。
ヒント: テクスチャはメモリ内
位图キャッシュを再利用できるため、メモリ使用量が増加することはありません。30%Flutter エンジンの画像ライブラリと比較して、テクスチャメソッドで削減できるメモリ消費量は、主に他のオブジェクトの使用によって引き起こされると考えられます。
H5画像の読み込みを最適化する
画像の読み込みをインターセプトしWebView、ネイティブ画像ライブラリに画像をダウンロードさせ、画像二进制データをWebViewディスプレイに渡すことができます。
トラフィック消費量を削減する
このようにして、URL预处理ネイティブ イメージ ライブラリのH5イメージに関連する機能をサポートし、H5読み込みプロセス中のイメージ トラフィックの消費を削減し、イメージの読み込み速度を向上させることができます。同時に、APP原生とWebView画像キャッシュ機構が独立しているため、ネイティブ側で画像キャッシュを一元管理することで、同じ画像の繰り返しダウンロードを軽減できます。
より多くの画像フォーマットをサポート
たとえば、iOSシステムではWKWebView// 画像形式のみが現在PNGサポートされています。したがって、ネイティブ側で/ピクチャをダウンロードし、ピクチャを再送信することで、他のピクチャ形式の表示をサポートできるようになります。JPGGIFWebPHEIC解码WebView
ヒント:バイナリデータ表示の
WebView直接送信には対応していないため、事前に/バイナリデータ送信位图に変換する必要があります。したがって、他の画像形式のエンコード処理を追加すると、パフォーマンスの消費が増加します。ただし、システムの場合、Web カーネル層でこの消費量を最適化し、削減できる必要があります。PNGJPGPNGJPGAndroid
要約する
この記事では、基礎となる画像読み込みライブラリの具体的な実装については説明しませんが、現時点では、画像ライブラリがサードパーティのライブラリによって直接使用されるか、自社開発の画像ライブラリによって実装されるかにほとんど違いはありません。私たちは、自社のビジネスと、画像サーバー機能を使用してネットワーク画像読み込みのパフォーマンスを最大化する方法に、より注意を払っています。したがって、一部の戦略はすべてのアプリに適しているわけではないため、独自のビジネス シナリオに合わせて最適化計画を慎重に評価する必要があります。