Android优雅的构建debug依赖

        这两天公司产品还处在紧锣密鼓的测试阶段，频繁发版，每次都要在公司企业微信中吼下，让测试人员去下新包。内测版本目前是放在蒲公英上，原意是方便下载的。可随着发版的次数变多，很容易就出现，搞不清楚到底用的是不是新版本，而且每次都要去网站上下载安装，很是麻烦。

        自动更新的需求，便顺理成章的孕育而生。

        初始想法，利用App内部已经做好的自动更新去实现。但很快便被抛弃，一是目前自动更新的逻辑是根据版本号来的，不可能每次发个测试包，还去自增版本号，这样数据收集平台上很快就会有多个版本的信息了，不利于控制。二来还需要去后台更改最新的版本号。繁琐没有意义。

        除了版本号，还能根据什么来做版本判断呢。本地写值，每次发版自增，根据这个值的大小来判断是否需要更新版本，但也需要服务端配合。幸运的是，蒲公英上已经做过这件事了。每次发版，相同applicationID都会自增build版本，而且已经提供了相关的版本更新sdk。奇怪的是，在最新的版本中，蒲公英平台改变了这种做法，沿用传统app内部版本号来控制。这里点到为止，再聊下去要偏题了。

        ok，剩下就是实现的事了。直接添加依赖，找个主activity注册方法，完活？

        固然这样写没毛病，但这个需求仅仅是在测试时需要，发版的时候再去注释，测试的时候再去反注释？

        这种情况，可不是大家想见到的。如何优雅的构建debug依赖呢，debug的时候i want you，release的时候who are you。

        Google官方早就给出了答案，利用风味（productFlavors）就可以解决这个问题。通过配置对应的debug风味，在依赖的时候，写上 “风味Implementation”就搞定啦。

        剩下一件事，就是如果如何注册了，利用风味添加了依赖，整了个库进来，如何利用这个库来进行注册呢？这里可以借鉴LeakCanary的做法，通过注册ContentProvider，来实现升级逻辑的注册，本身ContentProvider的初始化机制就在application的onCreate之前，通过在ContentProvider.onCreate中获取Application，并给Application注册registerActivityLifecycleCallbacks，就可以将升级的注册逻辑放到你想放的地方去了~  

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