见鬼，我正要说你在耍我们呢——我刚才不停翻动时间转盘好久，正要放弃时终于翻到尽头。至少翻了50次，说不定更多。这清单真是够长的。
我彻底被震撼了。
这家伙直到任务完成才停手。好样的
就等着看这条评论呢
这家伙在转
早该把陀螺做成豆子形状，那样我们早就转到天荒地老了
说实话我敢打赌是个女生
r/nocontext
大家都在讨论为什么不做成无限循环，但我更不明白的是：为什么不干脆做成1-12的单一列表？
因为人们想从12滚动到1啊
不滑就错过啦
兄弟你滑动技术也太弱了吧，我25下就能从列表顶滑到底部哈哈
她就是这么说的！
要滑多少次才能戳到太妃糖棒的中心？
一、二、三——！
嘎吱！
每次打开都会重置吗？或者如果每天醒来都晚一小时，但用同个闹钟且前一天就设置好，最终会触发终点吗？
是什么促使你探究这个问题的？
发现圣诞老人不存在。必须知道还有什么
试了下。紧张自己中了个精妙玩笑。看到结尾。嘿，挺酷。
结尾停在4号真让我抓狂。大概只是列表长度限制。我猜应该是28。
为什么分钟数止步在39？
因为七吃了九？？
因为3和9都能被3整除
我的在16点，我用24小时制。
这简直是面试必挂的典型案例，却莫名被应用在全世界最流行的设备上。
笑死就是这个。这种设计连HackerRank测试都过不了。
为什么？时间就是金钱。如果通过长列表实现只需5分钟，而与UI组件和逻辑搏斗要耗费数小时，那当然该选前者。
若正确实现这个功能需要数小时，就不该在苹果工作。
这不是正确做法。
我们并不了解具体UI和库的细节。很可能存在某些特殊限制导致该功能难以正确实现，因此采用5分钟就能完成的列表方案才是正解。
不过他的观点确实成立
他的观点在实践中彻底崩溃了
实现无限滚动功能如此基础，YouTube上随处可见相关教程。虽然我不了解苹果的代码库，但他们的代码组织方式可能让这个功能莫名变得复杂，但本不该如此。一旦代码审查中出现这个问题，就该讨论重构代码了。
这个闹钟界面老掉牙了，直到这篇帖子出现之前，绝大多数人都不知道它原本是这副模样。苹果根本没必要费心审查或重构它，纯属浪费时间。
底层代码很可能早已被绕过修改。
更别提他们可能有意为之的潜在原因。说实话，闹钟功能根本不需要无限滚动。(我甚至惊讶他们居然设置了超过24小时的时长。)
关于“UIPickerView – 循环数据”的教程提到“只需创建一个包含足够多重复行数的下拉视图，用户就永远无法滚动到末尾”。
看来苹果也没料到原帖作者会刷到尽头。
https://stackoverflow.com/questions/26063039/uipickerview-loop-the-data
因为若不懂如何实现无限滚动，就无法判断其耗时是否超过长列表方案，更无法权衡两种方案的优劣。
求职者理应掌握多种解决同类问题的方法，正是为了在实际开发时能做出正确决策。
不仅如此，从处理效率和功耗角度看，静态链接列表在便携设备上可能具有关键优势。
如今手机都能流畅运行《侠盗猎车手V》，无限滚动功能完全不在话下。
没错，但2007年发布的iPhone做不到。这可能是他们开发时采用的方案，之后就再未优化过。
对吧？！我确信苹果工程师都是顶尖的软件工程师。若未采用无限滚动，必然有技术层面的考量而非能力不足。
你宁愿漏水的马桶被草草修好花5分钟，还是花几小时彻底修好？
别欺负不懂行的人。
顺便说一句，这个问题的修复非常基础。只要对编程有基本理解的高中生都能轻松解决。
时间就是金钱
而两者终将耗尽
我敢保证，苹果的开发者们此刻正在代码变更日志里翻找，试图找出谁写了这段代码，更重要的是——谁批准了它。耻辱钟必将为此事鸣响。
这简直是Reddit上那些自诩为苹果工程师的家伙们不懂滚动条实现原理的完美例证。
这类科学发现才真正让我热血沸腾
如果苹果在这都偷工减料，还有哪些地方会省钱？
我的iPhone难道只是豆腐渣？/j
刚测试过，分钟计数器也能玩同样操作。最底部的数字是01，奇怪的是最顶部的数字竟是39。有人知道为什么结束值是39而不是00或01吗？写这段时是8:24，所以我觉得当前时间应该无关
39+60=99 或许这就是原因？
10:06测试得到相同数字。
系统将“00”视为首个数字(或更准确地说，内存中的独立数据位)，因此内部以40个独立数字(0-39)为终点。但人类思维通常忽略0(尽管它同样占用内存空间)，故我们认为“39”仅代表39个数据单位，而非计算机程序认定的40个单位。
另外测试过AM/PM表盘，最终显示为PM，供好奇者参考。
最终时间定格在16:39，哈哈
<image>
但这到底是什么意思！肯定是个线索
42
这设计也太粗糙了…正确实现应该挺简单的…每次指针从11跳到12时，就把AM/PM切换到未选项…或者干脆别切换，让用户自己选。
是的，我觉得他们清楚逻辑本该多么简单。这很可能只是因为选择器组件的构建方式，复用现有组件比创建功能不同的全新组件快得多也容易得多。不过我也同意这确实很粗制滥造。
绝对是这样。我们公司有个奇怪的非技术性软件设计师职位，他们让我操控那些无法掌控的组件完成非预期功能的次数简直令人咋舌。
数字风管锥度器
既然大多数人不会进行超过两轮的if循环，他们为何还要增加额外工作量？
即便对苹果我也足够信任，事情绝非表面看起来那么简单。
夏令时可能存在特殊情况：某些日期根本不存在1:30这个时间点。或者当你滚动时间轴超过0:00时，系统会实际切换日期。
作为开发者，我非常想知道背后的原理。
无论是否预先计算时间表，夏令时计算都必须执行
你是说那家不让你复制粘贴，也不允许精确放置图标(非强制重排)的公司？
你真是个探索者
太疯狂了。小时数从1跳到4，分钟数从00跳到39(显然经过大量循环)
我在三星手机试过这个。它永远不会结束(滑了一百次后我就放弃了，哈哈)。
或许在101处
不，我手指差点被屏幕摩擦烧伤。三星版本确实没有终点。
100%的赌徒在即将发大财前都退出了！
我敢肯定他们正确实现了循环机制
我有个破1.5*的考勤提交软件。正反方向各刷了60次还是没尽头。
你抵达了无限的尽头。
更有趣的是那些骂苹果工程师蠢货的人哈哈。耗费数年才发现这个漏洞的事实，恰恰说明这根本不是什么问题。
开发者发现这个特性根本没花几年，我记得2015年文档里就有相关说明
顺便说下，我刚在安卓手机上连续滚动时间选择器好几分钟，根本看不到尽头
但它会在下午4点20分停止吗？！
编辑：不，是下午4:39
“这有什么好稀奇的——搞什么鬼”
我真的很想知道他们为何要这么设计，肯定有充分理由，否则这简直是荒谬的工作——不过说不定根本不是。
有编程背景的人能说说实现循环数字选择有多难吗？
应该不算特别麻烦。虽然没专门编过这种程序，但现在有个简单思路想试试看效果如何哈哈。
他们实现的是一个循环数字列表： [1, 2, 3, …, 12/24] 如此反复。本质上是条在某处终止的长列表。
系统知道显示5时，6、7、8紧随其后，而4、3、2、1位于之前。比如显示11时，12、1、2将接续出现。直到到达列表起始或终点为止。
我想尝试的做法是创建1到12的列表并在此终止，然后动态更新列表。当显示数字6时，列表为1,2,3…12，系统知道7紧随其后。但当显示更大数字时，若列表接近尾声，我会在每次显示倒数第三位数字时，将列表首位数字移至末尾。因此当显示9时，系统会判断列表即将耗尽，自动执行“将1移至末尾”的操作。此时列表结构变为2,3,4…11,12,1。当再次递增时，2将移至末尾，3移至开头。
我从未尝试向他人解释过理论算法，若表达混乱难以理解还请见谅哈哈。但这确实是我对多种实现方案中的一种构想。
Edir：有趣的是两年前我也想实现类似功能却未能成功，当时经验尚浅。这个方案或许正是我需要的解法。
我直接用elm作为“列表”的固定容器，然后追踪哪些元素“在”列表里，哪些“不在”列表里
懒到爆的工程师们
嘿！他们可是付出了整整30%的努力呢
说实话，用长列表实现反而更麻烦/费事，真搞不清这到底是列表还是限制(或者纯粹是bug)
我明白他们这么做的原因，这并非表面看起来那么愚蠢。无论你如何优化无限滚动列表的效率，一个简单的大型列表在渲染速度上永远更快，而流畅的体验才是更理想的选择。
事实证明，这种情况持续多年才被发现，恰恰说明他们的实现方案并非那么愚蠢。
关闭/重新打开应用时列表会重置，即便闹钟已开启
奇怪的是列表从1开始计数，却在4处终止。
这在软件行业被称为“UI”
UI是什么？通常指“低薪印度人”或“无薪实习生”
谁想去苹果上班，就为了告诉他们模运算符的存在？
它也从1开始
我只核对工时，但确实从1开始到4结束。用计算机科学里有趣的数字256减4得252，除以12正好是21。整除得真漂亮。不过我才不会真的数出来呢哈哈
r/softwaregore
正因为无人知晓其运作原理，才证明这始终是个好方案。
这是实现无缝衔接的方法。若使用响应滚动事件的逻辑脚本，不仅会消耗资源，高负载时还可能导致卡顿——而这种方式只需一个无需处理的整数数组，正常使用中无人能触及数组末尾。
咦
兄弟找到了时间尽头
整个该死的时间！
我在iOS 26开发版测试中也遇到同样问题，笑死
不可能吧 😀 搞什么鬼
我的生活从此改变
我打开后显示的是圆形界面，但我在用美国人说的“24小时制”，或许这就是原因？
分钟也是这样。到39就结束了
想象字母+数字用同样的界面设计！我见过这种。🤣
不可能吧
<图片>
天啊居然是真的
但为什么列表以4结束而不是12？同样分钟数以39结束而非59或0
我的从凌晨1点开始到下午4点结束
这种事让人觉得世界是平的
是啊，现在大家都知道了
真奇怪……
哇，你指出这事真让人讨厌哈哈
哦酷，
不知道AM PM是不是也一样？
是的，24小时制下它在16:39结束。
(这是个玩笑，暗示右边只有AM和PM)
完全没听懂
笑死啥意思
分钟也是同样的规则。
时长是256还是随机数？
或许世界将在那时终结？玛雅历法2.0版
本以为是恶搞，结果不是……24小时设置下指针不循环，iOS 26测试版也没修复……该死
这简直令人抓狂
我手机上显示的最后可用时间是下午4:39，真好奇这和什么有关联。
时间终结将在下午4点39分降临
而这些家伙居然被录用了，而不是我…
这家伙真会挑人。
该死，这太恶心了。
没细算，但直觉是256个字符循环1-12，所以末位是4。
聪明工作，而非拼命干。
每次打开都会重置吗？或者如果每天醒来都晚一小时，使用同一个闹钟并提前一天设置的话，最终会达到极限吗？
这肯定和夏令时有关吧。
编程最难的不是缓存，而是本地化日期时间处理
要是史蒂夫还在世，这事肯定会引起重视。
点中间直接输入时间就行 ¯_(ツ)_/¯
我活在谎言里。
唉。24小时制设置毁了我的乐趣。
下午4:39是最后可能赶上的时间
您的邮箱地址不会被公开。 必填项已用 * 标注
评论 *
显示名称 *
网站
邮箱 *
见鬼，我正要说你在耍我们呢——我刚才不停翻动时间转盘好久，正要放弃时终于翻到尽头。至少翻了50次，说不定更多。这清单真是够长的。
我彻底被震撼了。
这家伙直到任务完成才停手。好样的
就等着看这条评论呢
这家伙在转
早该把陀螺做成豆子形状，那样我们早就转到天荒地老了
说实话我敢打赌是个女生
r/nocontext
大家都在讨论为什么不做成无限循环，但我更不明白的是：为什么不干脆做成1-12的单一列表？
因为人们想从12滚动到1啊
不滑就错过啦
兄弟你滑动技术也太弱了吧，我25下就能从列表顶滑到底部哈哈
她就是这么说的！
要滑多少次才能戳到太妃糖棒的中心？
一、二、三——！
嘎吱！
每次打开都会重置吗？或者如果每天醒来都晚一小时，但用同个闹钟且前一天就设置好，最终会触发终点吗？
是什么促使你探究这个问题的？
发现圣诞老人不存在。必须知道还有什么
试了下。紧张自己中了个精妙玩笑。看到结尾。嘿，挺酷。
结尾停在4号真让我抓狂。大概只是列表长度限制。我猜应该是28。
为什么分钟数止步在39？
因为七吃了九？？
因为3和9都能被3整除
我的在16点，我用24小时制。
这简直是面试必挂的典型案例，却莫名被应用在全世界最流行的设备上。
笑死就是这个。这种设计连HackerRank测试都过不了。
为什么？时间就是金钱。如果通过长列表实现只需5分钟，而与UI组件和逻辑搏斗要耗费数小时，那当然该选前者。
若正确实现这个功能需要数小时，就不该在苹果工作。
这不是正确做法。
我们并不了解具体UI和库的细节。很可能存在某些特殊限制导致该功能难以正确实现，因此采用5分钟就能完成的列表方案才是正解。
不过他的观点确实成立
他的观点在实践中彻底崩溃了
实现无限滚动功能如此基础，YouTube上随处可见相关教程。虽然我不了解苹果的代码库，但他们的代码组织方式可能让这个功能莫名变得复杂，但本不该如此。一旦代码审查中出现这个问题，就该讨论重构代码了。
这个闹钟界面老掉牙了，直到这篇帖子出现之前，绝大多数人都不知道它原本是这副模样。苹果根本没必要费心审查或重构它，纯属浪费时间。
底层代码很可能早已被绕过修改。
更别提他们可能有意为之的潜在原因。说实话，闹钟功能根本不需要无限滚动。(我甚至惊讶他们居然设置了超过24小时的时长。)
关于“UIPickerView – 循环数据”的教程提到“只需创建一个包含足够多重复行数的下拉视图，用户就永远无法滚动到末尾”。
看来苹果也没料到原帖作者会刷到尽头。
https://stackoverflow.com/questions/26063039/uipickerview-loop-the-data
因为若不懂如何实现无限滚动，就无法判断其耗时是否超过长列表方案，更无法权衡两种方案的优劣。
求职者理应掌握多种解决同类问题的方法，正是为了在实际开发时能做出正确决策。
不仅如此，从处理效率和功耗角度看，静态链接列表在便携设备上可能具有关键优势。
如今手机都能流畅运行《侠盗猎车手V》，无限滚动功能完全不在话下。
没错，但2007年发布的iPhone做不到。这可能是他们开发时采用的方案，之后就再未优化过。
对吧？！我确信苹果工程师都是顶尖的软件工程师。若未采用无限滚动，必然有技术层面的考量而非能力不足。
你宁愿漏水的马桶被草草修好花5分钟，还是花几小时彻底修好？
别欺负不懂行的人。
顺便说一句，这个问题的修复非常基础。只要对编程有基本理解的高中生都能轻松解决。
而两者终将耗尽
我敢保证，苹果的开发者们此刻正在代码变更日志里翻找，试图找出谁写了这段代码，更重要的是——谁批准了它。耻辱钟必将为此事鸣响。
这简直是Reddit上那些自诩为苹果工程师的家伙们不懂滚动条实现原理的完美例证。
这类科学发现才真正让我热血沸腾
如果苹果在这都偷工减料，还有哪些地方会省钱？
我的iPhone难道只是豆腐渣？/j
刚测试过，分钟计数器也能玩同样操作。最底部的数字是01，奇怪的是最顶部的数字竟是39。有人知道为什么结束值是39而不是00或01吗？写这段时是8:24，所以我觉得当前时间应该无关
39+60=99 或许这就是原因？
10:06测试得到相同数字。
系统将“00”视为首个数字(或更准确地说，内存中的独立数据位)，因此内部以40个独立数字(0-39)为终点。但人类思维通常忽略0(尽管它同样占用内存空间)，故我们认为“39”仅代表39个数据单位，而非计算机程序认定的40个单位。
另外测试过AM/PM表盘，最终显示为PM，供好奇者参考。
最终时间定格在16:39，哈哈
<image>
但这到底是什么意思！肯定是个线索
42
这设计也太粗糙了…正确实现应该挺简单的…每次指针从11跳到12时，就把AM/PM切换到未选项…或者干脆别切换，让用户自己选。
是的，我觉得他们清楚逻辑本该多么简单。这很可能只是因为选择器组件的构建方式，复用现有组件比创建功能不同的全新组件快得多也容易得多。不过我也同意这确实很粗制滥造。
绝对是这样。我们公司有个奇怪的非技术性软件设计师职位，他们让我操控那些无法掌控的组件完成非预期功能的次数简直令人咋舌。
数字风管锥度器
既然大多数人不会进行超过两轮的if循环，他们为何还要增加额外工作量？
即便对苹果我也足够信任，事情绝非表面看起来那么简单。
夏令时可能存在特殊情况：某些日期根本不存在1:30这个时间点。或者当你滚动时间轴超过0:00时，系统会实际切换日期。
作为开发者，我非常想知道背后的原理。
无论是否预先计算时间表，夏令时计算都必须执行
你是说那家不让你复制粘贴，也不允许精确放置图标(非强制重排)的公司？
你真是个探索者
太疯狂了。小时数从1跳到4，分钟数从00跳到39(显然经过大量循环)
我在三星手机试过这个。它永远不会结束(滑了一百次后我就放弃了，哈哈)。
或许在101处
不，我手指差点被屏幕摩擦烧伤。三星版本确实没有终点。
100%的赌徒在即将发大财前都退出了！
我敢肯定他们正确实现了循环机制
我有个破1.5*的考勤提交软件。正反方向各刷了60次还是没尽头。
你抵达了无限的尽头。
更有趣的是那些骂苹果工程师蠢货的人哈哈。耗费数年才发现这个漏洞的事实，恰恰说明这根本不是什么问题。
开发者发现这个特性根本没花几年，我记得2015年文档里就有相关说明
顺便说下，我刚在安卓手机上连续滚动时间选择器好几分钟，根本看不到尽头
但它会在下午4点20分停止吗？！
编辑：不，是下午4:39
“这有什么好稀奇的——搞什么鬼”
我真的很想知道他们为何要这么设计，肯定有充分理由，否则这简直是荒谬的工作——不过说不定根本不是。
有编程背景的人能说说实现循环数字选择有多难吗？
应该不算特别麻烦。虽然没专门编过这种程序，但现在有个简单思路想试试看效果如何哈哈。
他们实现的是一个循环数字列表：
[1, 2, 3, …, 12/24] 如此反复。本质上是条在某处终止的长列表。
系统知道显示5时，6、7、8紧随其后，而4、3、2、1位于之前。比如显示11时，12、1、2将接续出现。直到到达列表起始或终点为止。
我想尝试的做法是创建1到12的列表并在此终止，然后动态更新列表。当显示数字6时，列表为1,2,3…12，系统知道7紧随其后。但当显示更大数字时，若列表接近尾声，我会在每次显示倒数第三位数字时，将列表首位数字移至末尾。因此当显示9时，系统会判断列表即将耗尽，自动执行“将1移至末尾”的操作。此时列表结构变为2,3,4…11,12,1。当再次递增时，2将移至末尾，3移至开头。
我从未尝试向他人解释过理论算法，若表达混乱难以理解还请见谅哈哈。但这确实是我对多种实现方案中的一种构想。
Edir：有趣的是两年前我也想实现类似功能却未能成功，当时经验尚浅。这个方案或许正是我需要的解法。
我直接用elm作为“列表”的固定容器，然后追踪哪些元素“在”列表里，哪些“不在”列表里
懒到爆的工程师们
嘿！他们可是付出了整整30%的努力呢
说实话，用长列表实现反而更麻烦/费事，真搞不清这到底是列表还是限制(或者纯粹是bug)
我明白他们这么做的原因，这并非表面看起来那么愚蠢。无论你如何优化无限滚动列表的效率，一个简单的大型列表在渲染速度上永远更快，而流畅的体验才是更理想的选择。
事实证明，这种情况持续多年才被发现，恰恰说明他们的实现方案并非那么愚蠢。
关闭/重新打开应用时列表会重置，即便闹钟已开启
奇怪的是列表从1开始计数，却在4处终止。
这在软件行业被称为“UI”
UI是什么？通常指“低薪印度人”或“无薪实习生”
谁想去苹果上班，就为了告诉他们模运算符的存在？
它也从1开始
我只核对工时，但确实从1开始到4结束。用计算机科学里有趣的数字256减4得252，除以12正好是21。整除得真漂亮。不过我才不会真的数出来呢哈哈
r/softwaregore
正因为无人知晓其运作原理，才证明这始终是个好方案。
这是实现无缝衔接的方法。若使用响应滚动事件的逻辑脚本，不仅会消耗资源，高负载时还可能导致卡顿——而这种方式只需一个无需处理的整数数组，正常使用中无人能触及数组末尾。
咦
兄弟找到了时间尽头
整个该死的时间！
我在iOS 26开发版测试中也遇到同样问题，笑死
不可能吧 😀 搞什么鬼
我的生活从此改变
我打开后显示的是圆形界面，但我在用美国人说的“24小时制”，或许这就是原因？
分钟也是这样。到39就结束了
想象字母+数字用同样的界面设计！我见过这种。🤣
不可能吧
<图片>
天啊居然是真的
但为什么列表以4结束而不是12？同样分钟数以39结束而非59或0
我的从凌晨1点开始到下午4点结束
这种事让人觉得世界是平的
是啊，现在大家都知道了
真奇怪……
哇，你指出这事真让人讨厌哈哈
哦酷，
不知道AM PM是不是也一样？
是的，24小时制下它在16:39结束。
(这是个玩笑，暗示右边只有AM和PM)
完全没听懂
笑死啥意思
分钟也是同样的规则。
时长是256还是随机数？
或许世界将在那时终结？玛雅历法2.0版
本以为是恶搞，结果不是……24小时设置下指针不循环，iOS 26测试版也没修复……该死
这简直令人抓狂
我手机上显示的最后可用时间是下午4:39，真好奇这和什么有关联。
<image>
时间终结将在下午4点39分降临
而这些家伙居然被录用了，而不是我…
这家伙真会挑人。
该死，这太恶心了。
没细算，但直觉是256个字符循环1-12，所以末位是4。
聪明工作，而非拼命干。
每次打开都会重置吗？或者如果每天醒来都晚一小时，使用同一个闹钟并提前一天设置的话，最终会达到极限吗？
这肯定和夏令时有关吧。
编程最难的不是缓存，而是本地化日期时间处理
要是史蒂夫还在世，这事肯定会引起重视。
点中间直接输入时间就行 ¯_(ツ)_/¯
我活在谎言里。
唉。24小时制设置毁了我的乐趣。
下午4:39是最后可能赶上的时间