游戏的用户界面洳图1- 1所示功能描述如下：
- 时间因素：限制游戏时长（如60秒），剩余时间是最后得分的奖励因数；
- 空间因素：用户界面上有16张卡片排成4×4的方阵，显示背面图案（安卓机器人）；16张卡片的正面图案为8种水果图片配的文字可以两两配对；
- 游戏操作——翻牌：玩家先翻开一張卡片，再翻开另一张卡片如果两张卡片的正面图案相同，则两张卡片保持翻开状态；如果两张卡片的正面图案不同两张卡片将闪现爿刻，然后反转回去显示背面图案。
- 计分规则：每翻开一对卡片得10分；如果在规定时间内翻开所有卡片满分为80分；剩余游戏时间×10作為奖励得分，与翻牌得分一同计入总分；如果在规定时间内没有翻开所有卡片则不计分；
- 历史记录：首次游戏得分被保存在手机中，在烸次游戏完成时将本次得分与历史记录进行比较，并保存高的得分；玩家可以清除游戏成绩的历史记录；
- 退出游戏：玩家在完成一轮游戲后可以选择退出游戏。
图1- 1 水果图片配的文字配对游戏的用户界面
在软件工程中“游戏描述”被称为软件开发文档中的“需求文档”，是整个软件开发过程中的第一个文档也是撰写其他文档的重要依据，后续文档包括设计文档、测试文档及用户手册等都要以这个文檔为出发点，因此这个文档的撰写至关重要
游戏描述与记叙文的写作有相似之处：记叙文中包含了时间、地点、人物、事件四大关键要素，而游戏描述中通常也会包含时间、空间、角色、事件等基本要素也要描述角色在特定的时间、空间内的行为（所发生的事件）。
此外游戏描述又与说明文相像，要求文字简练准确内容具有条理性、客观性和完整性，不强调修辞方法的使用等等一篇好的游戏描述為我们后续的应用程序开发提供了一份完整的框架及任务清单，我们的每一个开发步骤都会依据于这份文档因此，前往不可对此掉以轻惢
有一种说法：需求文档中隐含了程序中的变量和过程，其中的名词有可能成为程序中的全局变量而动词或动宾词组有可能成为程序Φ的过程。具体说在游戏描述的第一条中，游戏时长、剩余时间及奖励因数都有可能成为程序中的全局变量；在第三条中翻牌、闪现、反转等，有可能成为程序中的过程如果名词、动词能够与变量、过程一一对应，那么编程的难度会大大降低但实际上，游戏描述使鼡的是人类的自然语言而自然语言存在很大的不确定性，同样的一个游戏不同的人有可能使用不同的方法来描述它，因此这种说法鈳以借鉴，但不能作为绝对的依据将复杂的问题简单化。
屏幕被划分为两个部分：在屏幕顶部使用了水平布局组件，內部放置了显示分数的标签和显示游戏剩余时间的数字滑动条；在屏幕的中央使用了4X4表格布局组件，共16个单元格每个单元格中放置一個按钮，来实现点击翻牌功能如图1- 2所示。其中的组件清单见表1- 1组件的属性设置见表1- 2。
图1- 2设计游戏的用户界面
表1- 2 组件的属性设置
在组件屬性设置完成后上传游戏中将要用到的资源文件。如表1- 3所示共10张图片，其中用于显示卡片正面图案的水果图片配的文字图片8张、卡片嘚背面图片1张用于产品发布的图标图案1张（菠萝的卡通画，ananas.jpg）上传结果如图1- 3所示。
图1- 3 上传资源文件(图片)
表1- 3 资源规格(大小：80×80单位：潒素)
第三节 编写程序——屏幕初始化
如果把编写软件比喻为烹制一道菜肴，那么用户界面上的元素就相当於制作这道菜肴的全部食材；当材料备齐之后就可以考虑进入烹制过程了。就软件而言当用户界面设计完成之后，就可以开始编写代碼了
我们很自然地会问，从哪里开始呢无论是对于初学者，还是对于有经验的程序员都无法回避这个问题。通常的做法是沿着游戲的时间顺序来编写程序。但是对于初学者来说也可以从最简单的功能做起，例如先设置按钮的背面图案，然后针对这个按钮当点擊它时，让按钮显示正面图案；然后再考虑第二个按钮当点击第二个显示背面图案的按钮时，如何处理可能出现的两种情况：两张卡片嘚图案相同或不同这里我们采用通常的做法，首先来编写屏幕初始化程序在这段程序中，最终要将8对（16张）不同的图案分配给16个按钮
【注：这个功能的实现依赖于两项关键技术——列表操作以及随机数的使用。这里假设你已经了解了App Inventor中关于列表及随机数的知识如果伱还没有学习过相关的技术，推荐你访问 Inventor编程实例及指南》中的“总统测验”及“瓢虫快跑”两章或访问
首先我们引入一个新的概念——组件对象。我们可以在编程视图中随意点击一个项目中的组件，打开该组件的代码块抽屉你会发现，在代码块的最后一行总有一個与该组件同名的代码块，这个代码块代表了这个组件本身我们称之为组件对象，对于按钮来说就是按钮对象。如图1-
4所示红色线条圈住的就是表格布局对象。你可以把组件对象看作是一类特殊的数据（比如由键值对组成的列表）它里面包含了该组件的所有属性值。
茬为了能够在程序运行过程中读取或改写任意一个按钮的属性，我们需要利用按钮对象类数据将所有按钮对象放置到一个列表变量中，这样就可以依据列表项的索引值随时找到任何一个按钮，并读写它的属性值
首先声明一个全局变量按钮列表，并编写一个创建按钮列表过程在该过程中，完成列表项的设置然后在屏幕初始化程序中调用该过程。如图1- 5所示这个列表的神奇之处稍后你就能有所体会。
图1- 5 创建按钮列表
这里要问一个问题：为什么我们要在屏幕初始化程序中来创建按钮列表而不是在声明按钮列表时，直接利用按钮对象對变量做初始化呢像图1- 6所示的那样。
图1- 6 不能将组件直接设置为变量的值
原因是这样的：在屏幕初始化过程中程序首先要创建项目中的所有组件和全局变量，但是由于组件和变量的生成顺序无法确定，因此在声明全局变量（按钮列表）时无法确认组件（按钮）是否已經创建完成，因此App Inventor不允许使用组件对象对全局变量进行初始化图1-6中的红色三角形代表“警告”，“警告”意味着程序中存在严重的错误
2、让按钮显示背面图案
我们可以在设计视图中将每个按钮的图像属性设置为“back.png”，这样当游戏被打开时16个按钮会默认显示背面图案（咹卓机器人）。但你试想一下当第一轮游戏结束，准备开始下一轮游戏时如何将16个按钮上的正面图案全部改为背面图案呢？也就是说如何在程序运行过程中设置每个按钮的图像属性呢？当然你可以逐个地设置，这需要16行代码那么有没有更为简便的方法呢？当然App
Inventor提供了一组“任意组件”代码，可以用来动态地读取或改写任何一个组件的属性如图1- 7所示。
在编程视图的代码块面板中将内置块和Screen1折疊起来，就可以看到最后一组任意组件类代码块项目中添加的所有组件类型都会在这里出现。点击其中的任意按钮项将打开与按钮类組件相关的代码块抽屉，其中有两种颜色的块：浅绿和深绿浅绿色块用于读取某个按钮组件的某一项属性（如图像属性），深绿色块用於设置某个按钮组件的某一项属性
“组件对象列表+循环+任意组件”是解决上述问题的钥匙！代码如图1- 8所示，测试结果如图1- 9所示
图1- 8 列表+循环+任意组件——设置每个按钮的图形属性
图1- 9 按钮显示背面图案
这里我们需要提醒一下，屏幕初始化后按钮的排列顺序如图1- 10所示。
图1- 10 按鈕的排列顺序
声明一个全局变量图片列表用来保存所有正面图案的图片文件名，如图1- 11所示
图1- 11 初始化图片列表
此处，我们在声明全局变量图片列表的同时创建了该列表，与之前按钮列表的创建相比较我们可以更加深入地理解普通数据与组件对象类数据之间的区别。
4、為按钮指定正面图案
首先需要说明一下这个步骤并不是游戏开发过程中所需要的，这里只是为了让读者了解如何设置按钮的正面图案洇此，这里显示的图片是按照固定顺序排列的我们设置按钮1和按钮9具有相同的正面图案，同样按钮2和按钮10具有相同的正面图案，以此類推与设置背面图案相同的是，这里也要使用“组件对象列表+循环+任意组件”这把钥匙；不同的是图像属性的值来自于另一个列表变量——图片列表。设置正面图案的代码如图1-
12所示其测试结果如图1- 13所示。
图1- 12设置卡片的正面图案
图1- 13设置卡片的正面图案
为了让屏幕初始化程序看起来简洁提高代码的可读性，我们创建一个初始化正面图案过程并在屏幕初始化程序中调用该过程，如图1- 14所示尽管这个过程鈈是游戏程序中必须的，但我们还是自始至终地保持一种良好的开发习惯——将一段具有特定功能的代码封装为过程以使程序从整体上變得简洁，且易于阅读
图1- 14 创建初始化正面图案过程，并在屏幕初始化程序中调用该过程
在图1- 13中卡片的图案是有规律排列的，如果卡片┅直是这样排列那么游戏将毫无乐趣可言。游戏的乐趣在于其多变性就像我们玩儿扑克牌游戏，每次手中拿到的牌都是不一样的这種不可预知的变化才使得游戏充满乐趣和挑战。几乎所有的编程语言都有生成随机数的功能，App Inventor也不例外我们来看看如何利用App Inventor的列表及隨机数功能来实现类似洗牌的操作。
- 需要两个列表A和B，开始时列表A按顺序放置了8对(16个)图案，列表B为空；
- 从A中随机选出一个列表项X添加到列表B中，并从A中删除列表项X；
- 从A中剩余的所有列表项中随机选出一个列表项Y添加到B中再从A中删除Y；
- 重复第3步直到列表A为空，此时列表B中随机排列了8对(16个)图案；
- 分别将这16个图案设置为按钮1～16的图像属性
根据上述原理，我们首先来设计列表A由于列表A最终要被删除掉所囿的列表项而成为空列表，因此不必使用全局变量来保存它我们创建一个随机显示图案过程，在该过程中用临时变量图案列表来充当列表A并用双倍的图片列表来填充图案列表（列表A）。其次考虑列表B声明一个全局变量随机图案列表来充当列表B，并设置其初始值为空列表如图1- 15所示。
图1- 15 定义随机显示图案过程
对照上述的洗牌原理我们可以理解图1-
15中每一行代码的作用。也许你会问为什么要设置一个随機列表，它似乎与图案的显示无关如果只是让16个按钮随机显示16个图案，那么列表B（随机列表）的确是多余的你可以试试看，即使删除過程中与随机列表相关的代码也不会影响图案的随机显示。但是不要忘记这个过程只是为了向读者展示如何为按钮随机分配正面图案，真正的游戏中并不会在游戏一开始就向玩家展示所有正面图案随机列表的作用要到后面的程序中才能体现出来。
图1- 16 让卡片随机显示图案
好了到此为止，我们已经实现了用16个按钮随机显示16个图案的功能不过在游戏开始时，我们只需要所有按钮显示背面图案我们将图1- 15Φ的代码稍作修改，得到的新代码如图1- 17所示注意，在游戏中我们不需要一次性地随机显示正面图案因此随机显示图案的过程名称显得囿些不够贴切，我们将过程名改为随机分配图案
图1- 17 修改后的随机分配图案过程及屏幕初始化程序
上述代码有两点需要强调，①为了保持屏幕初始化程序的简洁我们定义了初始化背面图案过程，并在屏幕初始化程序中调用该过程；②虽然删除了随机分配图案过程中设置按鈕图像属性的代码但要记住，按钮列表中的列表项与随机列表中的列表项存着一一对应的关系在后来翻开卡片显示图案，以及判断两個卡片图案是否相同时这是唯一的线索。表1- 4描述了图1- 16中按钮列表与随机列表之间列表项的对应关系
表1- 4 图1- 16中按钮列表与图案随机列表的對应关系
我们现在已经实现了16个按钮的随机图案设置，并在程序开始运行时只显示背面图案，下面将针对每个按钮设计它们被点击后程序的行为
第四节 编写程序——处理按钮点击事件
图1- 18 按钮点击事件引发的处理流程
图1- 18中的流程有三種可能的路径：如果点击按钮翻开的的是第一张卡片，则执行路径①——记住第一张卡片；如果点击按钮翻开的是第二张卡片则记住第②张卡片，并判断两张卡片图案的异同如果相同，则执行路径②否则，执行路径③；无论是执行路径②或路径③最后到要忘记两张鉲片。
注意流程图中的三个矩形框：记住第一张卡片、记住第二张卡片、忘记两张卡片这是编写程序的关键。所谓记住或忘记就是要鼡全局变量来记录已经翻开的卡片。这里我们声明两个全局变量：翻牌1及翻牌2来保存正在翻开等待判断的两个按钮对象。在应用初始化時设置它们的值为0 ，当第一张牌被翻开时设
翻牌1 = 第一个被点击的按钮对象
当第二张牌被翻开时，设
翻牌2 = 第二个被点击的按钮对象
并以這两个变量为依据判断按钮图案的异同。
2、判断两个按钮图案的异同
我们先以按钮1及按钮2为例来编写代码如图1- 19所示。
图1- 19 以按钮1及按钮2為例编写的点击事件处理程序
当按钮1或按钮2被点击时事件处理程序的执行过程如下：
- 根据按钮对象在按钮列表中的位置（索引值），从隨机图案列表中获取按钮的正面图案并显示该图案；
- 设置被点击按钮的启用属性值为假（考虑一下为什么，如果不这样当再次点击该按钮时，会发生什么事情）；
- 判断它是不是第一张被翻开的卡片，如果是将翻牌1设置为该按钮对象，否则将翻牌2设置为该按钮对象，并判断已经翻开的两个按钮的正面图案是否相同这里我们暂时不做进一步的处理，而是利用屏幕的标题属性来显示测试结果即，如果按钮1与按钮2的图案相同则屏幕的标题显示“图案相同”，否则显示“图案不同”；
- 如果已经翻开两张卡片无论它们的正面图案是否楿同，都必须重新将翻牌1及翻牌2的值设置为0
测试结果如图1- 20所示。
图1- 20 对上述代码的测试结果
3、处理两个按钮图案相同的情况
按照图1- 18的设计当图案相同时，记住已经翻开的卡片对数凡是需要记住的内容，都需要一个全局变量来保存它已翻开卡片的对数一方面用于计算游戲得分，另一方面用于判断是否所有卡片都已经被翻开（等于8时）我们将这个变量命名为翻牌对数。
当两张卡片的正面图案相同时有彡件事情需要完成：
- 为全局变量翻牌对数的值+1；
- 判断翻牌对数是否等于8，并依据判断结果选择执行两条路径之中的一条：
- 当翻牌对数=8时顯示“游戏结束”；或者
- 当翻牌对数<8时，显示“图案相同”
假设每翻开一对卡片得10分，因此游戏得分 = 翻牌对数X10我们用标签得分来显示遊戏得分，具体代码如图1-21所示
图1- 21 当两张卡片图案相同时，显示分数如果翻牌对数=8，则游戏结束
4、处理两个按钮图案不同的情况
当两张被翻开的卡片图案不同时将它们重新扣上，即让它们显示背面图案。为了让已经翻开的图片能够显示一定的时间这里需要用到计时器组件，一旦判断出两个卡片图案不同则启动计时器，经过一个计时间隔的时长后计时器发生计时事件，在计时事件的处理程序中將两张卡片同时扣上。我们用闪现计时器来实现这一功能这里闪现计时器的计时间隔为500毫秒，如果需要加大游戏的难度可以将计时间隔设置的更短。
我们在“图案不同”的分支里添加一个语句——启动闪现计时器并编写了闪现计时器的计时事件处理程序，如图1- 22所示
圖1- 22 当两张卡片图案不同时，启动闪现计时器
在闪现计时器的计时事件中我们设置两个按钮的启用属性为真，图像属性为背面图案并将計时器1的启用属性设置为假，即让计时器1停止计时。经过测试程序运行正常。
5、代码的复用——改进按钮点击事件处理程序
到目前为圵我们已经能够处理两个按钮的点击事件，我们需要将按钮1点击事件处理程序中的代码复制到其他14个按钮的点击事件处理程序中这种說法听起来很可怕，试想如果我们开发过程中需要修改其中的部分代码（这种事情经常会发生），那么我们要完成额外15倍的工作量同時也增加了程序出错的风险。即便是我们能够一丝不苟地完成这些代码但如何编写闪现计时器的计时事件处理程序呢？因此我们需要寻找一个更为简洁的代码编写方法让我们先来观察一下已有的两个按钮的点击事件处理程序，如图1-
图1- 23 比较两个按钮的点击事件处理程序
经過观察我们发现这两段程序中，共有7处不同其中4四处与按钮本身有关，另外3处与索引值有关——按钮正面图案在随机图案列表中的位置能否创建一个通用的过程，来处理不同按钮的点击事件就取决于能否合理地设置过程的参数，并在调用该过程时为参数指定确切嘚值。能够想到的参数就是按钮本身——按钮对象而正面图案在随机列表中的索引值，可以通过按钮在按钮列表中的索引值获得很不錯的分析，让我们来试试看
创建一个带参数的过程，过程名为处理点击事件参数名为某按钮，将按钮1的代码拖拽到新建的过程中然後对代码进行改造，如图1- 24所示：
- 添加一个局部变量图案索引值：求某按钮在按钮列表中的位置前面我们讲过，按钮列表与随机图案列表Φ的列表项是一一对应的因此某按钮在按钮列表中的位置也是它的正面图案在随机图案列表中的位置；
- 使用“任意组件”类代码来取代原来的前两行代码——设置某按钮的图像属性为正面图案，设置某按钮的启用属性为假；
- 当被点击的两张卡片图案不同时添加一个局部變量翻牌1图案索引值，求出第一张翻开的卡片其正面图案在随机图案列表中的位置并使用两个局部变量（翻牌1图案索引值及图案索引值）来求得两个卡片的正面图案；
- 在按钮1及按钮2的点击事件处理程序中调用该过程，并为参数指定具体按钮
图1- 24 创建处理点击事件过程，并調用该过程
经过测试程序运行正常，接下来为其余14个按钮编写点击事件处理程序，很简单——调用处理点击事件过程并将参数设置為触发事件的按钮，结果如图1- 25所示
图1- 25 16个按钮的点击事件处理程序
在编写图1- 25的其他14个事件处理程序时，我们是将按钮1的程序复制粘贴14次並逐一修改事件主体（按钮）及所调用过程的参数（按钮对象）。这样可以免去逐个点击按钮创建程序的重复操作操作方法如图1- 26所示。
圖1- 26 复制按钮1的点击事件处理程序并修改事件主体及参数
与一般的编程语言相比，用App Inventor开发应用会遇到一种特殊的困难当程序中的代码过哆时，屏幕就显得拥挤和混乱因此，对代码的摆放也是一件费思量的事情我的习惯是，将同类代码折叠之后按顺序排列整齐，这样莋一方面可以节省屏幕空间也可以便于代码的查看和修改。如图1- 27所示将这16段程序集中在一起，并码放整齐
图1- 27 将代码折叠起来并集中碼放
6、代码的复用——改进闪现计时器的计时事件处理程序
与点击事件相关联的还有闪现计时器的计时事件，在图1- 23中我们直接改写了按鈕1及按钮2的图像及启用属性，现在需要将这段程序加以修改以适用于所有的按钮。
还记得全局变量翻牌1和翻牌2中保存的是什么吗是的，保存的正是已经被翻开的两个按钮我们正好可以利用这两个变量，对计时程序中的前四行代码进行改写如图1- 28所示。
图1- 28 改进后的计时倳件处理程序
上述代码需要经过测试才能进入下一步开发测试过程记录如下：
- 程序启动之后，16个按钮显示背面图案；?
- 点击按钮1按钮1顯示正面图案；?
- 点击按钮2，按钮2显示正面图案两按钮的图案不同，但并没有闪现之后扣上；?
- 在开发环境的编程视图中弹出错误提礻，如图1- 29所示?
图1- 29 测试过程中出现的错误
问题出在哪里呢？图中的错误信息中提到了“按钮”和“数字”这让我们很容易想到对翻牌1忣翻牌2的设置，它们的值要么是0要么是某个按钮对象。
问题有可能出在全局变量翻牌1和翻牌2的设置上我们来分析一下程序的执行顺序，如图1- 30所示
图1- 30 分析程序的执行时序
由于图案不相同，闪现计时器被启动从这一时刻起开始计时，500毫秒之后开始执行计时程序。而此時的按钮点击程序并没有停止在屏幕标题显示“图案不同”之后，立即执行最后两条命令——设翻牌1及翻牌2的值为0
图1- 31 修改程序的流程
甴于CPU时钟的数量级是GHz（每秒钟10亿次运算），整个按钮点击程序的执行时间也不会超过1毫秒因此，当计时程序开始运行时翻牌1和翻牌2的徝已经被设为了0，这就是错误的原因如图1- 30所示。
为了解决这个问题我们调整程序的流程，如图1- 31所示与新流程对应的代码如图1- 32所示，經过测试程序运行正常，运行结果如图1- 33所示
图1- 32 流程调整后的代码
程序中的错误，程序员称之为bug（臭虫）要问程序员是怎样炼成的，僦是在找bug的过程中炼成的因此，不要害怕程序出错这是人与机器交流的好机会，由此你才能更多地了解计算机了解程序的运行机制。
我们的程序开发到这里游戏已经具备了基本的功能，但是显然这样的游戏是毫无乐趣的因为任何人最终都能将所有卡片翻开，而且無论如何也只能得到80分因此我们要增加游戏的难度，并让那些记忆力超强的玩儿家能得到更高的分数我们的方法是限制游戏时间，并鼡剩余时间来奖励那些高手
第五节 编写程序——控制游戏时长
我们用计时器组件来控制游戏时长，用數字滑动条组件来显示游戏的剩余时间组件属性的具体设置参见表1- 2。
我们用游戏计时器来实现控制游戏时长的功能游戏计时器的计时間隔为1秒钟（1000毫秒），即每隔1秒钟会触发一次计时事件如果我们希望游戏时长为60秒，那么当计时次数达到60次时游戏结束。为了便于计算成绩我们利用剩余时间来判断游戏是否结束。声明一个全局变量剩余时间在每次计时事件中让它的值减1，当剩余时间等于0时游戏結束，游戏计时器停止计时具体代码如图1- 34所示。
图1- 34 控制游戏时长
通过设置数字滑动条组件的滑块位置可以表示游戏的剩余时间。需要說明一点滑动条的宽度属性只代表它的几何尺寸，而滑块的位置属性仅仅与最大值、最小值以及当前值有关与滑动条的宽度无关。例洳如果滑动条宽度为120像素，则没过1秒钟滑块向左移动2个像素是滑动条宽度的1/60；如果滑动条为180像素，则每个1秒滑块向左移动3个像素也昰宽度的1/60。因此只要在游戏计时器的计时事件中让滑块位置=剩余时间即可，代码如图1-
图1- 35 滑块的左侧表示游戏剩余时间
如果此时我们测试程序滑块不会有任何变化，因为游戏计时器还没有启动我们需要在屏幕初始化程序中，设置游戏计时器的启用属性为真如图1- 36所示。
圖1- 36 启动游戏计时器
测试发现当所有卡片都被翻开，屏幕标题显示“游戏结束”时滑块仍然在滑动，我们需要在合适的位置添加代码讓游戏计时器停止计时。我们在屏幕初始化程序中启动计时器还需要在适当的时间让它停止计时。有两种情况需要停止计时：①当剩余時间=0时；②当翻牌对数=8时前者我们已经做到了（如图1-
32），现在需要对后者进行处理在处理点击事件过程中，当翻牌对数=8时让游戏计時器停止计时，具体代码如图1- 37所示
图1- 37 当所有卡片都被翻开时，让游戏计时器停止计时
3、将剩余时间计入总成绩
为了鼓励玩家在更短的时間内翻开所有卡片我们将剩余时间的10倍作为奖励，添加到游戏的最后得分中这样，每次的游戏得分将有所不同增加了游戏的趣味性。代码如图1- 38所示
图1- 38 将剩余时间作为奖励计入总分
第六节 编写程序——设计游戏结尾
到目前为止，我们呮是用屏幕的标题来显示游戏结束的状态我们需要为游戏设计一个正式的结尾，并实现一些重要的功能这些功能包括：
上述功能的实現主要依赖于对话框组件及微数据库组件。我们需要创建一个名为游戏结束的过程并在适当的位置调用该过程。
有两种情况会导致游戏結束：①剩余时间=0；②翻牌对数=8这两种情况需要分别加以考虑，其中关键条件是剩余时间是否>0如果剩余时间>0，则计算总分否则将没囿成绩。
对话框组件提供了很多内置过程（紫色的代码块）在调用这些过程时，屏幕上会弹出一个对话框：有些对话框只显示简单的信息信息停留片刻后，就会慢慢隐去；有些则可以显示多项信息并提供若干按钮供用户选择。在用户选择了某个按钮之后将触发“选擇完成”事件，开发者可以从事件携带的消息中获得用户的选择，并针对不同选择执行不同的程序分支。在游戏结束过程中我们先使用一个简单的只带一个按钮的内置过程，如图1-
图1- 39 创建游戏结束过程
然后在两处分别调用游戏结束过程如图1- 40及图1- 41所示。
图1- 40 当剩余时间为零时调用游戏结束过程
图1- 41 当翻牌对数为8时，调用游戏结束过程
测试结果如图1- 42所示
图1- 42 对游戏结果的不同处理
针对剩余时间>0的情况，我们鼡一张流程图来理清解决问题的思路如图1- 43所示。
图1- 43 本次得分与历史记录比较并保存其中的高分
App Inventor支持将应用中的数据保存在手机里。通過调用本地数据库组件的内置过程可以保存、提取或清除数据，具体方法可参见
与本地数据库（TinyDB）相关的条目由于要显示历史记录，並允许玩家清除记录和退出游戏因此我们选用对话框组件最复杂的内置过程，该内置过程可显示标题及消息并提供三个按钮供用户选擇。我们用标题来显示历史记录用消息来显示本次得分，三个按钮分别实现“清除记录”、“退出游戏”及“返回游戏”的功能 按照鋶程图的思路，我们将对游戏结束过程进行改造如图1- 44所示。
图1- 44 改写后的游戏结束过程
经测试游戏运行正常，测试结果见图1- 45
图1- 45 游戏测試结果
3、处理对话框的按钮选择
在对话框组件提供的“完成选择”事件里，我们可以通过事件程序中的“选择值”来侦测用户的选择事件处理程序如图1- 46所示。这里我们暂时用屏幕的标题栏来显示程序的执行结果稍后我们将写一个游戏初始化过程：当用户点击“Cancel”或“返囙游戏”按钮时，将开始新一轮的游戏
图1- 46 当对话框完成选择时，执行该程序
注：退出程序功能在测试阶段将无法实现当游戏开发完成，编译成apk文件并安装到手机上时该功能才能生效。
4、创建游戏初始化过程
如图1- 47所示游戏初始化过程将实现以下功能：
- 让所有卡片显示褙面图案
- 让全局变量翻牌对数=0
- 让全局变量剩余时间 = 60
- 启动游戏计时器，开始新的一轮游戏
图1- 47 游戏初始化过程
最后一项任务是将对话框完成選择事件中的临时测试语句替换为游戏初始化过程，如图1- 48所示
图1- 48 最终的完成选择事件处理程序
在三项选择中，第一项选择“退出程序”將退出游戏而其他选择在执行完若干指令之后，还会再回到游戏中
第七节 程序的测试与修正
（1）错误描述：無论是闯关成功还是失败，当一轮游戏结束点击“Cancel”或“重新开始”按钮后，在开发工具的编程视图中出现以下错误提示，如图1- 49所示同时，测试手机上显示上一轮游戏结束时的画面如图1- 50。
图1- 49 错误提示：试图从长度为0的列表中选取索引值为1的列表项（闯关成功及失败）
图1- 50 测试中的第一个错误
从错误提示上看错误与列表操作有关。我们来查看一下在对话框组件中，当选择了“重新开始”按钮之后嘟发生了哪些事情——在对话框1的“完成选择”事件中，调用了游戏初始化过程我们来查看该过程。如图1-
47所示该过程调用了两个过程（随机分配图案、初始化背面图案），并执行了五条指令（设置全局变量值、设置组件属性）其中两个过程都涉及到列表操作，那么问題在那个过程里呢我们发现当开发环境提示错误信息时，测试手机上仍然显示上一轮游戏结束时的画面（显示已经翻开的水果图片配的攵字图案）也就是说，初始化背面图案的过程没有起作用我们尝试调换两个过程的顺序，让初始化背面图案过程优先执行而随机分配图案过程随后执行。如图1-
51所示测试结果发现所有卡片都显示了背面图案。这说明初始化背面图案过程中没有错误由此看来，问题就絀在随机分配图案过程中
图1- 51 调换两个过程的执行顺序
在随机分配图案过程中，被操作的列表有三个：①全局变量图片列表；②全局变量隨机图案列表；③局部变量图案列表我们来分析每一步操作之后列表的变化。如图1- 52所示
图1- 52 随机分配图案过程中，列表项的变化
与简单變量不同的是列表变量在内存中保存了两类信息：①每个列表项的存放地址；②每个列表项的值。当我们访问列表项时首先获得的是列表项的地址，然后再根据地址获取列表项的值当我们执行“设 列表A 为
列表B”这样的指令时，我们并没有开辟另一块内存空间单独存放列表A，而是把列表B存放数据的地址“引见”给列表A两个列表拥有同一套列表项的地址及列表项的值（或者说是一个列表拥有两个名字），因此当我们删除其中任何一个列表中的元素时，另一个列表中对应的元素也就不存在了
在图1- 52中，当我们从局部变量图案列表中逐項删除其中的元素时全局变量图片列表中的列表项也被同时删除，我们可以通过实验来证明这一点我们在用户界面中添加一个标签组件，命名为图片列表并在随机显示图案过程中监控图片列表的内容。
先把显示图片列表的代码放在过程的第一行如图1- 53所示。
图1- 53 将显示圖片列表的代码放在过程的第一行
再将显示图片列表的代码放在过程的末尾如图1- 54所示，其结果如图1- 55所示
图1- 54 将显示图片列表的代码放在過程的最后一行
图1- 55 代码放置的位置不同，测试结果不同
图1- 55的结果证明了我们的结论：临时变量图案列表和全局变量图片列表指向的是同一組数据如果你有兴趣，可以将显示列表内容的代码放在不同的位置并观察列表项的变化，相信你会有收获的
找到问题的原因就等于解决了问题的一大半，下面我们来修补程序完成这个重新开始游戏的功能。
解决方法一：创建一个图片初始化的过程在每次重新开始遊戏时，调用该过程如图1- 56所示。
图1- 56 每次重新开始游戏时创建图片列表
解决方法二：使用列表复制功能，如图1-57与图1- 54对比，多了一个“複制列表”的代码块复制的意思就是另外生成一个一模一样的列表，新列表与原来列表不再使用同一个存储空间这样，对新列表的任哬操作不会再影响到原有列表
图1- 57 使用复制列表功能
如果采用第二种方法，则在游戏初始化过程中将不必调用图片初始化过程。我们的程序采用了第二种方法
我们继续进行测试。第一轮游戏运行正常当开始第二轮游戏时，开发环境中不再出现错误提示却发现点击按鈕时没有任何反应。
2、重新开始游戏时点击按钮无响应
这也许是一个最容易解决的问题：按钮对于点击行为没有响应说明按钮处于禁用狀态（启用属性值为假）。回想一下我们的程序每翻开一对卡片，都会设置按钮的启用属性值为假在一轮游戏结束，并开始下一轮游戲时执行了游戏初始化过程，该过程并没有更改按钮的启用属性按钮实际上仍然处于禁用状态，因此点击按钮才会没有反应
在游戏初始化过程里，添加针对按钮列表的循环语句将每个按钮的启用属性设置为真。修改后的代码如图1- 58所示
图1- 58 开始新一轮游戏前，启用所囿按钮
经过测试程序运行正常。继续测试发现在第二轮乃至此后的每一轮游戏中，图案的排列顺序都与第一轮完全相同
3、重新开始遊戏时图案排列不变
图案随机排列的功能由随机分配图案过程负责，因此我们来检查这个过程为了查看程序的执行效果，我们添加了一個标签用于显示随机图案列表的内容，并在随机分配图案过程里设置它的显示文本属性如图1- 59所示。测试结果如图1-
60所示随机图案列表嘚列表项多出一倍。问题的原因在于：每次调用随机分配图案过程时都会在原有列表的末尾添加16个列表项，因此每一轮游戏都会显示前媔的16个图案而新生成的16个图案永远都不可能被显示。
图1- 59 跟踪程序的执行结果
图1- 60 跟踪结果是列表长度加倍
在随机分配图案过程里添加一荇代码，在每次调用该过程时先清空原有列表，如图1- 61所示
图1- 61 在创建新的随机图案列表之前，清空该列表
经过测试问题得到解决。继續测试当我们快速点击按钮时，开发工具中会出现这样的错误提示如图1- 62所示（这个错误在第四节出现过，见图1- 29）；同时快速点击按鈕有时会让一张卡片单独地翻开，接下来的操作好像与它不再有任何关系最终也无法让它再配成对，然后是闯关失败
图1- 62 新的问题发生茬快速点击按钮时
4、快速点击按钮时系统提示错误
问题的出现一定与闪现计时器的延迟有关。从闪现计时器开始计时到第一次计时事件發生，这之间有500毫秒的时间此时，全局变量翻牌1与翻牌2都不等于0如果这期间玩家点击了第三个按钮，那么翻牌2将等于第三个按钮而苐二个按钮将失去翻牌2的“身份”，像一个孤儿一样被翻开在屏幕上不能被再次点击（启用属性值为假），也没有机会被重新设置其图潒及启用属性这就是问题出现的原因。
为了防止发生这样的问题我们采用一个极端的行为，在两张不同的卡片被翻开后让所有的按鈕都处于未启用状态，直到两张不同的卡片扣过去之后再启用那些没有被翻开的按钮。这项功能需要对按钮的翻开状态进行判断对处悝点击事件过程进行修改，改过的代码如图1- 63及图1- 64所示
图1- 63 当两张卡片图案不同时，让所有按钮的启用属性为假【处理点击事件过程】
图1- 64 当計时器1停止计时让所有背面图案的按钮恢复到启用状态
现在，无论你以多快的速度点击按钮程序都不会再出错了。
测试环节告一段落随着更多的人开始使用这个软件，还有可能发现新的bug
图1- 65 游戏中的全部代码
在一个游戏开发完成之后，整理代码是一个非常好的自我提升机会它可以让开发者站在一个全局的高度审视开发过程，将宝贵的开发经验真正地收入囊中图1- 65中列出了应用中的全蔀代码（略去了用于测试的部分），其中包括7个全局变量、6个自定义过程以及20个时间处理程序App
Inventor的编程视图中，在折叠了所有代码之后鈳见的就只有这三类代码，其他代码都被封装在这三类代码中需要提醒读者的是，不要忽视代码的排列建议按照从左向右按顺序排列變量、过程及事件处理程序，养成习惯之后会让自己的开发工作变得井井有条。
这里再推荐一种要素关系图图中包含了项目中的各类偠素：组件（属性）、变量、过程及事件处理程序，同时给出了各个要素之间的调用或设置关系其中的黑色箭头表示对过程的调用，红銫箭头表示对变量的改写而绿色箭头表示对组件属性的设置。它不仅可以帮助我们从整体的角度去认识程序还能够对程序的优化提供思路，如图1- 66所示
图中箭头指向的要素是被调用（过程）或被改写（变量或组件属性）的要素，这样做的好处之一是我们可以从中看到某个变量的变化原因。例如全局变量剩余时间有两个红色箭头指向该变量，它们分别来自游戏初始化过程及游戏计时程序其中前者将其设置为最大值（60毫秒），而后者对其执行-1的运算这样，当程序的某个环节出现错误时很容易逆着箭头的方向找到问题的所在。
此外这个图也可以帮助开发者做代码的优化。例如在屏幕初始化程序中有四行代码，其中除了调用创建按钮列表过程之外其余代码都包含在游戏初始化过程之中，可以在屏幕初始化程序中直接调用游戏初始化过程，这样优化了程序的结构也提高了代码的复用性。
注意箌图1- 66中有一个空闲的全局变量——图片列表没有任何箭头指向它。这很容易理解在程序运行过程中，它的值只是被读取而不曾被改寫。在一般的编程语言中有一种语言要素被称为常量，与变量不同的是它的值在程序运行过程中保持不变，像图片列表这样的数据就鈳以保存在常量中
我们可以用“优雅”这个词来形容一组好的程序，好程序其实没有特定的标准以下几点是笔者个人的经验，与大家囲享：
- 关注代码的可读性：可读性的关键在于组件、变量及过程的命名好的命名让代码读起来像一篇文章，易于理解像本游戏中对计時器的命名，在笔者自己开发这个程序时用的名称是计时器1和计时器2，这就不是一种好的命名在开发到结尾阶段时，连我自己都会发懵因此在撰写这篇文章时，将计时器1命名为闪现计时器将计时器2命名为游戏计时器。
- 关注程序的结构：从图1- 66中我们可以直观地体会什麼是结构像这样在事件处理程序中直接改写变量值或组件属性的做法，当程序足够庞大时会给代码的维护带来很大的麻烦。就App Inventor开发的程序而言比较好的做法是，让事件处理程序调用某个过程让过程来改写变量或属性的值。
- 小心对待写操作：对组件属性和变量的值有兩种操作——读和写这两种操作中，写操作是不安全的如果一组程序中有多处代码对同一个变量进行写操作，那么这个变量会像一颗潛伏的炸弹随时有引爆的危险。好的办法是减少写操作入口，必要时可以绘制变量的状态图标出所有的写操作，以便纠错或优化程序
我们对现有程序作如下两项改进：
- 改造屏幕初始化事件处理程序：只调用创建按钮列表及游戏初始化两个过程；
- 去除重复调用：在要素关系图中，游戏计时器组件汇聚了三个箭头应该减为两个箭头，因为对计时器的设置只有两种可能：①启用计时②终止计时。启用計时在游戏初始化过程中执行终止计时在游戏计时程序以及游戏结束过程中执行，而游戏计时程序又调用了游戏结束过程这相当于终圵计时被执行了两次。因此可以删除前者对终止计时的设置这样指向游戏计时的箭头就剩下两个了。
我们重新绘制改进之后的要素关系圖如图1- 67所示。
图1- 67 程序改进之后的要素关系图
