企业官网建设流程全解析

简介：这是一份基于Android Studio实现的2048小游戏完整工程源码，主要面向安卓初学者以及需要完成期末大作业、课程设计的在校生，可作为高分开题基础或二次开发模板。压缩包为zip格式，内含141个文件，核心游戏逻辑集中于21个Java源文件，50个XML文件负责界面布局，30个WebP文件用于图片资源，另有Gradle构建配置、依赖JAR和属性文件等，整包仅394KB，结构清晰、易于部署。该资源已有269人学习浏览。代码由作者手写并附带详细注释，是导师认可的高分项目；下载后简单配置即可运行，便于逐行理解滑动监听、方块合并、分数累加与界面刷新等关键点，对冲击期末大作业高分很有帮助。

1. 拿到“基于 Android Studio 实现的 2048 小游戏源代码”之后，你真正要做的是这三件事

基于 Android Studio 实现的 2048 小游戏源代码，几乎每个安卓方向的学生都见过，网盘、GitHub、课程群里同名压缩包一大把。但真正把它装进 Android Studio、Sync 通过、再放到真机上滑动一次，很多人第一晚就交代给了 Gradle 和 Logcat。这份源码虽然小，覆盖的东西其实不少：Activity 生命周期、自定义 View、手势识别、二维数组运算、SharedPreferences 存档，刚好对应安卓大作业爱考的几个能力点。这篇文章要做的，就是把这套源码从“能看懂”推到“能运行、能改、能答辩”。新手按章节一步步走，熟手直接跳到避坑那章看版本对应关系和触摸事件处理就够了。

2. 跑通 2048 源码的三个前置：SDK、Gradle 版本与工程结构顺序排查

2.1 Android Studio 版本与 Gradle JDK：先让项目能 Sync 再谈改代码

网上能找到的基于 Android Studio 的 2048 源码，绝大多数是 2021 到 2023 年间的老工程。如果你用的是 2023.1.1.16 或更新版本的 Android Studio 安装包，打开老工程时最常翻车的地方就是 Gradle 版本和 JDK 版本对不上。千万不要一上来就点 Run，先做两件事：第一，查看工程根目录下的 gradle-wrapper.properties；第二，打开 Android Studio 的 Settings -> Build Tools -> Gradle，看 Gradle JDK 是否指向了正确的 JDK 版本。

我一般会把 Module 级别的 build.gradle 里的几个 SDK 参数整理成固定模板，老工程打开后逐项核对：

android { // applicationId 是应用唯一标识，改包名时这里要跟着改 namespace 'com.example.game2048' compileSdk 34 defaultConfig { applicationId "com.example.game2048" minSdk 21 targetSdk 34 versionCode 1 versionName "1.0" } } dependencies { implementation 'androidx.appcompat:appcompat:1.6.1' implementation 'com.google.android.material:material:1.9.0' }

这段配置里最关键的是compileSdk和targetSdk。老源码很多停在 compileSdk 30 左右，而你本机装的是新版本 Android Studio，默认创建工程会用 34 到 35，两者不一致时 Gradle Sync 会提示下载对应 SDK，下载失败就是红字报错。minSdk 21值得刻意保留，它决定 App 能跑在哪些老设备上，大作业演示一般不需要抬高标准。dependencies 里的依赖版本也别急着升，升了以后容易出现 AndroidX 冲突。

提示：Android Studio 想切中文界面的，去 Settings -> Plugins 里装中文语言包，但报错信息仍然是英文，别指望翻译插件能帮你定位堆栈。Gradle JDK 推荐直接指向 Android Studio 自带的 JDK 17，不要用系统里另装的 JDK 8，老版本 Gradle 会直接罢工。

2.2 读懂 2048 源码的目录结构：从 MainActivity 到 BoardView 的调用链

结构清晰与否直接决定你改代码敢不敢下手。常见的 2048 安卓大作业源码，Java 文件不会很多，一般是四到五个类，加上布局、菜单和资源文件。拿到源码后不要急着看 MainActivity，先按下面这张表格把职责分清楚。

我见过的源码还有一种组织方式：算法逻辑直接写在 MainActivity 里，BoardView 只做绘制。这种写法改起来很痛苦，因为滑动事件、矩阵运算、UI 刷新全挤在同一个文件里。判断这份 2048 源代码质量好不好，第一眼看的就是逻辑类是否独立。站在“安卓大作业”的评分角度，逻辑独立是加分项，因为老师会问“如果要把棋盘改成 5x5，要动哪几个文件”，你答“只改算法类里的 N 和初始化部分”就稳了。

2.3 第一次构建与真机部署：命令行构建和 Run 按钮哪个更省心

老手拿到新工程通常先跑gradlew assembleDebug而不是直接点 Run。原因很简单：命令行能把完整的编译错误按顺序列出来，而 Android Studio 的 Run 按钮有时候把 Sync 错误和编译错误混在一次弹窗里，看起来像黑匣子。在项目根目录执行一次构建，你能更早发现签名、依赖、资源文件缺漏的问题。

# 在工程根目录先做一次完整构建，跳过测试，看编译能否通过 .\gradlew.bat assembleDebug --stacktrace # 模拟器已经启动的情况下，用 gradle 直接装到已连接设备 .\gradlew.bat installDebug

第一条命令里的--stacktrace是我每次必加的参数，报错时能输出完整的调用链，否则 Gradle 只给你一行“FAILURE: Build failed with an exception”，根本没有定位头绪。assembleDebug只构建不安装，适合先验证纯编译问题；installDebug则会安装到当前已连接的设备或模拟器。把老工程从别的机器上“移植”过来时，常见做法是只拷贝 gradle 目录、gradlew 脚本和 app 目录，不要连.gradle、build这些本地产物一起拷，拷贝后第一次 Sync 会重新生成本地配置。

3. 2048 核心算法：4x4 矩阵的滑动、合并与终局判定怎么写稳

3.1 棋盘数据模型：一维数组、二维数组与 0 值空位约定

2048 的棋盘本质是一个 4x4 矩阵，空位用 0 表示。绝大多数源码用二维数组int[][] board = new int[4][4]，简单直观，打印和调试都方便。用一维数组int[16]也能做，旋转和合并时下标换算更灵活，但可读性差，大作业答辩时容易解释不清楚。我建议你按二维数组读源码，如果手里的源码是一维的，优先自己重构成二维，后续加 AI 求解和动画都会省力。

初始化和生成新数字是每局游戏的基础，核心代码大概长这样：

// 棋盘类：负责所有矩阵运算，不关心 UI public class Game2048 { private int[][] board; private int score; private Random random = new Random(); public Game2048() { board = new int[4][4]; score = 0; addRandomTile(); addRandomTile(); } // 随机生成一张新牌，90% 概率为 2，10% 概率为 4 private void addRandomTile() { List<int[]> empty = new ArrayList<>(); // 收集所有值为 0 的格子 for (int r = 0; r < board.length; r++) { for (int c = 0; c < board[r].length; c++) { if (board[r][c] == 0) { empty.add(new int[]{r, c}); } } } if (empty.isEmpty()) return; int[] pos = empty.get(random.nextInt(empty.size())); board[pos[0]][pos[1]] = (random.nextInt(10) == 0) ? 4 : 2; } }

这里random.nextInt(10) == 0决定了生成 4 的概率约为 10%，生成的 2 和 4 只落在empty列表随机挑中的一个空位。源码里若是固定先找第一个空位，你会发现游戏很快就没法玩：新数字永远出现在左上角，滑动后棋盘越来越歪。score字段放在这个类里而不放在 Activity 里，是为了让逻辑层可以独立做单元测试。

3.2 左滑合并的完整实现：压实、合并、再压实的三个子过程

2048 的滑动合并是整个工程最容易写错的部分。正确做法不是“一边扫描一边合并”，而是分成三个子过程：先压实（把一行里的非零数字全部挪到左边），再合并相邻相同数字，最后再压实一次。为什么要做两次压实？因为合并后可能产生新的空位，比如[2, 2, 2, 2]合并成[4, 4, 0, 0]，中间的空位不压掉，下一轮状态就不对。

// 对一行执行左移合并，返回是否发生了变化 private boolean mergeRow(int[] row) { boolean moved = false; int[] compacted = compactRow(row); // 第一步：把非零数字压实到左侧 for (int i = 0; i < 3; i++) { if (compacted[i] != 0 && compacted[i] == compacted[i + 1]) { compacted[i] *= 2; score += compacted[i]; // 分数在这里累加 compacted[i + 1] = 0; i++; // 跳过下一格，避免同一格被合并两次 moved = true; } } int[] result = compactRow(compacted); // 第二步：合并后再压实 System.arraycopy(result, 0, row, 0, row.length); moved |= !Arrays.equals(row, compacted) | !Arrays.equals(row, result); // 简化示意 return moved; } // 把一行中的非零元素顺序取出，补零到原长度 private int[] compactRow(int[] row) { int[] out = new int[row.length]; int idx = 0; for (int value : row) { if (value != 0) out[idx++] = value; } return out; }

这段代码里最容易忽略的是i++那一步，它在合并后跳过被合并的数字，保证[4, 4, 4, 4]合并成[8, 8, 0, 0]而不是一路合并成[16, 0, 0, 0]。曾经有份网上流传的 2048 源码就是在这里少了一个自增，玩到后面分数虚高，老师一看矩阵就穿帮。score += compacted[i]放在合并瞬间累加，而不是等一轮结束再统计，这样每一步的变化都能和界面数字对应上。至于moved判断，我这里写的是简化版，实际工程里我会用一个临时数组before保存原始行，最后Arrays.equals(before, row)判断是否发生了移动，这样最严谨。

3.3 方向复用的技巧：旋转棋盘，让上下右滑共用同一套逻辑

只写一个mergeRow不够，棋盘有四个方向。新手最容易踩的坑是复制四份 merge 方法，分别处理左、右、上、下，结果四个方法各自有各自的 bug。常见的可靠做法是“旋转后统一左滑”：上滑 = 把矩阵顺时针旋转 90 度，左滑合并，再旋转回去；右滑 = 把矩阵水平镜像一次，左滑合并，再镜像回去。

// 将矩阵顺时针旋转 90 度，返回新矩阵 private int[][] rotate(int[][] src) { int n = src.length; int[][] dst = new int[n][n]; for (int r = 0; r < n; r++) { for (int c = 0; c < n; c++) { dst[c][n - 1 - r] = src[r][c]; } } return dst; } // 公共入口：direction 为 0=左 1=上 2=右 3=下 public boolean move(int direction) { int[][] temp = board; for (int i = 0; i < direction; i++) { temp = rotate(temp); } boolean changed = false; for (int r = 0; r < temp.length; r++) { changed |= mergeRow(temp[r]); } for (int i = 0; i < 4 - direction; i++) { temp = rotate(temp); } board = temp; return changed; }

这个技巧的价值在于：你只维护一份合并逻辑，四个方向全部复用，测试工作量少掉四分之三。direction用 0 到 3 表示，通过三次循环控制旋转次数，虽然性能上多做了几次数组拷贝，但 4x4 棋盘完全感觉不到。源码里如果四个方向各写一套，我建议动手重构到这个版本再继续，因为接下来要加撤销、自动求解时，一维的合并逻辑压根没法扩展。

3.4 终局判定：空位检查与相邻等值检查

游戏是否结束，很多源码是每次移动后遍历一遍矩阵，看有没有 0，再看有没有相邻相同数字。这个做法的判断逻辑没错，但有一个细节容易写得过于复杂：有人会从左上角开始，对每个格子检查右、下两个方向，发现相邻相等就返回 false，最后还要单独处理最后一行和最后一列的边界。其实只要两轮循环就能写得清晰。

public boolean isGameOver() { // 有空位就说明还能生成新方块，游戏未结束 for (int[] row : board) { for (int value : row) { if (value == 0) return false; } } // 检查横向和纵向相邻是否有相同值 for (int r = 0; r < 4; r++) { for (int c = 0; c < 3; c++) { if (board[r][c] == board[r][c + 1]) return false; if (board[c][r] == board[c + 1][r]) return false; } } return true; }

横向检查用board[r][c] == board[r][c + 1]，纵向检查用board[c][r] == board[c + 1][r]，两个判断挤在一个循环体里，顺便把没有 0 但还能通过滑动合并的情况也覆盖了。注意这里的board[c][r]和board[c + 1][r]就是把 r 和 c 对调后的写法，很多一眼看不出来的 bug 就是在这里把行列搞反。终局判定放在每次移动之后调用，放在移动之前会误判：棋盘满了但还能合并，不应该立刻结束。

4. 界面与交互：自定义 View、手势识别与多分辨率适配怎么协同

4.1 渲染方案选型：自定义 View 的 onDraw 还是 GridView 套卡片

2048 的棋盘渲染有两种主流写法。一种是用 GridView 套 16 个 TextView，另一种是自绘 View 重写 onDraw。拿大作业来说，GridView 方案写起来快，但每次滑动要更新 16 个 TextView 的数据，滑动瞬间还会闪一下；自绘 View 的代码量稍大，但动画、缩放、颜色渐变都可以后续往上加，答辩时更有的聊。我更喜欢第二种，因为 Android Studio 的自定义组件本来就是高频考点，源码里如果已经是自定义 View，保留它；如果源码是 GridView 版，可以考虑只改棋盘这一部分作为差异化亮点。

// 自定义棋盘 View：核心是 onDraw 里的排版 public class BoardView extends View { private int[][] board; private Paint backgroundPaint = new Paint(); private Paint textPaint = new Paint(); private float cellSize; private float margin = 12f; public BoardView(Context context, AttributeSet attrs) { super(context, attrs); backgroundPaint.setColor(0xFFBBADA0); textPaint.setTextAlign(Paint.Align.CENTER); textPaint.setTextSize(48f); textPaint.setTextScaleX(1.0f); } @Override protected void onDraw(Canvas canvas) { super.onDraw(canvas); if (board == null) return; float width = getWidth() - margin * 5; cellSize = width / 4f; // 第一层：画卡片背景，第二层：写数字 for (int r = 0; r < 4; r++) { for (int c = 0; c < 4; c++) { float left = margin + c * (cellSize + margin); float top = margin + r * (cellSize + margin); canvas.drawRoundRect(left, top, left + cellSize, top + cellSize, 12f, 12f, backgroundPaint); if (board[r][c] != 0) { drawTextCentered(canvas, String.valueOf(board[r][c]), left + cellSize / 2f, top + cellSize / 2f); } } } } }

这段代码里margin是卡片间距，cellSize在 onDraw 里按 View 实际宽度计算，保证 4 列铺满屏幕，这就是多分辨率适配的关键。很多源码把 cellSize 写死成 80dp，到平板上棋盘只占一小块，这就是典型的适配失败。从 Android Studio 的自定义组件角度看，必须重写(Context, AttributeSet)这个构造方法，否则在 XML 布局里引用该组件时直接崩。drawTextCentered是我封装的辅助方法，内部用Paint.getTextBounds测量文字宽高再计算偏移，避免数字不居中。

4.2 手势识别：onTouchEvent、GestureDetector 与误触阈值

手势识别的实现，简版代码是重写onTouchEvent记录按下和抬起的位置，然后算 dx 和 dy 判断方向。增强版是用 GestureDetector 配合onFling。对我来说，大作业用前者就够，因为 2048 不需要区分快速滑动和慢速拖动，只看位移方向即可，反而更可控。

@Override public boolean onTouchEvent(MotionEvent event) { switch (event.getActionMasked()) { case MotionEvent.ACTION_DOWN: downX = event.getX(); downY = event.getY(); return true; // 由本 View 处理整条事件流 case MotionEvent.ACTION_UP: float dx = event.getX() - downX; float dy = event.getY() - downY; int threshold = dpToPx(50); // 误触阈值，低于 50dp 的移动忽略 if (Math.abs(dx) < threshold && Math.abs(dy) < threshold) { return true; } if (Math.abs(dx) > Math.abs(dy)) { onSwipe(dx > 0 ? 2 : 0); // 0=左 2=右 } else { onSwipe(dy > 0 ? 3 : 1); // 1=上 3=下 } return true; } return super.onTouchEvent(event); }

ACTION_DOWN里return true是一件容易被忽略的小事。如果你返回 false，后续的 ACTION_UP 都不会传进来，手势识别直接失效，症状是“点击没反应、滑动完全无响应”。方向判断用Math.abs(dx) > Math.abs(dy)决定水平还是垂直，再用正负决定左右、上下。dpToPx(50)是我封装的密度换算，千万不要把阈值写死成50，在 2.x 密度的高清屏上 50px 连一个格子都划不满，操作会显得特别生涩。

4.3 多分辨率适配与大作业交付细节：图标、包名和状态栏

运行没问题之后，大作业交付前还要过几个“非功能项”：应用图标、包名、App 名称和状态栏沉浸。这些检查项不涉及算法，但直接影响演示观感。AndroidManifest 里的默认 Activity 图标和 android:label 要换掉，否则桌面显示的是机器人头和一个叫 “MainActivity” 的 App，老师一点开印象分先扣一半。

<application android:icon="@mipmap/ic_launcher" android:label="@string/app_name" android:theme="@style/Theme.Game2048"> <activity android:name=".MainActivity" android:exported="true"> <intent-filter> <action android:name="android.intent.action.MAIN" /> <category android:name="android.intent.category.LAUNCHER" /> </intent-filter> </activity> </application>

这段配置里的android:exported="true"是 Android 12 以后必须加的，不加的话安装到新设备直接闪退，这是老源码最常见的兼容问题之一。android:label建议从strings.xml里引用，不要硬编码在中文字符串，否则换语言环境容易变成乱码。图标替换路径是app/src/main/res/mipmap-*系列文件夹，把老师要求的图片丢进去，记得准备 48、72、96、144 四档，只放一张大图在 mipmap-xxxhdpi 里，别的档位会缩放糊掉。

5. 照着源码改会踩的 5 个坑：现象、原因与解决

5.1 Gradle Sync 失败：AGP 与 Gradle 版本对不上

现象：工程一打开，右侧 Gradle Sync 红条，构建窗口提示The Android Gradle plugin supports only Gradle 8.x。原因：老源码用 AGP 7.x 配 Gradle 7.x，你本机默认模板是 AGP 8.x 配 Gradle 8.x，两者版本矩阵没对上。解决：打开 gradle-wrapper.properties，把distributionUrl改成和 AGP 匹配的 Gradle 版本；如果不想记矩阵，直接新建一个空工程，把新工程的 gradle-wrapper.properties 和com.android.tools.build:gradle版本号抄过来，这是最快止血方案。

5.2 真机闪退：自定义 View 缺构造方法、Style 属性不识别

现象：模拟器上正常，一装真机就崩，Logcat 里InflateException指向BoardView。原因：布局 XML 里声明自定义 View 时，系统调用的是(Context, AttributeSet)构造方法，源码里只写了(Context)或无参版本。解决：补上完整的两个构造方法，并在其中一个里统一初始化资源。另一个常见变体是布局引用了自定义属性app:xxx但没加xmlns:app声明，解决方法是把自定义属性删掉，只保留系统支持的 layout 属性。

5.3 手势方向错乱或触摸无效：事件被消费、返回值和拦截

现象：向上滑，数字却向右移，或者第一次滑动没反应，第二次才有。原因：onTouchEvent 的 switch 写成了case MotionEvent.ACTION_DOWN后不返回值，还在 switch 结束后调用了super.onTouchEvent，导致事件被父容器或父布局拦截。解决：按我前面那版代码，DOWN 和 UP 都返回 true；方向判断重新测一遍，用 Log 输出 dx 和 dy，别忘了屏幕上顺手画一个 “+” 记下手指起点，对照起点判断方向才准。

5.4 合并翻车：一次滑动同一格被合并两次，分数乱跳

现象：[4, 4, 4, 4]左滑后变成[8, 8, 0, 0]是对的，但某些源码变成[16, 0, 0, 0]，或者单次滑动加了两次分。原因：循环里没有在合并后跳过被合并的格子，或者加分写在了循环体外。解决：合并后立即执行i++跳过一格；加分放在compacted[i] *= 2之后立刻算。验证办法很简单，在 mergeRow 入口和出口各打一行日志，把整行数组打出来，一眼就能看出结果对没对。

5.5 游戏结束误判：明明还有空位就弹结束

现象：棋盘上还有四五个空格，但系统已经弹了 “Game Over”。原因：终局判定写在了移动之前，或者移动失败时也进行了判定。有时是因为你滑动了不可移动的方向，moved 返回 false，源码不管三七二十一直接判定结束。解决：只在 moved 为 true 时执行isGameOver检查，检测顺序是“滑动是否改变状态 -> 改变后再看是否终局”；isGameOver 里保留两个遍历：空位检查 + 相邻等值检查，缺一个都会误报。

6. 让这份 2048 源码真正变成你自己的项目：存档恢复与自动求解

到了这一步，你已经离“读懂”很近了。但“安卓大作业”要拿高分，需要一些别人没有的差异化功能。我建议按下面顺序加两个东西：存档恢复和自动求解。这两个功能都不难，但都能写进答辩讲稿里。

6.1 存档恢复：SharedPreferences 存棋盘与分数的序列化方案

很多源码只管当前一局，退出 App 就丢进度。存档的常见做法是 SharedPreferences，但 4x4 矩阵不能直接塞进去，要么用 json 序列化，要么用简单分隔符拼字符串。

// 保存：把二维数组转成 "2,4,0,0,4,2,..." 字符串 public void saveState(Context context) { StringBuilder sb = new StringBuilder(); for (int r = 0; r < 4; r++) { for (int c = 0; c < 4; c++) { if (sb.length() > 0) sb.append(","); sb.append(board[r][c]); } } SharedPreferences sp = context.getSharedPreferences("game2048", Context.MODE_PRIVATE); sp.edit() .putString("board", sb.toString()) .putInt("score", score) .putBoolean("hasState", true) .apply(); } // 读取：把字符串再变回矩阵 public void loadState(Context context) { SharedPreferences sp = context.getSharedPreferences("game2048", Context.MODE_PRIVATE); if (!sp.getBoolean("hasState", false)) return; String data = sp.getString("board", ""); String[] parts = data.split(","); if (parts.length != 16) return; for (int i = 0; i < 16; i++) { board[i / 4][i % 4] = Integer.parseInt(parts[i]); } score = sp.getInt("score", 0); }

两个方法分别放在 MainActivity 的onPause和onCreate里调用，App 被杀掉再打开，进度就回来了。注意.apply()是异步写盘，.commit()是同步写，存档这种低频操作用 apply 完全够。有个坑是数组里的 0 也存进字符串了，解析时split(",")会把连续逗号处理成空字符串，Integer.parseInt对空字符串会抛异常，所以我在读回之后加了parts.length != 16的防御，防止老版本存档格式不一致导致崩溃。

6.2 一个 8 行的自动求解：按“最大化角落权重”选方向

2048 的 AI 是个大话题，但大作业只需要一个“自动跑”按钮。最简单的方案是给每个格子加一个权重，大数往角落堆，每次移动前取四个方向的“加权和”，选最大那个方向。

private int[] weights = { 16, 8, 4, 2, 8, 4, 2, 1, 4, 2, 1, 0, 2, 1, 0, -1 }; // 对四个方向分别计算得分，选最高者 public int autoMove() { int bestDirection = 0; int bestScore = -1; for (int dir = 0; dir < 4; dir++) { Game2048 copy = clone(); // 在副本上模拟，不破坏当前局面 if (copy.move(dir)) { int s = evaluate(copy.board); if (s > bestScore) { bestScore = s; bestDirection = dir; } } } return bestDirection; }

clone()在 Game2048 里实现一个浅拷贝，拷贝整个 board 二维数组。evaluate就是把每个格子的值乘上对应权重再求和。这样 AI 会倾向于把大数字堆在左上角，玩个几千分不成问题。你可以在界面上加一个“自动”按钮，点击后连发 move 事件，间隔 200 毫秒。答辩时老师问“这个 AI 怎么实现的”，你就说“贪心 + 静态权重”，比背神经网络名词实在多了。

6.3 验证方法：把改动回归跑一遍老用例

加完存档和自动求解之后，一定要按这条用例顺序回归一遍：第一，安装后首次进入，棋盘应有两个初始数字；第二，滑动一步，数字往期望方向移动，分数增加且带有 2 的幂值；第三，退出 App 再进入，棋盘和分数和退出前完全一致，不能丢格子；第四，连续滑动到死局，看是否弹出结束提示；第五，点自动按钮，观察 AI 能否连续完成几步，而不是原地不动。这套验证覆盖了算法、生命周期、存档和交互四条链路，跑完你才敢把它当自己的作品交上去。

我第一次写 2048 大作业时就翻过车：存档里忘了处理 0 值，恢复后棋盘全变成 0，分数还在。后来养成了习惯，凡是棋盘相关的数据结构，先序列化输出到 Logcat 看一眼，再写进 SharedPreferences。这也是我想提醒你的：源码能跑通只是第一步，真正的收获是把每个改动边缘试一遍。希望帮到你。

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