1448245065518844.jpg

  尽管谷歌在前不久表示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图片集分别打包。

1448245104350863.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.如果你的图片需要翻转或者旋转,那么你只需要存储初始版本,然后在运行的时候进行翻转或者旋转即可。