我们是因为美才瘦身的吗? 答案当然是, 不过也是为了健康. 而且美了, 也愉悦别人的眼睛.
图
图
通常我们 apk 下载的大小要小于安装后的尺寸. 下载后应用进行解压, 编译和优化最后部署到设备.
图
为什么我们需要关注 apk 安装前和安装后的尺寸. 现代是小而美, 快而全的时代. 我们越来越缺乏耐性. 所以如果我们 apk 尺寸过大, 一旦用户在下载等待时间过长, 就有可能失去耐性而取消下载. 下面图表我们可以看出 apk 因尺寸过大在 20% .
图
下图为 apk 尺寸和 apk 尺寸的关系图. 现在我们知道了为什么我们需要关注 apk 的大小, 在 apk 大小上花一些心思. 如果不注意, 我们连见到用户的机会都没有了.
图
图
在新版的 Android Studio 中可以在 build 菜单中找到 Analyze Apk 来分析 Apk. 来看一看我们的 apk 内部究竟有什么. 每一个文件或文件夹后面有他在 apk 中百分比.
图
我们在 apk 中, 可以找当上面图中的文件结构, res 文件夹下在一找到一些图形文件. 我们注意到了这里两个栏 Raw File Size 和 Download Size 分别为图片原有大小和下载大小, 看尺寸还是有些区别的.
图
我们选择下图中的 .dex . 我们可以简单地将 dex 理解为 zip 文件. 在这里我们能看到其中的内容, 一些依赖.
图
图
图
我们可以启用 Proguard, 使用方式也是比较简单, 就是 build.gradle 配置文件中添加如下图的代码.
图
图
在项目的 Manifest 文件中, 列出 Activity ,Service ,reciever 和 contentProdiver 这个号称 Android 四大组件. 这列出每个组件会依赖一些类, 这些类在优化过程中将存活下来, 而那些没有依赖的类将会被 remove 处理.
图
通过 Proguard 的一些列处理, 我们甚至可以减少到 33% 的体积.
图
我们也可以用 CompareWith 来比较两个 apk. 我们可以把我们的优化前的和优化后 apk 进行对比.
图
图
我们许多工作都是为了兼容, 兼容不同 CPU 架构, 兼容不同屏幕不同分辨率的尺寸. 为了在不同机型上都有同样良好的表现, 我们将资源文件按分辨率准备几份, 放置在不同文件夹, 看似解决了问题. 同样也带来了问题, 臃肿的 apk.
图
我们可以通过发布 apk 针对不同设备, 不同
图
来源: http://www.jianshu.com/p/5bd03e3206cb