关于 Android，用多个 activity，还是单 activity 配合 fragment？

哪个我都不用

我个人倾向在DecorView上add window，把每一个页面抽象成一个window。

好处是不需要处理fragment那一堆暧昧的生命周期和非同步回调导致的崩溃，也不会有多个activity跳转的那么差的性能。而且debug会更简单。因为是window，也都是独立绘制的没那么多重绘。封装好之后的后续开发很简单，我记得工作一年左右的新人俩小时就教懂了，之后也没有过bug。

坏处就是封装起来复杂度有点高，要控制window的栈和自己控制生命周期，自己添加回调。不过都自己搞也不需要依赖那么多系统api，灵活性高控制力强，代价是框架写起来很需要理解Android源码才行。

看了一下上面的答案，只有

答到了点子上。

如果真如多数人所说的，Fragment各个方面完爆Activity，那Google团队为什么不直接淘汰掉Activity，或者封装一个App总Activity，剩下的都用Fragment不就行了吗？

Fragment性能的确比Activity好，但是从性能方面比较Fragment和Activity无意义，因为它们的应用场景不同。

Activity更倾向于一个整体模块容器，而Fragment是其中的子模块。可以理解成一个工厂（App)有N个生产不同产品的产房（Activity），每个厂房（Activity）里面有生产N类子产品的机器（Fragment）。

所以，Activity的存在可以对应用更好的结构化和模块化的划分，让应用有更健壮和清晰的层次，而Fragment可以让将应用的功能细化和具象化。两者没有好坏之分，根据功能划分粒度来选取合适的载体才是正确的架构方式。

--------------

用我之前做的一个App简单举个例子，并不全面，抛砖引玉。

App提供课表、新闻、成绩、电费、地图、图书馆等功能模块，首先根据产品策略，主页提供是三个大入口，分别为课表、学校、我。然后，在各入口中，提供其余功能模块入口，如学校中提供新闻、地图，“我”中提供成绩单、图书馆等功能吗。

那我的设计思路是这样的，提供入口的主页可以设计成一个Activity和三个Fragment，主页的规划如图。

（随手画的，见谅）

接着，在学校页面，提供几个功能模块的入口，拿其中新闻举例。点开后，新闻页面是一个Activity，新闻公告列表、新闻详情分别是这个Activity附属的Fragment。同理，成绩单功能模块是一个Activtity，学期成绩单、总成绩单分别是两个附属的Fragment。

----------------------------update 补充“学校”界面---------------------------------