公司散伙了，總結一下（二）

        早上5點自然醒，寫下第一篇總結，引來很多人的關注，一些人跟我要github上的源碼，非常的抱歉啊，雖然公司解散了，但那些資產還是需要保密的，于情于理都不能公開給大家；不過附上我的Github帳號 https://github.com/SwordBearer，互粉吧 ;)  ，在接手這款即時通訊開發后，個人還是學到了很多東西，歡迎一起來交流交流。

 現在從開發層面說說自己遇到的事吧，3月份接手這個項目，還有另外一位同事（比我早畢業一年），我們兩個人一起開發。如果叫我一句話介紹當時對這項目的感覺，那只有三個字：一坨屎。 Android項目初期就是幾個新手在做，從一開始就沒有個好底子，隨后又經手了四五撥人，往上不斷堆積，給整個項目積攢了無數問題：

        1.這幾撥人最大的共同點就是：幾乎不寫注釋！，代碼干干凈凈！不多一行也不少一行！

        2.命名不規范，甚至Socket接口和包名，類名都不對應，連英文都有拼錯的，所有Fragment都寫成Flagment，這樣一兩處倒還好，關鍵是太多了。

以上兩個問題隨之帶來的結果就是出了BUG后，只能連猜帶讀去解決；可我覺得這都是一個程序猿最基本的常識啊，寫規范注釋，規范命名；

        3.對于第三方庫的引用問題，以前的代碼中，凡是用到第三方庫，尤其是UI的，基本上是把整個項目代碼都copy進主項目，順帶把一些文件前面的注釋都去了，并不是通過庫引用方式來使用，所以誰加進來的UI控件，別人基本上不知道怎么用，因為沒有文檔。連最核心的WebSocket網絡連接代碼，也是從Github上扒下來，然后塞進去，不加注釋，這就造成另外一個極其嚴重的問題，下文再述；

細細想想，這半年基本上都是在替人擦屁股，不過在重構整個項目的過程中，還是學到了很多的東西，尤其是在性能和Socket連接上，收獲頗多；

Android性能存在很多問題，內存占用大，點擊響應慢，數據庫讀寫慢，UI繪制慢等等，接下來一一分析一下；

        項目中有用到一個標題欄，所有頁面中都會出現，原來項目中，是定義了一個無比復雜的自定義控件，有左側返回按鈕，右側點擊按鈕，中間標題，以及進度條等等，所有頁面用這一個控件，由于使用了這個標題欄，所有Activity的XML布局中就多了一層。這個標題欄內部又嵌套好幾層，而大多標題欄只有左側返回按鈕和中間標題欄，剩余的那些控件就隱藏起來，這樣夠兇殘吧，過度封裝害死人。如何改進？我想大家都知道――ActionBar，移除原來所有的自定義標題欄，布局中減少了層次，并且ActionBar擴展性更高，可以顯示更多的操作，我沒有測試這個改進會有多少ms的提升，但是一定會更快。

        好多ListAdapter沒有使用復用原理！

有兩個問題著重說一下，一個是數據庫優化，另外一個是Socket連接問題；

一，數據庫優化

app中有一個場景是更新一系列聯系人，測試數據是780條（還包括112個分組，分組下的聯系人總共有780條），當數據變化后，需要將原來的聯系人刪除，先保存分組到分組表，再將這780條插入聯系人表。當時就在這一塊總是出現數據丟失的情況，一部分聯系人沒有保存，這是一個很嚴重的問題。問題就出在SQLite連續插入的地方，原代碼是如何插入的呢？數據庫打開，遍歷插入，然后關閉，最原始最簡單的方法，可是測試了一下，光780條數據，用時20s，很恐怖的結果，20s，一段廣告都看完了。

所以這就演變成了一個很常見的問題：如何在SQLite中一次性插入大量數據？

方法1，開啟事務，這是必須要做的，在for循環外開啟事務，循環中插入數據，循環結束關閉事務。這樣寫了之后，20s立馬變成了4s，當時就震精了。原因：事務是在內存中進行處理，當所有插入完成后，再一次性寫入數據庫，每一次寫入都是一次 IO操作，SQLite是個性能很低的數據庫，聽聞比文件操作的速度慢10倍左右（沒有具體進行比較過）。

方法2，使用SqliteStatement，使用后效果杠杠的，至于為什么，可以參考這里 http://liuzhichao.com/p/1664.html ；

講方法1和方法2結合使用后（最外層開啟事務，然后使用SqliteStatement操作，最后關閉事務），效果如何呢？ 20s直接降到 1s 左右！而且1s 完全可以接受了；

二，Socket連接問題

做過即時通訊的人都知道（當然我還是門外漢），客戶端需要一直保持一個socket長連接，并且要一直發送心跳來維護這個長連接，如果中斷了，需要重新請求連接。

我們的socket連接是放在一個單獨的thread里面去實現數據請求和接收的，這個設計本身其實是有問題的。首先，Android這種平臺，對內存占用非常敏感，后臺的線程一不留神就會被系統kill掉，這就是我們為什么一直斷網的最終原因；其次，socket長連接算是這個應用中最低層，最核心的部分，所有的數據接收發送最終都是在這里處理，不應該將它僅僅用一個線程來處理，不然在通訊過程中，遇到諸如鎖屏，網絡中斷，后臺運行等都有問題，當初在重構的時候是把它放在了一個Service里面，然后對socket在進行定時心跳維護等等，此處涉及的比較多，就不展開了。

經歷這個項目之后，我就在想，如何才能構建一個高性能的Android架構呢？看過INFOQ上分享的微信開發過程 點擊打開鏈接 ，著實讓人膜拜，一個龐大的系統，也是一點點積累起來的，技術，就是這么純粹，只需要時間和耐心去打磨而已。

說多了都是淚，公司倒了，項目停了，心里卻留下了一大段空白，有對技術的，也有對創業的，以后慢慢再敘述吧.........

生活不易，碼農辛苦
如果您覺得本網站對您的學習有所幫助,可以手機掃描二維碼進行捐贈