切图崽的自我修养-优化图片加载流程

前言

优化! 又是优化!

切图崽们作为整个web应用的纽带,连接着用户行为和机器性能. 而优化的最终意义,在于在这两者之间取得一个最佳的平衡点.

对于图片资源的加载来说,更是如此. 今天我们就来简单说说,项目开发中常见的图片加载优化方式.


预加载

1.遮罩大法

我们经常用jquery, jquery中$(function){})实际上是DOMContentLoaded事件完成的回调,只是完成了DOM树的构建. 诸如Css的渲染以及页面内图片等资源的下载不一定完成了.所以如果此时呈现页面,页面会非常难看.

为了解决这个问题,为了从设计和行为的角度提高用户体验,我们可以在图片等重要资源完全下载完之前,对页面加上较为美观的遮罩,并且弹出loading提示告知用户资源正在loading.等到图片完全加载完,才移除遮罩和加载动画.

具体的实现思路如下:

  1. $(function(){})调用之后,先弹出蒙板加上loading动画用来提示用户正在loading中
  2. 对页面中需要预加载的IMG元素进行下载var img = new Image(); img.src="xx.jpg"
  3. 图片下载完成会有一个onload的回调img.onload = function(){...}
  4. 在这个回调中移除loading动画以及遮罩

这样就可以给用户带来顺滑如丝般的操作体验了,再也不用担心用户看到那些正在下载的未显示完全的丑的要死图片了.

我们的口号是: 要么就不给你看,要么就给你看最好的
应用场景: 请在"首屏中存在图片的动画,或者和你对接的UI设计师极其强势"的情况下使用

2.有码大法

有码大法和遮罩大法略微有区别,具体实现思路如下:

  1. 首先对你需要预加载的图片准备两张,一张是高清一张低清. 比如girl_hd大小为60kb. 另一张是girl, 大小是6kb.
  2. html页面中需要预加载的image标签的src地址写的是低清的地址<img src="girl.jpg" class="hd-replace">
  3. 因为低清图很小,很快就能被加载出来.
  4. $(function(){})调用之后,获取页面需要高清替换的img的src(girl.jpg),以此src为基准拼接字符串(+‘_hd.jpg‘)获得高清图的地址(girl_hd.jpg),然后用下载该高清图var img = new Image(); img.src=“girl_hd.jpg”
  5. 图片下载完成会有一个onload的回调img.onload = function(){...}
  6. 回调中替换掉页面中img的src, 所以现在页面上的image标签为 <img src="girl_hd.jpg" class="hd-replace">

我们的口号是: 想看无码高清,请先看有码低清
应用场景: 请在"首屏中出现大量图片,且尺寸都不小"的情况下使用


懒加载

如果你仔细看了上面预加载的思路,一定往我脑袋上拍砖: 遮罩大法也好,有码大法也好,这并没有提高项目的加载速度啊,最后该下载的图片还不是得下载. 没错,懒加载只是改变了用户的操作感受,实际上项目的加载速度并没有提高. 但是,现在要说的懒加载,可是实实在在的提高了项目的加载速度哦.

什么是懒加载,一句话来解释, 就是图片按需加载.

大家一定刷过微博,微博的照片墙就是懒加载的最佳示例.一开始显示的照片并不多,只有用户下拉,拉到底部的位置, 照片墙才会被拉长,新的图片才会被加载.

操作思路:

  1. 监听滚动条scroll事件(当然touchmove事件也可以)
  2. 每次事件触发的时候,判断当前照片墙的位置
  3. 如果照片墙已经被刷到了底部某个临界位置点
  4. Js下载新出现的图片,var img = new Image(); img.src="xx.jpg"
  5. 下载完成有一个onload的回调img.onload = function(){...}
  6. 在下载完成的回调中向页面中插入已经下载好的图片

当然,根据项目不同,会有各种各样的懒加载方式.但核心是不变的:即页面初始加载的时候,只加载满足用户需求的最小数量的资源. 拿照片墙举例,可能用户的微博里有500张照片,如果你在页面加载的时候就加载500张,用户会卡到爆炸(因为后台一直处于图片下载状态). 如果页面加载的时候只初始加载20张图片,其他的图片通过用户自己的操作(滚动下拉),来按需加载,会极大提升项目运行的流畅程度.


结语

虽然预加载还是懒加载实现原理都非常简单,给我的启示确是巨大的:

  • 预加载除了改善用户的操作感受,其深层次的核心其实在于:对资源进行碎片化加载, 即预加载其实可以出现在任何时间段,当用户鼠标很长时间没移动的时候,我可不可以偷偷下载两张图片?在用户目前没有进行大量运算操作的时候,我可不可以偷偷下载两张图片?当用户当前在一个很精简的登陆界面的时候,我可不可以偷偷下载他登陆成功跳转到的页面的几张图片?等等等等
  • 懒加载的深层次核心在于:按需, 按需这个词已经被深深刻在我脑子里了. 现在回想起来,很多很多优化方式都是围绕着按需来展开的. 按需加载Js,按需加载图片等等
    首先,我们必须保证项目第一时间的加载速度,能让用户在最短的时间内看到页面和内容.

其次,尽量保证当前页面的精简程度,不去做无意义的加载. 只有当用户真正需要时,我们才展现给他.

各自的优缺点在于:

预加载:

  • 优点:如果提前下好了图片,等到这张图片需要用到时,可以秒开.
  • 缺点:下载图片的时候会影响项目的加载完成时间,会影响项目运行的流畅程度

懒加载在于:

  • 优点: 保证用户加载的项目是最精简的,最快的, 所下载资源是最少的
  • 缺点: 如果用户的操作触发了懒加载,那么需要等待资源下载到完成的时间,同时资源下载期间,操作流畅度降低

说到底,项目的优化是没有银弹的,这一部分的高效很可能导致另一部分的低效.A项目的优化方法照搬来B项目可能一文不值.
所以我们切图崽们能做的,就是深刻理解这些技术的原理,并且在项目中吸收经验,只有深刻地理解了各项技术的优劣,只有深刻的理解了用户的需求以及行为习惯,才能针对特定的项目,特定的场景,进行最适合的处理.

本文转载于猿2048:切图崽的自我修养-优化图片加载流程

原文地址:https://www.cnblogs.com/baimeishaoxia/p/12628370.html

时间: 2024-10-08 11:29:53

切图崽的自我修养-优化图片加载流程的相关文章

切图崽的自我修养-[MVVM] Js MV*模式浅谈

前言 做客户端开发.前端开发对MVC.MVP.MVVM这些名词不了解也应该大致听过,都是为了解决图形界面应用程序复杂性管理问题而产生的应用架构模式.网上很多文章关于这方面的讨论比较杂乱,各种MV模式之间的区别分不清,甚至有些描述都是错误的.本文追根溯源,从最经典的Smalltalk-80 MVC模式开始逐步还原图形界面之下最真实的MV模式. GUI程序所面临的问题 图形界面的应用程序提供给用户可视化的操作界面,这个界面提供给数据和信息.用户输入行为(键盘,鼠标等)会执行一些应用逻辑,应用逻辑(a

切图崽的自我修养-[ES6] 异步函数管理方案浅析

前言 业务开发中经常会用到异步函数,这里简单的对异步函数以及它的各种各样的解决方案做一个浅析 优缺点: 优点: 能够极大的提高程序并发业务逻辑的能力. 缺点: 异步函数的书写方式和代码执行逻辑很不直观,回调函数这种方式不太符合人类的的线性思维 异步函数的执行流程通常不好管理 不好对异步函数部署错误处理机制 解决方案 针对异步函数存在的缺点,所以才有了形形色色的异步的处理方案,常见的比如 原生的回调函数 promise/A+ async/await(generator); 业务场景 但这些解决方案

如何优化图片加载慢

1.压缩图片 2.懒加载(页面上图片多,但用户并不是要求立即就能看到全部图片,可以当用户将要看到的时候,再去加载,先加载用户看的,让出网络带宽) 3.对页面进行分帧Frame加载,比如页面很长,可以只加载前面一部分重要的HTML,当用户拉下来的时候,再加载下面的,塞进去. 4.使用BigPipe技术 5.JS进行异步加载 思路:1.对于用户关注的重要内容优先加载(比如视频网站的播放器),用户不怎么关注的内容(比如广告,推荐侧栏)懒加载. 2.减少http请求,合并js,css,image文件 3

优化图片加载的方法

1.图片懒加载  在页面上的未可视区域可以添加一个滚动条事件,判断图片位置到浏览器顶端的距离和到页面低端的距离,如果前者小于后者,优先加载. 2.如果为幻灯片.相册等,可以使用图片预加载技术,将当前展示图片的前一张和后一张优先下载. 3.如果图片为css图片,可以使用CSSsprite,SVGsprite,Iconfont等技术. 4.如果图片过大,可以使用特殊编码的图片,加载时会先加载一张压缩的特别厉害的缩略图,以提高用户体验. 5.如果图片展示区域小于图片的真实大小,则因在服务器端根据业务需

图片加载时间缓慢问题API

一.背景       最近段时间,开发写值工具项目中,出现图片加载问题API,响应时间缓慢:为了优化图片加载问题,我进行图片压缩方法,然后API的图片加载还是慢,最终在自己无意中乱写找到了根本的原因. 二.问题     优化图片加载问题 三.原因  1. 在API中,图片转换byte[ ]方法,用BMP的格式图片导致的API图片加载很慢: returnImage.Save(mstream2, System.Drawing.Imaging.ImageFormat.Bmp); 2. BMP 不支持压

Android中图片加载框架Glide解析2----从源码的角度理解Glide的执行流程

转载地址:http://blog.csdn.net/guolin_blog/article/details/53939176 在本系列的上一篇文章中,我们学习了Glide的基本用法,体验了这个图片加载框架的强大功能,以及它非常简便的API.还没有看过上一篇文章的朋友,建议先去阅读 Android图片加载框架最全解析(一),Glide的基本用法 . 在多数情况下,我们想要在界面上加载并展示一张图片只需要一行代码就能实现,如下所示: Glide.with(this).load(url).into(i

Android图片加载框架最全解析(二),从源码的角度理解Glide的执行流程

转载请注明出处:http://blog.csdn.net/guolin_blog/article/details/53939176 本文同步发表于我的微信公众号,扫一扫文章底部的二维码或在微信搜索 郭霖 即可关注,每天都有文章更新. 在本系列的上一篇文章中,我们学习了Glide的基本用法,体验了这个图片加载框架的强大功能,以及它非常简便的API.还没有看过上一篇文章的朋友,建议先去阅读 Android图片加载框架最全解析(一),Glide的基本用法 . 在多数情况下,我们想要在界面上加载并展示一

详谈高大上的图片加载框架Glide -源码篇

在上篇文章中,我们介绍了Glide图片加载框架的使用,通过之前的学习,我们可能已经能熟练的将Glide图片加载框架运用到我们的项目中,但是如果有人问你它是如何加载,工作原理是怎样的?为什么自定义GlideModule只需要在Manifest文件中加入meta-data即可?等等很多加载流程以及使用的注意事项.当然要想搞明白这些问题,就需要我们对Glide源码有个大致的认识,去剖析源码深处的奥秘. 接下来就让我们一起去进入Glide的源码世界,本篇文章分析的是Glide 3.7.0版本.特别提醒,

Android_优化查询加载大数量的本地相册图片

一.概述 讲解优化查询相册图片之前,我们先来看下PM提出的需求,PM的需求很简单,就是要做一个类似微信的本地相册图片查询控件,主要包含两个两部分: 进入图片选择页面就要显示出手机中所有的照片,包括系统相册图片和其他目录下的所有图片,并按照时间倒叙排列 切换相册功能,切换相册页面列出手机中所有的图片目录列表,并且显示出每个目录下所有的图片个数以及封面图片 这两个需求看似简单,实则隐藏着一系列的性能优化问题.在做优化之前,我们调研了一些其他比较出名的app在加载大数量图片的性能表现(gif录制的不够