转资深软件工程师谈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推出的那天起，界面就一直被宣传成内容充实，包含常用所有功能的入口，非常贴合用户的实际需求。也许在当时，这样的界面确实能满足一定的 需求，但是到了现在，这样的设计只能说是远离用户。每一项的高度都过小，因此需要使用笔来点击，或是使用指甲。位于右下角的三个图标，或许用指甲都很难点 到，使用笔即多占用用户的一只手，体验是直线下降的。在用户希望连耳朵都解放的现在，多占用一只手是什么概念，这就意味着用户乘车时没有办法握紧扶手，或 者没有办法拎着自己的包。另外，在手机操作时，拥有一只空闲着的手，就能有更多机会处理突发事件，占用用户的两只手实在是不应该的。可以说Windows Mobile的用户体验是非常差劲的，幸好微软在新的Windows Phone 7中，对界面做了巨大的改进，没有再犯过去的错误。
再 来看看Android是如何做的，和Windows Mobile相比，可以说是毫不出彩，甚至在有些人的眼里界面很丑陋。但它却是相当好用的，图标很大，图标的间距也很大。这就决定了用户可以使用指 腹去进行点击的操作，并且点击的范围可以比较大，降低了点错的几率。
虽然屏幕点击的方式一定程度上也和屏幕的材质有关，比如电阻屏只能 用笔或指甲，而电容屏允许使用指腹，有一些还可以支持多点触摸。对于普通用户来说，使用指腹比使用指甲显得更为常见，原因很简单，如果图标很大，那么用户 会不自觉的使用指腹去点击，而如果图标很小，那么用户会屈起手指然后用指甲去戳屏幕。这个“屈起手指”的动作不能被大部分的用户所接受。因此电容屏会渐渐 流行，而电阻屏会渐渐被淘汰，这完全是根据用户的体验，优胜劣汰，是一件非常符合进化论的事。
用户体验还不仅仅是界面上的那些事，作为 手机来说，每一个特点都将成为用户体验可以挖掘的一部分。比如说是否有键盘、是否支持多点触摸等。有键盘的手机与无键盘的手机，用户在执机时用的手势必然 不同，一个着重点在机身下半部分，即键盘上；而另一个着重点在整个屏幕上，换言之，手指可能在屏幕的任何一个位置活动。针对设备的具体情况来对应用进行设 计也是很有必要的，目前Google为Android设计的按屏幕大小自动切换布局方式的框架非常有用，它改变了以往在程序的设计过程中，需要为每一种设 备单独编译一个版本，或是仅对不同的屏幕做简单拉伸的情况。另外，在设计中，还需要考虑实际操作体验，比如放大一张图片，是使用放大按钮，还是使用多点触 摸。这两种做法都很常见，但是在一个有此需求的应用中，却不能单独的使用某一种。比较好的做法是，在程序代码中，判断设备是否支持多点触摸，若不支持，可 以显示一个放大按钮，而对于支持的，则在应用第一次启动时，弹出一个Toast提示，告诉用户可以多点触摸从而放大图片。
在移动平台上，到目前为 止，用户依然没有固定的操作习 惯，而软件的开发人员要做的事情，就是把用户往一个简单、明快的操作体验上引导，使他们更快的学会使用软件，并且让他们习惯、擅长某一种或几种操作。从某 种意义上来说，苹果的设计人员手册已经很好的解决了问题，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一词的本义指“机器人”，同时也是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推出的那天起，界面就一直被宣传成内容充实，包含常用所有功能的入口，非常贴合用户的实际需求。也许在当时，这样的界面确实能满足一定的 需求，但是到了现在，这样的设计只能说是远离用户。每一项的高度都过小，因此需要使用笔来点击，或是使用指甲。位于右下角的三个图标，或许用指甲都很难点 到，使用笔即多占用用户的一只手，体验是直线下降的。在用户希望连耳朵都解放的现在，多占用一只手是什么概念，这就意味着用户乘车时没有办法握紧扶手，或 者没有办法拎着自己的包。另外，在手机操作时，拥有一只空闲着的手，就能有更多机会处理突发事件，占用用户的两只手实在是不应该的。可以说Windows Mobile的用户体验是非常差劲的，幸好微软在新的Windows Phone 7中，对界面做了巨大的改进，没有再犯过去的错误。
再 来看看Android是如何做的，和Windows Mobile相比，可以说是毫不出彩，甚至在有些人的眼里界面很丑陋。但它却是相当好用的，图标很大，图标的间距也很大。这就决定了用户可以使用指 腹去进行点击的操作，并且点击的范围可以比较大，降低了点错的几率。
虽然屏幕点击的方式一定程度上也和屏幕的材质有关，比如电阻屏只能 用笔或指甲，而电容屏允许使用指腹，有一些还可以支持多点触摸。对于普通用户来说，使用指腹比使用指甲显得更为常见，原因很简单，如果图标很大，那么用户 会不自觉的使用指腹去点击，而如果图标很小，那么用户会屈起手指然后用指甲去戳屏幕。这个“屈起手指”的动作不能被大部分的用户所接受。因此电容屏会渐渐 流行，而电阻屏会渐渐被淘汰，这完全是根据用户的体验，优胜劣汰，是一件非常符合进化论的事。
用户体验还不仅仅是界面上的那些事，作为 手机来说，每一个特点都将成为用户体验可以挖掘的一部分。比如说是否有键盘、是否支持多点触摸等。有键盘的手机与无键盘的手机，用户在执机时用的手势必然 不同，一个着重点在机身下半部分，即键盘上；而另一个着重点在整个屏幕上，换言之，手指可能在屏幕的任何一个位置活动。针对设备的具体情况来对应用进行设 计也是很有必要的，目前Google为Android设计的按屏幕大小自动切换布局方式的框架非常有用，它改变了以往在程序的设计过程中，需要为每一种设 备单独编译一个版本，或是仅对不同的屏幕做简单拉伸的情况。另外，在设计中，还需要考虑实际操作体验，比如放大一张图片，是使用放大按钮，还是使用多点触 摸。这两种做法都很常见，但是在一个有此需求的应用中，却不能单独的使用某一种。比较好的做法是，在程序代码中，判断设备是否支持多点触摸，若不支持，可 以显示一个放大按钮，而对于支持的，则在应用第一次启动时，弹出一个Toast提示，告诉用户可以多点触摸从而放大图片。
在移动平台上，到目前为 止，用户依然没有固定的操作习 惯，而软件的开发人员要做的事情，就是把用户往一个简单、明快的操作体验上引导，使他们更快的学会使用软件，并且让他们习惯、擅长某一种或几种操作。从某 种意义上来说，苹果的设计人员手册已经很好的解决了问题，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必定越来越成熟，而开发者们，你们做好思想准备了吗？