摘要：图片懒加载简单的来说就是一些需要加载的图片，我们先使用占位的方式用于判断是否存在视图内。简单的替换图片进行这种获取转换的方法可以看出来上面这段代码实际上是很糟糕的。并且还携带一些属性。图片增加的处理。
图片懒加载
简单的来说:
就是一些需要加载的图片，我们先使用占位的方式(用于判断是否存在视图内。)，减少网络下载图片对首屏渲染的压力，从而使得首屏更快的load
(以下希望结合源码服用)
step 1：第一步肯定是run一个简单的demo能实现替换占位符。并且进行判断是否在view视图内。
https://github.com/ZWkang/jav...
这个demo可以看得出，是实现了之前提到的几点。
它使用offset类的api进行获取位置，并进行遍历,再计算从而获得相对整个视图的位置。简单的替换图片进行这种获取转换src的方法
可以看出来上面这段代码实际上是很糟糕的。它没有任何的封装
它没有可以让我输入的配置
它的获取性能太低效。（我们应该知道offset之类的api为了获得大小，总会触发一次Reflow，来进行位置的获取。）
它支持项太少了。只支持了我们特定的data-src
step 2:前端迭代过程我们可以发现。很多时候新的api的出现，是一部分是为了支持新的特性，一部分是为了弥补不够用
前面说到很低效的offset类api
并不够用。所以出现了
此处经过一段时间的思考
https://github.com/ZWkang/jav...
进行迭代到这一版、
事实上这一版的代码写的也是非常的糟糕的。因为我的es6在那个时候并不是很好。
可以在变量的声明上看出。很多时候我是没转变过来的。但是那不影响
简单的讲一下
首先当然是声明一些将被缓存的变量
然后可以发现，这一版本引入了Setting可配置。
lazyload是一个对象，一些实例方法挂载在上面。这里没有用class之类的，也就是使用，下面会说一下这种写法。页面共享一个实例。
在这一版我们引入了getBoundingClientRect
使用getBoundingClientRect来判断。明显是比较高效的。而且性能损耗并不会比offset类的高。
可以说这一版解决了第一版我们发现的几个问题。
引入了配置。UMD的模块写法。获取的api判断是否在视图内优雅降级。支持了更多项，srcset backgroundImage(当然对于srcset的处理其实并没有很好的方法。它还是有一些坑的。)
当然我们可以看看这样写法的用处。
我们可以很简单的侵入式的使用在vue上。
https://github.com/ZWkang/sim...
可以看看这个。核心代码基本是完全一致的。
只是获取元素需要在渲染后获取。不然会导致获取不了元素。当然这个涉及到了vue的执行时机。
Vue.use(lazy, {
background: true,
backgroundTag: "data-background",
imgSrc: true,
imgTag: "data-src",
parent: null,
srcset: false,
srcsetTag: "data-srcset",
delayTime: 200,
rendered: function () { },
deleleData: true,
firstLoad: true
})
在use 安装的时候设置配置文件，注入在vue组件的实例实际上在这个时候就已经有了对应的配置
updated: function () {
this.lazyload.init({})
},
destroyed: function () {
this.lazyload.cache = []
}
然后只需要简单的配置就可以使用我们的lazyload组件了。
实际上这种方法。是完全的将vue当成普通的html dom来处理了。
很多vue的高级东西并没有用到。但是这样确实是很简单不是么。
而这样子的做法很便捷，但是也有缺陷。那就是，多个子组件的时候。
你的组件init初始需要放在相对的父级组件使用，而不是多个子组件使用。。
更好的方式是应该使用一个component的组件来承载整个lazyload的流程
step 3:其实上面步骤的lazyload组件已经是可用了。
那么第三版我们还可以对它进行什么改造。
https://github.com/ZWkang/jav...
在第三版我们引入一个更新的api
IntersectionObserver
这个observer也是更为强劲。它可以直接进行判断是否在视图内，有一个boolean的处理值。并且还携带一些属性。
使用也很简单。
只需要new初始化时候传入对应的回调函数。然后observe element节点即可
第三版我们还可以进行更好的优化
例如加入loading图片 error图片 之类的配置文件
并且将我们的逻辑代码更抽象，例如一些判断的if else 可以用iife直接判断返回一个函数
减少一些if else的判断。而是在第一次解析的时候就确定了。
这里。我们可以看一下代码职责分离 耦合度低的好处
我在第二版写的srcChange 是独立的函数，传入对应的节点处理对应的事情。
而在第三版即使我们添加新的处理api
这个srcChange也是完全复用的。是完全。
图片增加loading error的处理。
就是new Image代理我们获取图片。onload成功之后就再替换。预加载的原理跟这个差不多，预加载就是将所有图片获取再进行Image获取
唔。大概这个时候这个lazyload插件就到达可用的程度了(当然可不可用我也不知道，因为我没有在实际情况下生产情况使用（欢迎使用后的反馈），从简单测试来看，它是可行的)
我很喜欢写小demo，因为它不大。我可以任意重构，想怎么搞就怎么搞。
唔。很欢迎很欢迎交流啊！！！！！！
但是不要喷我。我读书少，你喷不赢我的。最后是祝福语。
希望阅读这篇文章能有一点点帮助到你。
也厚脸皮求一下下star。当然该仓库还有一些宝藏~~
Intersection_Observer_API
getBoundingClientRect API
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/88763.html
摘要：前端优化已经是一个被写烂的题材了。前端模板方案有很多。重绘是浏览器性能优化的一个重点，特别是针对的优化。如果你对前端性能优化有自己的想法，欢迎骚扰我。 前端优化已经是一个被写烂的题材了。 虽千万人吾往矣，这里我仅分享我的一些实践经验。 欢迎一起交流 欢迎关注我的个人公众号，不定期更新自己的工作心得。 showImg(https://segmentfault.com/img/remote...
摘要：前端优化已经是一个被写烂的题材了。前端模板方案有很多。重绘是浏览器性能优化的一个重点，特别是针对的优化。如果你对前端性能优化有自己的想法，欢迎骚扰我。 前端优化已经是一个被写烂的题材了。 虽千万人吾往矣，这里我仅分享我的一些实践经验。 欢迎一起交流 欢迎关注我的个人公众号，不定期更新自己的工作心得。 showImg(https://segmentfault.com/img/remote...
摘要：前端优化已经是一个被写烂的题材了。前端模板方案有很多。重绘是浏览器性能优化的一个重点，特别是针对的优化。如果你对前端性能优化有自己的想法，欢迎骚扰我。 前端优化已经是一个被写烂的题材了。 虽千万人吾往矣，这里我仅分享我的一些实践经验。 欢迎一起交流 欢迎关注我的个人公众号，不定期更新自己的工作心得。 showImg(https://segmentfault.com/img/remote...
阅读 1617·2021-11-22 14:45
阅读 1063·2021-11-17 09:33
阅读 3322·2021-09-02 09:48
阅读 970·2019-08-30 15:54
阅读 2767·2019-08-30 15:53
阅读 2553·2019-08-30 12:54
阅读 2241·2019-08-29 12:37
阅读 2421·2019-08-26 13:58
