做了將近兩個月的android應用開發，第一版已差不多結束了。作爲一個新手，我感受比較深的就是開發中最重要的是邏輯設計。我覺得就語言而言，從應用的角度來將沒什麼感覺，就按照官方的demo照葫蘆畫瓢就可以了，不會的就google一下，沒有覺得什麼。當然實現這些實用的控件是非常了不起的，那些背後的設計模式是非常好的。暫時沒有去深究。在很方便的使用這些控件的時候，我感受比較深的是如何把應用做得穩定，如何提高訪問的速度，如何降低內存的佔用，等等。
這些方面我比較深刻的映象是對於數據流程的處理。上學期看了一些書，學了這些設計方面的知識。在一開始設計的時候，我把數據分成了三層：界面、領域、數據源。Android本身已經很好的實現了MVC，界面都是通過xml來編輯的。在一個手機應用中領域層的功能比較小，因爲沒有太複雜的計算，所以，在我的應用中，實際上領域層並不是很明顯。有的時候直接界面層訪問數據源層運行還好一些。數據源層中，主要處理來自手機數據庫，網絡，手機本地文件的數據。原本我覺得這些都是一個層次的，沒有對內部進行仔細的設計。沒想到在後面對這一部分改了好幾次，甚至在臨近發佈了，又進行了一次比較大的改進。
舉一個例子，我的應用中有一個功能是照片的顯示，我最初的流程是這樣的：
這樣的考慮是覺得數據庫和網絡是一個層次的，我覺得都可以理解爲從外部讀取數據。而且爲了在第一時間將結果呈現出來，所以這樣的設計都是在讀取到數據後馬上反映到界面上。結果這樣產生了很不好的效果。比如因爲實際上界面上顯示的數據來自不同的地方，至少有數據庫和網絡，那麼就要做判斷。我是用gridview來顯示圖片的。由於來源不同，在顯示的時候需要將得到的數據拼湊起來，如果要符合同統一的規律顯示就更加困難了。在實際的操作中，GridView如果從網絡讀取數據，就得另外開線程。就又需要考慮將得到的圖像和相應的ImageView配對起來。網上有很多這樣做的，事先用一個arraylist把需要放圖片的ImageView和對應的圖片存到裏面。用一個回調接口，等下載成功後把得到的圖片顯示到界面上。但不管哪個，都比較複雜。過一段時間之後，或者另外的人來看都會比較費勁。GridView在顯示的時候，一個方格可能會刷新很多次，會調用很多次getView方法，如果是開線程，就會開好多其實是一個目的的線程。這裏就又需要想辦法來限制。Android的UI不是線程安全的，顯示的任務只能交給主線程。這又要考慮線程之間的通信。讀取網絡很可能會出問題。線程又是不可控制的。所以這一切都會造成相冊顯示不穩定。
後來我考慮了一下，做了一些改進：
這裏其實是在數據源層內部也進行了明顯的分層。現在數據庫的數據來源只是網絡，手機界面顯示的數據只來自數據庫。這樣就可以解決很多的問題。因爲手機界面的數據來源是單一的，所以就免去了很多的判斷。並且很多的排序，篩選之類的工作都交給數據庫完成，手機界面就只是負責顯示的任務，減輕了很多的負擔。從網絡下載的圖片數據不再直接顯示到手機界面上，而是一律存儲到數據庫中。這就免去了主線程以外的線程來操控界面，省去了一些不穩定的因素。從網絡下載圖片放到軟件啓動的時候，這樣用戶打開相冊的時候就可以直接從數據庫讀取圖片，不用等待去網絡下載，速度會更加快。而且專門有一個時間來從網絡讀圖片就可以很方便的用線程池來維護這些下載圖片的線程，使線程可控性更高。當這樣清晰之後，可以節省很多代碼，不容易出錯，而且軟件更加穩定。前兩天看過一句話，我覺得很經典：“有兩種設計方式，一種是把系統設計得足夠複雜，以至於看不出明顯的錯誤；另外一種是把系統設計得足夠簡單，以至於明顯看不出錯誤。”深有體會啊。邏輯清楚簡單的代碼也容易讓別人懂。
這是一個我碰到的簡單的例子，這些日子我體會了爲什麼設計模式很重要，好的設計思想可以把複雜的事情變得簡單，簡單的流程意味着可以做出更加強大的系統。好的設計思想使系統簡潔，容易維護。簡單的容易維護四個字後面意味着可以容易擴展，可以節約很多的成本。可以有更長的生命週期，所帶來的價值太大了。這是我現在才體會到的。
今天看了Mark Little的一篇文章，深有啓發。所以決定在急着去學習下一個熱門技術之前。好好總結一下這些平淡無奇但是實用的思路，經驗。因爲很多時候，直接提高一個系統的性能的往往不是尖端的技術，而是這些平常的但是久經考驗的知識。由此，有勇氣把這個簡單的總結寫了下來。