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

      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

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

猜你喜欢

转载自blog.csdn.net/pulledup/article/details/109019196
今日推荐