android – 使用很多碎片是不好的做法?

我有一个应用程序,有15个不同的部分.我使用一个带有FrameLayout的Activity,我使用NavigationDrawer加载15个不同的Fragment.我还在少数父片段下面有子片段,我加载了滑动Tab布局.

所以,简而言之,我的应用程序中有很多片段.

问题是,如果我在添加到FrameLayout时将片段添加到BackStack,只要我的应用程序存在,片段就永远不会被破坏(只有View被破坏,这是设计的预期行为).更糟糕的是,如果用户继续悬停到不同的片段,BackStack的大小会不断增加,这可能会导致内存问题.

所以,我开始谷歌搜索并在SO中发现了几个线程,其中有一些suggests against using Fragments at all.但如果我想使用自己的Activity设计每个部分,我必须将NavDrawer添加到每个活动(或者至少将这些活动扩展到基本活动),我我不确定是否谨慎.

这留下了一个问题,在一个活动中有很多片段是一个好的设计吗?如果没问题,我应该将碎片添加到BackStack吗?如果我应该,那么内存问题呢?最后,有没有人在不同的活动中尝试过NavigationDrawer?它有效吗?

我为一系列问题道歉.

编辑:根据到目前为止的回复,我想澄清一下,我知道这是一般性问题,可以产生不同的基于意见的回答.所以,我想明确指出,我不是在寻找任何决定性的答案(因为可能没有任何答案),而是我想开展讨论以听取不同的观点.

最佳答案 这是一个非常普遍的问题.

使用Fragments是经过良好测试的Android模式.它们为您提供了一个方便的小型View Controller,具有完全托管的生命周期.那很整齐.

但碎片并不总是适合这项工作的工具.

我的经验法则是:每当我需要管理复杂的View的生命周期,Fragment动画以及每当我需要一个非全屏的Activity时,我就会使用Fragments.

如果你发现自己有很多碎片,那么问问自己你能得到什么abstract or generalise.例如:大多数列表碎片看起来和执行相同,并且每行可能不应该在它自己的碎片中实现.

后躯是恕我直言,一种用户体验工具.它需要以在应用程序的业务逻辑中有意义的方式进行管理.它是一个允许用户自然导航您的应用程序的工具.因此,在堆栈中推送超过4或5个碎片是没有意义的,因为您不应该期望用户记住5个导航决策.如果您发现自己处于大型后台堆叠状态,则可能需要重新考虑您的UX设计.

点赞