保证Android应用拥有良好用户体验的三要素(2)

Android架构图（图片来源：http://developer.Android.com/guide/basics/what-is-Android.html）

友好的体验

不友好的体验来自三个方面。

其一是Android的碎片化带来了UI适配问题。Android机型众多，和iPhone相比，界面适配饱受诟病。要保证应用能运行在不同分辨率的手机上，需要理解Android提供的自动适配方案。事实上，Android系统为UI适配做了充分的考虑，只要理解系统对此的精心设计，就能在开发时少走很多弯路，给不同分辨率的用户提供友好的呈现界面。

简单来说可做如下解释：

开发时避免绝对布局（AbsoluteLayout），因为这会让你的应用只在测试机上“看上去很美”，放到别处就横七竖八。

界面控件大小单位多用DIP（Device Independent Pixels），理由同上。

图片尽量使用系统提供的NinePatch技术，能使同一张小图片在不同分辨率的屏幕上保持精度自由缩放。

其二是滥用通知服务，导致用户很容易被打断。典型场景是在通知栏上的各种通知消息，有关无关的都推送，让用户感觉不适。建议是通知适可而止，除非是对用户真正有用的信息，否则最好让用户进入程序后再提示。

其三是主要来自设计师的问题，就是照搬iPhone应用的设计。Android的系统特点不同于iPhone，如程序的栈式管理机制、菜单按钮、返回按钮，从而用户的预期也不尽相同。比如我发现很多设计师喜欢抛弃返回键，模仿iPhone给每一页设计一个软返回按钮。生硬做作的移植会导致与用户预期不一致，是彻底的设计败笔。

节省电量

随时都得插在墙上充电的设备，不叫移动设备。如果你的App让用户一直守着墙角，用户也会很快把你丢到墙角。你会问：“他怎么知道我的应用耗电？”很抱歉，目前来看，Android用户中有大量发烧友和技术高手，同时系统很不客气地记录了每个应用的耗电量，于是用户偶尔会去系统后台查查耗电大户，之后会毫不客气地打开卸载工具。

所以需注意以下几点：

第一，不要绞尽脑汁设计复杂算法，不要在后台跑服务，不要网断了还不停重试。在开发一个模块前先想想会不会费电，如果会，就不要去做。代码是为了服务用户，而不是折腾用户。

高手喜欢挑战，尤其在手机上实现精巧的算法，这样能带来更强的征服感。有人曾在手机上实现了布隆过滤器（一个庞大精巧的类哈希表，多用于在服务器端如垃圾邮件查找），其内存消耗和计算复杂度都远远高于普通的HashMap，且实现并不容易。结果App发布之后，出现用户抱怨耗电量大，并且经常出现Bug，最后还是老老实实换成了HashMap。任何算法的目的都是为了服务用户，如果简单自然的方法能更好地做到这点，何乐而不为？如果真的在客户端找不到简单的算法，则需要反思——为什么在手机上需要复杂的计算？是否该将这些计算放在服务器端？

第二，不要在后台滥用Service。Android非常开放，开发者可在后台触发任何处理逻辑，肆意占用CPU和内存。一般来说，Service的目的是为了监控变化，包括系统和网络变化。系统变化可通过注册BroadcastReceiver监听控制，比如应用安装和卸载等事件，这样耗电量非常小，完全可替代在Service中轮播。网络请求无法用BroadcastReceiver监听，但是有两个建议。

无严苛的实时性要求，可延长轮播间隔，如6小时自动请求一次，同时时间隔可通过服务器在线更新。这样既省电，偶尔急需实时推送时也可在线调整时间间隔。

对实时性有要求，考虑使用成熟的推送服务，如Google的C2DM（http://code.google.com/Android/c2dm/），和亚马逊的AWS SDK （http://aws.amazon.com/sdkforAndroid/）。

第三，网络请求不要太频繁。系统组件中最耗电的是屏幕，其次就是网络。前文已经提到过，网络出错重发会降低用户体验，还会耗费电力。可通过数据预取结合数据压缩算法减少网络请求次数。

总之，在开发时我们要替用户思考是否做到了“流畅、友好、省电”，以保证App拥有不错的用户体验。

作者陈彧堃，曾任职于微软研究院，从事数据挖掘及机器学习的相关研究，对时空数据挖掘，普适计算等领域有深入了解。2010年4月加入友盟，开始打造友盟移动开发平台。