我们是因为美才瘦身的吗？答案当然是，不过也是为了健康。而且美了，也愉悦别人的眼睛。
图
图
通常我们 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 针对不同设备，不同
图
