前几年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.沉浸式状态栏的处理，相对也较繁琐。
…
你以为只有这几个坑吗？还有的，比如APP从后台切换前台，Fragment白屏；EditText输入框windowSoftInputMode的坑；切换Fragment输入法不消失等等，多着呢，列举不完的。
那为啥坑这么多，还有人采用这种架构呢？
也许他们认为，Fragment是轻量级的Activity，能带来性能上的提升，界面切换丝滑般流畅。
关于“丝滑般流畅”，作为一个普通用户来说，真的感受不出来呢，跟别人家用Activity的APP，没啥特别的呀。真的。玄学？
关于性能。其实用户打开界面的层级也不深的，一般2-4个吧。用Fragment在内存上是省了几K还是几M呀？
所以鄙人觉得，用这种架构，得不偿失。人家j神也许只是站在哲学或者学术的角度上发表的见解，各位别误解呢。在实际商业项目开发中，大家仍需多斟酌是否真的要去这样做。当然了，采用哪种架构无对错之分，适合就好。觉得喜欢，就采用吧。
最后，建议大家爱惜时间呢，韶华易逝。^ _ ^