APK的瘦身设计计划 1 APK瘦身前言
在开发流程中；由于业务的扩展；平台的迭代；第三方的集成等开发工作 ，我们安装包越越来越大；引发获取安装的流程中越来越慢.作用到读者的体验 ，瘦身的目的最明显的一个就是：提高获取转化率 。怎么理解呢？举个例子来说，假如我们的盛钱包成长版软件包20MB+,有100个潜在读者想要去获取尝试利用你的软件 ，在移动网络的蓝莓外汇平台现状下 ，结论有20个读者嫌弃安装包太大而直接放弃 ，有30个读者在等待获取的流程中取消获取 ，在wifi现状最后只有50个读者获取安装了软件 。这时你的软件的实际获取转化率其实是50/100 =50% 。
另外一个；apk的瘦身；可以为读者节省不少的流量；对我移动设备流量不多的人；是一个福音啊....
简单的总结 ：安装包越小 ，读者获取等待的时间越短 ，对移动设备配置要求的也越小 ，终端的体验愈佳 ，软件的获取转化率也就越高 。
2 APK安装包的蓝莓MT4交平台台组成架构解读
开展瘦身前 ，需要先了解一下APK都主要由哪些成分组成.我以盛代宝目前安装包的解读结论图如下 ：
（TIP:比例解读构成图（比例会自动按从大到小排好序呈现）
(TIP ：目前盛代宝经过优化打出的包的大小是6.33M)
1 .dex编写的所有的富拓外汇开户Java代码（包括各种引入的sdk代码）最后转化成在虚拟机上运行需要的字节码 2 res资料夹存放所有资源资料夹（除了里面raw资料夹的资料不会被编译 ，其他都会被编译） 3 .arsc编译后的二进制资源资料 4 资料夹用于保存需要保持初步资料的资源资料（这部分资源不会被编译） 5 lib 存放一些不同cpu 架构的so资料 6 .xml程序全局配置资料 7 META-INF资料夹存放几个签名校验有关的资料 ，用于保证APK的完整性和保养性 8其他一些配置生成的资料 APK瘦身精简素材概要
APK 的瘦身 主要针对、.dex、lib 、res素材进行精简.
1 减.dex资料——混淆压缩代码 第一 ，现在写的app 基本都是经过混淆了的,如果不混淆, 发布出去,别人一反编译 就可以直接看你的源码了 ，一般为了提高保养性会选择混淆；加大了反编译后阅读理解的难度. 第二；代码通过混淆之后在一定的程度上减小软件体积. 混淆不仅能将代码中的类名 、字段、方法名变为无意义的名称 ，保护代码 ，也由于移除无用的类、方法 ，并利用简短名称对类、字段 、方法进行重命名缩小了程序的大小 。 第三 开启混淆的步骤 ： A要通过开展代码压缩，在build.资料内相应的构建类别中添加 true 。
B 就是制定 混淆规则的资料, 默认生成了-rules.pro 资料
C 混淆规则定义
目前网络上现在大部分都有混淆模板 ，以及在 上也有混淆的插件可以集成 插件；一般都是基于混淆模板上去添加自己想要的XM外汇官网混淆规则 ，一般遵循以下混淆规则
###-----------基本配置-不能被混淆的------------###-
-keep class * .app.
-keep class * .app.
-keep class * .app.
-keep class * .app.
-keep class * ..
-keep class * ..
-keep class * .app..
-keep class * ..
###-----------.v4/v7包不混淆------------###-
###-----------保持不混淆------------###-
###-----------保持 不混淆------------###-
###-----------不混淆资源类------------###-
###-----------保持 方法不被混淆------------###-
###-----------保持自定义控件类不被混淆------------###-
###-----------保持枚举 enum 类不被混淆------------###-
###-----------保持自定义控件类不被混淆------------###-
###-----------保持实体类不被混淆------------###-
###-----------保持jar包不被混淆------------###-
###-----------保持反射有关的类和方法不被混淆------------###-
###-----------保持 与js互相调用的类 不被混淆------------###-
###-----------保持注解继承类不混淆------------###-
Tip:另外如果我们项目软件到第三方sdk 的混淆；如百度 ，友盟 ，极光等一般都是从官网上供给的混淆规则里复制；避免出现意外的错误
第四 移除废弃作用的代码
不要只是注释 ，担心可能以后会用到。因为一般的开发都会利用平台运维软件git svn等 ，所以这种担心是多余的 。
第五定期检验项目代码的习惯
发现有重复作用实现的代码或者框架要及时重构，删除重复部分的代码和框架。出现重复作用代码的情景大多如下 ：已经有了的作用代码或框架 ，团队成员不知道自己又写了一套或者引入另外的相同作用的框架 。这种现状的发生也反映出你们团队之间的沟通存在一定的难题 。有可能是个人经验难题 ，也有可能是整个团队的规范 ，共识难题 ，引发大家都不重视 。
第六业务模块采用插件化框架
插件化 ，一种懒启动思想的体现，先让读者能够安装宿主包，对于一些作用模块做插件化 ，在特定的时机再获取安装 。
(Tip 比如现在对比火的Small ，滴滴插件；还有360插件化，有空可以研究研究以下；绝对有好处)
2 精简
放在下的资料不会生成ID,存放的资料方法可以是多样的比如音频 、图像 、html,配置数据有关的等等 ，精简体积也就是精简这些素材。
(1)音频 ：主要用在铃声和通报方面 ，体积不要太大 ，利用压缩格式的音频 (2)图像 ：在不降低图像效果 、保证APK呈现效果的前提下缩小图像资料大小,可以利用进行图像压缩 (3)WEB画面 ：可以思考利用7zip压缩软件对该资料进行压缩 ，在正式利用的时候解压 3 减.arsc资料
简单介绍下.arsc资料出处与作用：除了和res/raw资源被原装不动地打包进APK之外 ，其它的资源都会被编译或者应对 。除了资源之外 ，其它的资源都会被赋予一个资源ID 。打包软件主管编译和打包资源 ，编译完成之后 ，会生成一个.arsc资料和一个R.java ，前者保存的是一个资源索引表 ，后者定义了各个资源ID常量 ，供在代码中索引资源 。所有的png资料是以STORE的方法存储到apk里的 ，通俗的说 ，当资料是的方法存储到zip，表示这个资料并没有经过压缩，现在业内有一个开源的插件针对以上原理进行了一定的压缩；它就是如下压缩插件
微信资源压缩插件 ：其原理就是 ：(可以研究一下；或许有意外的收获) (1)对资源（png, xml, jpg等）名称混淆 ，资源路径名称混淆以及名称长度压缩 (2)将原来以方法存储到zip中的png资料改成（普通压缩存储）方法 。 4减lib资料夹
lib目录用于存放通过C或C++编写编译生成的so资料（库/JNI开发）
目前市场上主流的架构还主要是arm架构 ，所以如果不是必要的话 ，可以思考不拥护x86和mips架构 ，但这并不意味着CPU是x86或mips架构的移动设备就不能正常安装利用APK了，因为放在arm目录下的so库是可以兼容到其他架构的；
另外arm架构中的eabi-v7a相比于eabi只是在图形渲染方面有了很大的优化，所以如果so库对图形渲染没有很高的要求的话 ，完全可以把so库只存放在arm eabi目录中 ，这样可以大大减小APK的体积 。
lib瘦身主要是减小对 CPU 架构的拥护，配置起来很简单 ，在 build. 利用 配置需要用到的 CPU 架构，并将不需要兼容的 so 资料从项目中移除即可 。一般只要拥护和x86就够了示例代码块如下 ：
5减res资料夹
res资料夹里面主要就是包括各种布局资料 ，value资料 ，图像资料 ，原生资料 。这一块的应对计划主要采用2种方法 ，一是压缩资源 ，二是删除未利用的资源 。
(1)压缩图像,一般而言图像压缩对减小Apk大小所产生的效果占到你所有减小Apk努力的效果50%以上,精选一款目前所知图像压缩效果最好的网站, 我举个例子；你能看得出下面压缩之后的差别吗 ？
(2)移除无用的资源 这里的移除无用的资源 ，主要是指2个方面 ，一是在工程里面直接删除没有利用的资源 ，二是不打包没有利用的资源 。
A) 在工程里面直接删除没有利用的资源 选中项目右键 =>=>
B)不打包不需要利用的资源利用 开启 的 进行构建打包 ，这时候没有被利用的资源将不会打进包里
(3)尽量只保存一份图像资源
开发目录下会有个或者目录用于适配不同dpi的屏幕 ，画面尺寸 ：480*800 、720*1280 、1080*1920 (美工在切图是基于一套分辨率进行切图)目前市面上绝大部分机型都处于的适配规模 ，所以可以思考只保留目录下一份图像资源即可；目前公司基于720 来切图就可以了；
(4)尽量利用 XML 、Color代替PNG图像
一些现状下 ，我们可以思考利用 XML 来代替 PNG，如 ：渐变的根源图 ，用几行 XML 就可以描绘出来 ，何必利用几十到上百K的 PNG 资料, 如下图其实都是可以不用图像就可以实现的一些简单的作用
图形呈现；比如圆角的按钮 ，圆形的UI 我们自己绘制 ，可以下降图像的导入；下降APK 的体积.
(5)不需要透明度时利用JPG代替PNG
当不需要透明度的图像时 ，可以思考用JPG代替PNG ，由于JPG没有Alpha 通道 ，所以资料更小 (6)思考利用WEBP图像资源格式
WebP是谷歌研发出来的一种图像数据格式，它是一种拥护有损压缩和无损压缩的图像资料格式 ，如果软件拥护到 4.0+ ，那么我们可以利用WebP格式代替PNG，我们的资源大小能降低50%多 。
不过就目前来说 ，对于4.0+ 到 4.2.1 ，原生只拥护完全不透明的webp图 ，4.2.1+ 对于webp的是完全拥护的（涵盖半透明的webp图） 。所以说对于4.2.2（API17）以下的平台 ，还是需要引入兼容库来处理 。但是另外一点 ，引入兼容库又会引发包体变大 。不过这种增量或许和把所有png图换成webp所带来的减量对比或许不值得一提，特别是图像特别多的软件 ，这种增量几乎可以不计。另外也要注意的是 ，某些国产rom会代理类为自己定义的，例如小米2刷成4.xx的移动设备上，小米机器代理了类为 ，但是这个未能正确识别webp资源 ，会引发启动资源资料失败而出现崩溃 。所以应该思考自己读者的机型分布 ，思考利用WEBP图像资源格式替换png格式 。
总结
APK 的瘦身好处； 就不言而喻了；或许还有其他有用的计划；这些也需要大家倡导完善；可能我总结的还不是很完美；目前我是拿了盛代宝做试点；效果还是看的见； 目前经过不断的优化； 目前包的大小维持在5M+；个人觉得还有优化的空间； 如果时间充裕 ，这个我会连续的优化下去；项目都是在不断优化；不要怕犯错 ，用心去做一件事；你会收获很多 ，善于总结；经验是累积的 我相信你可以为了你的项目瘦身做出很大的贡献。如果有好的提议；欢迎大家都倡导来；我将继续完善这个文档.
发表评论