盛大资深软件工程师谈Android开发经验

从G1上市到现在，市面上已经出现了至少30款Android手机。为什么至今依然有一些用户在抱怨Android不好用，在相关的开发中，什么才是真正值得关注的，开发的核心是什么？为什么移动应用需要格外关注用户体验？本文将对这些问题尽可能的作出解答。

 
 
文/何晓杰
 
 
 
Android一词的本义指
“
机器人
”
，同时也是
Google
于
2007
年
11
月
5
日宣布的基于
Linux
的开源手机操作系统的名称，该平台由操作系统、中间件、用户界面和应用程序组成，是首个真正为移动终端打造的开放并且完整的移动平台。
2008
年
9
月
22
日，美国运营商
T-Mobile USA
在纽约正式发布第一款
Google
手机，即
T-Mobile G1
，从那个时候起，
Android
的时代就真正的来临了。

从Android 1.0
至今经历了多次的版本更新，其中重要的变更是
1.5
、
2.0
和
2.2
。而其他的版本更新相对而言并不是那么重要。另外，由于每次更新都会多少改动包括
Dalvik
在内的底层模块，同时牵扯到
SDK
，导致了一些程序需要跟着
Android
版本进行变动。对于相对较为保守的开发人员而言，快速的版本更新将给他们带来越来越大的限制。在这种情况下，
Android
开源的意义就显得不是那么大了。

无论如何，由于Android
与
Google
服务的紧密捆绑，这款操作系统拥有了得天独厚的优势。通过
Google
强有力的支持，很多事情在
Android
上都会变得很简单。另外需要特别提出的是，
Android
是一款基于互联网的操作系统，在可以连接上互联网的情况下，一款
Android
手机可以发挥出比其他手机更多的能力。而在没有网络的情况下，
Android
手机并不比其他的手机出色，尤其是娱乐性相对于
iPhone
可以说是逊色不少。

作为开发人员，应当在学习并深入了解Android
之后，在自己的软件中，将
Android
的优势发挥出来，同时通过一些手段去弥补
Android
本身的缺陷或不足。下面来看一下
Android
拥有的特点吧：

与硬件交互非常方便，包括摄像头、GPS
等，都可以简单的操作。

拥有自己的运行时和虚拟机，优秀的内存管理能力。

提供丰富的界面控件供开发者使用，允许可视化开发，并保证Android
平台下的应用程序界面一致。

提供轻量级的进程间通信机制。

支持无界面的后台服务类应用程序。

支持高效、快速的数据存取方式。

在这些特性的支持下，试图在Android
下开发一个应用不会太过困难。事实上，一个稍有
Java
经验的开发人员，都可以快速的上手进行
Android
的开发。而开发的核心，一直以来也是围绕着
Android
手机几个大的特点来进行的，其中就包括了触摸屏、摄像头、
GPS
模块、互联网功能、语音输入、
Google
账户等。需要说的是，如果一位
J2ME
工程师想转行做
Android
，那么他将付出的代价比
J2SE
或
J2EE
工程师要大得多。毕竟
Android
所支持的是基本完整的
J2SE
的子集，反过来再看
J2ME
就会觉得它的功能太弱了。

除了Java
外，还有许多语言支持
Android
的开发，比较为人所熟知的有
Scala
，而作为
Android
本身的底层语言，
C/C++
的作用也完全不可忽视。而目前的开源社区内，已经有一些牛人在尝试让更多的语言可以开发
Android
应用。比较有代表性的可能是
Koushik Dutta
，他已经解决了在
Mono
平台下，让
Dalvik
调用
Mono
代码的问题。或许在不久的将来，
.NET
下的所有语言，都有可能借助
Mono
跑在
Android
上，这是一件值得让人期待的事情。

语言已不是问题，那还有什么会成为问题？也许很多人会说“
经验
”
。诚然，经验决定了一位开发人员能否快速地、流畅地完成开发工作，也决定了软件的鲁棒性，
Bug
的数量、等级和修正问题的返工次数。不过我认为，这些都不重要，哪怕是一个
Android
行业的新人，一边查询文档一边做开发，虽然效率会很低，但是一样能把项目做完。在
Android
下，开发技术几乎是没有瓶颈的。那么瓶颈在哪里呢？事实上，在用过很多软件后，就会发现，有很多软件并不好用。很多用户不愿意用某个软件，也并不是因为软件没有技术含量或是满足不了需求，原因很简单，就是不好用。

用
户体验是凌驾于技术之上的，可以说，优秀的用户体验将可以起到事半功倍的效果，在一堆同类的软件中，下载量最大的，一定是让用户用着感觉最舒服的，哪怕它
的功能并不比其他的产品出色，甚至略差一些。我见过很多开发人员，他们视技术为己任，一心只钻研技术，认为技术出色的软件，会受到用户的好评，甚至在一个
手机游戏中，加入各种华丽炫目的3D
效果。这些固然都不错，但是真正的用户却不会喜爱它们。在移动应用中，简洁明快才是用户希望看到的。试想一下，当用户在手机上玩一个
RPG
游戏，并被华丽的
3D
效果充斥了整个界面，那么他将完全无法着手进行下一个动作。诚然，华丽的画面是很容易吸引人，但是在这种华丽的背后，却会直接把用户和开发者自己领入一条深渊，再也无法回头，最终的结果就是，用户完全舍弃该款游戏，开发者或运营商也完全赚不到钱。

在移动平台开发的过程中，用户体验已经成为首要大事，只有聚焦在用户的设计，才有可能被用户所接受。下面来看一些典型的例子。



左图是经典的Windows Mobile 6.1
的界面，从
Windows Mobile
推
出的那天起，这个界面就一直被宣传成内容充实，包含常用所有功能的入口，非常贴合用户的实际需求。也许在当时，这样的界面确实能满足一定的需求，但是到了
现在，这样的设计只能说是远离用户。每一项的高度都过小，因此需要使用笔来点击，或是使用指甲。位于右下角的三个图标，或许用指甲都很难点到，使用笔即多
占用用户的一只手，体验是直线下降的。在用户希望连耳朵都解放的现在，多占用一只手是什么概念，这就意味着用户乘车时没有办法握紧扶手，或者没有办法拎着
自己的包。另外，在手机操作时，拥有一只空闲着的手，就能有更多机会处理突发事件，占用用户的两只手实在是不应该的。可以说
Windows Mobile
的用户体验是非常差劲的，幸好微软在新的
Windows Phone 7
中，对界面做了巨大的改进，没有再犯过去的错误。



再来看看Android
是如何做的，这个界面看起来简洁明了，和上面的
Windows Mobile
相比，可以说是毫不出彩，甚至在有些人的眼里，这个界面很丑陋。但它却是相当好用的，图标很大，图标的间距也很大。这就决定了用户可以使用指腹去进行点击的操作，并且点击的范围可以比较大，降低了点错的几率。

虽
然屏幕点击的方式一定程度上也和屏幕的材质有关，比如电阻屏只能用笔或指甲，而电容屏允许使用指腹，有一些还可以支持多点触摸。对于普通用户来说，使用指
腹比使用指甲显得更为常见，原因很简单，如果图标很大，那么用户会不自觉的使用指腹去点击，而如果图标很小，那么用户会屈起手指然后用指甲去戳屏幕。这个“
屈起手指
”
的动作不能被大部分的用户所接受。因此电容屏会渐渐流行，而电阻屏会渐渐被淘汰，这完全是根据用户的体验，优胜劣汰，是一件非常符合进化论的事。

用
户体验还不仅仅是界面上的那些事，作为手机来说，每一个特点都将成为用户体验可以挖掘的一部分。比如说是否有键盘、是否支持多点触摸等。有键盘的手机与无
键盘的手机，用户在执机时用的手势必然不同，一个着重点在机身下半部分，即键盘上；而另一个着重点在整个屏幕上，换言之，手指可能在屏幕的任何一个位置活
动。针对设备的具体情况来对应用进行设计也是很有必要的，目前Google
为
Android
设
计的按屏幕大小自动切换布局方式的框架非常有用，它改变了以往在程序的设计过程中，需要为每一种设备单独编译一个版本，或是仅对不同的屏幕做简单拉伸的情
况。另外，在设计中，还需要考虑实际操作体验，比如放大一张图片，是使用放大按钮，还是使用多点触摸。这两种做法都很常见，但是在一个有此需求的应用中，
却不能单独的使用某一种。比较好的做法是，在程序代码中，判断设备是否支持多点触摸，若不支持，可以显示一个放大按钮，而对于支持的，则在应用第一次启动
时，弹出一个
Toast
提示，告诉用户可以多点触摸从而放大图片。

下面再说说应用界面布局的问题，来看下面两个截图。





这两个应用同为Android
下的游戏机模拟器，上面的图是
PS
模拟器，可以看到虚拟按键的布局有些奇怪，特别是
L
和
R
，一上一下非常不习惯。而右面的是
GBA
模拟器，可以看到它的按键中规中矩，用户马上就可以上手了。但是，从上手的角度来说，
GBA
模拟器的确简单，但是从实用的角度来说，
PS
模拟器做得更好。为什么呢？原因很简单，
PS
模拟器利用到了整个屏幕，而且虚拟按键的布局，防止了两只手打架，也防止了屏幕下半部分由于手指的原因完全不可见的问题。通过一段时间的习惯，
PS
模拟器就可以被玩得很溜。而再看
GBA
模拟器，只利用到了一半的屏幕不说，而且还是纵向的，双手操作时，两只手很容易打架，相互干扰，要玩一些动作性稍强的游戏几乎不可能。虽然看起来直观易懂，但是这样的
UI
，是会被用户所舍弃的。

在移动平台上，到目前为止，用户依然没有固定的操作习惯，而软件的开发人员要做的事情，就是把用户往一个简单、明快的操作体验上引导，使他们更快的学会使用软件，并且让他们习惯、擅长某一种或几种操作。从某种意义上来说，苹果的设计人员手册已经很好的解决了问题，iPad
已经做到了中老年人也可以轻松上手，甚至连猫都会玩。但是至少目前为止，还没有见到适用于
Android
的设计手册，开发人员或是软件厂商也都各按自己的理解去进行软件的设计，用户也被迫在使用不同的软件时，适应不同的风格。

在未来为期不短的一段时间内，Android
上应用程序的用户体验将成为一个主要的研究点，特别是游戏类应用。由于
Android
上的某些限制，开发人员较难实现像
PSP
游戏那样的华丽效果，因此只能够在游戏本身的游戏性上下足工夫。当然了，等
Android
手机的性能再次大幅提升，电池容量再大幅提升后，可能会出现可以匹敌
PSP
游戏的华丽游戏，只是目前不应当过分考虑这些。

在我以前的一些文章也曾提到过，为移动平台做开发，应该尽可能的考虑程序的执行效率而不是架构，因为移动平台本身通常不会有多好的配置，在有限的配置下实现性能最佳化是非常重要的。从另一种角度上说，iPhone
能够用较低的配置来实现整机流畅运作，也是得益于较为严格地针对性优化，把硬件平台的性能完全发挥出来，这样做得到的结果是，
iPhone
的整体性能，看起来反而比一些更高配置的手机要好一些。

最后，再简单地说一下Android
的开发与其他平台的开发有什么异同。我们知道不同的开发方式将对最终的结果产生不同的影响。在以往的经验中，各厂家的开发工具，都在往可视化方向发展，比如说微软的
Visual Studio
，一代比一代强大，可视化程度越来越高。而苹果的
Xcode
也是一样，它建议用户完全使用可视化的方案来解决一个应用。这些固然很好，但是带来的问题也不小。举个简单的例子，有一个
Windows Mobile
的应用，上面有一个
ListBox
，而你正试图为该
ListBox
添加一个图标，并试图按每一项的内容限定来改变文字颜色。能做到吗？当然能，但是过程却不简单，你必须经历复杂的自绘才能实现这一点。这也是常规的
RAD
开发中普遍遇到的问题，即开发人员不能方便地控制到应用的每一个细节。开发框架对
API
的封装在某种程度上提高了开发的效率，但是另一种程度上，它屏蔽了太多的细节，而这些细节有可能就是开发人员所需要的。

而Android
虽然也拥有可视的开发环境，但是它非常弱，第三方的
RAD
方案迄今为止也依然显得虚弱无力，对于用惯了微软等公司出品的高级
RAD
环境的人来说，可能会充满了无奈，也可能充满了鄙视，这种可视化算什么呢？如果仅仅从开发人员的角度来看，有利也有弊，弊端很显然是开发效率不够高，而事实上，由于
Android
采用
Java
语言来进行开发，其开发效率本身就不会太高。而利的部分，可能是会被很多高级工程师所喜爱的，因为它是牺牲开发效率，来换取最大的可定制性的一个典范。也许有一些刚开始学习
Android
开发的朋友会觉得制作界面有种种的不便，但是只要深入地学习下去，就会觉得
Android
的界面实现方式是非常领先的。同样举出上面
ListBox
的例子，在
Android
下，就可以通过一组短小精悍的代码来自定义
ListItem
和相关
Adapter
以实现。

我想优秀的开发人员是应该完全放弃RAD
的，在目前的环境下，
RAD
几乎没有什么作为，反而会成为应用分层的一个巨大的绊脚石。在
RAD
的环境下，要求一位开发人员对软件的每一个部分都面面俱到，这怎么可能呢？比如说软件界面就是应该交由
UI
专员去设计，数据库部分也应该交由相关的负责人去做，完全不可能由开发人员从头到尾一个人搞定。如果哪个老板真的雇用了一位超级开发人员来包办一切，那么除非那个人拥有
100
年的工作经验，不然的话项目做死就是活该。我想
Android
的开发框架已经很好地说明了这个问题，程序资源（包括图片、字符串、其他的外部数据等）和代码完全分离，各部分人员各司其职，完成整个项目，每个部分的人员都不会有太大的压力。并且，由于
Android
采用
XML
对界面进行描述，使得对界面的更换也变得容易，设计师可以设计出多套界面，不论是用于
UI
方案评估或是在实际应用中更换界面风格都很方便。这也是其他移动平台的开发所不具备的。

最后，我想说的是，我非常想要一本类似于《Android
设计手册》的参考书，我相信很多的开发人员也非常想要。只是短期内，我们依然只能自己来研究，推测用户可能的行为，并为此可能性做好打算。
Android
必定越来越成熟，而开发者们，你们做好思想准备了吗？

 
作者简介：

何晓杰，就职于盛大创新院，资深软件工程师，移动行业研究者。同时也是手机爱好者，玩机达人，目前的主要关注点在Android
和其他的移动平台。

原文地址:http://www.programmer.com.cn/4031/