Android模块化页面跳转Scheme
创新互联专业为企业提供扎囊网站建设、扎囊做网站、扎囊网站设计、扎囊网站制作等企业网站建设、网页设计与制作、扎囊企业网站模板建站服务，十载扎囊做网站经验，不只是建网站，更提供有价值的思路和整体网络服务。
Github
通过注解实现Uri页面跳转
支持参数自动解析
使用场景：
1、应用内服务端下发uri进行页面跳转
2、通知栏点击，携带uri进行页面跳转
3、其他应用通过uri调起进行页面跳转
注：activity的注解格式：group/path
group为各个模块的唯一字符串，不同模块不可重复
接入：
使用姿势：
根build.gradle
module依赖：
使用姿势：
场景1：应用内服务端下发uri进行页面跳转
1、在需要支持uri跳转的Activity增加注解@SchemePath("{随意填，唯一字符串}")
2、跳转事件
注：参数支持
uri支持参数，如" scheme://ModuleA/Activity?data=1time=20200714hasData=true "
Activity的参数增加@SchemeExtra注解，如
场景2：通知栏点击，携带uri进行页面跳转
1、应用首页Activity增加注解@SchemePath("{随意填}")
2、application调用初始化
3、启动页，通知栏点击入口
场景三：其他应用通过uri调起进行页面跳转
1、注册中转activity
平时我们的程序可以在模拟器上安装并运行，是因为在应用程序开发期间，由于是以Debug面试进行编译的，因此ADT根据会自动用默认的密钥和证书来进行签名，而在以发布模式编译时，apk文件就不会得到自动签名，这样就需要进行手工签名。给apk签名可以带来以下好处：1.、应用程序升级：如果你希望用户无缝升级到新的版本，那么你必须用同一个证书进行签名。这是由于只有以同一个证书签名，系统才会允许安装升级的应用程序。如果你采用了不同的证书，那么系统会要求你的应用程序采用不同的包名称，在这种情况下相当于安装了一个全新的应用程序。如果想升级应用程序，签名证书要相同，包名称要相同！2、应用程序模块化：Android系统可以允许同一个证书签名的多个应用程序在一个进程里运行，系统实际把他们作为一个单个的应用程序，此时就可以把我们的应用程序以模块的方式进行部署，而用户可以独立的升级其中的一个模块3、代码或者数据共享：Android提供了基于签名的权限机制，那么一个应用程序就可以为另一个以相同证书签名的应用程序公开自己的功能。以同一个证书对多个应用程序进行签名，利用基于签名的权限检查，你就可以在应用程序间以安全的方式共享代码和数据了。不同的应用程序之间，想共享数据，或者共享代码，那么要让他们运行在同一个进程中，而且要让他们用相同的证书签名。
相信你看过微信关于模块化的分享 《微信Android模块化架构重构实践》 ，也注意到里面提到的pins工程结构。
作者是这样描述的 ------“pins工程能在module之内再次构建完整的多子工程结构，通过project.properties来指定编译依赖关系。通过依赖关系在编译时找到所有的资源和源码路径。”
仔细推敲这句话的意思，应该能知道它实现的基本原理------通过设置sourceSets指定多个java、res等路径.
有关sourceSets的介绍：
但是，有一个问题需要要知道的是，一个module只能指定一个AndroidManifest文件，pins工程中包含了多个AndroidManifest，它是怎么做到的？
研究过 com.android.tools.build:gradle ，会留意到它使用到一个子库 com.android.tools.build:manifest-merger ，官方通过这个库来合并多个AndroidManifest文件，或许pins工程也是用了这方式。
接下来，再它的基础上，我做的一些改动，取了另一个名字叫 MicroModule ，先来看一下工程结构：
与pins工程的结构大致不变，增加了 androidTest 和 test ，以及将 project.properties 替换为 build.gradle 。
基本原理是不变的，与微信pins工程一样配置 sourceSets 。AndroidManifest合并用了 com.android.tools.build:manifest-merger 。
在根项目的build.gradle中添加插件依赖：
在模块的build.gradle中引用插件并配置 MicroModule：
MicroModule中的build.gradle:
为了使用上的更加方便，专门写了Android Studio的插件，能快速的创建一个MicroMoudle.
插件安装步骤 :
插件详解 :
插件项目地址 :
MicroModule已经上传至Github，欢迎star交流。
Android模块化设计方案系列文章：
1、 Android模块化设计方案模型图
2、 Android模块化设计方案之接口API化
3、 Android模块化设计方案之使用代理模式解耦
本篇是Android模块化设计方案的第三篇，也是对 第一篇 中ThridLibs Proxy模块进行说明。
很多人觉得对那些优秀的第三方依赖库再次封装是一件多余的事情，因为这些库可能出自大神/大厂，或有非常高的star并且使用起来十分稳定，可以在项目中直接拿来使用。当然每个开发者都有自己的态度，我也只是根据以往的经验，表达一下自己的看法。
作为从了解四大组件就不愁找不到工作的互联网大时代中一路走来的Android老鸟，经历了网路请求框架从HttpConnection到Volley再到OkHttp，也经历了图片加载框架从UniversalImageLoader到Picasso再到Gilde，技术的迭代随时都会发生。让项目架构具有良好的扩展性是在设计之初就需要考虑的东西。
那么接下来我用一个简单的demo来演示一下如何使用代理模式对第三方框架进行解耦。
现在我们有一个名为 thirdlib 的模块，为我们提供图片加载功能。
第一步：我们创建了一个新的模块 thridlibproxy ，并且该模块依赖于 thirdlib ，我们在该模块中创建包私有的接口ImageLoaderInterface，这个接口中把thirdlib模块中提供的功能抽象为接口：
第二步：创建包私有的接口的实现类ImageLoaderOneImpl，类中图片加载的业务逻辑是通过调用 thirdlib 中的ImageLoader类实现的：
第三步：我们提供一个供外部调用的ImageLoaderOneImpl接口代理类ImageLoaderProxy：
最后我们就可以通过ImageLoaderProxy中提供的loadImage方法进行图片的加载了。
看到这里有些盆友就会问了，在第二步的时候，我们就完成了 thirdlib 的封装工作，为什么还要有第三步？还有我写一个单例类直接对 thirdlib 进行封装不就行了，为什么还要抽象出接口？
原因很简单，为的就是尽可能的满足软件设计七大原则中的第一个： 开闭原则 。
一个好的软件设计，需要对拓展开放，对修改关闭。我们在设计之初就要想到，在更换图片加载框架之后如何最大程度上满足开闭原则。
如果直接对 thirdlib 进行封装，是面向类的开发而不是面向接口。如果此时更换图片加载类库，那必然会对封装出来的类进行大量的修改，把原来的实现替换为新的实现。
使用代理模式的好处就是，我新创建一个被代理的类ImageLoaderTwoImpl：
然后只需要对第三步中的被代理类进行替换就行了。
在想要达到相同效果的时候，最大程度的满足了开闭原则。
我们业务层模块也和第三方库实现了完全的解耦，我不需要知道 thridlibproxy 是如何帮我完成图片加载工作的，但是只要调用它提供的方法就完事儿的，这也符合软件设计七大原则中的： 最少知道原则 。
关于为何以及怎么通过代理调用第三方依赖库，到这里就介绍完毕了，赶快动手试试吧~
我只想说： 原则是死的，人是活的????
如果觉得有收获的话，欢迎点赞评论以及关注~
