私は自分のウェブサイトからユーザーがアップロードした画像を表示するIOSアプリに取り組んでいます。
モバイルまたはサーバーで画像のサイズを変更する際のベストプラクティスは何ですか？
オプションA-サムネイルのサイズを変更し、希望のサイズにして、クラウドサーバー（たとえば、iphoneretina_ImgA、Iphone_ImgA、Ipad_ImgA、IphoneThumbnail_ImageAの画像をホストするAmazon S3）に保存します。
オプションB-デバイスで希望のサイズのサムネイルにサイズ変更します。
サーバーイメージをiphone/ipadデバイスに表示するための最良のアプローチは何ですか？
サーバー側で可能な限り多くの画像処理を実行し、最適なサイズの画像（つまり、目的のユーザーインターフェイスをサポートするための可能な限り最小の画像）をデバイスに配信できれば、デバイスで最適なパフォーマンスが得られます。これにより、ダウンロードだけでなく節約も可能になります。時間（特にユーザーが低速のセルラーネットワークを使用している場合）だけでなく、貴重なデバイスメモリと処理時間（高解像度の画像をデバイスにダウンロードする場合、それらを適切なサイズの画像に変換するために必要なCPUサイクルとメモリの量、またはさらに悪いことに、サイズ変更しないそれらを作成し、貧しい人々にUIImageViewそれらをレンダリングさせようとします）。
つまり、サーバー側で実行できるのであれば、それは理想的です。デバイスでこれを行うと、ネットワーク帯域幅、メモリ消費、およびデバイスでの処理時間が発生します。
ただし、元の画像が大きすぎない場合は、デバイス側での適度な処理を伴う合理的な妥協点を回避できます。たとえば、適度なサイズの画像と限られた既存のサーバー側の画像処理機能を備えたレガシーCMSシステムとやり取りしているので、ダウンロード/必要なときにデバイス上でサムネイルを怠惰に作成しますが、（a）元の画像は大きくありませんでした。（b）とにかくデバイスに元の解像度の画像が必要でした。（c）アプリが1回限りのサムネイル生成（サムネイルがキャッシュされる）を実行するときに、ユーザーインターフェイスがそれほど目立った影響を受けないようにするために、巧妙なGCDを実行する必要がありました（または他の同等の同時処理テクノロジを使用できます）。将来の最適なパフォーマンスのためにローカルで）。
これらの場合はいつものように、最終的なアーキテクチャは、イメージ、サーバー機能、アプリの要件に関する詳細の関数になりますが、経験則がある場合は、サーバー側でできる限り多くのことを行います。ネットワーク帯域幅とサーバーの複雑さの問題と、デバイスの他の要求とのバランスを取ります。