Android 使用单 Activity 多 Fragment 的框架的实现思路

铜球

这种架构用过度了容易把用户赶跑。。。知乎就是这样的

@nicevar

@nicevar 为什么呢

我试过用 fragment，挺灵活的，既能分解复杂 activity，也能实现同 activity 内容切换，fragment 也可在不同 activity 中复用。

至于框架啥的？不知道有啥框架，这个本身就是 ui 框架啊

见 Jake wharton 大神关于此的概述吧 medium 上 看过一篇文章 一个 app 只用一个 activity

就这点需求用不着框架啊.

没发现啥框架。可以自己封装一个 TabActivity.抽取公共方法。我都一般用 android studio 那种 tabllayout 模版

传统的做法不是一个页面一个 Activity，而是一个逻辑一个 Activity。
多 Fragment 越来越流行了吗？好处说不出几个，坏处我倒是能说好几个。lifecycle 更复杂，retain 保存数据坑很多..

我没觉得为了节约 Activity 创建时间而强行单 Activity 多 Fragment 的架构有多好，仅个人看法。

我们目前的做法是多对多的，根据功能不同来划分，并且兼顾手机和平板，在不同的布局有不同的实现。虽然在有些地方由于一些特殊的事件监测使得层级架构有点变得复杂了，但是维护起来还是比较方便的

有个 Fragmentation 框架,可以看看
https://github.com/YoKeyword/Fragmentation/blob/master/README_CN.md

先说下，这个不是框架，只是一种项目约定实现方式，就像 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 开发只剩下一个壳子而已）

我记得有个框架，实现了这个需求的。

Instagram 了解一下，他们的 App 就是单 Activity 架构的。

喔,这么多 Androider

iOS 可以看成是没有 activity 全部 fragment 吧，开发起来还是感觉安卓界面坑多

没听说过「越来越流行」的说法

我看现在的教材好像建议直接单 Activity 多 Fragment 了