Android開發(fā)經驗分享

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

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

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

下面再說說應用界面布局的問題，來看下面兩個截圖。

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

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

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

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

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

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