Delphi FMX正確設計和載入圖片滿足分散式跨平臺App的效能需求-分散式跨平臺App中美工圖片的處理、上傳下載、併發及客戶端顯示技術架構
Delphi FMX正確設計和載入圖片滿足分散式跨平臺App的效能需求
分散式跨平臺App中美工圖片的處理、上傳下載、併發及客戶端顯示技術架構
【綜合：客戶端（記憶體耗用、裝置螢幕的自動適配）、服務端（上傳效率、併發時效及網路瓶頸、記憶體）、美工工作量】
剛剛請教了高勇老師，結合高老師的GYListview的優秀設計和實際應用，就本文標題問題得出最後的解決方案，供大夥在實際軟體架構和設計開發時參考。
這個標題涉及的話題，看似很普通，也很平常，但如果App中包含有大量的產品，每個產品配有不同圖片（類似電商平臺的圖片載入效果），若不通盤考慮軟體的設計和架構，那麼做出的伺服器程式和客戶端程式，從“孃胎”裡羊水就沒有孵化好，整體執行效能可能就不如人意啦，特別是高併發時，尤為明顯。
一、關於本部落格博文《Delphi FMX正確載入圖片最大限度減少記憶體佔用（之一TBitmapSurface）》的本質
1.1、Delphi FMX中，TBitmap.LoadFromFile和TBitmap.LoadFromStream，是將外部圖片按照美工設計時的原始畫素尺寸大小，直接載入記憶體的，直接使用，會造成意想不到的大記憶體消耗的可能性，這取決於美工設計的畫素尺寸，圖越大記憶體消耗就愈大，反之就越小。
1.2、Delphi FMX中，TBitmap還提供了一個縮圖函式：TBitmap.LoadThumbnailFromFile，其本質同《Delphi FMX正確載入圖片最大限度減少記憶體佔用（之一TBitmapSurface）》
其函式原型申明為： procedure LoadThumbnailFromFile(const AFileName: string; const AFitWidth, AFitHeight: Single;
const UseEmbedded: Boolean = True);其中：引數 const AFitWidth, AFitHeight: Single;以新的“佈局方式=TAlign.Fit”的自適應寬高比例重新縮放圖片後，載入到記憶體。其中“自適應寬高比例縮放”的原理為：按照裝置螢幕物理解析度的短邊畫素值為基準（即TDisplayMetrics.PhysicalScreenSize.cx），將美工設計原圖按照寬高畫素比例縮放，詳見上文描述即程式碼實現。
但為了TBitmap自適應裝置螢幕及圖片載入後的顯示視覺精度，不能簡單地使用縮圖函式，而應當美工做特別的處理。
二、為了自適應裝置螢幕同時保證顯示清晰度和系統性能，需要美工做特殊處理
大家過去在BAT上申請專案時，可能經常看到如此字樣：“建議上傳尺寸108px*100px，最大不超過5M的圖片”，什麼意思呢，就是說：美工設計的圖片的磁碟空間不超過5M【潛臺詞是在限制設計輸出的畫素尺寸的最大值AMaxSizeLimit，本質即在控制：①上傳到伺服器端的CPU時間佔用、②併發的網路瓶頸、③伺服器端圖片點陣圖轉化的記憶體耗用CanvasClass.GetAttribute(TCanvasAttribute.MaxBitmapSize)】；④圖片的畫素尺寸最小應當為108*100，而且應當以此為寬高比例，才能達到合格的顯示清晰度。
還有一個Case就是，前些年在客戶專案中的增值服務：為客戶同時交付“淘寶店裝修”，發現淘寶後臺只需要美工設計並提交一套尺寸規範的圖片組，上傳即可。⑤現在看來，淘寶服務端在執行什麼程式處理，否則，一套圖片是不可能同時適配多樣化的裝置螢幕的顯示需求的。
那麼，既要保證顯示的清晰度，又要達到上述5個控制指標，最佳的架構方案是什麼呢？
通過向高老師學習和交流，結論為：
三、分散式跨平臺美工圖片處理、上傳下載、併發及客戶端顯示技術架構概要
3.1、美工設計輸出
根據實際應用需要，美工應當考慮裝置螢幕的最大和最小應用區間範圍，以最大的裝置螢幕物理尺寸為基準設計一套圖片，從而滿足實際應用中，可能發生的各種高頻度裝置螢幕的多樣性自適應適配，達到理想的顯示效果。
3.2、怎樣優化服務端和客戶端的效能
需要控制的5項效能指標，見上述二、，這裡不再贅述。
3.2.1、優化設計圖片的上傳效能、優化服務端圖片的下載效能
考慮到服務端的併發及網路瓶頸，上傳和下載，都需要高效能、高效率，儘量減少CPU和記憶體的開銷。請參考：《Delphi處理高速檔案上傳下載的程式碼及思路》。
3.2.2、設計圖片上傳後，服務端應當自動轉化原始圖片，自動生成多套圖片以適配客戶端裝置螢幕需求
這種類似的架構，大家在用Delphi開發Android客戶端應用，在Deployment中釋出好自己設計的圖片資原始檔，在Deploy工程時，已經非常熟悉了，可依據市面上主流裝置的螢幕尺寸，進行規劃：
同理，在服務端，應當為客戶端的圖片下載，提供不同裝置螢幕的適配圖片。因此需要在判斷成功上傳美工設計原圖後，執行自適應圖片的自動轉化和圖片檔案自動生成的方法程式碼。
3.2.3、下載圖片前先判斷客戶端裝置螢幕物理解析度短邊畫素值，作為引數告知服務端函式，以適配下載不同規格的圖片
3.2.4、客戶端以正確的AMaxSizeLimit，載入並顯示圖片，以達到最低的記憶體耗用和最佳的顯示清晰度。
3.2.5、高勇的GYListView圖片載入函式
已充分考慮了縮圖和原始圖片快取（方便檢視原圖或詳細圖時直接使用），大家可以放心使用。
（上面大量縮圖和圖片，載入並顯示，驗證過了，無任何問題）
3.2.6、高勇的三層中介軟體，完全能勝任分散式高併發需求
（下圖是載入94張選單圖片的效能，就在一瞬間，記憶體、cpu等也很優化）
本部落格相關博文：
1、《delphi XE關於Android四大元件之ContentProvider：案例delphi XE載入Android手機圖片的效率》
https://blog.csdn.net/pulledup/article/details/105642380
https://blog.csdn.net/pulledup/article/details/108660481
3、《Delphi FMX正確載入圖片最大限度減少記憶體佔用（之二TImageList）》
https://blog.csdn.net/pulledup/article/details/108979086
4、《Delphi FMX正確載入圖片最大限度減少記憶體佔用（之一TBitmapSurface）》
https://blog.csdn.net/pulledup/article/details/108935897