单个 Activity 控件过多，对手机影响大么？

[QBugHunter]

以小米 8 为例

现在有个 Activity 用于显示设备的某些信息，设备有好几项属性需要显示，所以我在一个 Activity 里面使用 ViewPager 来显示设备信息,用户左右滑动就能查看设备的信息。

但随着需求越来越多，导致 ViewPager 所在的 Activity 控件越来越多，比如第一个页面时设备基本信息，大概有近 20 个信息，每个信息都至少需要一个 TextView 和 TextEdit,有些条目还要 Spinner,多个 RadioButton 等。这样 ViewPager 的一个页面就有 50 多个各种控件

第二个页面是设备连接其他设备的列表，大概 60 多个页面

第三个页面是设备的当前支持的一些协议信息，控件 100+。。。。

然后因为小公司，也没有架构师，所以导致需求不断增加，ViewPager 的页面不断增加，而 ViewPager 所在的 Activity 里的控件非常多，目前各种 TextView,TextEdit,Spinner,Radiobutton,Button 等已经超过 700 个了

我向问下以小米 8 为例，这样一个包含这么多控件的 Activity,对手机的硬件压力大吗？

[SwiftFrank]

建议了解下 Android UI 的渲染相关知识，简单点讲效率跟你单个 Layout(XML)的嵌套层级有关系，推荐使用 ConstrainLayout，页面尽量解耦，方便维护和测试。另外建议看看 Jetpack Compose 的 Navigation 组件，应用单 Activity 的设计。

[ssynhtn]

太长的页面可以换成 recyclerview

[QBugHunter]

@ssynhtn
每个页面的显示设备某个方面的信息，每个页面之间的信息没有太多的关联以及共同点，用 recyclerview 这种滚动页面用户体验不太好

[QBugHunter]

@SwiftFrank
ViewPager 的每个页面嵌套非常简单，每个页面都是诺干行，每行一个都是 TextView+TextEdit/RadioButton/Spinner 等

[QBugHunter]

@SwiftFrank
每个页面布局文件就 2-3 层嵌套，就是控件的数目比较大。。。

[coolesting]

viewpager 里面放的是 fragment，每次翻页都 replace 掉，不会有太大的性能消耗。

如果你数据是一直加载却一直用 add 的方式来添加内容，那估计肯定消耗内存的。

[KNOX]

考虑下 ViewPager2? 因为是基于 RecyclerView 实现的，可以利用复用来减轻实时渲染压力，而且不应该只看一个设备。

[NexTooo]

@QBugHunter #3 纯好奇，单个页面如果要全塞下几十个 View 显示信息的话，那字体应该不能大到哪儿去，这种情况下用户体验好么……

[QBugHunter]

@NexTooo
没有，比如设备状态，需要 TextView+2 个 RadioButton(开和关）+RadioGroup,总计 4 个控件
然后一个设备信息页面，有十几条这样的信息，一个屏幕可以显示 10 条+，用一个 ScrollView 滚动最多半个屏幕就可以显示全部信息了，对于用户来说不算糟糕，但这样一个页面十几条信息，每条 3-5 个控件，总计就 40+了

一个页面向下滚动最长的都没有超过 1 个屏幕，但那个页面控件 100+。。。

然后这个 ViewPager 有 6 个 view,现在还要加。。。。。

因为设计一改再改，所以 ViewPager 所在的 Activity 的控件数量就非常多了（加上刚提的需求，可能会超过 800 ）

[mcluyu]

不是 Android 开发，有类似性能调试工具的直接看下渲染，滑动时性能消耗什么样？总的来说你这些东西看起来都不如随便拉出个游戏消耗的 1/10 多。。

[Arthur5]

@QBugHunter 一屏就 40 个控件还好吧。不显示的控件又不会绘制到屏幕上，上下滑动的页面用 RecyclerView 复用，左右滑动的 ViewPager 默认只保留当前和左一右一的 3 个页面。

[StrorageBox]

看你怎么写的了，如果 google 建议写法，正确添加的 fragment，没有任何问题。
不过看你所说“一个页面向下滚动最长的都没有超过 1 个屏幕，但那个页面控件 100+。。”，就知道不容乐观了，会有问题的，建议先学习一下 Android 绘制相关知识还有 viewpager1 的机制及 Android 界面的内存使用这三方面知识，然后再着手进行优化。

[QBugHunter]

@Arthur5
一个页面 40-100 个控件，然后这个 ViewPage 目前 6 个页面，现在还要再加 3 个。。。。

[NexTooo]

@QBugHunter 我是觉得你可能需要先确定目前的绘制性能消耗如何，有必要了再优化吧，比如极限开到 9 个界面之后的情况。因为感觉如你这么说，要么不动，动起来是个蛮大的工程了。但我感觉若是基本的绘制优化做到位，应该不会有太大的问题，毕竟都是很简单的 View 而不是一些带复杂动画、大内存控件。
你可以看看绘制层级、View 嵌套层级这两块的优化模式，以及 ViewPager1 的机制进一步优化 Fragment 的回收与重建。细节的话我不清楚具体的情况就想不到别的，能想到的就是多个格式不同的文本可以通过富文本拼接的方式合并成一个 TextView

[lwlizhe]

我感觉控件数量跟渲染没啥关系吧

如果卡的话应该是控件本身的问题，或者层级结构什么的，或者说一个控件里面有个 xml 需要解析这种，总之应该是 xml 的锅；
要是直接 textView 那帮没啥 xml 内容的东西应该不影响渲染吧；无非就是 canvas 本身的操作，这块应该没啥问题吧；

我觉的现在你们这更大的问题反而是维护成本问题……假如来个人接手代码，会不会看一眼直接爆炸~

[QBugHunter]

@lwlizhe
这是我接手别人的代码。。。。。

[QBugHunter]

@lwlizhe
想换成碎片，但项目太赶了，我还有别的事情要处理，实在没时间把这个 ViewPager 里的 View 全部换成碎片了，所以只能暂时再加几个 View

[pekki]

屏幕总共就那点大，怎么可能放下几十个控件，详细了解一下 android 屏幕绘制的机制，只不过是不断的重复绘制罢了，性能上影响不大，你看视频每秒都在重绘几十次也不卡啊。

[lwlizhe]

@QBugHunter 略表同情……感觉除了这块，还有其他地方的坑在等着你……这应该是个大坑项目~

[hongch]

如果几十个控件 tv 、et 都会影响到性能的话，你让那些做游戏的怎么办