从106MB降低至12MB 揭秘游戏开发者压缩包体秘方

　　尽管谷歌在前不久表示Google Play的应用大小从50MB提高到了100MB，但对于碎片化严重的Android平台来说，一款游戏想要适配多种屏幕尺寸仍然需要考虑包体的问题。最近一名安卓游戏开发者在博客中讲述了自己把游戏包体从106M降低到12M所用到的方法，遇到同样问题的童鞋们不妨借鉴，以下是记者编译的博文内容：

　　在分析了各种安卓设备的不同分辨率之后，我决定把所有的游戏资源都用6种不同的尺寸来做。然而，我担心这样做会增加最终游戏的apk文件大小，所以，我首次开始做这款游戏的时候就决定检查所有的资源。

　　我创造了一个只包含最低(800×480)和最高(2560×1600)分辨率图片的包体，大小是106M!

　　我需要增加4种其他大小的分辨率，所以我推测最终的apk大小至少在300MB以上，我搜索了文档，然后发现谷歌的要求包体是100MB以下，其他必须通过分割资源包的形式下载。要不然，你也可以为不同的设备提供不同的apk文件，但这两种做法我都不太喜欢，我最讨厌下在安卓游戏之后还必须等待更多的时间下载数百兆资源，我需要新的方式解决这种冲突。

　　我上网进行了搜索，大多数的建议是把你的代码用压缩器或者模糊处理(obfuscator programs)软件打包，但得到的效果其实是可以忽略不计的。随后，一个建议引起了我的注意，那就是把图片格式全部使用JPEG。我使用 TextureAtlas自动打包所有资源，但我可以把这些图片和没有透明区域的地方分隔开，然后把它们作为PNG或者JPG图片集分别打包。

　　然而问题是，我游戏当中90%的图片都是需要透明度的，在这种情况下我们最主要的问题就是卡牌图片，这些图片都有圆角。随后我想到了这个想法：把这些卡牌图片分为框架和内容，这款游戏中只有4种卡牌类型，所有同类的卡牌都有相同的框架。卡牌内部每一个都是不同的，但这些内容都不要求透明度。我并没有把126张卡片打包成PNG图片，而是全部做成了JPG图片，外加4张PNG框架图。

　　在分步处理图片的时候，确保JPG图片首先被画出来，PNG框架覆盖其上。顺便提一句，我说的分步处理指的是把图形放到 libGDXStage(Group)当中。为了让代码更简单，我创作了Cardimage类(class)来处理透明化的绘图，这个Group包含来自 JPG图片的卡牌中心，然后把来自PNG图片的框架覆盖其上。

　　这节约了大量的空间，但我还担心在做翻转动作的时候导致包体过大。当卡牌面向左边或者右边的时候，我会直接把这张图翻过来，这样就会节约空间，因为我不必存储完整的卡牌图像。我尝试过能否只翻转一部分图像，这可能要使用AtlasRegion.flip()函数，但我不想翻转完整的JPG图像，这些图片部分应该保持相同，而且只有完整的图形才需要展示出来，为此，在calling flip(true,false)之后，我使用了setRegionY和setRegionHeight缩减翻转区域的大小，通过使用翻转区域，我创造了另一个图形而且把它加入到了CardImaeg group里，在运行的时候，我只需要简单地展示或者隐藏这个图片就可以了。

　　结果

　　新方法创作出来的apk文件在包含了同样内容的情况下，大小降到了12MB，也就是说这个处理节约了88%的空间。加入了其他四种分辨率之后，apk包体降到了42MB，和此前预计的300MB相差9倍多。

　　总结

　　除了你能够在网上找到的所有其他建议之外，比如压缩代码等等，还需要增加以下三条：

　　1.在可能的情况下尽量使用JPG格式的图片;

　　2.如果你使用PNG只是为了半透明边框，最好是把图片剪裁成边框+内容的方式，把框架用PNG存储，内容用JPG存储。或者，还可以用更换高的方式：把边框建材城四部分(左右上下)，然后在运行的时候把它们组合起来，不要在PNG框架中增加更多的空间，这样不仅可以节约存储量，还可以使用更少的图片，所以游戏运行会更快。

　　3.如果你的图片需要翻转或者旋转，那么你只需要存储初始版本，然后在运行的时候进行翻转或者旋转即可。