JS图片懒加载能大幅提升页面加载速度，结合摄像头加载指定图片的场景，则需要更精细的优化来保证流畅体验。
理解JS图片懒加载的核心原理
懒加载的工作机制
图片懒加载的核心是延迟加载非可视区域的图片，直到用户滚动到图片附近才触发加载，实现时，通常将图片的真实URL存放在data-src属性中，src属性只放一个占位图或留空，当图片进入视口时，JavaScript将data-src的值赋给src，浏览器开始下载图片，这套机制减少了首屏请求数，节约带宽,尤其适合图片密集的页面。
为什么需要懒加载
据统计，页面中超过60%的图片资源在首屏时并不需要立即展示，如果全部加载，会拖慢首次渲染时间，增加用户等待焦虑，业内专家指出，懒加载可以让首屏加载速度提升40%以上，同时降低移动端数据消耗，对于摄像头获取的图片（如用户拍照后上传的预览）,懒加载同样能避免同时解码大量图片导致界面卡顿。
图片懒加载的常见实现方式
基于IntersectionObserver的实现
现代浏览器推荐使用IntersectionObserver来监听图片是否进入视口，这种方式不需要频繁计算滚动位置,性能更好且代码简洁。
const observer = new IntersectionObserver((entries) => {
entries.forEach(entry => {
if (entry.isIntersecting) {
const img = entry.target;
img.src = img.dataset.src;
observer.unobserve(img);
}
});
});
document.querySelectorAll('img[data-src]').forEach(img => observer.observe(img));
基于scroll事件的传统实现
在不支持IntersectionObserver的旧浏览器中，可以监听scroll、resize或orientationchange事件，结合getBoundingClientRect()判断图片位置，但需要做节流（throttle）处理，避免频繁触发，行业内通常使用requestAnimationFrame或lodash.throttle来优化。
库和框架的选择
- lazysizes：功能全面，支持响应式图片和自动计算,社区活跃。
- vanilla-lazyload
：轻量级，无依赖,适合简单场景。
- vue-lazyload（Vue专用）或 react-lazyload（React专用）：与框架深度集成,使用方便。
选择时需考虑项目体积、兼容性以及对摄像头场景的支持（如动态添加的图片节点），多数情况下，IntersectionObserver原生实现已足够,无需额外库。
摄像头加载指定图片的场景与挑战
移动端拍照后的图片处理流程
当用户通过摄像头拍照或从相册选择图片时，前端会拿到一个Blob或File对象，为了在页面上展示，通常需要创建一个本地URL：URL.createObjectURL(file)，如果用户连续拍摄多张照片，这些本地URL会占用大量内存，且如果不加控制地同时加载,可能造成浏览器卡顿甚至崩溃。
如何将摄像头获取的图片进行懒加载
将摄像头图片与懒加载结合，核心思路是：不要立刻将本地URL赋值给所有图片的src，而是像普通图片一样，用data-src存储本地URL，只有图片进入视口时才真正赋值，这样，即使一次拍摄了20张照片，首屏只会显示前几张，后面的图片并不会立即解码,内存占用大幅降低。
具体做法：
- 拍摄完成后，生成图片列表，每个图片的
data-src设置为URL.createObjectURL(blob)。 - 使用
IntersectionObserver监听这些图片，进入视口时赋值给src。 - 当图片被移除或不再需要时，及时调用
URL.revokeObjectURL释放内存。
注意事项
- 内存管理：
createObjectURL创建的URL必须手动释放，否则会泄漏，建议在图片加载完成后或组件销毁时调用revokeObjectURL。 - 图片方向：手机拍摄的图片可能包含EXIF方向信息，直接使用
createObjectURL可能导致显示不正确，可以使用canvas或第三方库（如blueimp-load-image）进行方向校正。 - 加载状态：摄像头图片通常是本地文件，加载速度极快,但仍然需要处理加载失败或用户取消的情况。
实战：结合摄像头与懒加载的完整示例代码
获取摄像头图片
使用<input type="file" accept="image/" capture="environment">调用摄像头，或通过navigator.mediaDevices.getUserMedia实时获取视频流,这里以拍摄后选择为例：
const input = document.getElementById('cameraInput');
input.addEventListener('change', (e) => {
const files = e.target.files;
for (let file of files) {
const url = URL.createObjectURL(file);
// 将url存入data-src，并创建img元素
const img = document.createElement('img');
img.dataset.src = url;
img.classList.add('lazy');
container.appendChild(img);
}
// 对新添加的图片重新注册观察者
observeNewImages();
});
懒加载显示
使用IntersectionObserver观察所有lazy图片：
function observeNewImages() {
const images = container.querySelectorAll('img.lazy:not(.loaded)');
images.forEach(img => observer.observe(img));
}
const observer = new IntersectionObserver((entries) => {
entries.forEach(entry => {
if (entry.isIntersecting) {
const img = entry.target;
img.src = img.dataset.src;
img.onload = () => {
img.classList.add('loaded');
URL.revokeObjectURL(img.src); // 释放内存
};
observer.unobserve(img);
}
});
});
代码注意事项
- 在
onload回调中释放revokeObjectURL,确保图片已经显示。 - 如果图片加载失败，需要处理
onerror,避免一直占用内存。 - 对于大量图片（如连续拍摄100张），仍然建议使用分页或虚拟滚动，懒加载只解决展示问题,不解决DOM节点过多的问题。
性能优化与最佳实践
图片格式选择
摄像头拍摄的原始图片通常是JPEG或HEIC，体积较大，在前端展示前，可以先用canvas压缩到合适尺寸（如宽度不超过1200px），再创建Blob用于懒加载，这样既减少了内存占用，也加快了加载速度，行业共识认为，将图片压缩到100-200KB左右,在移动端依然能保持较好的视觉效果。
预加载策略
对于摄像头图片，用户通常期望快速看到第一张，可以在用户拍照后，立即将第一张图片的src赋值为createObjectURL，跳过懒加载，称为“首张优先”，后续图片再按需懒加载,这种策略在相册类应用中非常常见。
错误处理
- 网络异常：摄像头图片是本地文件，不存在网络错误，但可能因格式问题导致解码失败，可使用
onerror事件,替换为占位图或提示用户重新拍摄。 - 权限问题：调用摄像头前检查权限，若用户拒绝，给出友好提示,并回退到相册选择。
- 内存溢出：拍照数量过多时，建议限制同时存在的图片DOM数量（例如最多50张）,超出部分用虚拟滚动或覆盖方式替换。
Q&A：JS图片懒加载与摄像头加载指定图片常见问题
问：摄像头拍照后生成的图片懒加载有什么特别之处？
答：主要区别在于图片来源是本地Blob，加载速度极快，但仍需注意内存释放和方向校正，懒加载本身逻辑与远程图片一致，但必须及时调用URL.revokeObjectURL避免内存泄漏，同时处理EXIF方向问题,否则图片可能显示颠倒。
问：如何让摄像头加载的图片在滑动时不卡顿？
答：关键点在于控制同时解码的图片数量，懒加载只解码视口内的图片，但若用户快速滑动，大量图片同时进入视口并触发解码，仍可能卡顿，建议对IntersectionObserver设置rootMargin为负值（如rootMargin: '-100px 0px'），让图片提前加载，但不要一次性加载过多，压缩图片尺寸和格式（如使用WebP）能显著降低解码压力。
问：js图片懒加载代码在移动端适配时需要注意什么？
答：移动端需考虑触摸事件和滚动性能，使用IntersectionObserver是最佳选择，避免监听scroll事件导致的频繁计算，注意src属性在低端设备上赋值时的重绘开销，可将图片先隐藏（display:none）再显示，减少布局抖动，对于摄像头图片，建议限制单次拍摄数量，并利用requestAnimationFrame分批处理DOM插入。
首发原创文章，作者：王坚，如若转载，请注明出处：https://test.idctop.com/article/537556.html
