中小企业建站服务,wordpress教程 gofair,纯文本网站连接,网站建设的运作原理背景
在做图片、视频相关功能的时候#xff0c;相册是一个绕不开的话题#xff0c;因为大家基本都有从相册获取图片或者视频的需求。最直接的方式是调用系统相册接口#xff0c;基本功能是满足的#xff0c;一些高级功能就不行了#xff0c;例如自定义UI、多选图片等。
…背景
在做图片、视频相关功能的时候相册是一个绕不开的话题因为大家基本都有从相册获取图片或者视频的需求。最直接的方式是调用系统相册接口基本功能是满足的一些高级功能就不行了例如自定义UI、多选图片等。
我们调研了官方的image_picker它也是调用系统的相册接口来处理的可定制程度不高不能满足我们的要求。所以我们选择自己来开发Flutter相册组件。
我们的组件需要有如下的功能
在app内完成图片、视频的选取完全不用依赖系统相册组件可以多选图片支持指定选定图片的总数目在多选的时候UI反应出选择的序号。可以控制视频、图片的选择。例如只让用户选择视频图片是灰色的。大图预览的时候可以放大缩小也可直接加入到选取列表。
设计思路
API使用简单功能丰富灵活具有较高的订制性。业务方可以选择完全接入组件也可以选择在组件上面进行UI定制。
Flutter做UI展现层具体的数据由各Native平台提供。这种模式天然从工程上把UI代码和数据代码进行了隔离。我们在开发一个native组件的时候常常会使用MVC架构。Flutter组件的开发的思路也基本类似。整体架构如下 可以看出在Flutter侧是一个典型的MVC架构这里Widget就是ViewView和Model绑定在Model改变的时候View会重新build反映出Model的变化。View的事件会触发Controller去Native获取数据然后更新Model。Native和Flutter通过Method Channel进行通信两层之间没有强依赖关系只需要按约定的协议进行通信即可。
Native侧的组成部分UIAdapter主要是负责机型的适配、刘海屏、全面屏之类的识别。Permission负责媒体读写权限的申请处理。Cache主要负责缓存GPU纹理在大图预览的时候提高响应速度。Decoder负责解析BitmapOpenGL负责Bitmap转纹理。
需要说明的是我们的这一套实现依赖于flutter外接纹理。在整个相册组件看到的大多数图片都是一个GPU纹理这样给java堆内存的占用相对于以前的相册实现有大幅的降低。在低端机上面如果使用原生的系统相册由于内存的原因app有被系统杀掉的风险。现象就是从系统相册返回app重新启动了。使用Flutter相册组件在低端机上面体验会有所改观。
一些细节
1分页加载
相册列表需要加载大量图片Flutter的GridView组件有好几个构造函数比较容易犯的错误是使用了第一个函数这需要在一开始就提供大量的widget。应该选择第二个构造函数GridView在滑动的时候会回调IndexedWidgetBuilder来获取widget相当于一种懒加载。
GridView.builder({...ListWidget children const Widget[],...})
GridView.builder({...required IndexedWidgetBuilder itemBuilder,int itemCount,...})
滑动过程中图片滑过后也就是不可见的时候要进行资源的回收我们这里这里对应的就是纹理的删除。不断的滑动GridView内存在上升后会处于稳定不会一直增长。如果快速的来回滑动纹理会反复的创建和删除这样会有内存的抖动体验不是很好。
于是我们维护了一个图片的状态机状态有None,Loading,Loaded,Wait_Dispose,Disposed。开始加载的时候状态从None进入Loading这个时候用户看到的是空白或者是占位图当数据回调回来会把状态设置为Loaded的这时候会重新build widget树来显示图片icon当用户滑走的时候状态进入 Wait_Dispose这时候并不会马上Dispose如果用户又滑回来则会从Wait_Dispose进入Loaded状态不会继续Dispose。如果用户没有往回滑则会从Wait_Dispose进入Disposed状态。当进入Disposed状态后再需要显示该图片的时候就需要重新走加载流程了。
2 相册大图展示
当点击GridView的某张图片的时候会进行这张图片的大图展示方便用户查看的更清楚。我们知道相机拍摄的图片分辨率都是很高的如果完全加载内存会有很大的开销所以我们在Decode Bitmap的时候进行了缩放最高只到1080p。大图展示可以概括为三个步骤。
1 从文件Decode出Bitmap2 Bitmap转换成为纹理并释放Bitmap3 纹理交给Flutter进行展示
在步骤1中Android原生的Bitmap Decode经验同样适用先Decode出Bitmap的宽高然后根据要展示的大小计算出缩放倍数, 然后Decode出需要的Bitmap。
Android相册的图片大多是有旋转角度的如果不处理直接显示会出现照片旋转90度的问题所以需要对Bitmap进行旋转采用Matrix旋转一张1080p的图片在我的测试机器上面大概需要200ms如果使用OpenGL的纹理坐标进行旋转大于只需要10ms左右所以采用OpenGl进行纹理的旋转是一个较好的选择。
在进行大图预览的时候会进入一个水平滑动的PageViewFlutter的PageView一般来说是不会去主动加载相邻的page的。举个例子在显示index是5的page的时候index为46的page也不会提前创建的。这里有一个取巧的办法对于PageController的viewportFraction参数我们可以设置成为0.9999。对于前面这个例子就是在显示index是5的page的时候index为46的page也需要显示0.0001。这样index为46的page显示不到1个像素基本上看不出来
PageController(viewportFraction0.9999)还有另外一种办法就是在Native侧做预加载。例如在加载第5张图片的时候相邻的46的图片纹理提前进行加载当滑动到46的时候直接使用缓存的纹理。
纹理缓存后一个直接的问题什么时候释放纹理等到预览页面退出的时候释放所有的纹理显示不是很合适如果用户一直浏览内存则会无限增长。所以我们维护了一个5个纹理的LRU缓存在滑动过程中最老的纹理会被释放掉。在页面退出的时候整个LRU的缓存会进行销毁。
3 关于内存
相册图片使用GPU纹理会大幅减少Java堆内存的占用对整个app的性能有一定的提升。需要注意的是GPU的内存是有限的需要在使用完毕后及时删除不然会有内存的泄漏的风险。另外在Android平台删除纹理的时候需要保证在GPU线程进行不然删除是没有效果的。
在华为P8Android5.0上面进行了对比测试Flutter相册和原native相册总内存占用基本一致在GridView列表页面新增最大内存13M左右。它们的区别在于原native相册使用的是Java堆内存Flutter相册使用的是Native内存。
总结
相册组件API简单、易用高度可定制。Flutter侧层次分明有UI订制需求的可以重写Widget来达到目的。另外这是一个不依赖于系统相册的相册组件自身是完备的能够和现有的app保持UI、交互的一致性。同时为后面支持更多和相册相关的玩法打好基础。
后续计划
由于我们使用的是GPU纹理可以考虑支持显示高清4K图片而且客户端内存不会有太大的压力。但是4k图片的Bitmap转纹理需消耗更多的时间UI交互上面需要做些loading状态的支持。
组件功能丰富稳定后进行开源回馈给社区。
原文链接 本文为云栖社区原创内容未经允许不得转载。
