程序员：Android开发经验分享（三）

      在移动平台上，到目前为止，用户依然没有固定的操作习惯，而软件的开发人员要做的事情，就是把用户往一个简单、明快的操作体验上引导，使他们更快的学会使用软件，并且让他们习惯、擅长某一种或几种操作。从某种意义上来说，苹果的设计人员手册已经很好的解决了问题，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必定越来越成熟，而开发者们，你们做好思想准备了吗?