作者：Tom Killen

我刚刚完成了将自己的游戏《Train Conductor 2: USA》从iOS移植到Android的工作。在采取这个措施时，细心探索Android功能是件很重要的事情。不能只是将你的游戏移植过去，你需要采取多个步骤来确保应用获得较好的表现，不可将Android视为“另一个iPhone平台”。

虽然苹果有时会否决我们的游戏或更新，告诉我们修改某些问题，但该公司的确是在为开发者着想，它扮演的是尽职的看门人这个角色，它会审查所有应用的每个细节。

这赢得了用户对iOS平台的信任，这样他们就不会纠结于是否要掏出0.99美元的问题，因为他们知道苹果已经审核通过该游戏，它的质量不会太成问题。如果该游戏获得苹果的推荐，用户就知道只要买下就肯定能得到非同寻常的游戏。

但谷歌却并没有为Android Market产品把好质量关，任何人只要能够支付25美元就可以注册和发布Android应用。许多Android应用非常糟糕，尤其是在那些有独特功能的手机上，因而该平台很难赢得付费用户的信任。

任何进入Android领域的iOS开发者都只有自己为应用质量把关这个选择，确保所发布Android应用拥有最好的表现。

游戏必须能够准确地支持按键。iOS设备只有1个按键，我们通常无需做过多考虑。Android手机有返回、主界面和搜索键，往往还会出现选项键。这些通常被称为“硬键”。

游戏必须能够良好地与其他应用兼容。当用户iOS设备上玩游戏时，如果接到电话就会自动暂停游戏，接完电话后可以返回游戏中。在Android设备上，这些工作需要你来完成，而且还要做更多的事情。

Android的多任务进程比iOS更为复杂，所以你需要确保游戏能够与其他时常需要玩家关注的应用、行为、任务和通知良好地兼容。

首先，让我们讨论硬键的问题。

硬键

返回。不要与你网页浏览器上的返回键混淆起来。在Android设备上，返回键的更像是将某些东西从层叠上移除。当玩家看到某个屏幕时，这个屏幕就被放置在层叠上。

示例：

第1步：用户查看主菜单（主菜单被放置到层叠上）

第2步：用户开启关卡（关卡屏幕被放置到层叠上，如果这时点击返回键，用户就会回到主菜单）

第3步：用户完成关卡后回到主菜单（关卡屏幕被移出层叠，如果这是点击返回键，用户就会回到Android主界面）

主界面。游戏中无法定义主界面的作用。按动主界面键总是会让用户回到Android主界面。保持其原有的功能。

选项。这是个功能相当直观的按键。如果游戏中有任何用户可以选择的设置，可以将其绑定在这个选项按键上。

搜索。这也是相当直观的按键，如果玩家正在看某些可以搜索的东西，他们应当可以通过这个按键来搜索。如果你的游戏中不含有可供搜索的东西，那么就不要给这个按键绑定功能。有些游戏设置可以用这个按键来取消对话，你应当确保不要让搜索键与返回键混同。

你可以优先考虑在主活动中使用以下方法：

@Override

public boolean onKeyDown(int keyCode, KeyEvent event) {

//Generally you don’t want to handle a hard key’s onKeyDown.

//Common practice is to perform the appropriate action on the key up, not the key down

}
@Override

public boolean onKeyUp(int keyCode, KeyEvent event) {

//Here is where you usually want to handle the hard key.

}

你还需要处理的是：

@Override

public void onBackPressed() {

//…

}

应当注意的是，这只是种重写返回键作用的简单方法。onKeyDown和onKeyUp是我较为喜欢的管理按键的方法，因为这些方法提供了更多有关按键的信息，使你的应用可以表现得更好。

你还应当知道以下内容：

@Override

public boolean onKeyLongPress(int keyCode, KeyEvent event) {

//…

}

onKeyLongPress在按键被长按时调用。通常情况下，保持默认设置是个较好的选择。

游戏运行不可与其他Android应用相冲突

Android和iOS间最基本的差别在于更为高级的多任务功能。当玩家需要将注意力转移到其他应用上时，你的游戏应当作出合理的回应。

无论玩家何时接到电话，游戏就会失去玩家的关注，iOS开发者对此已经相当熟悉。这种情况在Android上同样存在。玩家在玩游戏的时候接到电话，游戏会自行暂停，这样玩家在回到游戏时可以从暂停之处开始。

Android应用应当有同样的表现。当玩家接电话时，游戏和音乐应当自动暂停。当玩家回到游戏中，让音乐再次响起，等待玩家展开某些交互行动（游戏邦注：比如点击“恢复”）重新开始游戏。无论其他应用何时占有屏幕，需要引起玩家的关注，都应该有与上述相同的流程。

执行这个很简单。可以设置在游戏不显示于屏幕上时调用onPause方法。一旦玩家返回游戏，让系统自动调用onResume方法。

@Override

protected void onPause()

{

super.onPause();

RemoveDialogs();

Pause();

}
@Override

protected void onResume()

{

super.onResume();

//Start the game back up

//You may want the player to perform a “resume” action

//before restarting gameplay

}

在Android设备上，你还需要关注其他导致玩家注意力脱离游戏的通知，但是却不可调用onPause方法。处理这个问题需要更大的技巧。

有个较好的方法是在主活动中添加onWindowFocusChanged方法。这个方法只在玩家注意力转移到其他窗口时调用。

@Override

public void onWindowFocusChanged(boolean hasFocus) {

if (hasFocus) {

//this means the player is paying attention to us

}

else {

//something else has the players attention right now

}

}

设置了onPause和onWindowFocusChanged，你就可以恰当地处理那些需要暂停游戏来确保用户获得最佳体验的情况。

这些方法并非100%有效。比如，Galaxy Tab玩家会看到应用通知出现在屏幕下方，占据了窗口10%的面积。而当这种情况发生时，你的游戏却丝毫察觉不到。

在这种情况下，我们就需要确保没有关键的游戏内容呈现在被覆盖的屏幕上。（本文为游戏邦/gamerboom.com编译，拒绝任何不保留版权的转载，如需转载请联系：游戏邦）

Even Androids Need Love: How To Make Your Game Play Nicely On Android Devices

Tom Killen

I just finished porting my game Train Conductor 2: USA from iOS to Android. It’s a plunge every good iOS developer should take… to transition from the well organised air-conditioned mall of the App Store to the often bewildering bazaar of the Android Marketplace.

When taking this plunge, it’s very important to show Android some love. Don’t just port your game. You need to take steps to ensure that you are hitting a high quality benchmark and you need to be careful that you don’t think of Android as the “other iPhone”.

You see, Apple are really quite good to us. Sure, sometimes they reject our games or our updates telling us to fix up some issue, but really that’s in our own best interests. Because Apple acts as a gatekeeper, ensuring a minimum level of quality for all apps.

This engenders a certain level of trust from consumers – they aren’t so scared of parting with their $0.99 because they know they that the game they are buying won’t crash (too often) and if the game is featured by Apple, consumers know they are going to get something special.

Google do not act as a gatekeeper for the Android Marketplace. Anyone with $25 can sign up and release more or less what they want. Many apps can be very buggy – especially on phones with unusual features – and so it’s very hard for a consumer to trust a game before they buy it.

Any iOS developer entering the world of Android must take it upon themselves to be their own gatekeeper and to make themselves aware of what constitutes best practices for an Android application. Just as iOS users want and deserve lists that move and bounce nicely when you scroll them, Android users want and deserve some key conventions to be observed.

Games must properly support the buttons. On iOS there is one button, and we usually don’t need to think about it too much. On Android there is back, home, search, and usually an options button too. These are commonly referred to as the “hard keys”.

Games must play nicely with other applications. You know how in your iOS game, you detect when the user makes a phone call and you politely pause the game and wait until they come back? You need to do this and more for Android.

Android has more complex multitasking than iOS, and so you need to ensure you game is a good Android citizen that will get along with all the other applications, activities, tasks, and notifications that will often demand your players attention.

First, let’s discuss how the hard keys are supposed to work.

The Hard Keys

Back. Don’t be confused by your web browser. On Android, the back button is more like popping something off the stack. Whenever your player sees a screen, that screen goes onto the stack. When the user is done with that screen, you then remove that screen from the stack.

An example:

Step 1. The user views the main menu (push main menu onto the stack)

Step 2. The user starts a level (push the level onto the stack – pushing back here should return the user to the main menu)

Step 3. The user finishes the level and returns to the main menu (pop the level off the stack – pushing back here should return the user to the Android home screen)

Home. There’s no place like home. The home button should always – always – return the user to the Android home screen. Don’t fight this. Let it happen.

Options. A fairly straightforward button really. If there are any settings the user can tweak, allow the user to tweak them after they press the options button.

Search. Also fairly straightforward, if the player is viewing something that can be search, they should be able to search by pressing this button. If you don’t have anything that can be searched, then this button should do nothing. Some dialogs allow themselves to be cancelled by this button, so ensure that you don’t allow search to behave like the back button.

In your main Activity, you will want to override the following methods:

@Override

public boolean onKeyDown(int keyCode, KeyEvent event) {

//Generally you don’t want to handle a hard key’s onKeyDown.

//Common practice is to perform the appropriate action on the key up, not the key down

}
@Override

public boolean onKeyUp(int keyCode, KeyEvent event) {

//Here is where you usually want to handle the hard key.

}
You may also want to handle:

@Override

public void onBackPressed() {

//…

}

Note that this is just a convenient way of simply overriding the back button. onKeyDown and onKeyUp would be my preferred way of managing the key press as those methods provide a lot more information about the key press, allowing your app to behave more appropriately.

You should also be aware of:

@Override

public boolean onKeyLongPress(int keyCode, KeyEvent event) {

//…

}

onKeyLongPress is called when the key is held down for an extended period. Generally it’s better practice to let the default implementation handle this.

How To Be A Good Android Citizen: Play Nicely With Other Apps

One of the most fundamental differences between Android and iOS is the more advanced multitasking features. Your game needs to appropriately respond appropriately whenever it ceases to be the center of attention and another App takes over.

iOS developers would already be familiar with their games losing attention (or “focus”) whenever the player recieves a phone call. This kind of interruption has much the same flow on Android. The player is playing your game, receives a phone call, and the game politely pauses itself so that when the player returns to the game they are able to pick up where they left off.

Android applications should behave in a very similar matter. When the player receives a phone call, politely pause the game, quickly fade out music, and when the player returns to the game, fade the music back in and wait for the player to perform some interaction (such as pressing a “resume” button) before restarting the game. This same workflow applies whenever any other application takes over the screen and has the users focus.

This is rather simple to implement. As soon as your game is no longer in charge, the onPause method with be called. Once the player has returned to your game, the system will nicely call onResume.

@Override

protected void onPause()

{

super.onPause();

RemoveDialogs();

Pause();

}
@Override

protected void onResume()

{

super.onResume();

//Start the game back up

//You may want the player to perform a “resume” action

//before restarting gameplay

}

On Android, you also need to be careful to cover other notifications which do take the players attention away from your game, but don’t call the onPause method. These can be a bit more tricky to handle.

One good trick is to override the onWindowFocusChanged method in your main Activity. This method is called whenever a window gets the players attention.

@Override

public void onWindowFocusChanged(boolean hasFocus) {

if (hasFocus) {

//this means the player is paying attention to us

}

else {

//something else has the players attention right now

}

}

By overriding onPause and onWindowFocusChanged, you will be able to catch the vast majority of instances where you would want to pause your game to ensure the best possible player experience.

These methods don’t catch absolutely everything. For example, on the Galaxy Tab the player is able to make an application dock appear over your game, obscuring the bottom 10% of the window. Your game is not informed of this at all.

Unfortunately, for many of these fringe cases you will need to find some kind of workaround that works for your game. In this instance, we were careful to ensure that no critical gameplay occurs on that part of the screen. Such is Android development. (Source: Gamasutra)