以下是我這個系列的相關文章，有興趣可以參考一下，可以給個喜歡或者關注我的文章。

[Android]如何做一個崩潰率少于千分之三噶應用app--章節(jié)列表

看到這個標題，可能有人會恥笑，認為這應該很簡單吧。

但是請認真思考一下啦，

你設計的app是否有經(jīng)過萬級的日活，十萬級的日活，千萬級的日活？

你設計的app是代碼量是多少？你能保證你代碼不停迭代，依然保持低崩潰？

你設計的app的有沒有通過云測？

你設計的app的適配性和優(yōu)化性是否已經(jīng)達到業(yè)內領先？

產品的設計和運營是否已經(jīng)達到瓶頸？

如何算崩潰呢？這里崩潰是指app被強制關閉或者app捕獲異常重啟。

就以現(xiàn)在的手機YY為例吧，他們的日活超過百萬，他們的崩潰率是千分之七。

我們現(xiàn)在研發(fā)的app經(jīng)過六個月的迭代，崩潰率卻依然低于千分之三。

如何統(tǒng)計崩潰？一般成熟的app都會有抓log后臺上傳機制，這里就不過多的介紹啦。

下面屬于我的觀點

1.過度的代碼框架設計不是好的設計，以我看來過于臃腫噶設計框架，大大降低了文件噶可讀性（有時，你找一個別人寫的文件都需要找半天這樣效率是多低），文件命名和層級別嵌套太深。

2.需要一定基礎工具類構建，而且需要這些類的擴展性很好。圖片和網(wǎng)絡類型庫等等，還有定義的BaseActivity和BaseFragment。

3.很多大公司都會自己封裝一些框架類，而不是用第三方的開源。這樣的好處很明顯，就是可以減少代碼方法和避免一些不必要的適配，或者是多種庫的優(yōu)勢的集合。但是缺點就是，可能會缺乏維護這樣的框架，而且也不如成熟第三方開源更新得快。

4.是沒可能完全解決耦合的，沒有任何依賴是產生代碼關聯(lián)的，我們要只是降低代碼耦合，所以現(xiàn)在出現(xiàn)了很多代碼注入的框架（例如Dragger2），一些設計模式（MVP，MVVM）。

這里先說明一下，這是個持續(xù)更新的貼子，只是一些經(jīng)驗分享，如果有更（犀）好（利）的經(jīng)（吐）驗（槽）在帖子里回復。

可以給你們看一下現(xiàn)有的工程框架

簡單介紹一下這套框架，不同于其他MVP，MVVM的代碼框架。我們這套框架最主要通過功能分層。

1.base依賴于core和framework兩個module

2.modules里面是有很多功能模塊，都是通過獨立的library，每個library都依賴于基礎的base。

3.client是依賴了modules里面全部的功能library。

4.mi和baidu是屬于多渠道特征加載入編譯里面，也是依賴于base。

可以考慮一下這樣的設計有什么特別的地方？

一個工程有多個modules的好處體現(xiàn)在，做業(yè)務就是功能疊加，倘若需要移除和添加功能模塊，就要最低消耗下降低模塊的耦合。

如果我想添加一個功能模塊只需要在添加一個功能modules的libray，然后再client里添加依賴，client添加一個modules的調用入口和布局入口。（client是所有modules的調用入口，和整體布局，也是通過client來生成app），刪除一個功能module也是同理。而且就算保留這些入口，直接移除modules也是不會出現(xiàn)崩潰的。

可以接入多個渠道的定制功能，每個渠道可以獨立加入不同的模塊（支付，登錄，登錄頁特效等等）。

所有模塊都可以共用core和framework提供的接口。

*2016.11.27更新

架構的示例圖

****2017.3.6****

有些同學是想說崩潰率是怎么計算的，每次發(fā)版后計算 ?崩潰數(shù)/啟動次數(shù)?

然后某直播公司的灰度是千分之三就可以發(fā)版了。

這只是個開端，如果簡友有更好的框架推薦，可以留言地址，謝謝！

我建立了一個關于Android架構學習的群，里面可以進一步進行組件化學習的交流。

群號是316556016，也可以掃碼進群。我在這里期待你們的加入?。?！