????????這兩天公司產(chǎn)品還處在緊鑼密鼓的測(cè)試階段，頻繁發(fā)版，每次都要在公司企業(yè)微信中吼下，讓測(cè)試人員去下新包。內(nèi)測(cè)版本目前是放在蒲公英上，原意是方便下載的?？呻S著發(fā)版的次數(shù)變多，很容易就出現(xiàn)，搞不清楚到底用的是不是新版本，而且每次都要去網(wǎng)站上下載安裝，很是麻煩。

? ? ? ? 自動(dòng)更新的需求，便順理成章的孕育而生。

? ? ? ? 初始想法，利用App內(nèi)部已經(jīng)做好的自動(dòng)更新去實(shí)現(xiàn)。但很快便被拋棄，一是目前自動(dòng)更新的邏輯是根據(jù)版本號(hào)來的，不可能每次發(fā)個(gè)測(cè)試包，還去自增版本號(hào)，這樣數(shù)據(jù)收集平臺(tái)上很快就會(huì)有多個(gè)版本的信息了，不利于控制。二來還需要去后臺(tái)更改最新的版本號(hào)。繁瑣沒有意義。

? ? ? ? 除了版本號(hào)，還能根據(jù)什么來做版本判斷呢。本地寫值，每次發(fā)版自增，根據(jù)這個(gè)值的大小來判斷是否需要更新版本，但也需要服務(wù)端配合。幸運(yùn)的是，蒲公英上已經(jīng)做過這件事了。每次發(fā)版，相同applicationID都會(huì)自增build版本，而且已經(jīng)提供了相關(guān)的版本更新sdk。奇怪的是，在最新的版本中，蒲公英平臺(tái)改變了這種做法，沿用傳統(tǒng)app內(nèi)部版本號(hào)來控制。這里點(diǎn)到為止，再聊下去要偏題了。

? ? ? ? ok，剩下就是實(shí)現(xiàn)的事了。直接添加依賴，找個(gè)主activity注冊(cè)方法，完活？

? ? ? ? 固然這樣寫沒毛病，但這個(gè)需求僅僅是在測(cè)試時(shí)需要，發(fā)版的時(shí)候再去注釋，測(cè)試的時(shí)候再去反注釋？

????????這種情況，可不是大家想見到的。如何優(yōu)雅的構(gòu)建debug依賴呢，debug的時(shí)候i want you，release的時(shí)候who are you。

????????Google官方早就給出了答案，利用風(fēng)味（productFlavors）就可以解決這個(gè)問題。通過配置對(duì)應(yīng)的debug風(fēng)味，在依賴的時(shí)候，寫上 “風(fēng)味Implementation”就搞定啦。

? ? ? ? 剩下一件事，就是如果如何注冊(cè)了，利用風(fēng)味添加了依賴，整了個(gè)庫進(jìn)來，如何利用這個(gè)庫來進(jìn)行注冊(cè)呢？這里可以借鑒LeakCanary的做法，通過注冊(cè)ContentProvider，來實(shí)現(xiàn)升級(jí)邏輯的注冊(cè)，本身ContentProvider的初始化機(jī)制就在application的onCreate之前，通過在ContentProvider.onCreate中獲取Application，并給Application注冊(cè)registerActivityLifecycleCallbacks，就可以將升級(jí)的注冊(cè)邏輯放到你想放的地方去了~??

? ? ? ? Demo:https://github.com/qinhehu/DebugRely