搜索到
2
篇与
的结果
-
前端优化-渐进式图片 前言关于前端的性能及体验问题，图片的加载绝对是重中之重，尤其是在一些有着许多大图的页面，在网络不稳定或稍慢的时候，我们经常能够看到页面中图片的位置是一片空白，等图片加载完成才开始慢慢渲染，在这段时间对用户的体验其实是非常不友好的。那么我们应该如何来进行优化呢？大家想说的是不是：把图片压缩一下不就好了？是的，图片压缩是我们前端开发过程必备的一步，但是光靠图片压缩并不能解决所有的图片体验问题，有些图片本身就比较大，内容质量都比较高，此时压缩图片带来的加载性能提升似乎就没有那么明显了，这时候我们就可能需要使用一些技巧来进行优化了。background-image之前在需求中有使用过 background-image来进行优化，先来看看效果：优化前：优化后：从上述对比中可以清晰看出，优化后的图片加载体验相较于优化前实现了显著提升。优化后，用户所经历的白屏时间显著缩短，取而代之的是图片从模糊逐渐变得清晰的过程。这意味着用户能够更早地预览到图片的内容，而无需再焦急地等待白屏消失，从而大大提升了用户的体验感受！原理原理实际上很简单，从上图我们可以看到优化后的效果实际上是加载了两张图片，一张小图（1.9k），一张原图（2.8M），所有最开始看到的模糊图片其实是这张小图，最后变清晰看到的是原图。这里使用的技术也很简单，只需要CSS的 background-image❝background-image 属性用于为一个元素设置一个或者多个背景图像。.pic_container { width: 300px; height: 375px; background-image: url("../assets/origin.jpg"), url("../assets/small.jpg"); background-repeat: no-repeat; background-size: 100% 100%; }在绘制时，图像以 z 方向堆叠的方式进行。先指定的图像会在之后指定的图像上面绘制。因此指定的第一个图像“最接近用户”。也就是说，原图与缩略图是叠在一起的，并且原图在上缩略图在下，在原图还没加载完成时，可以先看到下面的缩略图，也就是那张模糊的图片，等原图加载完成之后，浏览器才会开始渲染原图，由于两张图是在同一个位置，所以我们可以看到一个从模糊变清晰的过程。img + background-image虽然 background-image天生就支持设置多个背景图，但更多时候我们还是使用 img来承载图片，但是 img的 src属性可没有这一特点。是的，如果不使用JS的话光靠 img也是做不到上面的效果的。如果想要使用 img的话，可以使用 img + background-image组合来实现。<div class="pic_container"> <img src="../assets/origin.jpg" alt="origin" /> </div> <style lang="scss" scoped> .pic_container { background-image: url("../assets/small.jpg"); background-repeat: no-repeat; background-size: 100% 100%; img { width: 300px; height: 375px; } } </style>效果跟上面那种类似，实际上原理也差不多。需要注意的是：img元素占位在图片还没开始渲染时，它在页面上实际上是透明的，所以我们能够在看到下面的背景图片，等 img资源加载完成开始渲染时，才会慢慢遮盖下面的背景图。为了更方便的复用，我们可以把它封装成一个通用组件用来提升用户体验，但该组件需要提供两张图片，一张原图，一张缩略图。这样做有的同学可能觉得很麻烦，那么有没有更简便的方法呢？渐进式图片除了以上这两种方案，我还见过另外一种方案实现的效果，但它并不依赖于 background-image，只需要 img元素就可以，比如：这种效果应该图片格式的功劳，通常网站使用的 JPEG 的内容显示通常有两种类型：基线 JPEG渐进式 JPEG一般来说我们见的比较多的应该是基线JPEG基线JPEG（Baseline JPEG）基线 JPEG 最常见的应用之一是在 Web 浏览器中呈现的图像。基线 JPEG 算法在从网络下载处理数据时逐行渲染图像。当数据从网络到达计算机的缓冲区时，数据以流的形式进行处理。基线式的编码方式是图片从上到下，从左到右地进行处理和编码。这就会形成我们查看大图时比较常见的从上至下逐行显示，即首先显示图像的顶部。然后它会逐行加载到底部，直到显示出完整的图像。这种格式的图片在面对越大的图片时，往往需要我们等待越长的时间才能看到完整图片，比较容易让网站流失用户渐进式 JPEG（Progressive JPEG）渐进式 JPEG 以特定方式压缩照片和图形，与基线 JPEG 不同，PJPEG 在 Web 浏览器中呈现时，会首先给出模糊图像的外观。然后一点一点地开始图片渲染，直到它显示完全渲染的图像。浏览器实际上是逐行解释图像，但在占位符中提供了完整图像的模糊预览。随着 Web 浏览器的渲染引擎处理数据，图像的对比度开始变得更清晰、更详细。直到最后渲染完毕，用户将看到完整的清晰图像。如何生成渐进式图片通常情况下，设计师给我们提供的切图素材通常就是普通格式的图片，并不支持渐进式加载，但实际上他们在导出图片的时候可以选择导出为渐进式图片图片的，但他们可能并不会帮你这样干。那么我们自己能不能将非渐进式图片转换为渐进式图片呢，答案是可以的！GraphicsMagick我们可以使用该工具库来生成渐进式图片，我们只需要安装node对应的版本npm install gmconst gm = require('gm').subClass({ imageMagick: true }); const path = require('path'); function transformImage(imagePath, transform, generatePath, callback) { gm(imagePath) .interlace('Line') // 生成渐进式图片 .resize(transform.width, transform.height) .write(generatePath, callback); } const basePath = path.join(__dirname, '../src/assets/'); transformImage( path.join(basePath, 'sy.pic.jpg'), { width: 500, height: 500 }, path.join(basePath, 'sy.line.jpeg'), (res) => { console.log(res); } );如何选择首先明确的一点，渐进式图片的加载体验的确是要比普通图片的加载要好上不少，无论是我们自己模拟的渐进式加载还是通过依赖图片本身算法来实现的，这几种方案在各大网站都能看到在应用。渐进式图片的优缺点优点 ：移动网络流量优化 ：渐进式图片下载技术允许用户仅初始下载图片的一部分，有效降低图像分辨率并减少数据使用量，特别适用于移动网络环境。减少加载等待时间 ：渐进式图片能够让用户先快速预览图片的轮廓，随后逐步加载更多图片细节，提升用户体验。缺点 ：图片格式转换成本 ：由于大多数现有图片采用普通压缩格式，转换为渐进式格式需要额外的处理成本。兼容性 ：部分老旧浏览器（例如IE8）对渐进式图片格式的支持不足，尽管随着时间推移，这些浏览器将逐渐被市场淘汰，但当前仍可能影响部分用户的浏览体验。 -
【整理】开发注意事项-1 开发注意事项考虑 边界值 ：如果要展示一个列表，就要考虑列表为空、列表长度超过一页的情况；如果展示的是文字，则要考虑文字为空、文字超长的情况；访问a.b.c时，a或b是否可能为undefined。考虑 特殊场景 ：如交互状态（hover、disabled、文字提示）、浮点数计算精度（使用utils方法）、防重复提交、分辨率兼容、移动设备兼容、事件冒泡、防抖和节流；考虑 需求变更和功能拓展 ：需求变更是不可避免的，那就要在开发的时候考虑到哪些地方容易变(数值、变量)，哪些不容易变（框架、模式），提前做好设计规划，减少因需求变更造成的大规模重构。考虑代码 可读性 ：复杂方法标注用途、复杂逻辑解释清楚、修改他人代码先理解上下文并做好自测。保持优化代码的好习惯：所有不合理的问题，都是可以改的，代价大，就细致谋划，不要搁置，避免埋雷。代码越短就越好吗？实际的业务书写中，如果减少10%的代码换来的是可读性变差，那并不推荐这么做。我们推荐的是，在保证可读性的前提下，尽可能让代码变少。 // bad 三元嵌套三元不利于可读性 let message = (age < 3) ? 'Hi, baby!' : (age < 80) ? 'Hello!' : 'What an unusual age!'; // good if (age < 3) { message = 'Hi, baby!'; } else if (age < 80) { message = 'Hello!'; } else { message = 'What an unusual age!'; } // bad if (company == 'Netscape') { return true; } else { return false; } // good return company === 'Netscape';魔法值的问题魔法值，也叫做魔法数值、魔法数字，通常是指在代码编写时莫名出现的数字， 无法直接判断数值代表的含义，必须通过联系代码上下文分析才可以明白， 严重降低了代码的可读性。除数字之外，代码中作为key值的常量字符串也被认为是魔法值， 尽管其表示含义比数值较为清晰，但是仍然会产生不规范问题。 // 魔法值举例 if(flag === '5'){ ....... } if (businessType === 101){ ....... }通常会采用枚举类型来解决魔法值问题，由于JS中没有枚举类型，可以使用对象字面量的方式来模拟枚举，如下： const BusinessTypeEnum = { SYSTEM: 0, // 系统 CRM: 1, // CRM JXC: 2, // JXC UNKNOWN: 404, // 未知对象类型 CUSTOMER_MANAGEMENT: 100, // 客户管理 CUSTOMER: 101, // 客户 CUSTOMER_FOCUS: 102, // 重点客户 CUSTOMER_DEAL: 103, // 成交客户 CUSTOMER_FOLLOW: 104, // 跟进客户 CUSTOMER_PUBLIC: 105 // 客户公海池 } if (businessType === BusinessTypeEnum.CUSTOMER){ ....... }采用枚举的另外一个好处，当某个值因为需求迭代需求变更时，我们只需要在枚举中将该值替换，并不需要在全局搜素替换。程序中的电车难题如图，当一辆电车快速驶来，无论图上的人采取哪种选择，似乎都是错误的。但是，在程序中出现预期之外的错误必须要导致一个负面结果时，一定要选择代价最小的。举个例子： 某同学开发了一个新手引导弹窗功能，该功能有个透明的全屏遮罩，只有当新手引导结束时，遮罩才会消失。由于程序中存在一处逻辑判断不严谨，导致在特定情况下全屏遮罩不能被关闭，然后整个系统都不能被点击了。一个简单的新手引导功能却引发了系统不可用的严重故障，这是非常大的代价。通过上述例子去分析，系统不可用的负面影响远大于新手引导不可用。因此，我们应该修改逻辑判断方案，当程序脱离预期执行时，直接去关闭新手引导。 // before if (step === 0) { dialog.close() } else { dialog.show() } // after if ([1, 2, 3].includes(step)) { dialog.show() } else { dialog.close() }我们无法保证自己写的代码没有任何差错，但是我们可以提前考虑，万一发生预期之外的错误，我们要如何处理来让损失最低。不要让用户等待由用户触发的交互操作，应立即给予响应。立即响应不等于立即呈现数据，有些异步操作，无法立即呈现数据给用户，但应马上给予loading提示，告知用户数据正在处理中。下面的代码中，用户点击编辑按钮时，会先发起一个异步请求，拿到数据结果后再显示弹窗。这个短暂且没有任何提示的等待，会让用户认为是程序卡顿，体验不畅，间接诱导用户重复点击按钮。正确的做法应该是先展示弹窗，再去请求数据。三元和if该怎么选？ // 如果条件表达式后面跟的是返回值，建议使用三元运算，如下方的例子，就可以优先考虑使用三元运算 // good a > b ? 1 : 2 // bad if (a > b) { return 1 } else { return 2 } // 其他复杂的分支代码，写成三元可能并不利于阅读，建议使用if语句，如下面的例子 // good if (a > b && b !== 0) { val = a + b } else { val = a - b } // bad a > b && b !== 0 ? val = a + b : val = a - bwhile和for该怎么选？for循环往往是用来遍历一个固定长度的可迭代对象，遍历的次数一定是<=可迭代对象的长度，如数组遍历、对象遍历等等；for和while在绝大部分场景下都可以互换，只是部分场景下，使用while会更符合我们的直觉。while循环往往用于 不定次数的条件执行 ，即达到目标条件就终止，但我们事先并不知道达到这个目标条件需要进行多少次执行。举个例子，我们希望从1开始，取前10个能整除3或5的数字，参考如下代码： let numArr = [] let i = 1 while (numArr.length < 10) { if (i % 3 === 0 || i % 5 === ) { numArr.push(i) } i++ }while在某些场景下，可以代替递归函数。比如我们希望得到100以内的斐波那契数列： // 使用递归 function fib (prev = 0, next = 1) { if (next < 100) { return [next, ...fib(next, prev + next)] } return [] } // 使用while functon fib2 (n = 100) { let prev = 0 let next = 1 let result = [] while (next < n) { result.push(next) const temp = prev prev = next next = next + temp } return result }上面的例子很难用for循环去实现，因为我们并不知道100以内存在多少个斐波那契数字，但知道终止条件是数字必须小于100，因此更适合用while循环来实现。再来说说递归和while，递归往往在代码量上来看是简洁的，但本质上它是一个N层的函数嵌套，所以直觉上不易理解，且耗性能（不考虑尾递归优化的前提下）；while循环只有一层嵌套，所以直觉上更容易理解，且性能更优。这里并不是说递归不好，不推荐大家使用，一来性能并不是大家首先要考虑的问题，二来while只能在部分场景中来代替递归。
