App Inventor编程开发集锦是App Inventor编程教程的延伸,通过PBL项目制的实战案例,讲解App ...

App Inventor编程开发集锦-目录

第7课 代码整理

图1- 65 游戏中的全部代码
在一个游戏开发完成之后,整理代码是一个非常好的自我提升机会,它可以让开发者站在一个全局的高度审视开发过程,将宝贵的开发经验真正地收入囊中。图1- 65中列出了应用中的全部代码(略去了用于测试的部分),其中包括7个全局变量、6个自定义过程以及20个时间处理程序,App Inventor的编程视图中,在折叠了所有代码之后,可见的就只有这三类代码,其他代码都被封装在这三类代码中。需要提醒读者的是,不要忽视代码的排列,建议按照从左向右按顺序排列变量、过程及事件处理程序,养成习惯之后,会让自己的开发工作变得井井有条。

这里再推荐一种要素关系图,图中包含了项目中的各类要素:组件(属性)、变量、过程及事件处理程序,同时给出了各个要素之间的调用或设置关系,其中的黑色箭头表示对过程的调用,红色箭头表示对变量的改写,而绿色箭头表示对组件属性的设置。它不仅可以帮助我们从整体的角度去认识程序,还能够对程序的优化提供思路,如图1- 66所示。

图1- 66 要素关系图
图中箭头指向的要素是被调用(过程)或被改写(变量或组件属性)的要素,这样做的好处之一是,我们可以从中看到某个变量的变化原因。例如全局变量剩余时间,有两个红色箭头指向该变量,它们分别来自游戏初始化过程及游戏计时程序,其中前者将其设置为最大值(60毫秒),而后者对其执行-1的运算。这样,当程序的某个环节出现错误时,很容易逆着箭头的方向找到问题的所在。

此外,这个图也可以帮助开发者做代码的优化。例如,在屏幕初始化程序中有四行代码,其中除了调用创建按钮列表过程之外,其余代码都包含在游戏初始化过程之中,可以在屏幕初始化程序中,直接调用游戏初始化过程,这样优化了程序的结构,也提高了代码的复用性。

注意到图1- 66中有一个空闲的全局变量——图片列表,没有任何箭头指向它。这很容易理解,在程序运行过程中,它的值只是被读取,而不曾被改写。在一般的编程语言中,有一种语言要素被称为常量,与变量不同的是,它的值在程序运行过程中保持不变,像图片列表这样的数据就可以保存在常量中。

我们可以用“优雅”这个词来形容一组好的程序,好程序其实没有特定的标准,以下几点是笔者个人的经验,与大家共享:

  1. 关注代码的可读性:可读性的关键在于组件、变量及过程的命名。好的命名让代码读起来像一篇文章,易于理解。像本游戏中对计时器的命名,在笔者自己开发这个程序时,用的名称是计时器1和计时器2,这就不是一种好的命名,在开发到结尾阶段时,连我自己都会发懵。因此在撰写这篇文章时,将计时器1命名为闪现计时器,将计时器2命名为游戏计时器。
  2. 关注程序的结构:从图1- 66中我们可以直观地体会什么是结构。像这样在事件处理程序中直接改写变量值或组件属性的做法,当程序足够庞大时,会给代码的维护带来很大的麻烦。就App Inventor开发的程序而言,比较好的做法是,让事件处理程序调用某个过程,让过程来改写变量或属性的值。
  3. 小心对待写操作:对组件属性和变量的值有两种操作——读和写。这两种操作中,写操作是不安全的。如果一组程序中有多处代码对同一个变量进行写操作,那么这个变量会像一颗潜伏的炸弹,随时有引爆的危险。好的办法是,减少写操作入口,必要时可以绘制变量的状态图,标出所有的写操作,以便纠错或优化程序。

我们对现有程序作如下两项改进:

  1. 改造屏幕初始化事件处理程序:只调用创建按钮列表及游戏初始化两个过程;
  2. 去除重复调用:在要素关系图中,游戏计时器组件汇聚了三个箭头,应该减为两个箭头,因为对计时器的设置只有两种可能:①启用计时,②终止计时。启用计时在游戏初始化过程中执行,终止计时在游戏计时程序以及游戏结束过程中执行,而游戏计时程序又调用了游戏结束过程,这相当于终止计时被执行了两次。因此可以删除前者对终止计时的设置,这样指向游戏计时的箭头就剩下两个了。

我们重新绘制改进之后的要素关系图,如图1- 67所示。

图1- 67 程序改进之后的要素关系图