未手动重载时UIPickerView的numberOfRowsInComponent为何高频调用？

这是否属于UIPickerView的正常表现？ #

这完全是UIPickerView的正常运行逻辑，不属于异常情况。
UIPickerView采用UIKit通用的数据驱动渲染机制，并不会像你预期的那样，仅在初始化阶段查询一次组件行数、之后只在主动调用重载接口时才触发回调。以下这些场景都会自动触发numberOfRowsInComponent方法的调用：

• 第一次把pickerView添加到视图层级、完成初始布局时
• 父视图更新约束、触发布局周期调整尺寸时
• 滚动到组件边缘触发回弹动画、选中行状态同步时
• 窗口层级变化、界面触发重绘流程时

你测试到的19次调用完全在合理区间：因为pickerView包含2个组件，每一次布局流程触发时都会分别查询两个组件的行数，再叠加首次展示、交互反馈、状态同步带来的额外查询，十几次回调是非常常见的情况，并不存在系统Bug。

频繁调用会影响应用性能吗？ #

如果回调内部的实现逻辑很轻，那完全不会对性能造成负面影响；但如果像你当前的实现一样，在numberOfRowsInComponent回调里直接调用loadMonths()做实时数据加载，就有可能带来明确的性能损耗：

• 该回调是在主线程同步执行的，高频触发的重复加载会造成不必要的CPU开销，严重时会导致界面掉帧、交互卡顿。
• 这类回调的设计定位是「快速返回轻量的数值结果」，系统并不会对它的返回值做长期缓存，所有耗时操作都不应该放在这个方法里执行。

正确的实现方式 #

把数据加载逻辑和数据源回调解耦：在控制器视图加载、或者年份列表确定的阶段，就提前把对应的年份、月份数据计算完成存入类属性，numberOfRowsInComponent回调里仅返回已存在的数组的count值即可，不要在回调内部执行网络请求、批量数据计算、重复加载这类重操作。

补充说明：不仅UIPickerView，同样遵循UIKit数据源协议的UITableView、UICollectionView，其返回行数、返回单元格高度的回调方法，都是被设计为可以高频调用的，这是UIKit框架的通用设计逻辑，并非组件异常。

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