Android应用程序或游戏开发前的一些忠告

Android应用程序或游戏开发前的一些忠告

(2011-02-27 02:07:23)

转载

标签：

android

忠告

it

分类：Android开发

不要放弃数据

Always keep in mind that Android is a phone platform. It may seemobvious to say it, but it’s important to remember that anotherActivity (such as the “Incoming Phone Call” app) can pop up overyour own Activity at any moment. This will fire the onFreeze() andonPause() methods, and will likely result in your application beingkilled.

If the user was editing data in your application when the otherActivity appeared, your application will likely lose that data whenyour application is killed. Unless, of course, you save the work inprogress first. The “Android Way” is to do just that: Androidapplications that accept or edit input should override theonFreeze() method and save their state in some appropriate fashion.When the user revisits the application, she should be able toretrieve her data.

A classic example of a good use of this behavior is a mailapplication. If the user was composing an email when anotherActivity started up, the application should save the in-processemail as a draft.

请记住Andriod是一个电话平台。很明显可以这么说，最重要的是要记住,随时都有可能另外一个活动的程序抢占的当前活动的程序（比如:“来电”程序）。这将会调用OnFreeze()和OnPause()方法，并将可能导致你的程序被关闭。如果用户正在你的程序中编辑数据，当另外一个行为出现，你的程序可能被关闭而丢失数据。当然，除非你在处理前就保存工作进度。“Android的方法”是这样做的：Android程序接收或编辑输入需要重载OnFreeze(),在适当的时候并保存它们的状态。当用户再次打开应用时，能够重新恢复数据。一个经典的例子就是邮件程序。当另一个行为启动时，如果用户正在写一封邮件,程序将要保存当前的进度到草稿箱里。

没人想要数据是裸露的

（No One Wants to See Your Data Naked）

If you wouldn’t walk down the street in your underwear, neithershould your data. While it’s possible to expose certain kinds ofapplication to the world to read, this is usually not the bestidea. Exposing raw data requires other applications to understandyour data format; if you change that format, you’ll break any otherapplications that aren’t similarly updated.

The “Android Way” is to create a ContentProvider to expose yourdata to other applications via a clean, well-thought-out, andmaintainable API. Using a ContentProvider is much like inserting aJava language interface to split up and componentize twotightly-coupled pieces of code. This means you’ll be able to modifythe internal format of your data without changing the interfaceexposed by the ContentProvider, and this without affecting otherapplications.

如果你穿着内裤是不会走在街上的，你的数据也是如此。或许可以暴露给确定的几种类型的程序，这通常不是最佳的方法。暴露有规律的数据需要其他程序能够知道你的数据格式。如果你改变了格式，你将破坏那些没有得到同步更新的程序。”Android 的方法“是通过一套简洁的、深思熟虑的、可维护的API来创建一个ContentProvider(内容提供者)来暴露你的数据给其他程序。使用ContentProvider 很像插入Java语言接口分割和组合两段紧密耦合的代码。这意味着您将是能修改您的内部数据格式而不用改变由ContentProvider 暴露接口,你的改变不会影响其它应用。

不要打断正在通话中的用户

If the user is running an application (such as the Phoneapplication during a call) it’s a pretty safe bet he did it onpurpose. That’s why you should avoid spawning Activities except indirect response to user input from the current Activity.

That is, don’t spawn Activities from IntentReceivers or Servicesrunning in the background. Doing so will interrupt whateverapplication is currently running, and result in an annoyed user.Perhaps even worse, your Activity may become a “keystroke bandit”and receive some of the input the user was in the middle ofproviding to the previous Activity. Depending on what yourapplication does, this could be bad news.

Instead of spawning Activities directly from the background, youshould instead use the NotificationManager to set Notifications.These will appear in the status bar, and the user can then click onthem at his leisure, to see what your application has to showhim.

(Note that all this doesn’t apply to cases where your own Activityis already in the foreground: in that case, the user expects to seeyour next Activity in response to input.)

不要打断正在通话中的用户

如果用户正在运行一个程序(如：通话期间的电话程序)，并需要高可靠性。这是为什么忽略新的活动除了用户在当前程序的输入的直接反馈。也就是说，不要让在后台的服务程序或接收程序产生行为。这样做会打断当前运行的程序，并会导致骚扰用户。可能更糟糕是，你的行为可能变成“键盘监视”去接收一些用户的输入。如果你的程序做了这些，这将是一个坏消息。

替换在后台直接产生活动，你需要用NotificationManager来设置通知。这些通知将出现在状态栏,等用户有空的时候可以点击他们，来查看你的程序要做的事前。

(注意：以上所说的不适合于你的活动已经运行在后台,在这样情况下，用户是想看看到输入的下个的活动的）

做大量的事，放到线程中去

If your application needs to perform some expensive or long-runningcomputation, you should probably move it to a thread. This willprevent the dreaded “Application Not Responding” dialog from beingdisplayed to the user, with the ultimate result being the fierydemise of your application.

By default, all code in an Activity as well as all its Views runsin the same thread. This is the same thread that also handles UIevents. For example, when the user presses a key, a key-down eventis added to the Activity’s main thread’s queue. The event handlersystem needs to dequeue and handle that event quickly; if itdoesn’t, the system concludes after a few seconds that theapplication is hung and offers to kill it for the user.

If you have long-running code, running it inline in your Activitywill run it on the event handler thread, effectively blocking theevent handler. This will delay input processing, and result in theANR dialogs. To avoid this, move your computations to a thread;click here to learn how.

做大量的事，放到线程中去

如果你的程序需要执行高CPU占用或长时间的计算，你需要将它挪到线程中。这可以防止显示给用户”程序没反应”的对话框，最终的结果是，你的程序将让出系统的使用权。

默认的情况下，所有的代码是运行在同一个线程中的。处理UI就是在同一个线程中。比如，当用户按下一个按键，一个key-down事件被添加到主线程队列中。事件处理处理器必须出列，然后快速的处理事件。如果不是这样的话，在几秒中后系统推断程序正在挂起中，并提示用户去关掉它。

如果你有长时间运行的代码，并运行在事件处理线程中，将会阻塞事件处理器。这使处理被延时，并会导致”程序为反应”对话框的出现。为了避免这样，需要把它移动程序中；[点击这里学习如何使用]

Avoid Huge Activities

Any application worth using will probably have several differentscreens. When partitioning your UI, be sure to make effective useofActivities.   

Depending on your development background, you may interpret anActivity as similar to something like a Java Applet, in that it isthe entry point for your application. However, that’s not quiteaccurate: where an Applet subclass is the single entry point for aJava Applet, an Activity should be thought of as one of potentiallyseveral entry points to your application. The only differencebetween your “main” Activity and any others you might have is thatthe “main” one just happens to be the only one that expressed aninterest in the “android.intent.action.MAIN” action in yourAndroidManifest..xml file.

So, when designing your application, think of your application as afederation of Activities. This will make your code a lot moremaintainable in the long run, and as a nice side effect also playsnicely with Android’s application history and “backstack”model.

Extend Themes

When it comes to the look-and-feel of the user interface, it’simportant to blend in nicely. Users are jarred by applicationswhich contrast with the user interface they’ve come to expect. Whendesigning your UIs, you should try and avoid rolling your own asmuch as possible. Instead, use a Theme. You can override or extendthose parts of the theme that you need to, but at least you’restarting from the same UI base as all the other applications. Forall the details, click here.

Make Being Flexible part of your Resolutions

Different Android devices will sport different resolutions. Somewill even be able to change resolutions on the fly, such as byswitching to landscape mode. It’s important to make sure yourlayouts and drawables are flexible.

Fortunately, this is very easy to do. Check out Implementing a UserInterface for the full details, but in brief what you must do isprovide different versions of your artwork (if you use any) for thekey resolutions, and then design your layout to accommodate variousdimensions. (For example, avoid using hard-coded positions andinstead use relative layouts.) If you do that much, the systemhandles the rest, and your application looks great on anydevice.

Assume the Network is Slow

Android devices will come with a variety of network-connectivityoptions. All will have some data-access provision, though some willbe faster than others. The lowest common denominator, however, isGPRS, the non-3G data service for GSM networks. Even 3G-capabledevices will spend lots of time on non-3G networks, so slownetworks will remain a reality for quite a long time to come.

That’s why you should always code your applications to minimizenetwork accesses and bandwidth. You can’t assume the network isfast, so you should always plan for it to be slow. If your usershappen to be on faster networks, then that’s great — theirexperience will only improve. You want to avoid the inverse casethough: applications that are usable some of the time, butfrustratingly slow the rest based on where the user is at any givenmoment are likely to be unpopular.

One potential gotcha here is that it’s very easy to fall into thistrap if you’re using the emulator, since the emulator uses yourdesktop computer’s network connection. That’s almost guaranteed tobe much faster than a cell network, so you’ll want to change thesettings on the emulator that simulate slower network speeds. Youcan do this in Eclipse, in the “Emulator Settings” tab of yourlaunch configuration or via a command line option when starting theemulator.

Different Keystrokes for Different Folks

Android will support a variety of handset form-factors. That’s afancy way of saying that some Android devices will have full“QWERTY” keyboards, while others will have 40-key, 12-key, or evenother key configurations. Similarly, some devices will havetouch-screens, but many won’t.

When building your applications, keep that in mind. Don’t makeassumptions about specific keyboard layouts — unless, of course,you’re really interested in restricting your application so that itcan only be used on those devices.

Don’t Assault the Battery

A wireless device isn’t very wireless if it’s constantly pluggedinto the wall. Handheld devices are battery-powered, and the longerwe can make that battery last on a charge, the happier everyone is— especially the user. Two of the biggest consumers of batterypower are the processor, and the radio; that’s why it’s importantto write your applications to do as little work as possible, anduse the network as infrequently as possible.

Minimizing the amount of processor time your application usesreally comes down to writing efficient code. To minimize the powerdrain from using the radio, be sure to handle error conditionsgracefully, and only fetch what you need. For example, don’tconstantly retry a network operation if one failed. If it failedonce, it’s likely because the user has no reception, so it’sprobably going to fail again if you try right away; all you’ll dois waste battery power.

Users are pretty smart: if your program is power-hungry, you cancount on them noticing. The only thing you can be sure of at thatpoint is that your program won’t stay installed very long.