先说下，这个不是框架，只是一种项目约定实现方式，就像 java 后端的流程化思路。
单 Avtivity 多 Fragment 的思路，3 年前我就实践了，说下当时总结的好处和坏处：
好处：
1、清内存后恢复，界面后退的过场动画不会丢失，而且更容易控制切换动画。
2、Fragment 不用注册，打成 jar，直接加载就可以，热加载、热更新是非常简单方便（曾出现过某个 Fragment 不停的 crash，花了 1 小时改好，再推送出去，crash 解决了）。
3、一个界面里玩多个 Fragment，有更强的切换控制和更多更棒的效果实现。
坏处：
1、需要折腾一个 Fragment 管理器，各种相互切换、相互消息传递、层层 Fragment 穿透等。尤其那种多层 Fragment 动态嵌套加载。
2、硬件的问题，再次问候国产几家生产低端机的资本家，多个 Fragment，显示残影、刷新卡顿、响应缓慢等。


总结下：单 Activity 多 Fragment 的方式，可行，但是少量 Activity 超多 Fragment 的方式更棒。

然而，这只是 UI 上的实现约定，还有很多地方需要探索，比如（三年前了解的，现在估计已经变天了） EventBus、RxAndroid，响应式、动态埋点、无 UI 测试等等。以及直接上 webapp （ webapp 的出现，让我彻底觉得 android 开发受到了危险，简单无特别效果的，webapp 就可以了。复杂类似游戏的，直接上 C/C++，android 开发只剩下一个壳子而已）