Face第一天——App瘦身

本文介绍了18种有效的App瘦身技巧,包括去除无用语言资源、开启代码混淆、使用tinypng有损压缩、采用webp格式等,帮助开发者减少APK体积,提升用户体验。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

App瘦身
.App瘦身是指在不减少App功能的前提下,通过一些技巧将打包出来的APK的体积尽可能减少。
这样做的好处
加快用户的下载速度
提升用户下载体验(就是减少用户下载流量,减少下载时间)
如果不进行瘦身,默认打包的APK会包含所有未曾用到的源代码,资源文件等,极大的增加了APK的体积.
1.去除无用的语言资源
.通过resconfigs可以选择只打包哪几种语言,从而去掉各种arr包中的全世界各种语言,尤其是support中的
.选择保留什么语言要根据产品的市场来定,如果只选择中文语言,应该配置

android{
defaultConfig{
resConfigs"zh"
}
}

第2条:开启minifyEnabled混淆代码
.在gradle使用minifyEnabled进行Proguard混淆的配置,可大大减小APP大小:
.代码混淆主要目的是增加反编译解读源码的难度,提高应用安全性。但是它同时的确带来了代码量的减少,虽然减少的可能不是特别显著。
.在proguard中,是否保留符号表对APP的大小是有显著的影响的,可酌情不保留,但是建议尽量保留用于调试。详细proguard的相关的配置和原理可自行查阅。
3.开启shrinkResources去除无用资源
.在gradle使用shrinkResources去除无用资源,效果非常好。

android { buildTypes { release { shrinkResources true } }}

shrinkResources 用来开启删除无用资源,也就是没有被引用的文件( 经过实测是drawable,layout,实际并不是彻底删除,而是保留文件名,但是没有内容,等等 ),但是因为需要知道是否被引用所以 需要配合mififyEnable使用,只有当两者都为true的时候才会起到真正的删除无效代码和无引用资源的目的
4.使用一套资源
.对于绝大多数APP来说,只取一套设计图就足够了。鉴于现在分辨率的趋势,建议使用720p的资源,放在xhdpi目录(1080p)
.相对于多套资源,只使用720p的一套资源,在视觉上差异不大,很多大公司的产品也是如此,但却能显著的减少资源占用大小,顺便也能减轻设计师的出图工作量了(注意:这里不是说把不是xhdpi的目录都删除,而是强调保留一套设计资源就够了)
5. 使用tinypng有损压缩
. TinyPNG使用一种智能有损压缩技术(通过降低图片中的颜色数量,来减少存储图片所需的数据)来降低PNG图片的大小这样的压缩对图片的效果影响是很小的,但是可以大大降低图片的大小,并且还能保持png的alpha透明度
因为TinyPNG将PNG图片压缩成8位的PNG(而不是24位),所以它的压缩比例非常高,至少都是50%以上的压缩比例,有些甚至可以达到70%,并且压缩之后的图片和原图人眼看不出来
6.使用jpg格式
.PNG包含了图片一些和显示效果无关的信息,转换为JPG,体积也会变小,且转换之后的图片和原图人眼看不出来,如果图片中没有透明度的要求,可以将png图片转换为jpg图片.但如果png进行过有损压缩可能会让转换后的图片文件变大.
.如果对于非透明的大图,jpg将会比png的大小有显著的优势,虽然不是绝对的,但是通常会减小到一半以上。在启动页,活动页等之类的大图展示区采用jpg将是非常明智的选择。
7.使用webp格式
.webp支持透明度,压缩比例比jpg更高但显示效果却不输于jpg(官方评测quality参数等于75均衡最佳)。相对于jpg、png,webp作为一种新的图片格式,限于android的支持情况暂时还没用在手机端广泛应用起来。从Android 4.0+开始原生支持,但是不支持包含透明度,直到Android 4.2.1+才支持显示含透明度的webp,使用的时候要特别注意。 
8.缩小大图
.如果已经使用了webp格式,你的工程里面还有一些大图,考虑是否有必要维持这样的大尺寸,是否能适当的缩小。事实上,由于设计师出图的原因,我们拿到的很多图片完全可以适当的缩小而对视觉影响是极小的.
9.覆盖第三库里的大图
.有些第三库里引用了一些大图但是实际上并不会被我们用到,就可以考虑用1x1的透明图片覆盖。你可能会有点不舒服,因为你的drawable下竟然包含了一些莫名其妙的名称的1x1图片…
10.删除armable-v7包下的so
.基本上armable的so也是兼容armable-v7的,armable-v7a的库会对图形渲染方面有很大的改进,如果没有这方面的要求,可以精简。这里不排除有极少数设备会Crash,可能和不同的so有一定的关系,请大家务必测试周全后再发布。
11.删除x86包下的so
.与删除armabe-v7包下的so不同的是,x86包下的so在x86型号的手机是需要的,如果产品没用这方面的要求也可以精简。建议实际工作的配置是只保留armable、armable-x86下的so文件,算是一个折中的方案。
12.矢量图
.矢量图是由点与线组成,和位图不一样,它再放大也能保持清晰度,而且使用矢量图比位图设计方案能节约30~40%的空间,现在谷歌一直在强调扁平化方式,矢量图可很好的契合该设计理念。 
—优势 
(1)占用存储空间小 
(2) 无极拉伸不会出现锯齿,可以照顾不同尺寸的机型 
(3)Android Studio自带很多资源,减小UI工作量 
—劣势 
(1) 只支持5.0及以上系统 
(2) 与位图相比多了一层计算,需消耗更多性能 
(3) 不支持.9图 
(4) 不适合表现真实照片和复杂图形,一般使用在简单的icon和动画上
13.使用shape背景
.特别是在扁平化盛行的当下,很多纯色的渐变的圆角的图片都可以用shape实现,代码灵活可控,省去了大量的背景图片。
14.使用着色方案
.相信你的工程里也有很多selector文件,也有很多相似的图片只是颜色不同,通过着色方案我们能大大减轻这样的工作量,减少这样的文件。 借助于android support库可实现一个全版本兼容的着色方案,参考代码: DrawableLess.java
15.在线化素材库
.如果你的APP支持素材库(比如聊天表情库)的话,考虑在线加载模式,因为往往素材库都有不小的体积。这一步需要开发者实现在线加载,一方面增加代码的复杂度,一方面提高了APP的流量消耗,建议酌情选择。
16.清理第三方库和冗余代码
.版本迭代过程中,因为删减功能经常有冗余代码和第三方库留下,这或多或少都会增加包体,这种情况没有捷径,只能每个文件查找,这是苦力活。还有要查看第三方库有没可能精简,比如谷歌分基础、广告和分析包,网络库、supportv4等,这个就具体情况具体分析,不多阐述。
17.支持插件化
.插件化技术支持动态的加载代码和动态的加载资源,把APP的一部分分离出来了,对于业务庞大的项目来说非常有用,极大的分解了APP大小。因为插件化技术需要一定的技术保障和服务端系统支持,有一定的风险,如无必要(比如一些小型项目,也没什么扩展业务)就不需要了,建议酌情选择。
18.避免重复库
.避免重复库看上去是理所当然的,但是秘密总是藏的很深,一定要当心你引用的第三方库又引用了哪个第三方库,这就很容易出现功能重复的库了,比如使用了两个图片加载库:Glide和Picasso。通过查看exploded-aar目录和External Libraries或者反编译生成的APK,尽量避免重复库的大小,减小APP大小。

评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值