0基礎手把手教你開發探探類社交軟件（Tinder項目產品架構說明文檔）

目錄介紹

1.關於項目App總體架構

1.1項目總體架構

1.1.1 目前項目使用架構

1.1.2 目前常見的架構

1.1.3 MVP架構優勢及缺點

1.2.主要的技術要點

1.2.1 佈局經常使用及技巧技術

1.2.2 複雜頁面展現及數據渲染

1.2.3 自定義控件編寫及使用

1.2.4 數據結構及網絡數據使用

1.2.5 常見業務流程處理

1.2.6 工具自定義封裝使用

1.3 主要開源框架介紹

1.3.1 網絡請求框架

1.3.2 註解框架

1.3.3 圖片加載框架

1.3.4 api 23之後權限申請

1.3.5 事件總線框架

2 .項目中的代碼規範

2.1 關於包名，類名，方法名等命名

2.1.1 包名與分包

2.2.1 日誌統開關，平時測試環境，上線關閉

2.3 資源文件string，color，dimen

3.項目中的總結分析

3.1 總結

4.常見問題思索

4.1 業務代碼避免耦合度太高

4.2 如何解決問題

4.3 儘可能少寫無用代碼

5.參考說明

5.1 參考連接

1.關於項目架構

1.1 該項目App總體架構

1.1.1 目前項目使用的架構

準備使用架構是MVP，Rxjava+Retrofit+OkHttp是網絡請求框架，MVP是由MVC的基礎演化而來，解決了MVC很多的缺點，相對MVC來講MVP提高解耦更好，業務分層清晰等特色，而以往MVC是把activity、fragment做爲的controller和view使用，MVP的model相對於MVC是同樣的，而activity和fragment再也不是controller層，而是純粹的view層，全部相關業務操做所有交由presenter層處理，這樣作到一個相對的分離。

1.1.2 市面常見的架構

目前存在常見架構有MVC，MVP，MVVM等，

1.1.3 MVP架構優勢及缺點

MVP框架由3部分組成：View負責顯示，Presenter負責邏輯處理，Model提供數據。

View:負責繪製UI元素、與用戶進行交互(在Android中體現爲Activity或者fragment)

Model:負責存儲、檢索、操縱數據

Presenter:做爲View與Model交互的中間紐帶，處理與用戶交互的負責邏輯。

View interface:須要View實現的接口，View經過View interface與Presenter進行交互

優勢：(1)MVP相對於MVC來講下降了耦合 爲何真麼說呢？ MVC中咱們把業務數據交織在一塊兒，也就是activity或fragment中，那麼咱們後期須要去修改需求的時候會引起修改難度大改一處而動全身，因此工程量會比較大總結下來就是(下降耦合)，

(2)業務模塊相對來講比較清晰，以往咱們很 多業務交織在一塊兒，因此比較模糊不太容易分辨咱們具體業務，MVP能很容易看出咱們的業務分層，也爲咱們開發後期維護有很大幫助，總結下來就是(模塊劃分清晰)

(3) 不少時候咱們的業務模塊類似，那麼這個時候咱們是否是想到一點就是代碼複用。少寫一部分代碼能夠提升開發效率，然而MVC就解耦性比較差，就大大減小代碼複用，開發的靈活性比較差，總結就是(代碼複用及靈活性高)

這些呢是我的對於MVP的一些觀點固然還有其餘的，這幾點相對來講比較突出因此大家也能夠繼續探索。

缺點：(1)那麼說了這麼多優勢咱們來看看缺點，咱們Persenter和View交互咱們須要經過接口實現，那麼各個業務不一樣會形成接口過多，加上咱們的Model 那麼代碼中會相對比較繁瑣，這樣會使項目體積變大，後期也會有麻煩，總結下來就是(接口多項目體積變大)。

(2) View和Persenter 會頻繁的交互那麼若是咱們的View發生變化時相應Persenter也要作出改變(交互頻繁)

1.2 主要的技術要點

1.2.1 佈局經常使用及技巧技術

佈局中主要的一點就是儘可能的層級嵌套不要過於複雜，由於渲染時一層一層往下渲染因此層級過於複雜的話那麼耗時相對比較長，根據設計圖的佈局選擇相對比較合適的佈局方式，依然可使用android最新的約束佈局實現一個層級佈局，這當中會涉及到約束佈局使用，包括居中，向上，下，左，右，平分佈局等，具體能夠參考連接地址： study.163.com/course/intr…

1.2.2 複雜頁面展現及數據渲染

對於複雜頁面，咱們選擇是自帶控件RecyclerVIew 支持擴展性強，功能強大 ，因此咱們能夠用它的多類型擴展特性完成咱們的複雜佈局，同時一個控件展現渲染也爲後期業務變化修改提供便利性，具體能夠參考連接地址： study.163.com/course/intr…

1.2.3 自定義控件編寫及使用

一般項目中控件不能知足咱們平時開發，那麼這時候咱們須要自定義一些控件來知足咱們開發，自定義相對比較複雜，要求掌握知識比較全面一些，咱們能夠根據本身的需求來定義控件

此次咱們自定義中涉及到事件分發，動畫，自定義流程，事件回調等，具體能夠參考連接地址： study.163.com/course/intr…

1.2.4 數據結構及網絡數據使用

數據是咱們開發中相對比較重要的一個知識點，咱們View須要數據來渲染纔會使咱們的視圖有生命，完成咱們的頁面邏輯及業務，項目中咱們提供了真實企業級的項目接口也封裝了網絡 請求工具，具體能夠參考連接地址： study.163.com/course/intr…

1.2.5 常見業務流程處理

項目的最終目的都是咱們爲了實現咱們的業務，項目中要根據產品提供的文檔來對業務作一些具體的操做，我在項目作了企業級的項目業務處理，雖然不是同一個項目可是萬變不離其中

處理方式無非就是咱們的流程控制及回調處理，具體能夠參考連接地址： study.163.com/course/intr…

1.2.6 工具自定義封裝使用

對於項目中咱們須要用到一些方法，那麼若是不少地方都用到那麼寫一次，這樣會代碼會比較繁瑣， 能夠把這些方法寫成咱們公用類靜態方法以提供給其餘地方調用，好比咱們的時間格式化，獲取手機參數，轉化單位，獲取屏幕寬度，高度，像素密度等，具體能夠參考連接地址： study.163.com/course/intr…

1.3 主要開源框架介紹

1.3.1 網絡請求框架

Retrofit: 底層基於OkHttp 實現，Retrofit 負責請求的數據和請求的結果，使用接口的方式呈現，OkHttp 負責請求的過 程，RxJava 負責異步，各類線程之間的切換

OkHttp: 也是Square 開源的網絡請求庫

RxJava:RxJava 一個在 Java VM 上使 用可觀測的序列來組成異步的、基於事件的程序的庫，總之就是讓異步操做變得很是簡單。

RxJava + Retrofit + okHttp 已成爲當前Android 網絡請求教優的選擇。

1.3.2 註解框架

目前常見的註解框架：

XUtils：xutils是經過反射來實現的，跟Butterknife的是它須要手動實現註解

AndroidAnnotations：該框架的原理跟Butterknife同樣

ButterKnife： 自動生成註解與類屬性，Butterknife目前支持的註解有: View綁定，資源綁定，事件綁定。

1.3.3 圖片加載框架

ImageLoader：異步加載本地及網絡圖片，同時實現緩存

Picasso：不只實現了異步加載圖片，仍是決解了圖片加載的一些問題，錯位，壓縮，自帶二級緩存等

Glide：Glide具備高效 獲取、解碼和展現視頻劇照、圖片、動畫等功能。

1.3.4 api 23之後權限申請

權限管理，直接使用谷歌原生權限框架

1.3.5 事件總線框架

activity，fragment，service等不一樣組件直接通訊一直是個頭疼的問題，那麼咱們使用事件總線來進行通訊

EventBus：EventBus邏輯很是的清晰，代碼之間高度解耦，在進行組件、頁面間通訊的時候，是很好的選擇，

具體使用方法能夠參考地址： github.com/greenrobot/…

2 .項目中的代碼規範

2.1 關於包名，類名，方法名等命名規則

2.1.1 包名與分包規則

包名：com.xxxx.project 例如：com.ousang.tinder 其中xxxx是我們企業名稱，最後是項目名稱

分包以以下圖：

2.2.1 環境統一開關，平時測試環境，上線關閉

在咱們的管理類中設置一個方法控制咱們的環境，平時測試時使用測試環境，上線時更改成上線環境

2.3 資源文件string，color，dimen

(1)對於項目中的字符串咱們統一寫入到清單文件string中以規範化，後期更改只需找到清單文件更改便可

(2)由於設計顏色相對會比較繁多，因此項目中的顏色值咱們統一寫入到清單文件color中以規範化，後期更改只需找到清單文件更改便可

(3)一樣尺寸咱們統一寫入到清單文件dimen中以規範化，後期更改只需找到清單文件更改便可

3.項目中的總結分析

3.1 總結及收穫

(1)項目中存在問題時要多思考問題緣由，由於這樣才能收穫，不要盲目搜索，帶着問題關鍵去尋找。

(2)完結項目後要回頭去看代碼是否能夠更完美，嘗試優化。

(3)和他人分享，每一個人的想法有多是一種收穫

4.常見問題思索

4.1 業務代碼避免耦合度太高

平時開發時儘可能避免項目的耦合度太高，Persenter與View儘可能作到耦合低， 避免往後的維護修改麻煩增長工做量，

4.2 如何解決問題

開發時會遇到不少的問題，那麼咱們能夠藉助搜索引擎的尋找答案，可是你要能看問題的核心，報錯時咱們須要看咱們日誌而後找到問題所在倒推問題發生源，若是是業務出錯時回頭去仔細查看文檔分析，檢查代碼而後調試斷點查處問題，總之就是不要慌，鎮定。

4.3 儘可能少寫無用代碼

咱們佈局，業務代碼，工具，能抽取出來成爲一個公用的時，就抽取，就公用，由於這部分相同代碼實際上沒有意義，到還繁瑣，浪費時間或者均可以放進一個公用的包內。

5.參考說明

5.1 參考連接

Android App的設計架構：MVC,MVP,MVVM與架構經驗談：

www.tianmaying.com/tutorial/An…

淺談 MVP in Android：

blog.csdn.net/lmj62356579…

劉望舒大神，Android架構（一）MVP全解析：

blog.csdn.net/itachi85/ar…