1 、我是怎么思考这件事情的
APK是平台安装包的资料格式 ，关于这个议题其实是一个老生常谈的题目 ，不论是公司内部，还是外部网络 ，前人前辈已经总结出很多方法和规律。蓝莓mt5外汇交易平台不过随着移动端技术近两年的飞速推动 ，一些新的思维方法和优化方法也逐渐涌现和成熟起来 。笔者在实践流程中踩过一些坑 ，收获了一些经验 ，在这里做个思考和总结 ，所以随笔给大家 ，希望对大家从事有关工作的时候有所帮助和参考，并且也是抛砖引玉，希望大家共同探讨这个开放性的议题 。
关于为什么APK要瘦身，这个不多说 ，只从三个方面唠叨一下，对于读者（或者客户）来说 ，APK越大，在获取安装流程中 ，他们耗费的流量会越多，安装等待时间也会越长；对于产品本身，意味着获取转化率会越低（因为竞品中 ，读者有更多机会选择那个体验最好 ，作用最多 ，性能最好 ，包最小的蓝莓外汇监管牌照）；对于研发来说 ，是一种优化优化技术的机会。
欲瘦身 ，我们先找找胖的原因和难题 。按方向－路径－资源的思维模式，BBMarkets外汇平台找原因和难题有如下几条路径 ，一是拍脑袋 ，按自己的经验和判断 ，甚至是主观想象；二是去查找引擎找关键字，逛各种技术论坛听技术大牛们怎么说，看各类技术素材抽取提炼；三是用一种可测量的软件或者方法发现难题 。
前两种不赘述，我这里说说第三种方法 。用一种可测量的软件或者方法来解读，所谓工欲善其事 ，必先利其器 。这个器可以可以自己锻造 ，也可以用现成的 。这里精选一个在线apk解读软件 ，因为是外部软件 ，所以大家请在利用流程中 ，不要提交未发布出去的产品 ，为了数据保养 ，笔者这里拿一个上开源的项目作为瘦身示例 。
2 、寻找难题
是美国哥伦比亚大学的博士创业团队研发出来的解读 app性能指标的平台 ，解读的方法有静态和动态两种方法，其中静态解读可以解读出APK安装包中大资料排名榜 ，各种知名SDK的大小以及占代码整体的比例 ，各种类别资料的大小以及占排名 ，各种知名SDK的方法数以及占所有dex中方法数的比例，废话不多说 ，下面上高清无码大图看看颜值吧 。
如果想利用解读作用解读自己的TMGM外汇官网产品 ，请登录并提交自己产品的apk包 ，所有作用目前均免费利用 ，如果是想解读 Play上已经发布的产品 ，可以直接打开"Play Apps"查看 ，还可以利用查找作用根据软件名和包名查看结论 。再次重申下 ，请不要提交任何未发布的产品 。
登录
提交apk资料
解读结论摘要 ，可以看到一些概览的数据 ，apk资料大小 ，总的方法数
资料大小解读详情页，大资料列表 ，这里列出的是apk资料中超过100k的资料排名 ，这里的资料大小指的是apk资料中的大小
各种知名SDK的大小以及占代码整体的比例 ，这里目前能识别出 ， JSON , Play , , Glide, , SDK, , Gson等等 ，表示App中自己编写的代码部分
各种类别资料的大小以及排名
各种知名SDK占所有dex中方法数的比例
各种知名SDK的方法数排名榜
看完这个apk内剖图是不是有一种神清气爽的感觉！我把这个解读软件比做我们家买的智慧体重秤 ，可以称体重 ，脂肪含量，骨重，骨密度 ，肌肉含量等等 ，那么 ，我们是不是发现了一些难题 ，进而把这些难题和我们之前靠经验和一拍脑袋的原因可以用逻辑联系在一起。
那么 ，我们接下来可以通过解读数据归纳出我们的优化方向
大资料排名榜里 ，有11张png资料的大小超过了100k，记住 ，这可是压缩之后的啊；
大资料排名榜里 ，.arsc的大小接近2M ，这也是一个优化点；
大资料排名榜里 ，.dex接近3M ，.dex是代码的载体 ，这块的优化需要细分 ，再去看看细分SDK的排名榜；
组件占比环图里 ， , JSON 和 Play 是三方库的前三甲；
资料类别排名榜里，png, dex 和arsc是前三甲；3、梳理优化方向
所以我们的方向是没有蛀牙 ，不对，是下面的方向：
png图像优化；
.arsc资料的优化；
代码优化
3.1图像优化的尝试
首先是第一个方向，图像的优化 ，慢点 ，我们看看这些图为什么这么大先 ，精确的说 ，为什么这些图在apk（其实就是zip资料）里这么大，好了，上软件解读 。
这次用了一些简单的软件组合 ，平台自带的cmd就好 。
命令落实的结论如下
恩 ，所有的png资料居然是STORE的方法存储到apk里的 ，关于zip里的STORE和，详见 )
通俗的说，当资料是的方法存储到zip，表示这个资料并没有经过压缩 ，如果是Defl:N的方法 ，表示通过 的方法压缩存储到zip 。
这看起来有点不合理 ，png原封不动的放入zip，当然最后产出的apk会对比大。那么，如何处理呢 ？笔者首先尝利用 的方法 ，发现和都未能处理难题 。在上发现一个开源项目 ，试了集成到项目中 ，再看结论如下：
优化前：
字节
优化后 ：
普通zip压缩： 字节 （压缩了将近17%）
采用7zip压缩 ：字节 （压缩了将近19%）
再看看这个软件做了什么，对比下开启资源混淆前后
优化前
优化后
资源（png, xml, jpg等）名称混淆 ，资源路径名称混淆以及名称长度压缩；
原来以方法存储到zip中的png资料被改成了（普通压缩存储）方法；
意外发现.arsc, META-INF/*.SF 以及 META-INF/*.MF变小了 ，而且是解压之后的资料大小也变小了 。
用apk反编译神器jadx内窥apk寻找真相
原来apk中资源（png, xml ，以及资料）的相对路径会存放到META-INF/*.SF 以及 META-INF/*.MF中并为每个资源资料计算SHA1值并存储在这两个资料中 ，至于为啥这么做以及这两个SHA1有啥区别和作用请参考网络上关于这方面知识的素材 ，已超出本文的主题所以这里不再赘述 。
对于.arsc资料
很容易看出来它是资源资料索引表 ，所以 ，看到这里大家应该明白这三个资料为啥会变小了吧 。
3.2一次意外的发现
顺着.arsc往下看，发现一个有趣的东西 ，
这又将成为一个优化点 ，去除那些没用的翻译资源 ，引入一些第三方的SDK ，往往这些SDK带了很多翻译资源在里面 ，比如 库 ，去掉后我们来看看效果 。
假设我们只保留英文 ，当然只是个实验 ，现实中看具体现状了，
采用7zip压缩：字节 （压缩了将近22% ，再提升3个点）
当然 ，真实的项目里不可能这样 ，但是蚊子肉也是肉啊 ！
其实 ，我想说的是这供给了一种优化思路 ，就是利用的配置干掉无用的资源，同样的可以用在so本地库上 ，分辨率（配置已）上 。
配置示例如下 ：
记得包在{}中间哦 。那么 ，有人要问了 ，abi里肿么没有x86 ？据说intel供给了一个处理计划叫，是一个运行在x86终端上的中间件 ，可以将arm转码为x86的指令 ，不过效率很低 ，有些运算型的 ，比如计算MD5和SHA1，甚至不如java ，笔者曾经做过测试对比，又是另外一个议题，此处不赘述 ，感兴趣的读者可以移步。
到此为止 ，我们已经在朝第一个方向迈进 ，不经意间发现了第一个方向和第二个方向之间的关系 ，所以利用资源混淆软件 ，达成了第二个方向 。
利用7zip压缩，我们对整个包进行了2个点的压缩 ，这是一个超出预期的成果 。
3.3图像优化的方法
关于第一个方向，我们的路径还没有终止 ，拍脑袋想出来的路径是压缩png，非alpha图转成jpg ，还有什么？所以去各种技术论坛逛了一圈 ，请教了各种技术大牛，梳理的路径如下 ：
1 、手动lint检查 ，手动删除代码中没有引用到的资源 ，实际效果不等。
在 中进入“” 然后选择" Code..." ，规模选择整个项目，然后打开"OK"
配置如下图
2 、脚本中开启
脚本参考如下
配合利用效果更佳 ，详见用法以及注意
采用7zip压缩：字节 （压缩了将近23% ，再提升1个点）
3 、利用图像压缩软件 ，压缩png图的大小 ，将非alpha的图转换成jpg方法 ，关于这点同事以及网络上的大牛们已经归纳的很具体了 ，我这里做简单总结 ，欲知详情 ，请见附录的参考。
利用 ，我只想说咱们在公司做产品 ，此计划慎用 ，提交任何未发布产品的素材到外部网络 ，都有可能引起数据泄漏，所以慎用此计划。下面说替代计划 。
以上软件太散，有没有集成化的软件，答案是“有”
@心伦 童鞋开发的
@姐夫童鞋开发的er
png转成jpg格式 ，具体效果不等 。
4 、终极大杀器 ，png转成webp ，关于webp ，更多详情请参考谷歌官方文档以及安卓开发者在线参考
先上效果图 ：
采用7zip压缩：字节 （压缩了将近53% ，再提升30个点）
没看错吧 ，是30个点 ，目前apk的大小是初步apk大小的一半不到 ，而我做的，一行代码木有改动 ，仅用了一些软件而已 ！
说人话 ，我木有吃减肥药 ，木有绝食 ，体重却轻了一半 ！！ ！
但是，目前却没能用到项目中 ，因为有两个坑
关于第一个方向 ，图像资源的优化 ，就写到这里了。
3.4代码优化
第二个方向已达成 ，剩下第三个方向 ，代码的优化 ，梳理如下优化路径 ：
1 、开启的代码优化
将
le('-.txt'),'-.txt'
改为
le('--.txt'),'-.txt'
开启代码优化后的注意点请参见附录。
2 、去除无用的库
如果apk拥护的最低平台是API14,而代码中没有用到高于api14的api就可以思考拿掉整个 库 。
3、用更小的库替代计划
如果只用到了谷歌汇总 ，那么就不要把整个 play 都集成进来 ，只集成需要的部分 。
4 、定期清理废弃的代码
定期删除无用的逻辑和过期的业务作用模块 ，以及废弃的A/B test代码 。
5 、业务模块采用插件化框架 ，代码动态从云端拉取
插件化 ，这是另外一个课题了 ，这里不赘述 。
apk瘦身记最后的成果
字节压缩到字节, 压缩了将近53%
总结脚本中开启资源混淆和资源压缩
用7zip代替zip
脚本中开启代码混淆优化和无用资源删除
用更小的图 ，利用压缩软件压缩图像大小
去除无用的资源 ，语言 ，本地so库，二方三方库和分辨率
用更小的库
尝试将 库彻底踢出你的项目
定期清理代码
尝试用H5编写画面 ，图像云端获取
尝试插件化业务模块
寻找到zip资料夹中所有用STORE方法存储的资料（不限于raw目录下），尝试压缩 ，以及替代计划启动这些资源
尝试webp的图像启动计划 ，寻求突破
最后 ，继续学习和尝试新的优化计划
以此文献给“唯瘦身与产品不可辜负”的技术们！！ ！
附录
如何做到将apk大小下降6M
APP终极瘦身指南
APK瘦身实践
发表评论