泊头西环网站建设,哈尔滨网络公司代理商,郑州企业网站建设,百度网站上做推广受骗APK 瘦身的主要原因是考虑应用的下载转化率和留存率#xff0c;应用太大了#xff0c;用户可能就不下载了。再者#xff0c;因为手机空间问题#xff0c;用户有可能会卸载一些占用空间比较大的应用#xff0c;所以#xff0c;应用的大小也会影响留存率。
1 APK 的结构
…APK 瘦身的主要原因是考虑应用的下载转化率和留存率应用太大了用户可能就不下载了。再者因为手机空间问题用户有可能会卸载一些占用空间比较大的应用所以应用的大小也会影响留存率。
1 APK 的结构
包含以下目录
assets/包含了应用的资源这些资源能够通过 AssetManager 对象获得lib/包含了针对处理器层面的被编译的代码。这个目录针对每个平台类型都有一个子目录比如 armeabiarmeabi-v7aarm64-v8ax86x86_64 和 mipsres/包含了没被编译到 resources.arsc 的资源META-INF/包含 CERT.SF 和 CERT.RSA 签名文件也包含了 MANIFEST.MF 文件
包含以下文件
classes.dex包含了能被 Dalvik/Art 虚拟机理解的 .dex 文件格式的类resources.arsc包含了被编译的资源。该文件包含了 res/values 目录的所有配置的 xml 内容。打包工具将 xml 内容编译成二机制形式并压缩。这些内容包含了语言字符串和 styles还包含了那些内容虽然不直接存储在 resources.arsc 文件中但是给定了该内容的路径比如布局文件和图片所以又叫资源映射表AndroidManifest.xml包含了主要的 Android 配置文件。这个文件列出了应用名称、版本、访问权限、引用的库文件。该文件使用二进制的 .xml 格式存储
主要是针对 lib/ 、res/ 和 classes.dex 进行瘦身 2 图片优化
2.1 一套图片资源
图片优化主要是针对多套图片资源的问题。
Android 常见分辨率
ldpi320 x 240mdpi480 x 320hdpi 800 x 480xhdpi1280 x 720xxhdpi1920 x 1080
因为 APP 在加载图片时会优先加载对应分辨率文件夹下的图片如果在对应的分辨率文件夹下没有所要的图片就会找高分辨率文件夹下的图片。那么如果我们把所有的图片都放在高分辨率的文件夹下是不是就可以了呢并不是这样做会导致低分辨率手机加载图片时会消耗更多的内存。
2017年后Android 手机一般大小在 5 寸以上分辨率至少是 720p1080p所以对应的 dpiDots Per Inch 每英寸点 分别为
1280 x 7205 寸的手机对应的 dpi 大约是 300dpi1080 x 19205 寸的手机对应的 dpi 大约是 440dpi
对于绝大多数 APP 来说只需要取一套设计图就足够了。鉴于现在分辨率的趋势建议取 720p 的资源放在 xhdpi 目录。相对于多套资源只使用 720P 的一套资源在视觉上差别不大很多大公司的产品也是如此但却能显著的减少资源占用大小身边也能减轻设计师的出图工作量了。
注意这里不是说把不是 xhdpi 的目录都删除而是强调保留一套设计资源就够了。
2.2 使用 TinyPNG 有损压缩
TinyPNG 工具只支持上传 PNG 图片到官网上压缩然后下载保存在保持 alpha 通道的情况下对 PNG 的压缩可以达到 1/3 之内而且用肉眼基本上分辨不出压缩的损失。
TinyPNG 的官方网站http://tinypng.com/
2.3 使用 jpg 格式
如果对于非透明的大图jpg 将会比 png 的大小有显著的优势虽然不是绝对的但是通常会减小一般都不止。
在启动页活动页等之类的大图展示区采用 jpg 将是非常明智的选择。
2.4 使用 webp 格式
webp 支持透明度压缩比 jpg 更高且显示效果却不输 jpg官方评测 quality 参数等于 75 均衡最佳。
相对于 jpg、pngwebp 作为一种新的图片格式限于 android 的支持情况暂时还没用在手机端广泛引用起来。从 Android 4.0 开始原生支持但不支持包含透明度直到 Android 4.2.1 才支持显示含透明度的 webp使用的时候要特别注意。
官方介绍https://developers.google.com/speed/webp/docs/precompiled
2.5 缩小大图
如果经过上述步骤之后你的工程里面还有一些大图考虑是否有必要维持这样的大尺寸是否能适当的缩小。事实上由于设计师出图的原因我们拿到的很多图片完全可以适当的缩小而对视觉影响是极小的。
2.6 覆盖第三库里的大图
有些第三方库里引用了一些大图但是实际上并不会被我们用到就可以考虑用 1x1 的透明图片覆盖。这样会导致 drawable 文件下包含了一些莫名其妙的名称的 1x1 图片…
2.7 SVG
对于位图图像来说其的大小是固定的分辨率低占的内存空间小分辨率高占的内存空间大。
SVGSVG 意为可缩放矢量图形Scalable Vectors Graphics使用 XML 格式定义图像适用简单的小图标。
首先在 res 包目录下点击 New — Vector Asset 进入 Configure Vector Asset 窗口 选择 Local file (SVG, PSD)选择要导入的 svg 图片 点击 Next — Finish 导入成功 使用 在 apk 包的 drawable 目录下是 .xml 文件而不是 .png 使用 svg 可以不用考虑图片的分辨率、大小、颜色等信息。.xml 的性能比 .png 更好占用内存更少转换成机器码的效率更高。
如果 SVG 文件包含不受支持的功能将在 Vector Asset Studio 的底部显示一个错误提示。不支持的功能
滤镜效果不支持投影模糊和颜色矩阵等效果文本建议使用其他工具将文本转换为形状 Tint 着色器可以直接在 xml 文件中修改矢量图的颜色但是并不建议直接修改我们一般用 Tint 着色器去修改矢量图的颜色
selector xmlns:androidhttp://schemas.android.com/apk/res/androiditem android:color#00ff00 android:state_pressedtrue /item android:colorandroid:color/black /
/selectorImageViewandroid:idid/ivandroid:layout_width60dpandroid:layout_height60dpandroid:clickabletrueandroid:focusabletrueandroid:srcdrawable/fanhuiapp:tintcolor/selector_back_color /使用 .svg 格式的图片转换成 vector 格式的文件不同大小不同颜色的图片只需要一个文件就可以了实现了。
矢量图是由点与线组成和位图不一样它再放大也能保持清晰度而且使用矢量图比位图设计方案能节约 3040% 的空间现在谷歌一直在强调扁平化方式矢量图可很好的契合该设计理念。
优势
占用内存空间小无限拉伸不会出现锯齿可以照顾不同尺寸的机型Android Studio 自带很多资源减小 UI 的工作量
劣势
只支持 5.0 及以上的系统与位图相比多了一层计算需消耗更多的性能不支持 .9 图不适合表现真实照片和复杂图形一般使用在简单的 icon 和动画上
3 动态库打包配置
在 Android 开发中so 库是不可或缺的。so 库指的是动态链接库也就是在运行时载入内存的库文件。在 Android 应用程序中使用 so 库可以大大降低内存的使用提高系统的性能。so 库文件的产生主要有两种方式
使用 C/C 编写的 Native 代码将 Native 的 C/C 代码编译为 so 文件通过 Java Native Interface(JNI) 的方式使用 so 文件使用第三方的 so 库文件例如 FFmpeg、OpenCV 等开源库
so 库是由 ndk 编译出来的动态库是 C/C 写的所以不是跨平台的即每一个平台需要使用对应的 so 库。
ABI 是应用程序二进制接口简称Application Binary Interface定义了二进制文件尤其是 .so 文件如何运行在相应的系统平台上从使用的指令集内存对齐到可用的系统函数库。
在 Android 系统上每一个 CPU 架构对应一个 ABIarm64-v8aarmeabi-v7aarmeabix86_64x86mips64mips。现在我们一般只需要配置 arm64-v8a。
arm64-v8a第 8 代 64 位 ARM 处理器。目前国内的应用生态正在向 64 位架构过渡移动芯片平台也将逐步弱化对 32 位应用的支持兼容 armeabi-v7a、armeabiarmeabi-v7a第 7 代及以上的 AMR 处理器兼容 armeabiarmeabi第 5、6 代的 ARM 处理起早期的手机用的比较多x86_6464 位的平板X86平板、模拟器用的比较多mips64/mips极少用于手机可以忽略
在 build.gradle 构建脚本中配置 ndk 编译的动态库 CPU 架构类型
android {defaultConfig {ndk {abiFilters armeabi-v7a, arm64-v8a, x86, x86_64}}
}按照以上配置打包时会将 4 种 CPU 架构的动态库都配置到 APK 中。事实上绝大多数的应用都不需要配置全架构的动态库arm64-v8a 架构的 CPU 可以向下兼容
android {defaultConfig {ndk {abiFilters arm64-v8a}}
}4 移除无用资源
Android Studio 给我们提供了一键移除所有无用的资源如下所示 但是这种方式不建议使用因为如果某资源仅存在动态获取资源 id 的方式那么这个资源会被认为没有使用过从而会直接被删除。
动态获取的方式getResources().getIdentifier(“name”, “defType”, getPackageName())
另外一种方式是通过 Analyze Code 手动移除无用资源 搜索 unused resources 选择搜索范围 无用资源 5 代码压缩-混淆
长类名改为短类名长方法名改为短方法名变量名改变删除无用代码缺点启用后编译较慢混淆可能导致编译出错或其他 bug。debug 模式下最好不要做混淆因为做了混淆之后方法名、类名都会发生变化不容易定位 bug。
buildTypes {debug {minifyEnabled false // 不做混淆proguardFiles getDefaultProguardFile(proguard-android-optimize.txt), proguard-rules.pro}release {minifyEnabled true // 做混淆shrinkResources trueproguardFiles getDefaultProguardFile(proguard-android-optimize.txt), proguard-rules.pro}
}minifyEnabled 用来开启删除无用代码比如没有引用到的代码。
shrinkResources 用来开启删除无用资源也就是没有被引用的文件drawable、layout实际上并没有删除只是保留文件名但是没有内容。但是需要知道资源是否被引用需要配合 minifyEnabled 来使用只有当两者都为 true 的时候才能真正的删除无效代码和无用资源。
资源压缩只与代码压缩协同工作。
默认情况未启用严格模式严格模式是指清除掉资源本身非严格模式指的是只清除资源内容如需启动则设置 shrinkMode创建 keep.xml如下
?xml version1.0 encodingutf-8?
resources xmlns:androidhttp://schemas.android.com/toolstools:shrinkModestrict 如果开发者想要特定保留或者必须移除的资源可以进行自定义配置
tools:keep指定要保留的资源如果有多个资源保留需要用逗号隔开Tools:discard指定要移除的资源如果有多个资源移除需要用逗号隔开
?xml version1.0 encodingutf-8?
resources xmlns:toolshttp://schemas.android.com/toolstools:discardcolor/selectortools:keeplayout/l_used*_c,layout/l_used_a,layout/l_used_b*tools:shrinkModestrict!-- 该设置支持 * 通配符设置 --!-- shrinkModestrict: 该模式只保留在代码或者资源文件中明确引用的资源--!-- shrinkModesafe: 该模式会保留所有明确引用的资源以及可能被 Resources.getIdentifier() 动态引用的资源--/resources6 动态加载 so 库
Java 加载 so 库的方式有两种
静态加载System.loadLibrary(String libname)参数为 so 库名称位于 APK 的 lib 的目录下。采用此种方式是要将 so 库打包进 apk 或者 jar 包中的动态加载System.load(String filePath)参数为 so 库在磁盘中的完整路径可以加载磁盘中的 so 库文件
//加载的是 jni_mix.so注意的是这边只需要传入 jni_mix
static {System.loadLibrary(jni_mix);
}
//传入的是 so 文件完整的绝对路径
System.load(/data/data/[packagename]/lib/jni_mix.so)静态加载会导致 apk 包比较大所以采用动态加载 so 库的形式也就是从网络上下载放入本地数据目录下。这样做的好处是不仅减小了 apk 的大小而且可以随时使用最新的依赖库这也是动态加载的最多的用途之一。
用动态加载技术编译前不把 so 文件放入 jniLibs 目录原因很多比如想减少安装包的大小自然打包生成的安装包也不包含该 so 库。接着在手机上安装这个 apk 并启动 APP如果 APP 的运行不涉及到 jni 方法的调用那就当 so 不存在如果 APP 打开某个页面而该页面又需要调用 jni 方法则 APP 自动到指定地址下载需要的 so 文件然后保存到用户目录并从用户目录加载该 so最后再调用 jni 方法。
步骤一下载 so
步骤二拷贝 so 至私有data目录
步骤三通过绝对路径加载 so
7 插件化压缩包
通过插桩式来实现加载插件AssetManager 加载资源和 java 文件
插件化开发就是将整个 APP 拆分成很多模块每个模块都是一个 APK最终打包的时候将宿主 APK 和插件 APK 分开打包插件 APK 通过动态下发到宿主 APK。
插件可以放到服务器加载。
8 删除无用的语言资源
在 resources.arsc 文件下可以查看支持的语言 大部分应用其实并不需要支持几十种语言的国际化支持。比如只支持中文、英文
android {defaultConfig {resConfigs zh, en // 支持中文、英文}
}去除无用资源之后 9 shape 背景、着色、在线化素材、避免重复库
9.1 使用 shape 背景
特别是在扁平化盛行的当下很多纯色的渐变的圆角的图片都可以使用 shape 实现代码灵活可控省去了大量的背景图片。
9.2 使用着色方案
相信你的功能里面也有很多 selector 文件也有很多相似的图片只是颜色不同通过着色方案我们能大大减轻这样的工作量减少这样的文件。
借助 android support 库乐意实现一个全版本兼容的着色方案参考代码 DrawableLess.java
9.3 在线化素材库
如果你的 APP 支持素材库比如聊天表情库的话考虑在线加载模式因为往往素材库都有不小的体积。
这一步需要开发者实现在线加载一方面增加代码的复杂度一方面提高了 APP 的流量消耗建议酌情选择。
避免重复库
避免重复库看上去是理所当然的但是秘密总是藏得很深一定要当心你引用的第三方库又引用了哪个第三方库这就很容易出现重复的库了比如使用了两个图片加载库Glide 和 Picasso。
通过查看 exploded-aar 目录和 External Libraries 或者反编译生成的 APK尽量避免重复的库的大小减小 APP 大小。
10 清除冗余代码
版本迭代过程中因为删减功能经常有冗余代码和第三方库留下这或多或少都会增加包体这种情况下没有捷径只能每个文件查找这是苦力活。还有要查看第三方库有没有可能精简比如谷歌分基础、广告和分析包网络库、supportv4 等这个就具体情况具体分析了不多阐述。
11 使用微信资源压缩打包工具
微信资源压缩打包工具通过短资源名称采用 7zip 对 APP 进行极致压缩实现减小 APP 的目标效果非常好强烈推荐。
建议开启 7zip注意白名单的配置否则会导致有些资源找不到官方已经发布 AndResGuard 到 gradle 中了非常方便。
12 Provided 编译
对于一些库是按照需要动态加载的可能在某些版本并不需要但是代码又不方便去除否则编译不过。
对于 provided 可以保证代码编译通过但是实际打包中并不引用第三方库实现了控制 APP 大小的目标。
但是也同时就需要开发者自己判断不引用这个第三方库时就不要执行到相关的代码避免 APP 崩溃。
参考
【Android】浅谈APP的瘦身之路 Android SO库的详细阐述 安卓APK安装包arm64-v8a、armeabi-v7a、x86、x86_64有何区别如何选择 【转】android中的armeabi、armeabi-v7a、arm64-v8a及x86等 【Android 安装包优化】动态库打包配置 ( “armeabi-v7a“, “arm64-v8a“, “x86“, “x86_64“ APK 打包 CPU 指令集配置 | NDK 完整配置参考 )
