我正在開發一個IOS應用程序，該應用程序將顯示用戶從我的網站上傳的圖像。IOS應用程序的圖像顯示選項
什麼是重新調整大小在移動或服務器上的圖像的最佳做法是什麼？
選項A - 調整縮略圖，所需大小並將其存儲在Amazon S3的雲服務器上，例如iphoneretina_ImgA，Iphone_ImgA，Ipad_ImgA，IphoneThumbnail_ImageA的哪些主機映像。
選項B - 調整縮略圖，在設備上的所需大小。
什麼是上顯示服務器圖像到iPhone/iPad設備的最佳方法？
您將獲得在設備上實現最佳性能，如果你能在服務器端儘可能做盡可能多的圖像處理，並提供最佳大小的圖像的設備（即儘可能小的圖像，以支持所需的用戶界面），這將不僅可以節省下載時間（尤其是如果用戶使用速度較慢的蜂窩網絡），還可以節省寶貴的設備內存和處理時間（如果將高分辨率圖像下載到設備，則需要將CPU週期和內存轉換爲適當大小的圖像，更糟糕的是，沒有調整它們的大小，並試圖讓窮人嘗試渲染它們）。
總之，如果你能做到這一點的服務器端，這是理想的。如果您在設備上執行此操作，則會遭受網絡帶寬，內存消耗和設備上的處理時間。
如果原始圖像是不是太大，不過，你可以逃脫它意味着適度的設備端處理一些合理的妥協。例如，我正在使用傳統的CMS系統與適中大小的圖像進行交互，並限制了現有的服務器端圖像處理功能，因此我只是在設備上下載/需要時懶惰地製作縮略圖，但（a）原始圖像不是很大; （b）無論如何，我都需要設備上的原始分辨率圖像; （三）我不得不做一些聰明的GCD（或者你可以使用一些其他同等concurrent processing技術），以確保用戶界面是不是太顯着影響的應用程序不會一次性生成縮略圖（縮略圖，然後可在本地緩存以便在未來獲得最佳性能）。
像往常一樣在這些情況下，您的最終體系結構將是關於您的圖像，服務器功能和應用程序需求的詳細信息的函數，但是，如果有任何經驗法則，它將盡可能多地執行服務器端儘可能平衡網絡帶寬和服務器複雜性問題以及設備上的其他需求。