從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 6.1的界面，從Windows Mobile推出的那天起，這個界面就一直被宣傳成内容充實，包含常用所有功能的入口，非常貼合使用者的實際需求。也許在當時，這樣的界面确實能滿足一定的需求，但是到了現在，這樣的設計隻能說是遠離使用者。每一項的高度都過小，是以需要使用筆來點選，或是使用指甲。位于右下角的三個圖示，或許用指甲都很難點到，使用筆即多占用使用者的一隻手，體驗是直線下降的。在使用者希望連耳朵都解放的現在，多占用一隻手是什麼概念，這就意味着使用者乘車時沒有辦法握緊扶手，或者沒有辦法拎着自己的包。另外，在手機操作時，擁有一隻空閑着的手，就能有更多機會處理突發事件，占用使用者的兩隻手實在是不應該的。可以說Windows Mobile的使用者體驗是非常差勁的，幸好微軟在新的Windows Phone 7中，對界面做了巨大的改進，沒有再犯過去的錯誤。
再來看看Android是如何做的，這個界面看起來簡潔明了，和上面的Windows Mobile相比，可以說是毫不出彩，甚至在有些人的眼裡，這個界面很醜陋。但它卻是相當好用的，圖示很大，圖示的間距也很大。這就決定了使用者可以使用指腹去進行點選的操作，并且點選的範圍可以比較大，降低了點錯的幾率。
雖然螢幕點選的方式一定程度上也和螢幕的材質有關，比如電阻屏隻能用筆或指甲，而電容屏允許使用指腹，有一些還可以支援多點觸摸。對于普通使用者來說，使用指腹比使用指甲顯得更為常見，原因很簡單，如果圖示很大，那麼使用者會不自覺的使用指腹去點選，而如果圖示很小，那麼使用者會屈起手指然後用指甲去戳螢幕。這個“屈起手指”的動作不能被大部分的使用者所接受。是以電容屏會漸漸流行，而電阻屏會漸漸被淘汰，這完全是根據使用者的體驗，優勝劣汰，是一件非常符合進化論的事。
使用者體驗還不僅僅是界面上的那些事，作為手機來說，每一個特點都将成為使用者體驗可以挖掘的一部分。比如說是否有鍵盤、是否支援多點觸摸等。有鍵盤的手機與無鍵盤的手機，使用者在執機時用的手勢必然不同，一個着重點在機身下半部分，即鍵盤上；而另一個着重點在整個螢幕上，換言之，手指可能在螢幕的任何一個位置活動。針對裝置的具體情況來對應用進行設計也是很有必要的，目前Google為Android設計的按螢幕大小自動切換布局方式的架構非常有用，它改變了以往在程式的設計過程中，需要為每一種裝置單獨編譯一個版本，或是僅對不同的螢幕做簡單拉伸的情況。另外，在設計中，還需要考慮實際操作體驗，比如放大一張圖檔，是使用放大按鈕，還是使用多點觸摸。這兩種做法都很常見，但是在一個有此需求的應用中，卻不能單獨的使用某一種。比較好的做法是，在程式代碼中，判斷裝置是否支援多點觸摸，若不支援，可以顯示一個放大按鈕，而對于支援的，則在應用第一次啟動時，彈出一個Toast提示，告訴使用者可以多點觸摸進而放大圖檔。
下面再說說應用界面布局的問題，來看下面兩個截圖。
這兩個應用同為Android下的遊戲機模拟器，上面的圖是PS模拟器，可以看到虛拟按鍵的布局有些奇怪，特别是L和R，一上一下非常不習慣。而右面的是GBA模拟器，可以看到它的按鍵中規中矩，使用者馬上就可以上手了。但是，從上手的角度來說，GBA模拟器的确簡單，但是從實用的角度來說，PS模拟器做得更好。為什麼呢？原因很簡單，PS模拟器利用到了整個螢幕，而且虛拟按鍵的布局，防止了兩隻手打架，也防止了螢幕下半部分由于手指的原因完全不可見的問題。通過一段時間的習慣，PS 模拟器就可以被玩得很溜。而再看GBA模拟器，隻利用到了一半的螢幕不說，而且還是縱向的，雙手操作時，兩隻手很容易打架，互相幹擾，要玩一些動作性稍強的遊戲幾乎不可能。雖然看起來直覺易懂，但是這樣的UI，是會被使用者所舍棄的。
在移動平台上，到目前為止，使用者依然沒有固定的操作習慣，而軟體的開發人員要做的事情，就是把使用者往一個簡單、明快的操作體驗上引導，使他們更快的學會使用軟體，并且讓他們習慣、擅長某一種或幾種操作。從某種意義上來說，蘋果的設計人員手冊已經很好的解決了問題，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必定越來越成熟，而開發者們，你們做好心理準備了嗎？