正如前面提到的here以及其他一些地方，fragment而不是activities与bottom navigation
bottom navigation.更好
如果不推荐，那么我几乎没有问题，
我将在底部导航中有5个项目，所有项目都将从Web服务检索数据，并且具有大量数据，每个项目都必须进行解析并具有复杂的布局。
现在我的问题是，使用这些类型的片段的活动是否会对性能产生任何影响。
以及为何不建议使用df1:
ID NAME ADDRESS PHONE
1 abc street1 9999
df2:
ID NAME ADDRESS PHONE
2 xyz street2 8888
df_col_priority:
COLUMN PRIORITY_BY_ID
NAME 1
ADDRESS 2
PHONE 2
答案 0 :(得分：3)
如果我在你的位置，我会将视图寻呼机与底部导航组件结合使用。这将管理片段的创建/删除，并应解决您对性能的关注。它还会为用户预加载上一个/下一个屏幕，并且可以在使用之前在这些屏幕上进行网络呼叫。
这是一个非常简单的链接，显示了这一点： http://www.truiton.com/2017/01/android-bottom-navigation-bar-example/
为了解决您的问题，为什么不使用活动，这种小部件和情况正是为什么创建了片段。它们可以很容易地嵌套在一个活动中并在它们之间交换。没有创建活动以嵌套在彼此之内。相反，您必须将底部导航视图作为每个活动的一部分，并管理每个活动的切换。你将失去在它们之间交换的动画。这不仅会产生大量不必要的和重复的代码，而且活动会更加严重，而且会丢失嵌套方面。
这正是片段的意思。我已经在几个类似于你的应用程序，每个屏幕上的网络请求，每个选项卡上相当复杂的布局上遵循了这个范例。这是一个非常标准的方法。希望这有帮助，如果您需要进一步解释，请告诉我。