前言
距离上次Activity基类的感想已经过去了大半年了，大家感兴趣的话，可参看我当时对于Activity基类整合出现的一个疑问，进而解决的记录，文章地址如下：
基类(BaseActivity)设计开发谈
今天就让我们重拾Activity，来一次畅谈吧。
今天涉及以下内容
- 为啥又提及Activity基类
- Activity牵涉到哪些东西
一. 为啥又提及Activity基类
一个久远的问题，一个已经被大家使烂的玩意——Activity基类。为啥现在又提及这个问题，是作者脑袋灌水了吗？
不，对于为啥现在又开始提及这个问题。是因为我本人在使用自己的Android基础库的时候，发现了一些问题。我的Android基础库第一次发布是2019年，距今已有两年多了，到目前为止发布了一百多个版本，提交次数达到500多次。我构建Android基础库的初衷是帮助快速实现Android开发，当然了，此库页协助我解决了不少问题，不同程度的加快了我项目开发的进度，但是，瑕疵依然有，需要更迭优化的空间还很大。其中对于Actiivty集成的模块，使用十分频繁。使用次数多了，发现问题很大，已经有些违背我当时建库的初衷。使用不是很便利，这种不便利主要体现在：
- 文档说明杂乱无章，不便理解
- 要使用
Activity基类的时候要斟酌选择
这种不便利不是体现在使用中，而是使用前。在使用之前我要知道这个Activity基类是怎么用的，还要根据不同场景，不同特性来选择相应的Activity基类。于是成本产生了。理解是需要花时间的，这就是成本。
当然，这问题的产生，原因就在于我对Activity基类的整合不够到位，由于当时封装过程比较繁琐，以及考虑不够全面，出现了几个问题导致使用不便，一个是说明文档东一个，西一个，比较分散，我使用起来都比较吃力，其他开发者使用的话，估计更郁闷。再就是Activity基类涉及到了几个类，为的是处理不同场景，这对于一个app中只用一个activity基类的设计理念上，已经增加了不少成本，甚至失去了基类该有的样子。
二. Activity牵涉到哪些东西
那么，Activity基类到底涉及到哪些东西呢？是什么导致我的Activity基类不那么清新？
这里，我不得不梳理下我的工具包了。
目前，我的Activity基类涉及到几个应用场景：
- 用于一般的
Activity(不涉及fragment，不涉及网络通讯) - 便于实现
网络通讯的Activity - 便于加载
fragment的Activity - 便于加载有
fragment的Activity进行网络通讯
这里需要解释的是，为了便于实现网络通讯，此Activity基类需要能快速加载mvp模式，由于涉及到加载fragment的问题，则此Activity基类还要具备能快速实现Activity与fagment进行数据交互的问题。
这就是为啥我的Activity基类整合不够满意的原因，虽然这些功能，目前Activity基类们都具备，但是还是比较繁琐，而且是基类们实现的，而不是基类实现的。
那么在接下来的日子，我将对我的Activity基类架构做一个简单的介绍，并开始来优化他们。
ok, 今天就讲到这里了，谢谢大家。
