初窥 Android 游戏开发

最近一个月的时间熟悉了一下 Android 平台上的游戏开发流程. 因为游戏相对于软件来说还是有一定区别的, 可能跟系统提供的大部分 API 关系并不是特别的大,主要使用的可能就是系统的图形和声音,以及影像相关的 API 了。

最初学习 Android,只是跟着官方提供的文档和示例一个个地去抄,抄完了之后自己写,主要就学习了一下 Activity 的一些简单的知识,主要是 Activity 之间的通信,Activity 的生命周期,以及 Activity Stack 等等一些。对于游戏开发几乎是 0,因为之前自己做的工作主要是 Java 中间件开发,使用的技术是 JNI,并没有太多的接触过业务逻辑,对于功能的实现和集成还是非常的生疏。此次游戏开发委实长了不少的经验啊。从对 Android 的基础绘图 API 和线程的控制,状态机的维护,资源的释放等等,不一而足啊。

下面列举一下,近来学习的一些方面:

  • SurfaceView 的使用,我想这大概是 Android 为了游戏开发人员做的一个特殊的基类,通过继承该类,并实现 SufaceHolder.CallBack 接口便可,通过 SurfaceHolder.lockCanvas() 获取画布,之后的各种绘制操作均可在当前画布上执行 (Canvas.draw() 系列方法),之后使用 SurfaceHolder.unlockCanvasAndPost(Canvas canvas) 方法,将绘制刷新到屏幕。
  • Thread.sleep(long millis) 方法中的 millis 是跟系统时钟相关的,并不是真正的实际的时长,所以在这里需要做一个换算,使用多次 Thread.sleep(long millis) 方法来探测当前的换算比是多少,然后使用自己所需要的时长乘以该比值,设置给 sleep() 方法,才能得到正确的效果。
  • 关于游戏配置资源的读写,在游戏中,通常会有几种资源文件,图像,声音,XML 关卡数据,游戏运行时配置文件 (ini/properties). 声音,图像,XML 文件通常只需要使用系统默认的资源管理方式即可,如果程序中不需要使用文件名来进行配置的话,但是如果需要使用“logo.png”类似的名字来进行配置的话,可能系统提供的通过资源预编译后 ID 的方式就并不是那么尽如人意了,通常这种情况下,可以通过 AssetManager.open(String fileName) 来打开 assets 目录下的文件,可以使用子目录只是 fileName 就应该是”subfolderName/filename” 这种格式了。在写入配置文件时,Android 为每个应用程序都提供了一个私有目录,”file://data/data/fullpackagename/files/” 目录 (fullpackagename 是当前应用程序所在的包名,例如 com.xixun.games),通过调用 Context.openFileInput(String name, int mode) 和 Context.openFileOutput(String name, int mode) 来获取输入和输出流。
  • Bitmap 相关方法将可能导致 error:OutOfMemory,这个确实是在手持设备上的一个问题,Android Dalvik VM 的实现中,只给了每个应用程序 8M(该数据从互联网查得,并未验证是否属实) 的内存用于图形,当程序为 Bitmap 对象申请超过 8M 内存时,将会抛出该错误 (不是异常) 并退出程序,并没有什么非常好的方法一定能帮你解决这个问题,通常我们应该养成一种编程行为习惯,那就是在 Bitmap 不再使用的时候立刻将资源回收 (调用 Bitmap.recyle() 方法),因为 Bitmap 的实现是系统级别的 API,VM 对这种对象的管理并不会那么尽如人意,所以最好还是程序自身来管理,否则在后续的开发中,如果再次加入更大的资源将极为频繁地出现该问题。那么什么时候可能会出现该问题呢?8M 的内存,我什么时候可能知道内存快要用了呢?对,你不知道,我也不知道,不过我们要预防,而且自己在编程时也可以简单的计算一下,如果你使用 png 图片的话,1.5M,到了程序中,如果你将所有的 png 均转化成了 Bitmap 对象,那么你的程序中使用的内存就至少会使用 4.5M 的内存。而且如果图片还带透明效果的话,那么就可能是 6M 的内存了。

以上就是近期的一些学习总结。下次将分享一个关于 Android 应用程序访问网络的问题。