最近一个月的时间熟悉了一下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应用程序访问网络的问题。