安卓单机斗地主源码拆解：牌型判断、自定义View与AI出牌实现要点

简介：安卓单机斗地主项目源码基于Java与Android SDK开发，代码内带有较详细注释，适合刚接触Android开发、希望借助完整游戏项目理解界面与逻辑分层实现的读者。压缩包共515个文件，体积约10.45MB，主要包含466张PNG图片、9个Java源文件、5个XML布局文件、20个Class字节码、JAR库与APK成品包，图片资源、布局描述、业务逻辑和构建配置分开存放，便于导入Android Studio后按模块分析。目前已有420人学习下载。项目完整覆盖洗牌、发牌、手牌排序、出牌规则、胜负判定等核心玩法，并涉及自定义CardView绘制扑克牌、触摸与点击事件处理、多线程任务调度、Activity生命周期状态保持，以及AI决策等典型知识点。将Java源码与XML布局、扑克牌图片资源相互对照，可以看清小游戏从界面绘制到对战逻辑的完整实现链路；若用于课程设计、毕业设计或入门练手，通过断点调试与规则改写，还能进一步加深对Android组件、数据结构、事件机制和资源管理的理解。

1. 安卓单机斗地主源码：这份带注释的 Android 项目到底能拆出什么

做 Android 开发最头疼的事之一，就是找个能完整跑起来的游戏源码当参考，结果下载下来要么缺资源文件要么逻辑绕成一团。我拿到这份安卓单机斗地主源码时，先看了下压缩包结构，发现它是个不依赖 Unity、libGDX 的原生 Java Android 项目，核心逻辑全部自己实现。对于想搞懂牌型判断、自定义 View 绘制、事件分发和 Activity 生命周期怎么配合的开发者来说，它比市面上那些封装好的游戏引擎 demo 更有拆解价值。适合三类人：刚学完 Android 四大组件想找个完整项目练手的初学者、要做棋牌类 Demo 但不想碰第三方库的从业者，以及想把“源码带注释”当成代码规范教材来读的人。这篇笔记会直接拆到类级别，讲清楚牌型算法、界面绘制、AI 出牌这些关键模块的实现思路和坑。

2. 从 class 文件反推项目结构：先看清这份源码的骨架

2.1 核心类逐一拆解：每个 class 负责什么

压缩包里的文件是编译后的 .class 和打包产物，没有直接给出 .java 源码，但类名已经足够暴露设计结构。最常见的原生 Android 游戏组织方式，是把「入口 Activity」和「业务逻辑」分离，我这里按经验把这份源码的模块划分还原出来：

从这些类名可以看到一个典型的「数据 + 逻辑 + 视图」三层结构。Card 类负责单牌数据，CardType 负责判断连对、顺子、炸弹这类规则，MyView 负责把数据画出来，EventAction 把用户操作转成游戏行为。这种结构没有用 MVP 或 MVVM，纯粹是早期 Android 开发最常见的写法，好处是简单直接，坏处是当游戏状态变多时，Activity 里会塞大量逻辑。

2.2 资源与代码分离：resources.ap_ 里藏了什么

resources.ap_ 是 Android 构建时生成的资源索引文件，对应开发工程里的 res 目录。也就是说，原工程里应该有 layout 布局文件定义游戏主界面，有 drawable 文件夹放扑克牌图片，可能还有 values 下的颜色和字符串资源。扑克牌图片通常是一张大图里裁切出来的，或者每张牌单独一张小图。

我一般会先把这类文件当黑匣子处理，不急着解包看图片。先通过aapt dump命令把资源清单导出来，确认里面有哪些布局文件和图片条目，这样能避免在代码里瞎猜资源 ID。常见做法是在命令行执行：

aapt dump badging MyCards.apk aapt dump resources MyCards.apk > resources.txt

第一条命令看包名、版本号和启动 Activity，第二条命令导出完整的资源映射表。拿到 resources.txt 后，重点搜 layout 和 drawable 条目，配合 .class 文件里的R$drawable.class，就能反推出哪张图片对应哪个控件 ID。这套方法在分析任何没给完整工程的 APK 时都通用。

3. 牌型判断与数据结构：CardType 和 Card 的算法核心

3.1 单牌数据模型设计：Card 类的属性与排序

斗地主游戏里，单张牌有两个关键属性：点数（3 到 2 再到大小王）和花色（黑桃、红心、梅花、方块）。在 Java 里最常见的建模方式有两种：一是用 int 常量直接编码，二是用枚举。这份源码里既然有 CardType.class，说明牌型判断单独抽成了工具类，那 Card 更可能是一个简单的 POJO。

我见过的原生写法普遍长这样：

public class Card implements Comparable<Card> { public static final int COLOR_SPADE = 0; public static final int COLOR_HEART = 1; public static final int COLOR_CLUB = 2; public static final int COLOR_DIAMOND = 3; public static final int COLOR_JOKER = 4; private int color; private int point; // 3~10, J=11, Q=12, K=13, A=14, 2=15, 小王=16, 大王=17 private int id; public Card(int id, int color, int point) { this.id = id; this.color = color; this.point = point; } @Override public int compareTo(Card other) { if (this.point != other.point) { return this.point - other.point; } return this.color - other.color; } }

这里把点数做了线性映射，2映射到 15，比 A 的 14 还大，这样排序时天然符合斗地主规则。大小王分别映射到 16 和 17，花色在点数相同时才参与比较。这个设计的核心价值在于：后续所有牌型判断只需要比较点数，不需要关心花色，顺子判断直接看 point 是否连续即可。

3.2 牌型枚举与判定：从单牌到王炸的完整规则

单机斗地主的 AI 和胜负逻辑全靠 CardType 这个类撑起来。源码级别的实现里，判断牌型的输入通常是List<Card>，输出是一个类型枚举加一个关键值，比如顺子最大牌的点数、炸弹的点数。我按斗地主完整规则梳理一遍判定优先级：

public class CardType { public static final int ERROR = 0; public static final int SINGLE = 1; // 单牌 public static final int PAIR = 2; // 对子 public static final int THREE = 3; // 三张 public static final int THREE_ONE = 4; // 三带一 public static final int THREE_TWO = 5; // 三带二 public static final int STRAIGHT = 6; // 顺子，五张起 public static final int STRAIGHT_PAIR = 7; // 连对，三对起 public static final int PLANE = 8; // 飞机不带 public static final int PLANE_ONE = 9; // 飞机带单 public static final int PLANE_TWO = 10; // 飞机带对 public static final int FOUR_TWO = 11; // 四带二 public static final int BOMB = 12; // 炸弹 public static final int KING_BOMB = 13; // 王炸 public static int getType(List<Card> cards) { int size = cards.size(); if (size == 0) return ERROR; if (size == 1) return SINGLE; int[] points = getPointArray(cards); // 判断王炸 if (size == 2 && points[0] == 16 && points[1] == 17) return KING_BOMB; // 判断炸弹 if (size == 4 && allSame(points)) return BOMB; // 其余规则按长度和相邻性继续判断 return ERROR; } }

这个判定逻辑的核心思路是：先看长度缩小范围，再看是否所有点数相同，最后看点数是否连续。源码里通常还会有一个配套方法，用来比较两副牌的大小关系，比如都是顺子时比较最大牌，炸弹能压过普通牌型。写这部分的时候最容易翻车的点是四带二带的是两张单牌还是一对，这在规则里会被认为是不同的出牌组合，收牌时必须区分。

3.3 手牌管理：用 TreeSet 还是 ArrayList

手牌的存储方式直接影响排序和出牌效率。源码里大概率用的是List<Card>，因为出牌后需要频繁移除元素，而 ArrayList 的随机访问快、删除尾部元素快。但为了界面显示时牌是有序的，每次添加牌后都得调用Collections.sort()。

如果是我自己重新实现，会选择TreeSet<Card>配合自定义 Comparator，因为斗地主手牌理论上不会有重复牌（同一副牌只有 54 张），TreeSet 的好处是插入时就保持有序，省掉了每次出牌后的排序操作。不过这类源码为了兼容老设备、减少类库依赖，用 ArrayList 加 sort 才是常态。需要注意的是：洗牌用Collections.shuffle()是纯随机，真实斗地主还需要考虑发牌后手牌的平滑程度，但单机版为了省事基本不处理，这也是为什么单机斗地主经常出现一手牌全是单张的局面。

4. 从 MyView 到 EventAction：UI 层与交互事件的配合方式

4.1 自定义 View 绘制扑克牌：onDraw 里的坐标系

MyView.class 是扑克牌绘制的主战场。原生 Canvas 绘图模式下，每张牌就是一个带圆角的矩形，上面画点数文字和花色符号。常见做法是把牌背图片和牌面图片都从 drawable 资源里加载成 Bitmap，绘制时按当前牌的位置裁剪或直接 drawBitmap。

绘制逻辑通常长这样：

@Override protected void onDraw(Canvas canvas) { super.onDraw(canvas); for (int i = 0; i < handCards.size(); i++) { Card card = handCards.get(i); float left = paddingLeft + i * cardSpacing; float top = getHeight() - cardHeight - paddingBottom; drawCardBg(canvas, left, top, i == selectedIndex ? 30 : 0); drawCardFace(canvas, card, left, top + (i == selectedIndex ? 30 : 0)); } } private void drawCardFace(Canvas canvas, Card card, float left, float top) { Bitmap bmp = cardBitmapMap.get(card.getId()); if (bmp != null) { canvas.drawBitmap(bmp, left, top, null); } }

这里 cardSpacing 是牌与牌之间的重叠间距，value 通常在 20 到 30 像素之间。selectedIndex 表示当前被点选抬起的牌，绘制时把纵坐标往上偏移 30 像素，形成视觉上“这张牌被选中”的效果。这个偏移值会影响触摸命中的判断区域，很多源码在这块容易出 bug：画的时候偏移了，但点击判断还是按原来的位置算，导致玩家点击已经抬起的牌却选不中。

处理触摸事件时，需要把 MotionEvent 的坐标换算成手牌索引。我一般会用index = (int) ((event.getX() - paddingLeft) / cardSpacing)，再检查点击点是否落在该牌的矩形范围内。如果手牌有选中的逻辑，还需要在点击同一张牌时取消选中，这就是 EventAction 里需要处理的状态切换。

4.2 事件动作封装：EventAction 与 Activity 的通信

EventAction.class 从命名上看是在封装游戏内的动作指令。原生写法常见的有两种思路：一种是定义 int 常量，比如ACTION_PLAY = 1、ACTION_PASS = 2、ACTION_GRAB = 3，然后用 switch 分发；另一种是定义成接口或者抽象类，让不同动作实现不同的 execute 方法。

我在类似项目里更推荐用命令模式封装动作，因为斗地主的操作类型相对固定，但每个操作涉及的数据不同：

public class EventAction { public static final int TYPE_PLAY = 1; public static final int TYPE_PASS = 2; public static final int TYPE_GRAB_LANDLORD = 3; private int type; private List<Card> cards; public EventAction(int type, List<Card> cards) { this.type = type; this.cards = cards; } public void execute(GameSession session) { switch (type) { case TYPE_PLAY: session.playCards(cards); break; case TYPE_PASS: session.pass(); break; case TYPE_GRAB_LANDLORD: session.grabLandlord(); break; } } }

核心优势是 Activity 里只需要把触摸事件转成 EventAction 对象再调用 execute，不需要自己写一长串 if-else。源码里大概率就是把点击「出牌按钮」的回调封装成了 TYPE_PLAY 动作，把点击「过牌」封装成 TYPE_PASS，代码可读性比直接在 Activity 里堆逻辑好得多。这里有个值得注意的点：EventAction 在上面的写法里直接依赖了 GameSession，如果后续想支持联机对战，这种直接依赖会导致耦合，更优雅的方式是让动作只携带数据，由事件总线或接口回调去触发游戏逻辑变更。

4.3 布局与生命周期：为什么单机斗地主不推荐 SurfaceView

很多初学者会问：既然要画牌、要做动画，为什么不直接用 SurfaceView？答案在于帧率需求和实现成本的权衡。斗地主不像射击或跑酷游戏需要持续刷新画面，它更多是事件驱动的：玩家点一下，界面变一下。用普通的 View 加 invalidate() 就足够，代码简单，也不需要管理独立的渲染线程。

MyActivity 里应该做了这些事：onCreate 里 setContentView 加载布局，找到按钮控件并设置点击监听，初始化游戏逻辑对象，然后可能有一个startGame()方法负责发牌和刷新界面。生命周期上，单机游戏还有一个隐性需求——游戏中途来电或切后台时需要保存对局，否则重新打开就从头开始了。源码里常见的做法是在onPause()里把当前手牌和桌面牌序列化成字符串存进 SharedPreferences，onResume()里再读回来重建牌型，相当于给玩家一份后悔药。

5. 单机斗地主的避坑指南：从编译到跑起来的三类典型问题

5.1 高版本 Android 编译报错的坑

现象：把源码导入 Android Studio 后，编译直接报错，错误信息指向R类无法找到，或者提示android:debuggable等属性过期。

原因：这份源码的构建方式大概率是最老式的 Eclipse 加 Ant 构建，资源文件和代码目录结构与 Android Gradle 插件期望的不一致。而且很多老项目里会把android.jar之外的第三方库直接塞进libs/目录，Gradle 默认不会自动编译libs/里的.class文件。

解决：新建一个 Android 工程，把java目录里的源码复制进去，res目录里的资源也复制进去，再逐个修正 build.gradle 里的compileSdkVersion和minSdkVersion。具体操作是：

# 用 unzip 解包 APK，拿到 res 和 classes unzip MyCards.apk -d apk_rebuild # 对比 resources.ap_ 与解包目录，确认资源完整

实际操作时，我建议直接把源码工程当成「参考手册」而不是「直接编译的代码库」。用它来理解牌型判断、自定义 View 这些模块的写法，然后在新工程里重写一份自己的实现，这比反复修 Gradle 兼容性问题更省时间。

5.2 触摸事件失灵与卡牌位置偏移

现象：运行到游戏界面后，点击屏幕下方的牌没有反应，或者点了 A 牌却选中了 B 牌。

原因：这个问题在自定义 View 的触摸事件里非常典型。绘制时对选中的牌做了上移偏移，但触摸判断区域没有同步上移。另一种可能是触摸监听用的是OnTouchListener，但返回了false，导致 ACTION_UP 事件没有被消费。

解决：给 View 的触摸监听统一返回true，然后在事件处理里自己匹配 ACTION_DOWN 和 ACTION_UP：

@Override public boolean onTouchEvent(MotionEvent event) { if (event.getAction() == MotionEvent.ACTION_DOWN) { int index = getCardIndexByPos(event.getX(), event.getY()); if (index >= 0) { toggleCardSelected(index); return true; } } return super.onTouchEvent(event); }

注意getCardIndexByPos必须和onDraw里用的坐标保持一致，选中偏移量selectedOffsetY不能只在画的时候用，判断命中时要把点击点往回偏移同样距离再算索引。血泪经验：把这两处偏移量的定义收敛成同一个常量，不要各写各的。

5.3 状态保存不完整导致对局错乱

现象：游戏玩到一半切到后台，再回来发现手牌少了或者出现重复牌，甚至直接闪退。

原因：onPause()里只保存了手牌数据，没有保存地主身份、当前出牌轮次、上家出的牌型这些状态。重新恢复时，手牌数组是恢复了，但牌局阶段回到了初始状态，代码继续往下跑就会出现下标越界或空指针。

解决：用 JSON 或固定格式的字符串把所有对局状态打包保存，恢复时按顺序解析。我习惯用一个小方法把状态序列化的逻辑收拢起来：

private String serializeGameState() { StringBuilder sb = new StringBuilder(); sb.append("landlord=").append(landlordIndex).append(";"); sb.append("round=").append(currentRound).append(";"); sb.append("hand=").append(encodeCards(handCards)).append(";"); sb.append("table=").append(encodeCards(tableCards)).append(";"); return sb.toString(); }

从这以后，我再分析这类棋牌源码时，都会下意识检查有没有onSaveInstanceState或SharedPreferences相关的代码。如果源码里没有处理，那就是一个很好的改进点，可以拿来练手写状态持久化。

6. 把源码改成你自己的版本：从换牌背到调 AI 出牌逻辑

拿到这份源码，最有价值的玩法不是跑通它，而是改它。我先说一个最简单的实验：换牌背图片。找到资源目录里牌背的位图文件，用任意图像编辑工具改成你想要的图案，保持相同尺寸和格式，重新构建。这个操作能让你直观理解 Android 的Resources加载机制——图片被编译进 APK 后，代码里通过资源 ID 引用，改图片文件不影响任何 Java 代码。

第二个实验是调 AI 的出牌难度。在单机斗地主源码里，AI 的出牌逻辑通常是「对手牌进行扫描，找出所有可行的出牌组合，然后按优先级选择」。优先级规则常见的是：先出单牌和散牌、保留炸弹和王炸、根据对手剩余手牌数调整策略。你可以找到 AI 决策相关的方法，加一条规则，比如「当我的手牌只剩 5 张以内时，优先出最大的单牌逼对方出炸弹」，改完以后重新运行，观察电脑对手的决策变化。建议在决策方法里加日志输出，用Log.d("AI_TEST", "play: " + cards)，配合 Android Studio 的 Logcat 查看实际打法，这样能看到规则代码与实际出牌行为是否一致。

第三个实验是验证牌型判断的完备性。斗地主有个经典边界：四带二到底能不能带两张单牌、能不能带一对？不同平台的规则定义不一样。源码里 CardType 的判断逻辑大概率只实现了基本牌型，对四带二的组合判断可能比较草率。建议你写一组单元测试，把顺子长度为 5、连对长度为 3、飞机带翅膀这些边界情况全部覆盖，跑一遍看哪些用例会挂，这比盲目加功能更能帮你理解规则细节。

我当时拆这份源码时踩过一个印象很深的坑：加了个「自动出牌」按钮，以为只要调 AI 的决策方法就行，结果点击按钮后界面卡死。后来定位发现是决策方法里做了大量循环计算，跑在 UI 线程上导致 ANR。从那以后我每次拿到这类单机游戏源码，都会先全局搜一遍有没有子线程处理逻辑，没有的话默认把耗时计算包进一个Thread或Handler里，强制走一遍这条检查链路再动其他代码。这个习惯能帮你避免一半以上的运行时崩溃。希望这份拆解能让你在复现这份安卓单机斗地主源码时少走弯路。

本文还有配套的精品资源，点击获取