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

      2、《Delphi处理高速文件上传下载的代码及思路》

      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

喜欢的话，就在下面点个赞、收藏就好了，方便看下次的分享：