我的App里头，主要是2种形式的Activity：

• 单Activity
• 单Activity+多Fragment的结构。

这里主要是单Activity+多Fragment结构的解耦。

所谓Fragment解耦，最起码要达到build.gradle配置的module，移除就移除，不会对App的编译产生影响。

若是有声明 import 去除module的类。自然就会报错。这是耦合。

情景：App Module中的HomeActivity 是个多页TabActivity。

先看一段源码

mFragments.add(INDEX_FIRST_PAGE, new FirstPageFragment());
mFragments.add(INDEX_PRODUCT, new RootProductFragment());
mFragments.add(INDEX_ACCOUNT, new AccountFragment());

很显然，这里是直接对这些 Fragment类进行import的

根据组件化设计的思路，我们把 FirstPageFragment、RootProductFragment、AccountFragment分别放到了三个module内。
进行独立开发。

这就涉及到跨模块调用对象。

在App的build.gradle内进行module引用

implementation project(':m_first_page')
implementation project(':m_account')
implementation project(':m_product')

ARouter提供了跨模块获取Fragment对象的操作。
只需要进行声明就可以用ARouter进行反射 获取。

@Route(path = RouterUrl.FRAG_ROOT_PRODUCT)
public class RootProductFragment extends BaseVcTabListFragment {
    .....省略中间代码
}

当然RootProductFragment的部分就改成了

        //#添加Root Product Fragment
        Fragment rootProductFrag = (Fragment) ARouter.getInstance().build(RouterUrl.FRAG_ROOT_PRODUCT).navigation();
        if (rootProductFrag != null) {
            mFragments.add(rootProductFrag);
            mItemData.add(new NavigationItemView.Data(R.drawable.main_home_ic_product,
                    getString(R.string.main_home_title_product), mFragments.get(mFragments.size() - 1)));
        }

自然的import就可以去掉了。

小结

组件化最重要的思想是： 解耦、聚合。

大家都懂。

只是最近几天，总在想玩什么做的不够好。其中的一个原因就是，**差不多的心态**在作祟。