We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
在混合应用(webview 方式)中,我们需要对图片进行必要的优化,使用户在流量、速度与体验上取得平衡。
优化图片的常用手段就是根据用户设备所处的网络环境、屏幕分辨率等,对网页需要加载的图像进行优化处理,在快、省、好中寻找平衡点。
影响优化策略的维度有多个:
由于不同的网络环境在图片加载的表现上差异巨大,同样大小的图片,在 wifi 环境和在 2G 环境下的差距可能有 10 多秒。所以需要基于不同的网络环境做全面的优化策略分析。
模拟一下场景,比如在 2G 环境下,可能尝试将图片降质 50%,以减小流量损耗,加快加载速度,但是降质的图片不应该让用户感觉很模糊。试想满屏糊糊的图片,看着心里真的难受。那么可以考虑将图片的质量提高一点,缩小图片尺寸以降低图片大小。
在图片的尺寸与质量之间调节是必然需要折腾的一件事。除此之外我们也能根据操作系统和浏览器折腾图片格式,比如 WebP。WebP 格式的图像大小只有 JPG 格式的三分之二,非常适合在移动端使用。目前除了 IOS safari 不支持外,安卓阵营都支持 WebP 格式图片。
屏幕分辨率也是需要考虑的因素,比如 2 倍屏可以在 wifi 下使用 2 倍图,在 4G 下使用 1.5 倍图等。目前市面上的屏幕尺寸种类很多,但是分辨率只有区区几种。前者可以通过 CSS 样式加以处理,而后者必须通过多套不同尺寸的图片加以解决。
尝试性的调整策略后,通过反馈数据分析出比较合适的方案,以用于之后的图片优化。
页面中的图片都应该通过懒加载方式,由 JS 判断是否需要露出,需要的时候再加载。而上面的方案就可以在懒加载的过程中加以实施。
在懒加载执行的时候,由网络环境、屏幕等因素决定使用哪一套图片。由于图片域一般支持图片的热处理,以灵活地调整图像尺寸、质量。根据图片域的热处理规则,拼接出符合方案的图片 URL 进行替换。相应环境下的图片就优化完成了。
对于没有图像处理功能的静态域,就只能通过规范图片命名方式实现图片 URL 替换了。比如原图名叫 a.jpg,那么 2 倍图可以叫 a_x2.jpg,质量 80% 的图可以叫 a_q80.jpg 等。由原图生成的所有图片规格需要能够覆盖优化方案中的所有的格式、尺寸和质量。
a.jpg
a_x2.jpg
a_q80.jpg
有时候网页首屏是必须直出的,避免用户感觉卡顿。这时候我们不希望通过客户端执行 JS 进行懒加载处理图片,而是通过浏览器直接进行加载,提升网页的呈现速度。
如果是首屏直出 HTML ,那么在面对其中的图片进行优化呢?
这个事情就需要 APP 帮忙解决一下了,比如将原始 HTML 读入内存后,根据优化策略,进行 URL 替换。之后 webview 加载优化后的 HTML 内容。这时候直出的图片就已经是经过策略优化后的。
当然为了避免 APP 在优化过程中的时间损耗,可以在空闲时且网络环境允许的情况(比如 wifi)下预先进行上面的操作,在后台将网页悄悄的提前优化完,就类似我们网页中 dns-prefetch 等。
dns-prefetch
以上方案仅供参考。
The text was updated successfully, but these errors were encountered:
No branches or pull requests
混合应用中的图片优化策略与实施方案
在混合应用(webview 方式)中,我们需要对图片进行必要的优化,使用户在流量、速度与体验上取得平衡。
优化图片的常用手段就是根据用户设备所处的网络环境、屏幕分辨率等,对网页需要加载的图像进行优化处理,在快、省、好中寻找平衡点。
## 优化策略分析
影响优化策略的维度有多个:
- 网络环境决定图像质量
由于不同的网络环境在图片加载的表现上差异巨大,同样大小的图片,在 wifi 环境和在 2G 环境下的差距可能有 10 多秒。所以需要基于不同的网络环境做全面的优化策略分析。
模拟一下场景,比如在 2G 环境下,可能尝试将图片降质 50%,以减小流量损耗,加快加载速度,但是降质的图片不应该让用户感觉很模糊。试想满屏糊糊的图片,看着心里真的难受。那么可以考虑将图片的质量提高一点,缩小图片尺寸以降低图片大小。
- 操作系统/浏览器决定是否采用 WebP
在图片的尺寸与质量之间调节是必然需要折腾的一件事。除此之外我们也能根据操作系统和浏览器折腾图片格式,比如 WebP。WebP 格式的图像大小只有 JPG 格式的三分之二,非常适合在移动端使用。目前除了 IOS safari 不支持外,安卓阵营都支持 WebP 格式图片。
- 屏幕分辨率决定图像大小
屏幕分辨率也是需要考虑的因素,比如 2 倍屏可以在 wifi 下使用 2 倍图,在 4G 下使用 1.5 倍图等。目前市面上的屏幕尺寸种类很多,但是分辨率只有区区几种。前者可以通过 CSS 样式加以处理,而后者必须通过多套不同尺寸的图片加以解决。
尝试性的调整策略后,通过反馈数据分析出比较合适的方案,以用于之后的图片优化。
## 实施方案 ### 懒加载与热处理
页面中的图片都应该通过懒加载方式,由 JS 判断是否需要露出,需要的时候再加载。而上面的方案就可以在懒加载的过程中加以实施。
在懒加载执行的时候,由网络环境、屏幕等因素决定使用哪一套图片。由于图片域一般支持图片的热处理,以灵活地调整图像尺寸、质量。根据图片域的热处理规则,拼接出符合方案的图片 URL 进行替换。相应环境下的图片就优化完成了。
对于没有图像处理功能的静态域,就只能通过规范图片命名方式实现图片 URL 替换了。比如原图名叫
a.jpg
,那么 2 倍图可以叫a_x2.jpg
,质量 80% 的图可以叫a_q80.jpg
等。由原图生成的所有图片规格需要能够覆盖优化方案中的所有的格式、尺寸和质量。### 模版直出
有时候网页首屏是必须直出的,避免用户感觉卡顿。这时候我们不希望通过客户端执行 JS 进行懒加载处理图片,而是通过浏览器直接进行加载,提升网页的呈现速度。
如果是首屏直出 HTML ,那么在面对其中的图片进行优化呢?
这个事情就需要 APP 帮忙解决一下了,比如将原始 HTML 读入内存后,根据优化策略,进行 URL 替换。之后 webview 加载优化后的 HTML 内容。这时候直出的图片就已经是经过策略优化后的。
当然为了避免 APP 在优化过程中的时间损耗,可以在空闲时且网络环境允许的情况(比如 wifi)下预先进行上面的操作,在后台将网页悄悄的提前优化完,就类似我们网页中
dns-prefetch
等。以上方案仅供参考。
Thanks
The text was updated successfully, but these errors were encountered: