一款基於Kotlin+MVP+元件化的麻雀App
為什麼叫麻雀
麻雀雖小，五臟俱全。
其實本app並不叫做麻雀，只是本人認為它比較符合麻雀的特點：小而全。
小，即輕量級，一是指app只專注於實現常見app基礎的邏輯業務功能，並沒有在某個功能點或者UI上做更為細節的實現；二是指app使用了簡潔的的Kotlin語言作為實現語言，使用了相對簡單的一種MVP實現方式，使用了一種比較輕量級的元件化方案。
全，當然是相對的，一是指app的後端也是本人開發，這能讓整個業務邏輯更為全面，也能讓感興趣讀者能更為全面的瞭解此app；二是指app涉及了當前技術趨勢下安卓開發的多個技術點，包括kotlin,mvp,元件化,rxjava,retrofit等；三是指本app實際上可以作為一個快速開發框架，這主要得益於元件化的實現，具體怎麼使用，後續會提到。
此app名字不叫麻雀，而是叫做KtDevBox。
倉庫地址：
為什麼要寫這個app
誠然，網上關於Kotlin，MVP，元件化的研究、分享已經有很多，但是多數部落格僅僅是泛泛而談，程式碼庫沒有提供不說，部落格中的程式碼甚至都有問題，有些更是抄來抄去。雖然有些好資源的確有挺好的借鑑意義，比如KotlinMvp、Reading等【本文僅著眼於專案級別實現，一些好的library並不在此討論中】，但以下幾點還是讓我覺得有些不足：
- 這些專案的介面，基本都是爬來的，大多數都是get方式實現，很難形成比較完整的一個功能邏輯，也很難從更全的角度去來展示某些技術點的實現；
- Kotlin的使用，Java的味道較重，特別是網路請求的封裝部分；
- 元件化幾乎沒有涉及，專案是個app，並不能方便的轉為另一專案的實現框架；
- 文件等介紹略少
KtDevBox當然也存在的一些不足，但該專案的初衷，也僅做學習交流之用，以期對該方面技術的發展，起到一點點幫助。
為什麼用Kotlin
僅說自己體會，至少有這幾個原因吧：
- 語言切換，對老手真不是問題，況且kotlin與java的相容性很好，所以學習成本不應作為不使用kotlin的理由；
- 真正擺脫了控制元件從佈局到使用的查詢問題，簡潔明瞭；
- 函式地位的提升，帶來的程式設計思想的改變，對開發者開發思維是有提升的，當然，程式碼的靈活、更好的擴充套件是可視的效果；
- 閉包、擴充套件函式、命名引數等語法糖帶來的諸多便利。
為什麼用MVP
有關MVP的討論真是太多了，不過正如本人之前的部落格提到，MVX不管怎麼叫，核心在於分層，至於是C、P或是VM，要看專案自身情況來，甚至可以在同一專案中出現。本專案使用的是MVP的一種簡化些的實現方式，至於好不好用，仁者見仁，這裡只談使用，不談優劣，手動滑稽。再簡略叨叨下MVP的發展吧，以表原因。
- MVC中C重，於是功能轉移，出現來了xxModel、xxLogic黨，主要分擔資料獲取的職責；
- C和xxModel的強依賴、空指標問題和記憶體洩露問題，促進了Presenter的出現，其主要處理業務邏輯，並繫結View的生命週期，面向介面，更為鬆耦合；此時C轉為P。
- 完全面向介面之後，難以避免的V和P介面爆炸，也過於分散，出現了Contract，人工約束，首見於github上谷歌的MVP官方示例。
個人認為，M結構相對很穩定，View並無太大必要通過持有P的介面引用去使用P，再者通過Contract的維護並不能真正降低介面太多造成的注意力分散問題。本專案app的MVP實現較為簡單些，也是一種比較常見的方式，具體可閱讀專案程式碼。
為什麼用元件化
元件化是近兩年才較為突出的一種專案管理實現方案，本人認為其符合基本的分而治之的思想，是同MVX一樣，應該出現在任何一個打算長期維護的專案中的技術方案。其實，不僅在安卓端，在ios端、前端(Vue)、後端(Java、Python)都有元件化的使用。至於什麼是元件化，元件化有什麼好處以及如何實現，我想網上有太多優秀部落格和開源庫提及，這裡就不再贅述。
本app雖然小，但也涉及了元件化，選擇的是一種很輕量級、侵入性小的方案--Appjoint，方案雖然輕量級，但是本人認為：元件化思維，入侵性小、能在最初的時候將業務進行元件化管理是元件化的核心，而這個庫很好的符合了要求。
主要功能點
- 使用者註冊、登入以及資料管理功能；
- 部落格建立、更新、刪除和檢視等功能；
- 部落格的收藏、評論、點贊功能；
- 爬了網易新聞和一些電臺的介面以展示，主要做元件化演示。
專案架構
專案核心架構如圖所示：
專案中的shell只含有MyApplication這一個類檔案，目前app涉及的業務也僅usercenter和media這兩個module，其中usercenter和module並無依賴關係。因此，此專案完全可以作為一個快速開發框架。簡單做法：新建幾個module編寫自身的業務，僅需要被shell依賴，它們並不會受到原業務usercenter和module的影響。然後更改入口Activity之後，就是一個新專案，也不會被打包進apk中。更多元件化的使用可見Appjoint的介紹。
目錄結構
每個元件和一般app的目錄結構基本一致，主要多出了一個package，用來盛放與其它元件通訊用到的類，專案中media元件有例項展示。
router庫的結構如下圖，其中每個元件都單獨擁有一個package，裡面分別盛放元件間通訊的服務介面和共享的資料（元件通訊資料實體類，或者面向json程式設計，手動哈哈，另一個話題）。
主要使用的第三方庫
感謝：
- Retrofit
- RxJava
- glide
- statusbarutil
- eventbus
- appjoint
- logger
- ultraviewpager
- multiple-status-view
- SmartRefreshLayout
- DToast
- MultiWaveHeader
- xedittext
- Targetfun
本專案僅做學習交流之用。
倉庫地址：
喜歡請記得Star一下。
後續還有更為詳細的專案介紹。
最後，可能有些童鞋還對下面這張圖感興趣。不過，本文只談技術，不談“風月”，微笑。