Stateless与Stateful Widget性能对比及转换后的性能问题咨询

• 实例化开销：StatelessWidget的构造和渲染流程更短，不需要维护可变状态对象，初始化时仅需调用自身build方法即可，同等配置下首次实例化的耗时比StatefulWidget低10%~20%左右，列表批量渲染时差异会被放大。
• 重绘逻辑差异：StatelessWidget仅在父组件重绘、或者入参变化时才会触发重绘，自身没有主动触发重绘的能力；而StatefulWidget绑定了State对象，可通过setState()主动触发重绘，额外增加了状态监听、diff校验的逻辑开销。
• 内存占用：StatefulWidget会长期持有关联的State对象，即使组件暂时退出渲染树也会等待缓存回收周期，同等场景下内存占用比StatelessWidget高5%~15%，如果State对象中持有大量资源（图片、大数组）差异会更明显。
• 生命周期开销：StatefulWidget有完整的生命周期回调（initState、didUpdateWidget、dispose等），框架需要额外维护生命周期的分发逻辑，StatelessWidget只有构造和build两个核心流程，生命周期管理成本几乎为0。

转换后产生的变化 #

• 组件会额外生成关联的State子类对象，原有build方法的逻辑会迁移到State类的build方法中
• 新增完整的生命周期回调能力，可在State的各个生命周期节点插入自定义逻辑
• 新增主动触发重绘的能力，调用setState()即可基于当前状态刷新组件UI
• 组件的状态会在树重建时默认保留（比如页面旋转、父组件重绘时，默认不会丢失State中存储的变量）

性能相关影响 #

正常场景下的转换不会引发显著的性能问题，只有以下特殊场景需要注意：

• 如果转换后的StatefulWidget没有主动调用setState()的需求，也没有用到任何生命周期回调，相当于平白增加了State对象的维护开销，批量渲染时（比如长列表）会出现可感知的性能下降
• 如果State类中没有做好资源释放逻辑，比如在initState创建的控制器没有在dispose中销毁，会引发内存泄漏，长期运行下会导致应用卡顿
• 如果频繁无节制调用setState()刷新整个组件，没有使用局部刷新方案，会带来不必要的build开销，性能反而不如StatelessWidget

内容的提问来源于stack exchange，提问作者Hamed Rezaee