对Android项目使用单Activity多Fragment架构的一些看法

前几年JakeWharton大神在采访时提出了一个观点：一个 App只需要一个Activity，你可以使用 Fragments，只是别用Fragment的回退栈。

当时在网上引发了一些热议，大神毕竟是大神，拥泵比较多，所以持赞同观点的开发人员占了大多数，他们纷纷提出了正面的见解，甚至还有付诸实践的。

实践出真知。单Activity+多Fragment的架构，坑非常多，有一些问题还是需要解决的：

1.回退栈的管理。比如界面的跳转和回退，界面间的传值等。要做到startActivity、 startActivityForResult那样舒适还是有点难度的。

2.启动模式。Activity天然就有四种启动模式，Fragment回退栈也想要的话，则开发者自己去实现。

3.生命周期的管理。add和pop一个Fragment，onResume、onStop等方法不会调用了，开发者要另想他法，自定义LifeCallback。

4.Dialog和Fragment的交互。Fragment在Activity的布局层级里，即显示在xml中的某个ViewGroup，而Dialog的布局层级在Window。Dialog点击按钮开启一个新界面，你会发现新界面在Dialog底下显示。。。

5.有些路由框架不支持Fragment。想要组件化？？需选别的或者自己写一套路由框架。

6.遇到Intent隐式意图打开APP的某个界面的需求，就“好玩”了。比如点击通知栏打开消息中心页，或者浏览器里H5打开某个原生界面。如果全是Fragment，这种需求实现起来的话，相对于Activity来说，比较繁琐。

7.多屏显示支持的问题。比如设备接有多个屏幕或者设备是折叠屏等，往往需要同时显示多个Activity的。（当前遇不到这种业务场景？1.经历得少；2.以后就未必了吧。。）

…

你以为只有这几个坑吗？还有的，比如APP从后台切换前台，Fragment白屏；EditText输入框windowSoftInputMode的坑；切换Fragment输入法不消失等等，多着呢，列举不完的。

那为啥坑这么多，还有人采用这种架构呢？

也许最主要的原因是，Fragment是轻量级的Activity，能带来性能上的提升，界面切换丝滑般流畅。

关于“丝滑般流畅”，作为一个普通用户来说，真的感受不出来呢，跟别人家用Activity的APP，没啥特别的呀。真的。玄学？

关于性能。其实用户打开界面的层级也不深的，一般2-4个吧。用Fragment在内存上是省了几K还是几M呀？

所以鄙人觉得，用这种架构，得不偿失。人家j神也许只是站在哲学或者学术的角度上发表的见解，各位别误解呢。在实际商业项目开发中，大家仍需多斟酌是否真的要去这样做。多Activity+多Fragment更稳妥些，单Activity有点极端了。。需要费很大功夫去填完坑以享受那丁点好处。当然了，采用哪种架构无对错之分，适合就好。觉得喜欢，就采用吧。

最后，建议大家爱惜时间呢，韶华易逝。^ _ ^