产品：“能否将apk的大小优化如下，这样更容易推广！”
我：“不！”
产品：“能否将apk的大小优化如下，这样更容易推广！”
我：“不！”
产品：“能否将apk的大小优化如下，这样更容易推广！”
我：“我考虑一下！”
面对这样的产品我们怎能怯懦！我写代码很轻松！
不过回想起来，这和写代码有关系啊！
好了，投诉环节结束了！
今天我们将讨论一些优化apk大小的方法：
一些奇怪的apk 优化技巧！
svg的使用与优化
Tint着色器的使用和优化
资源打包配置优化
动态库的打包配置优化
删除无用资源（物理和非物理删除）
代码混淆
webp 转换（API 级别18）
资源混淆
这要求API级别最低为18，基本上可以满足现在的需求了！
这使用起来非常简单。只需右键单击所选图像并选择转换为Webp.它就会直接转换！图像越大，节省的尺寸就越多！
基本上我优化的时候都是围绕以上几个方面进行的。与之前没有优化过的项目相比，我至少可以减少30%的体积！不信你可以在你的项目中尝试一下！可以肯定地说，我开车不稳，车翻了！
1.svg的使用和优化
首先我们先来了解一下svg是什么。百度百科是这么说的！其实我们只需要关注主要概念就可以了！可缩放矢量图形。事实上，人类的文字是在不同大小的地方显示的，不会变形！具体概念看百度百科就可以了！
方便大家演示！这里呢？我特地找到了一个叫阿里矢量图的网站。从该网站，您可以下载各种矢量图形。接下来怎么办？没有了。
下载之后呢？将会出现一个丑陋的IE浏览器图标，后缀为.svg！如何使用这个？强大的android studio已经为我们准备好了！
res-new-vector 资源
稍后会弹出类似的内容
前一个红框是系统图标，后一个是本地图标！这样你就会生成一个以.xml结尾的图标！
里面的代码大概是这样的！
其实里面的具体语法我也不太了解。应该在指定区域内分成宽度和高度相等的部分，然后填充！有兴趣的话可以自己去了解一下！
如果用了的话，就会和之前的src不一样了！一定要这样用！
app:srcCompat='@drawable/ic_arrow_back_black_24dp'
这里很多人会有两个疑问？
这与apk 大小优化有什么关系吗？
艺术家往往会给出很多图片，所以你不能一张一张地转换它们，对吗？
针对以上两个问题，我们分别来说一下：
1.首先，svg是可缩放的矢量图像，那又怎样呢？您只需在项目中添加一个SVG 即可替换之前艺术家给您的相应图片集。这会同时减少几张图片。你认为这重要吗？其次，将svg转换为xml后，尺寸也相应减小。这真的是翻倍了！但是，但是，但是。这需要适应，适应，适应！他妈的0.0！据说Android适配起来真是难受啊！来看看解决办法吧！将以下内容添加到app-build.gradle 中的defaultConfig 标记中：
//5.0兼容适配
//5.0以下将svg图片生成为指定尺寸的png图片。下面写几个，就会生成几个对应的图像。
vectorDrawables. generatedDensities('xhdpi','xxhdpi')
//5.0及以上使用support-v7进行兼容。
矢量Drawables.useSupportLibrary=true
这是我找到的解决方案，但我编译了它并尝试了一下。如果我只是在上面写这句话，图片就会在相应的文件夹中生成，但是如果写下面这句话，相应的图片就没有了！我很好奇，为什么？然后我找到了对应的手机并尝试了一下。上面这句话加不加都没有用！我在19版本上测试过！像这样的手机确实很难找。如果不是我父母，我根本就找不到它！所以呢？我们想一想！
2.大神已经帮我们解决这个问题了！
下面是批量转换工具！俗话说，没有什么能难倒程序员！ （对我不起作用）
威震天/SVG-Android
下载这个jar包-svg2vector-cli-1.0.1.jar
那就来一波小单吧！卡卡卡
2.Tint Shader的使用和优化
不知道大家在开发的时候是否有过这样的经历呢！使用状态选择器时，是否需要使用两个相同颜色和不同颜色的相同图像？其实可以使用tint属性来完成（不过这里指的是那种纯色图片，你应该只做彩色的，除非你想把它们变成纯色！）
其实很简单，把它添加到如图所示的图片中即可
app:tint='颜色值'
这样你就可以改变图像的颜色，但是状态选择器呢？如何使用？其实很简单！我们看下面的代码！
我们先看一下两个状态选择器的代码：
?xml 版本='1.0'编码='utf-8'？
也许你想知道，为什么两张照片是一样的？以后看到你就明白了！
?xml 版本='1.0'编码='utf-8'？
其实原理就是这样，那状态选择器呢？只需通过色调的状态选择器更改图片的颜色即可！
但这里有几点需要注意：
颜色状态选择器必须位于颜色文件夹中；
设置tint时，使用app作为前缀，否则低于5.0会报错；
如果设置svg 图像，请使用srcCompat。如果是普通图片，则使用src。
基本上这个级别的优化到这里就结束了！
3.资源打包及配置优化
其实这个标题有点夸张，但其实就是删除不必要的语言！
也许你没有注意到，但是当你使用Android Studio查看你的apk时，你会看到这样的东西！
我的框架里哪里用了很多中文？你会好奇地问吗？我没设置语言？这一切从何而来？事实上，它包含在v7 包中！其实我们一般的应用不会涉及到这些语言！所以我们可以只留下其中的一个或几个。具体怎么做呢？其实只有一行代码。
只需将这句话添加到应用程序的build.gradle中的defaultConfig中即可！
resConfigs('zh-rCN'')
其实这里可以添加多个，只需用逗号连接即可！
优化后就是这个样子了！
4、动态库的打包配置
其实说到动态库，基本上都是.so引入的动态库。其实这里还有很大的优化空间！其实可以解压较大的项目，但是so文件的类型没有那么多！
平时我们开发的时候基本都是这样写的！
sourceSets{ main{ jniLibs.srcDirs=['libs'] } }
然后
ndk{ abiFIlters('armeabi','armeabi-v7a','xxx'.) }
是不是每次导入百度语音等第三方库的时候，文档都是这么说的，我们就这么搞啊！但实际上我们不需要那么多架构！
以下是一些常用的：
armeabi真机
x86 模拟器
其实如果我们真的开发的话，直接使用armeabi就可以了。如果你制作的是定制的apk，可以添加其他的，但如果是普通的手机应用，这里只需要armeabi即可！
如果您不知道该使用哪一个怎么办？你可以解压较大的项目，看看其他人使用了哪些并使用它们！哈哈
5.删除无用资源（物理和非物理删除）
5.1 物理删除（无法找回，谨慎使用）
关于物理删除，很多人不建议这样使用，因为这样真的没有节操！这里有两个问题：
如果你的项目没有项目管理的话，真的不建议用这种方式，因为删了之后真的找不到了！实在是找不到（如果用git的话，就拉个分支用力敲吧）！
如果有反射或者动态加载ids(ids.xml)，直接删除！可能会报错！
好了，前提已经解决了！不要删除它，稍后再找到我。
选项一：
重构-删除未使用的资源.
这里会出现一个包含三个选项的框：
（重构）第一个直接删除。
（预览）第二个会在下面弹出提醒，让你选择性删除。
(取消)取消
选项二：
按名称分析-运行检查
这里会弹出一个框输入
未使用的资源
然后会弹出一个框。只需单击上面的圆圈，然后单击“确定”即可。你会发现底部会出现相应的无用资源。如果您不使用其中任何一个，只需根据右侧的提示将其删除即可。
再次强调，这是物理删除，一旦删除就没有了！
5.2 非物理删除
事实上，我估计谷歌之父已经考虑过这个问题了。其实还有一种非物理删除，就是混乱期间！相信大家在困惑的时候都写过这句话吧！
收缩资源true
一开始我不知道那是什么，后来看到别人说是启动资源压缩！
不过，如果你见过压缩后的apk，这个资源压缩使用的是占位符，而不是删除对应的文件！
其实这个资源压缩还有一个有趣的点。您可以自定义保留的内容：
res-raw-keep.xml 自定义要保留的内容
这是在Google 文档中写的！但我真的不知道为什么要保留它？出于什么原因？请知道的人给我指导一下！
6. 代码混淆
我不打算在这里谈论这个。网上有很多代码混淆可用！基本上固定模板加上你引入的第三方库的混淆就可以了（只要注意实体类，我每次都忘记了）！
7. webp转换（api级别18）
百度百科关于webp是这样解释的。这要求API级别最低为18，基本上可以满足现在的需求了！
这使用起来非常简单。只需右键单击所选图像并选择转换为Webp.它就会直接转换！图像越大，节省的尺寸就越多！看看对应的换算就知道了！
这里再多说一句，有这个图片压缩网站其实很好！每次艺术家给我一张图片时，我都会选择压缩它以节省一些体积！关键是这个网站可以批量上传，这才是重点！然后你就可以再次进行webp 了！其实我个人觉得没必要用webp，除非引导图片是……比较大的图片！只是个人感觉。
推荐阅读：
Android开发该往哪里走？ —— Android程序员的焦虑
2019字节跳动腾讯Android面试必答题：性能优化+JNI+布局+WebView
用户评论
做安卓开发几年了，也遇到过类似情况，和产品经理沟通优化 APK 尺寸确实不是容易的事，他们总觉得体积小一点用户体验会不会更差啊。 唉…
有16位网友表示赞同！
写的真是太好了！我最近也在努力压缩 APK 体积，很多技巧都没有见到这个总结里，比如代码混淆、资源裁剪等，看来还有好多路可以探索呢!
有10位网友表示赞同！
以前以为优化APK体积很简单，只要删除没用的图片和代码就好了。现在发现问题远比我想象的复杂多层吧！特别是产品方面的压力…
有7位网友表示赞同！
我有个奇葩的产品经理，他觉得用户下载速度不快是运营的问题，我们开发团队就要专注于其他更重要的事物！每次都让我无话可说…
有20位网友表示赞同！
分享了这么深入的总结，真的帮助到很多Android工程师了！尤其是那些刚入门的菜鸟，可以作为很好的入门指南，避免一些弯路！
有12位网友表示赞同！
五年的经验啊！这篇文章看得真切実感，产品总是把优化APK体积当成负担的最后手段，哎… 希望开发者们多沟通，让产品经理明白我们的苦衷！
有19位网友表示赞同！
虽然我还没毕业，但对Android开发很有热情。看了这篇总结，决定好好学习一下APK体积优化的技巧，在未来实践中应用！相信以后能为我的工程做出贡献！
有16位网友表示赞同！
这篇文章确实揭开了很多行业的黑幕，产品经理总是把优化视为附加任务，完全不理解开发者的难处！真是无语了...
有15位网友表示赞同！
Android开发是个挑战性的领域，需要不断学习进步。感谢这位工程师分享经验，也希望更多人参与到APK体积优化的探讨中来，共同推动行业发展！
有16位网友表示赞同！
总结很到位，尤其是对产品经理的吐槽部分，哈哈！我也曾被产品的过度要求，逼到崩溃！但还是要保持乐观的心态，努力克服眼前的困难！
有6位网友表示赞同！
我从业多年，对于Android开发和apk体积优化已经比较熟悉了。不过这篇总结依然很有参考价值，有些细节之处让我受益匪浅，值得每一个开发者收藏起来！
有20位网友表示赞同！
产品经理就是最难搞的群体…他们永远不理解我们开发者的苦楚！希望以后能更多尊重开发者的专业意见，让APK体积优化成为双方共同的目标！
有11位网友表示赞同！
这篇文章从一个深受“产品虐”的工程师的视角出发，把 APK 体积优化的真实情况呈现得淋漓尽致。读完之后，更加坚定了自己精益求精的态度，不断提升自己的技术能力！
有5位网友表示赞同！
作为一名开发新人，看到这篇总结收获满满！原来APK体积优化是一个这么复杂的过程，需要考虑那么多因素。以后我会更加注意这些细节，希望能在未来做出优秀的Android应用！
有6位网友表示赞同！
产品经理的思维方式真的令人捉摸不透…他们总是把用户的需求和产品的目标放在第一位，却忽略了开发者的现实困境！
有8位网友表示赞同！
apk体积优化是一个永恒的难题 作者总结经验非常珍贵，希望能激发更多开发者关注这个问题，一起探索更有效的方法！
有19位网友表示赞同！
五年的经验确实很丰富，文章语言简洁明了，关键点概括精炼，对于想深入了解 apk 体积优化的同学很有帮助！
有9位网友表示赞同！
作者的经历让我感同身受！产品经理总是觉得apk体积小一点用户体验就差很多，这真是个误区…希望越来越多的人认识到APK大小对用户的真实影响！
有6位网友表示赞同！