android 开发用 “单 activity 多 fragment” 还是 “多 activity 多 fragment” 还是 “主用 activity”？

看需求吧，我 Android TV 项目开发，一个 activity 一个 fragment，上次别人说这是智障的做法。

你遇到什么坑？知乎就是单 activity 多 fragment

配合使用，具体还是得看需求和情况，有时候单个 Activity+多 Fragment 组合，有时候需要多 Activity，怎么方便怎么用，没有特别的规定
Fragment 一路上来很多坑的，内存泄露，内部状态异常，现在好多了，坑 google 填得差不多了，不过做 TV 开发还是要谨慎使用，Fragment 在不同系统版本上如果集成 gridView 焦点搜索和绘制表现不一致，具体记不太清楚了，应该是 4.4 版本前后差异

前两天某大神不是说一个应用只用一个 activity ？

@YellowLittleDog 一个 activity 配一个 fragment 吗？这样感觉怪怪的，嵌套的 fragment 是不是要用来搞什么大事情。
看需求该怎么看呢，我现在都是无脑流单 activity，确实太死板了。

@KNOX 就是摸索过程中常见的坑，用 fragment 显示布局时各种 null，回退呀和回退栈管理。
以前以为这模式是万金油的套路，现在才发现不是这样额。

@GuLuDaDuiZhang 如果是复杂的项目，大的模块用单独的 Activity+Fragment 组合来做，简单关联性不强的模块就不要用单独的 Activity 了，毕竟 Activity 太重，写起来也麻烦，还得去 manifest 配置
别人的应用只能参考，知乎的 app 可以单 Activity 不代表你的就可以，具体看自己的应用设计

你要是新入手就直接 activity 吧。。。
activity 生命周期已经够负责了，fragment 更复杂。
最复杂的是单 activity 配合很多 fragment

@nicevar 谢谢解答，关于需求和情况，能告诉我一些简单的例子吗。实习经验匮乏加上转行缺少编程思维，不知该怎么分析需求。如果能举例分析一下特定情况下哪种模式效率高以及为什么就最好啦。

@youngxhui emm.意思是单 activity 靠不住吗。

@nicevar 码完字回你第一条回复，才看到你第二条回复，尴尬。
这里简单关联性不强的模块，不用单独的 activity 是什么意思呀。

@vjnjc 看来我一开始就选了一条长征之路啊。循环懵逼

如果一个模块超重，那么就直接放 Activity 里面。如果一个模块今天放这明天挪那，你搞不清产品的想法，那么放进一个 fragment 里面。

fragment 的劣势在于，没有 context，有一个 attach 到 Activity 的过程，生命周期依附于 Activity 的周期。此外，接收 intent，接收 Activity 返回，设置 title、option menu 等等都麻烦一点。

我一般写一个专门的 Activity 用于装载任何一个 fragment，功能覆盖上面谈及的劣势。

@hyyou2010 我司也这样

能用就行 就多个 Activity，因为简单，相当来说 fragment，各自处理各自的 Activity

@GuLuDaDuiZhang 主要看需求，比如你需要 fragment 复用的话就只能 fragment 了，不然要写很多重复的 activity。。

多 Activity，多 Fragment。

项目上其实不考虑那么多的，更多是从业务角度去看，如果一个页面中有某些业务不仅从 UI 上互不耦合，而且从逻辑上也不耦合，那就拆分开两个 Fragment，举个例子，比如直播的页面，一般下边的推拉流是一个单独的业务，上边的弹幕、礼物等又是一个单独的业务，那就拆分成两个 Fragment 好了，如果所有代码都放到一个 Activity 中，那代码就太多了。但是比如只是一个文本展示的页面，那就没必要用 Fragment，直接放到 Activity 里就好。

拆分的目的是使逻辑清晰、方便维护、提炼重复逻辑等。不要太局于书本，非要把两种情况对立化，在合适的场景下用更优的方式就好。

个人偏好和习惯，以及项目需求啊。
Fragment 的 Lifecycle 的确复杂化了问题，但使用 ViewPager，PreferenceFragment 时也算方便。
完全不用 Fragment 也可以做到，我也见过单个 Activity，仅通过 View 实现 Master Detail Flow 的例子。
个人喜欢把逻辑上一块的东西放在一个 Activity 中，使用 Fragment 目的明确，代价比较小时才会用。

我现在在写的项目使用一个 Activity+多个 Fragment。确实不少坑，Fragment 不好用，兼容包也很讨厌，但是觉得这样做还是更灵活的。生命周期的管理相对会简单一些，全局通知也简单一些，在任意一个 Fragment 里面 getActivity 得到的是一个全局的 Activity，感觉更方便了。

emmmm 你可以参考这个 https://juejin.im/post/5a2faecd6fb9a045263b8fb4

Fragment 翻译是碎片，这意思还不明白？

简单的不需要移动来移动去的单 activity 就可以了，
activity+fragment 灵活点，不过坑也多点。
看需求用

我 单个 Activity 多个 Fragment

很赞同啊，碎片这个命名就可以解释清除谷歌的意图了，何必拧着来呢

一个 Activity 一个 View，view 自管理，能放任何容器，例如：activity，dialog，fragment。

mark，我做过一个 Android 客户端，用的多个 Activity + 多个 Fragment，然后后面改成了一个 Activity + 多个 Fragment 的模式，感觉 Fragment 可以重用也挺棒的。

看适配需求

至于采用哪种好暂时说不上，但是在使用 fragment 下面几点需要注意：
1. 控制好页面的可见和不可见状态的判断，因为项目里面可能会用到页面是否可见来做一些逻辑处理；前面的弄懂了之后，记得弄一种统一处理的机制: 如果 fragment 如果嵌套 frament 情况下，如何判断子页面是否可见的机制也要弄好统一处理。
ps: fragment 里面判断可见不可见，可以通过 isHidden()&getUserVisibleHint()来判断，他们之间的区别你一定要搞清楚。
2. 多个页面切换用 fragment 去实现，你是到底用 viewpager 呢，还是直接用放到一个 layout 里面，切换效果通过自己动画去实现，直接去 show()或者 hide()这个最好统一处理，不然有些时候可能会搞死你。


暂时就想到这么多。

都可以的，只是 fragment 坑多要注意

Jake Wharton 建议一个应用只使用一个 Activity

我们公司开发了 3-4 个产品了
你说的这几种方式我们都用过了 而且都很成熟的 运营上线了，没有出什么问题
但是回过头看 最累的一次开发 就是单 Activity 多 Fragment 那次 队友集体表示 再也不碰了