当使用带有大量元素的 UIPickerViews 时，翻转视图转换变得笨拙
我在 XCode 上使用实用程序应用程序项目模板创建了一个非常简单的应用程序。我的 MainView 有两个 UIPickerView 组件和两个按钮。 FlipSideView 有另一个 UIPickerView。
主视图上的选取器各有 4 段，每段有 8 行。另一面的选择器只有 1 个 8 行段。所有选择器上的所有行都只是文本。
通过这种设置，按下按钮来前后翻转视图会在动画实际开始之前显示明显的延迟，然后动画实际上似乎比应有的速度更快，就像它试图弥补损失的时间一样。
我删除了界面生成器中的选择器并将应用程序加载到手机上，动画现在看起来很自然。我也只尝试了一个选择器（另一面的），事情看起来仍然正常。所以我目前的理论是主视图中涉及的对象数量是原因。问题是我不认为有那么多（4 x 8 x 2 = 64），但我可能完全错了。这几乎是我的第一个应用程序，所以也许我只是做了一些严重错误的事情，或者手机的处理能力比我想象的要有限得多。
我正在考虑使用 pickerView:viewForRow:forComponent:reusingView: 创建选择器视图，看看这是否希望表现更好，但我不确定这是否只是浪费时间。
有什么建议吗？
谢谢 Ruy
P.S.：在 3.1.2 上的 3G 手机上进行测试
I have a very simple app created with the Utility Application project template on XCode. My MainView has two UIPickerView components and two buttons. The FlipSideView has another UIPickerView.
The pickers on the main view each have 4 segments and each segment has 8 rows. The picker on the flip side has just 1 segment with 8 rows. All rows on all pickers are just text.
With just this setup, pressing the button to flip the view back and forth displays a noticeable delay before the animation actually starts, and then the animation actually seems to go faster than what it should, like it's trying to make up for the lost time.
I removed the pickers in interface builder and loaded the app on the phone and the animation now seems natural. I also tried just one picker (the flipside one) and things still seem normal. So my current theory is that the number of objects involved in the main view is the cause. The thing is that I don't think it's that many (4 x 8 x 2 = 64), but I could be completely wrong. This is pretty much my first app so maybe I'm just doing something grossly wrong, or maybe the phone is has a lot more limited processing than I thought.
I am thinking of creating the picker views with pickerView:viewForRow:forComponent:reusingView: to see if this hopefully performs better, but I'm not sure if this is just a waste of time.
Any suggestions?
Thanks
Ruy
P.S.: Testing on a 3G phone on 3.1.2
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
行和组件的数量与选择器视图本身的性能关系不大。选择器视图的工作方式类似于表格，它们实际上没有内存中的组件数和行数。相反，它们会随时交换并重复使用屏幕上显示的相同的少数视图。因此，如果您有 4 个组件，每个组件一次显示 5 行，则即使每个组件中有数百个逻辑行，选取器视图也永远不会容纳超过 20 个视图。
因此，选择器视图数据源中逻辑元素的数量与其视觉性能无关。
我不太确定您在选择器视图和转换中看到了什么，但这很可能是加载和配置选择器视图的自定义代码中某个地方陷入困境的结果。我会设置断点/日志来查看它在过渡期间将时间花在哪里。
The number of rows and components has little to do with the performance of the picker view itself. Picker views work like tables, they don't actually have the number of components and rows in memory. Instead, they swap out and reuse the same handful of views displayed on the screen at any one time. So, if you have 4 components that each display 5 rows at a time, the picker view never holds more than 20 views even if you have hundreds of logical rows in each component.
Therefore, the number of logical elements in the picker view's datasource is irrelevant to its visual performance.
I'm not exactly sure what you are seeing with the picker views and the transition but its most likely a result of bog down somewhere in the your custom code that loads and configure the picker view. I would set breakpoints/logs to see where it is spending its time during the transition.