再來看看Android是如何做的，這個(gè)界面看起來簡潔明了，和上面的Windows Mobile相比，可以說是毫不出彩，甚至在有些人的眼里，這個(gè)界面很丑陋。但它卻是相當(dāng)好用的，圖標(biāo)很大，圖標(biāo)的間距也很大。這就決定了用戶可以使用指腹去進(jìn)行點(diǎn)擊的操作，并且點(diǎn)擊的范圍可以比較大，降低了點(diǎn)錯(cuò)的幾率。

雖然屏幕點(diǎn)擊的方式一定程度上也和屏幕的材質(zhì)有關(guān)，比如電阻屏只能用筆或指甲，而電容屏允許使用指腹，有一些還可以支持多點(diǎn)觸摸。對(duì)于普通用戶來說，使用指 腹比使用指甲顯得更為常見，原因很簡單，如果圖標(biāo)很大，那么用戶會(huì)不自覺的使用指腹去點(diǎn)擊，而如果圖標(biāo)很小，那么用戶會(huì)屈起手指然后用指甲去戳屏幕。這個(gè)“屈起手指”的動(dòng)作不能被大部分的用戶所接受。因此電容屏?xí)u漸流行，而電阻屏?xí)u漸被淘汰，這完全是根據(jù)用戶的體驗(yàn)，優(yōu)勝劣汰，是一件非常符合進(jìn)化論的事。

用戶體驗(yàn)還不僅僅是界面上的那些事，作為手機(jī)來說，每一個(gè)特點(diǎn)都將成為用戶體驗(yàn)可以挖掘的一部分。比如說是否有鍵盤、是否支持多點(diǎn)觸摸等。有鍵盤的手機(jī)與無 鍵盤的手機(jī)，用戶在執(zhí)機(jī)時(shí)用的手勢(shì)必然不同，一個(gè)著重點(diǎn)在機(jī)身下半部分，即鍵盤上;而另一個(gè)著重點(diǎn)在整個(gè)屏幕上，換言之，手指可能在屏幕的任何一個(gè)位置活 動(dòng)。針對(duì)設(shè)備的具體情況來對(duì)應(yīng)用進(jìn)行設(shè)計(jì)也是很有必要的，目前Google為Android設(shè) 計(jì)的按屏幕大小自動(dòng)切換布局方式的框架非常有用，它改變了以往在程序的設(shè)計(jì)過程中，需要為每一種設(shè)備單獨(dú)編譯一個(gè)版本，或是僅對(duì)不同的屏幕做簡單拉伸的情 況。另外，在設(shè)計(jì)中，還需要考慮實(shí)際操作體驗(yàn)，比如放大一張圖片，是使用放大按鈕，還是使用多點(diǎn)觸摸。這兩種做法都很常見，但是在一個(gè)有此需求的應(yīng)用中， 卻不能單獨(dú)的使用某一種。比較好的做法是，在程序代碼中，判斷設(shè)備是否支持多點(diǎn)觸摸，若不支持，可以顯示一個(gè)放大按鈕，而對(duì)于支持的，則在應(yīng)用第一次啟動(dòng) 時(shí)，彈出一個(gè)Toast提示，告訴用戶可以多點(diǎn)觸摸從而放大圖片。

下面再說說應(yīng)用界面布局的問題，來看下面兩個(gè)截圖。

這兩個(gè)應(yīng)用同為Android下的游戲機(jī)模擬器，上面的圖是PS模擬器，可以看到虛擬按鍵的布局有些奇怪，特別是 L和R，一上一下非常不習(xí)慣。而右面的是GBA模擬器，可以看到它的按鍵中規(guī)中矩，用戶馬上就可以上手了。但是，從上手的角度來說，GBA模擬器的確簡單，但是從實(shí)用的角度來說，PS模擬器做得更好。為什么呢?原因很簡單，PS模擬器利用到了整個(gè)屏幕，而且虛擬按鍵的布局，防止了兩只手打架，也防止了屏幕下半部分由于手指的原因完全不可見的問題。通過一段時(shí)間的習(xí)慣，PS 模擬器就可以被玩得很溜。而再看GBA模擬器，只利用到了一半的屏幕不說，而且還是縱向的，雙手操作時(shí)，兩只手很容易打架，相互干擾，要玩一些動(dòng)作性稍強(qiáng)的游戲幾乎不可能。雖然看起來直觀易懂，但是這樣的UI，是會(huì)被用戶所舍棄的。

在移動(dòng)平臺(tái)上，到目前為止，用戶依然沒有固定的操作習(xí)慣，而軟件的開發(fā)人員要做的事情，就是把用戶往一個(gè)簡單、明快的操作體驗(yàn)上引導(dǎo)，使他們更快的學(xué)會(huì)使用軟件，并且讓他們習(xí)慣、擅長某一種或幾種操作。從某種意義上來說，蘋果的設(shè)計(jì)人員手冊(cè)已經(jīng)很好的解決了問題，iPad已經(jīng)做到了中老年人也可以輕松上手，甚至連貓都會(huì)玩。但是至少目前為止，還沒有見到適用于Android的設(shè)計(jì)手冊(cè)，開發(fā)人員或是軟件廠商也都各按自己的理解去進(jìn)行軟件的設(shè)計(jì)，用戶也被迫在使用不同的軟件時(shí)，適應(yīng)不同的風(fēng)格。

在未來為期不短的一段時(shí)間內(nèi)，Android上應(yīng)用程序的用戶體驗(yàn)將成為一個(gè)主要的研究點(diǎn)，特別是游戲類應(yīng)用。由于Android上的某些限制，開發(fā)人員較難實(shí)現(xiàn)像PSP游戲那樣的華麗效果，因此只能夠在游戲本身的游戲性上下足工夫。當(dāng)然了，等Android手機(jī)的性能再次大幅提升，電池容量再大幅提升后，可能會(huì)出現(xiàn)可以匹敵PSP游戲的華麗游戲，只是目前不應(yīng)當(dāng)過分考慮這些。

在我以前的一些文章也曾提到過，為移動(dòng)平臺(tái)做開發(fā)，應(yīng)該盡可能的考慮程序的執(zhí)行效率而不是架構(gòu)，因?yàn)橐苿?dòng)平臺(tái)本身通常不會(huì)有多好的配置，在有限的配置下實(shí)現(xiàn)性能最佳化是非常重要的。從另一種角度上說，iPhone 能夠用較低的配置來實(shí)現(xiàn)整機(jī)流暢運(yùn)作，也是得益于較為嚴(yán)格地針對(duì)性優(yōu)化，把硬件平臺(tái)的性能完全發(fā)揮出來，這樣做得到的結(jié)果是，iPhone的整體性能，看起來反而比一些更高配置的手機(jī)要好一些。

最后，再簡單地說一下Android的開發(fā)與其他平臺(tái)的開發(fā)有什么異同。我們知道不同的開發(fā)方式將對(duì)最終的結(jié)果產(chǎn)生不同的影響。在以往的經(jīng)驗(yàn)中，各廠家的開發(fā)工具，都在往可視化方向發(fā)展，比如說微軟的 Visual Studio，一代比一代強(qiáng)大，可視化程度越來越高。而蘋果的Xcode也是一樣，它建議用戶完全使用可視化的方案來解決一個(gè)應(yīng)用。這些固然很好，但是帶來的問題也不小。舉個(gè)簡單的例子，有一個(gè) Windows Mobile 的應(yīng)用，上面有一個(gè) ListBox，而你正試圖為該 ListBox 添加一個(gè)圖標(biāo)，并試圖按每一項(xiàng)的內(nèi)容限定來改變文字顏色。能做到嗎?當(dāng)然能，但是過程卻不簡單，你必須經(jīng)歷復(fù)雜的自繪才能實(shí)現(xiàn)這一點(diǎn)。這也是常規(guī)的RAD開發(fā)中普遍遇到的問題，即開發(fā)人員不能方便地控制到應(yīng)用的每一個(gè)細(xì)節(jié)。開發(fā)框架對(duì)API的封裝在某種程度上提高了開發(fā)的效率，但是另一種程度上，它屏蔽了太多的細(xì)節(jié)，而這些細(xì)節(jié)有可能就是開發(fā)人員所需要的。

而Android雖然也擁有可視的開發(fā)環(huán)境，但是它非常弱，第三方的RAD方案迄今為止也依然顯得虛弱無力，對(duì)于用慣了微軟等公司出品的高級(jí)RAD環(huán)境的人來說，可能會(huì)充滿了無奈，也可能充滿了鄙視，這種可視化算什么呢?如果僅僅從開發(fā)人員的角度來看，有利也有弊，弊端很顯然是開發(fā)效率不夠高，而事實(shí)上，由于Android采用Java語言來進(jìn)行開發(fā)，其開發(fā)效率本身就不會(huì)太高。而利的部分，可能是會(huì)被很多高級(jí)工程師所喜愛的，因?yàn)樗菭奚_發(fā)效率，來換取最大的可定制性的一個(gè)典范。也許有一些剛開始學(xué)習(xí)Android開發(fā)的朋友會(huì)覺得制作界面有種種的不便，但是只要深入地學(xué)習(xí)下去，就會(huì)覺得Android的界面實(shí)現(xiàn)方式是非常領(lǐng)先的。同樣舉出上面ListBox的例子，在Android下，就可以通過一組短小精悍的代碼來自定義ListItem和相關(guān)Adapter以實(shí)現(xiàn)。