Android休闲游戏-快踩我-开发笔记

该游戏有三种游戏模式：踩颜色，踩数字和踩边线。

游戏效果图：

开发工具：Android Studio

具体实现过程及问题：

该游戏最关键的就是实现方块的下落效果，而这一般情况下都是通过无限循环实现的，显然这个无限循环不能放在主线程中进行，否则会导致ANR或者响应触摸事件延迟。Android中有一个SurfaceView类，它允许在一个非UI线程中绘制界面元素，因此我们的下落界面（View）需要继承自SurfaceView而不是View，这样就能实现方块下落与触摸事件监听同时进行。

public class DropSurfaceView extends SurfaceView implements SurfaceHolder.Callback {    ......}

在点击开始游戏后，我们开启一个线程，在该线程中进行无限循环：

private class DropThread extends Thread {        @Override        public void run() {            while (!Thread.currentThread().isInterrupted()) {            if(mStatus == Status.STOPPED) {                    break;             }             if (mStatus == Status.PAUSE) {                    continue;             }             drawOnce();             if(isGameOver()) {                    mIsGameOver = true;                    break;             }}private void drawOnce() {    Canvas canvas = null;    long drawdata = 0L;    try {        canvas = mSurfaceHolder.lockCanvas();        drawBaseView(canvas);        updateData();        drawData(canvas, false);    } catch (Exception e) {        e.printStackTrace();    } finally {        if (canvas != null) {            mSurfaceHolder.unlockCanvasAndPost(canvas);        }    }}

在该无限循环中，先判断是否处于停止状态，是的话直接退出循环游戏结束，否则再判断是否处于暂停状态，是的话continue不进行任何操作，否则就是游戏进行状态，那么：

先更新方块数据，就是把所有方块按速度大小下移一段距离
lock一个canvas
绘制基本界面（背景，分割线等）
绘制更新后的方块
判断是否游戏结束（该判断不同模式标准不一样，因此利用监听器抽象出来）

以上就是整个下落过程的关键代码，在实际开发中发现在低配置的手机上下落会发生卡顿，通过对代码进行分析，发现大部分情况下都是因为lockCanvas耗时太多（我们知道Android中如果一帧不能在16ms内绘制完就会发生丢帧，也就是产生卡顿效果），一番努力仍没有解决方法，因此该问题暂时没有解决，下一个版本会尽力解决该问题。

需要解决的问题：

1.在方块下落中，我们需要遍历方块集合判断哪些方块已经下落到屏幕下面（完全看不见）了，如果有就必须删掉，那么现在有一个问题就是删掉后又需要继续遍历集合，这可能会导致混合（当然下标处理得好就没问题），因此该程序使用的是两个集合交替使用，每次都把不必删掉的方块搬到另外一个集合中就行（感觉有点类似双缓冲这东西）。

2.由于该游戏有三种模式，而这三种模式的大体框架都是一样的，比如都需要一个速度等，因此要考虑怎样做好大体框架就很重要了，否则会导致一大堆重复代码，这样以后修改维护也变得异常繁琐困难。这时设计模式的作用就体现出来了，其中用得最多的就是弄一个接口，接口中声明几个公共方法，然后在具体的游戏模式中按不同的规则实现这些方法，比如判断游戏结束，三种游戏模式的游戏结束标志都是不一样的，因此需要都实现游戏结束接口方法。其实这中思想跟Android中的点击事件监听器那些是同一个道理。

3.三种模式也有共同的地方，比如游戏结束都会弹出游戏结束对话框，游戏进行中按Home键都会自动暂停游戏，这些公共的东西都放在一个抽象基类中，又可以避免许多重复代码。

4.游戏中涉及到许多随机数，比如那个方块的产生就是随机的，踩数字的数字也是随机的，那么现在就有一个问题，有时随机数貌似不太符合我们的要求，在游戏开发初期阶段发现下落了几十个方块，颜色方块中还没有一个符合条件的（可以点击），这样肯定不行，这时就需要人工进行纠正了，该游戏中纠正算法使用的是判断如果在N次（这里的N也必须是随机数）中仍没有出现符合条件的，那么人工产生一个一个符合条件的。

5.游戏中有很多需要随时改变的东西，或者说是类似配置信息之类的，包括方块下落的管道数，分割线的宽度颜色，方块的大小等，这些都不能写死在程序中，否则如果以后需要修改就会很麻烦，而且外面不能进行配置自定义，因此该游戏中采用的是低耦合的方式进行处理，所有配置信息都抽象出来，形成一个一个配置类，外面可以自定义配置。

6.错误信息收集，用户在使用应用过程中如果奔溃了，那么应用会把异常信息发送到后台服务器。

7.每一个APP上线到应用商店都必须考虑的一个问题，就是安全问题，如何防止安装包被反编译，窃取源代码及相关信息是一个需要解决的问题。在该程序中进行了代码混淆，并使用的第三方加密服务爱加密进行一系列加密（不过有些应用商店需要使用它们自己的加密服务进行加密，否则会审核不通过），包括dex加固，防止二次打包等。

其它细节问题：

1.刚开始管道分割线设置为1px，结果在高分辨率的手机中那线不见了，结果发现是1px在高分辨率屏幕下绘制出来但太细看不见了，最后改成dp就行了。

2.速度的计算需要考虑到屏幕的大小，使用的也是dp。如果使用px，那么增加相同px在不同分辨率手机下得到的效果是不一样的。

3.在进行游戏时如果按Home键，再进入游戏界面，会发现SurfaceView的东西都不见了，这是因为游戏切换到后台时SurfaceView对应的画布信息会被销毁掉，因此此时必须重新绘制一次。

4.意见反馈对话框使用的是AlertDialog，但是发现在一部小米2s手机上整个编辑框和按钮都是黑色的，而在其它测试手机上却能正常显示，怀疑是手机主题的问题，因此最后代码设置编辑框和按钮背景为白色解决。

5.对于多人协作开发的项目，最好使用一种版本控制工具进行版本控制，该游戏的开发使用的是版本控制工具是Git。

下载地址：

http://www.wandoujia.com/apps/com.lym.stamp

转载请注明原文地址：http://blog.csdn.net/u012619640/article/details/50135891