開源的豆瓣客戶端源碼 你們能夠學習下

開放源代碼

因爲豆瓣關閉了我的開發者 API Key 申請，此應用已不可能向公衆發佈，所以決定提早開放源代碼，也給有興趣者作些 HACKING。

如下是關於豆芽的說明。

部分特性

• Material Design
• 首頁友鄰廣播
• 啓動速度優化
• 界面動畫
• 支持屏幕旋轉
• 平板多列視圖
• 支持使用 Custom Tabs 打開網頁
• 支持切換長/短連接顯示

預覽

圖片：

          

視頻：

• 優酷連接
• Vimeo 連接

關於名字

豆芽的名字取自「Douban, Yet Another」的縮寫和中文詞語「豆芽」的拼音正好相同的巧合。

取名以後，我才得知豆瓣的 Windows Phone 客戶端的名字也叫作「豆芽」。因此相對於豆瓣官方應用「一個叫‘豆瓣’的App」，也正好將這個應用稱爲「另外一個叫豆芽的應用」了。

爲何要有豆芽？

直接訪問豆瓣的全部人裏，最廣泛而一致的用法是圍繞電影、電視、書、唱片、活動(咱們叫作」條目」的東西)的評分評論、發現和討論。咱們會把和網站同步的評分評論做爲一個起點和基礎，在手機上從新構建圍繞我的興趣的發現和討論。

一個叫「豆瓣」的App——豆瓣日誌

豆瓣歷來不是一個單一的網站，而對於豆瓣的用法天然不盡相同。使用豆瓣是爲了獲取信息，但信息的獲取是基於條目和算法，仍是基於友鄰和人，這個問題在豆瓣的屢次改版中大概一直懸而未決。

此次，一個叫「豆瓣」的應用選擇的是基於條目的推薦。但我我的做爲一個重度豆瓣用戶，重視的卻剛好是基於人的推薦，喜歡的是友鄰間的雞犬相聞，以及閒逛時從條目評論、廣播、日記中發現新友鄰的驚喜。正如我在某次「還我舊版」運動中聽到的聲音，「無論怎麼改版，只要友鄰們還在就好」，改版是豆瓣不斷良好發展的必經之路，但這句話中對友鄰的珍重又令我感覺到了豆瓣最寶貴的特質。

豆瓣做爲一個工具的價值能夠經過條目很好體現，但豆瓣做爲一個獨一無二的社區，只能經過它獨有的、剋制的、以人爲本的方式才能維繫。做爲一個普通但也深愛豆瓣的用戶，我但願豆瓣在這個方向上也不要失落，由於一個只有工具屬性的網站對我而言將再也沒有這樣的歸屬感。

我在這一點上與豆瓣應用有了不一樣的追求，而且剛好有一些這方面的能力，又剛好豆瓣提供了開放的 API，因而就想要將這個想法實現出來了。

選擇開始豆芽這個項目，還有一個緣由是我但願在豆瓣繼續看到平臺原生的設計。

豆瓣廣播在幾年前就已是國內少有的幾個 Android Design 的應用，這一點一直令我欽佩和喜好。在豆瓣應用最開始的版本中，也曾有過 Material Design 的嘗試，但隨着和 iOS 風格設計的雜糅，逐漸顯得不合時宜，以致於最終選擇了徹底的 iOS 風格。我對此一直感到有些遺憾，何況 Material Design 也是一款更加優秀的設計語言。因此，我但願實現未能見到的另外一種可能性。

指導原則

豆芽的最終目標是爲豆瓣中基於友鄰的信息獲取方式提供在移動端的便利。爲了優雅地實現這個目標，豆芽將主要遵循如下的原則：

• 遵循 Material Design 規範，且指導思想優先於細節規定。
• 像素完美，但更注重以人爲本。
• 實現精確，代碼能夠自我辯護。
• 行爲合格，支持屏幕旋轉和平板佈局。
• 功能崇尚簡約，不打擾用戶。
• 行爲默認值合理，且用戶可調節。
• 積極表現豆瓣特性，如廣播、友鄰、豆郵等。
• 經過細節設計，提倡用心、考慮到他人的內容。

規則能夠被打破，但前提是理解規則。

功能架構

豆芽的架構將與當前網站的設計十分相似。

你可能會問，難道豆芽只是要作一個豆瓣網站源碼的移動端界面麼？並不是如此。豆芽的最終目標是爲基於友鄰的信息獲取方式提供便利，因此架構設計也是爲此服務。而架構與當前網頁端設計基本相同，則是由於如今網頁端正是一個符合這個目標的設計，而且與移動端的導航也能夠很好地契合。

讓咱們詳細地規劃一下豆芽吧。

導航採用抽屜一級導航 + 選項卡二級導航的方式。工具欄上將顯示全局的動做。

• 工具欄
  • 提醒：全部類別的提醒，能夠查看歷史提醒
  • 豆郵：用戶間的郵件往來，但願鼓勵鄭重而非聊天。
  • 搜索：當即訪問想要的內容。
• 用戶：點擊後顯示我的頁面，至關於「個人豆瓣」。
• 首頁
  • 友鄰廣播：友鄰互動、友鄰推薦、系統定製的推薦。
  • 九點：友鄰的日記、博客文章等，有深度的內容。
  • 一刻：全站範圍的熱門內容推薦。
  • 同城：基於地理位置的內容。
  • 線上活動：基於共同興趣的內容。
• 讀書
  • 分類瀏覽、首頁推薦：入口，以及最有可能發現新內容的地方。
  • 我讀：管理本身的讀書標記、創造內容。
  • 動態：查看友鄰的閱讀動態，互動、得到推薦。
  • 豆瓣猜：基於算法的推薦。
• 電影
  • 相似讀書。
• 音樂
  • 相似讀書。
• 設置：提供應用設置等。

在子頁面設計中，豆芽將盡可能鼓勵長內容和用心的互動。由於我相信只有豆瓣值得這樣嘗試。

實現情況

我在最初的二十天內衝刺實現了應用的網絡層、帳戶系統等基礎架構，和查看友鄰廣播須要的大部分功能，大約 8000 行代碼。

在接下來的八十天中，因爲課業、其餘事情和速度瓶頸，實現過程有所減慢。可是，應用的細節功能和界面交互都正在不斷地被實現和優化。代碼量達到了 14000 行，同時爲此應用而寫做的多個開源庫的數千行代碼並無被計入。

目前實現了友鄰廣播的查看、迴應、刪除等操做，提醒的查看，以及相關的設置條目。剩下的工做也正在繼續進行中。

實現架構

數據層面

應用除了對少數內容進行緩存，其餘內容均直接從網絡獲取。

• 基於 Android 帳戶系統提供用戶帳戶和身份認證。
• 使用 Volley 及部分自定義加強處理網絡請求。
• 使用 Gson 自動填充數據模型。
• 使用 Glide 加載圖片。
• 使用 DiskLRUCache 及自定義加強對首頁數據進行緩存。
• 使用 EventBus 同步不一樣頁面間對象狀態。

界面層面

使用 Support Library 中的 AppCompat、Design、CardView、RecyclerView 進行 Material Design 實現，在必要時引入/本身寫做第三方庫以實現部分界面元素和效果。

使用框架的 Shared Element Transition 實如今 Android 5.0 以上的界面過渡動畫。

界面實現通常分爲 Activity、Fragment、Adapter 三個模塊，分別負責做爲容器，發起請求、展現數據和用戶交互，以及數據/交互綁定。

實現難點

網絡請求

Volley 自己是一個不算十分完備的庫，對於請求參數、重試、認證等方面都須要開發者本身實現。在豆芽中，應用對 Volley 進行了包裝，增長了以上功能，而且盡力作到了通用，爲以後 API 層創建提供了不少方便。

磁盤緩存

DiskLRUCache 是一個只實現了同步讀取寫入的庫，所以豆芽對其進行了包裝，提供了異步讀寫的 API，正確實現，提升了應用的響應速度。

狀態同步

因爲各個界面獨自獲取數據，數據自己與常規的 ContentProvider 機制中不一樣，是去中心化的，便可能遇到狀態不一樣步的問題。

具體地說，即有可能用戶在廣播詳情界面中點贊後，回到主界面列表視圖，發現並未更新狀態。

而豆芽解決方案則是使用 EventBus，在請求完成後通知全部界面刷新同一數據。

界面動畫

Android 5.0 以上提供了 SharedElementTransition，然而默認狀況下共享的界面元素在動畫時卻會被放置在其餘界面元素之上，致使其忽然越過 AppBar 或 StatusBar 的狀況。

經過大量的文檔閱讀、源代碼分析和調試，通過大約一週的時間，最終實現了較爲理想的效果。

屏幕旋轉

Android 在屏幕旋轉時，會銷燬視圖和 Activity 並重建，此時如何保存視圖狀態和已加載的數據、正在進行的網絡請求便是問題。

Android 對部分視圖狀態提供了自動保存恢復，而豆芽對於其餘須要保存的狀態則經過自定義的 onSaveViewState() 和onRestoreViewState()。

對於數據，豆芽經過自定義的一個無界面的 RetainDataFragment 進行數據保留，而且接口十分簡單易用。

同時，因爲網絡請求的異步特性，豆芽經過自定義的一個 RequestFragment 實現了網絡請求在 Activity 重建期間的保留，而且可以在 Activity 重建完成後將請求前的狀態和請求結果回調至新的 Activity。

平板適配

Android 自己的資源系統提供了對不一樣配置的很好支持，經過創建不一樣的資源文件，便可在手機和平板上使用不一樣的界面設定。

此外，因爲採用了 RecyclerView，經過在運行時判斷當前設備配置，能夠動態給界面設置爲 一、二、3 列視圖，充分利用屏幕空間。

啓動速度

Android 默認在冷啓動應用進程至可以調用 Activity.onCreate() 前會加載應用主題中的背景做爲預覽，而默認背景是白色，與應用在上部擁有綠色 AppBar 的效果不相匹配。

爲了生成適應於不一樣屏幕大小、系統版本的圖片，我使用 bash 編寫了一系列腳本，並實現了一個通用的模板化 SVG 格式，詳情見 MaterialColdStart 和 AndroidSVGScripts。

通過自定義窗口背景和其餘優化，應用在手機上已經能夠達到當即啓動的視覺效果。

下載地址：http://www.codesocang.com/gn/xiangmu/29703.html