no

@usVexMownCzar

苹果关于 ArraySlice 的文档（ https://developer.apple.com/documentation/swift/arrayslice ）原话是这么说的“Sharing indices between collections and their subsequences is an important part of the design of Swift’s collection algorithms.”

除了 Array 和 ArraySlice ，甚至 String 和 Substring ，Data 和 Data.SubSequence 都是这样子的。

感觉最直观的好处就是可以在原对象和切片之间需要频繁调整 index 的步骤简化掉这一步骤。

比如 Apple 的示例：

```
let absences = [0, 2, 0, 4, 0, 3, 1, 0]

if let i = absences.firstIndex(where: { $0 > 0 }) { // 1
let absencesAfterFirst = absences[(i + 1)...] // 2
if let j = absencesAfterFirst.firstIndex(where: { $0 > 0 }) { // 3
print("The first day with absences had \(absences[i]).") // 4
print("The second day with absences had \(absences[j]).")
}
}

// Prints "The first day with absences had 2."
// Prints "The second day with absences had 4."
```

这个并不是苹果现在 bug 越来越多的原因。

我还以为是讲技术债之类的，结果居然是吐槽 Swift 的语法。真的是浪费时间。

我就一个人开发啊，虽然收入主要并不靠这些产品，但我自己也觉得我活得不错。

作为给苹果修修补补的第三方开发者之一，我弱弱地觉得，很多时候第三方开发者也是在做东西满足用户需求，最后卖出去。

一个产品吃一辈子听起来是很爽，但是开发者不能指望这个世界不变化。

怎么可能没有影响，没影响这个事情不就白做了，现在正值一堆新机发布的时间，怎么可能不会影响手机销量，之前捧的时候消息能轰炸出一大批路人粉，黑的时候自然也能带出一大批路人黑。

有些时候还是得承认，人就是很容易受影响的。就算是这个论坛一堆自诩信息层面的精英的群体，很多时候总结也都是“谁赢帮谁”。和多数“路人”的选择基本没啥区别。

这个事情其实最终还是要落实到最终小米的成长的结果之上，小米扛住了，活得更好了，这种攻击在投流的人眼中，投入已经低于产出了，才会停止。

所以对于小米，逆风刮得猛，那就好好做产品做服务，实力才是一切的解决之道。

修正 #59

“因为我知道 如果提前打招呼了 她肯定是不同意的，考虑到我妈从来没来过上海，我就自作主张让我妈来了。因为我觉得我做的事情天经地义，不需要经得起他人同意。”

我觉得你其实最紧要的事情不是评价你爸妈或你老婆，你最需要的是自我评价。

“因为我知道 如果提前打招呼了 她肯定是不同意的，考虑到我妈从来没来过上海，我就自作主张让我妈来了。因为我觉得我做的事情天经地义，不需要经得起他人同意。”

我觉得你其实最紧要的事情评价你爸妈或你老婆，你最需要的是自我评价。

你之前所谓的接触只是看过照片的微信好友几个月，然后国庆期间吃了一顿饭，见了几次面，就想彻底定下来。

结果没达到预期的效果，觉得“这世上什么都可以努力，唯独爱情不行。”

总之槽点有点多。

就不说这样子定下来未来几十年的人生伴侣是不是太草率。

1. 我至少没看出来你哪里努力了，开车回老家和回公司，这个你不相亲国庆也是要往返的吧？至于一路上几个小时还是十几个小时，更是你家到单位的距离，感觉也和女方没关系。剩下的就只有吃饭和约会了，感觉能不能击败 20% 相亲想结婚的人都不好说。

2. 你是这么定义爱情的吗？你追求的好像也不是谈恋爱而是结婚吧？

3. “良言一句三冬暖，恶语伤人六月寒。”，我默默打出了一个问号？

苹果这种服务，感觉就不存在那种理想的“运行没问题”的时候。

停是绝对不能停的，有问题只能带病运行想办法直接改。

只要多数用户感觉不到病就行。

@HTravel

1. XP 时代是二十年前了，你能做到单核 U 不卡顿，这话说的要多离谱有多离谱。

2. 你滚动的时候除了运营需要的打点，以及内容的网络数据加载之外，只是一个滚动视图的布局本身就已经有相当程度的消耗了，更不要说每个 App 还有各自类似于消息之类的不是展示给你的服务需要在其他线程持续工作了。还“只要不故意作恶”……

3. 你也没搞清楚液态玻璃的计算量，更不清楚全屏游戏的性能消耗。

为什么能有这么大的底气做这种类比，我真的有点难以理解。就说这么多吧，你要觉得可能就尽管觉得可能。

@HTravel 省电、液态玻璃惊奇效果、流畅不卡顿，构成一个不可能三角，只能选择两个。

页面没啥元素的时候，不卡顿确实也是不卡顿，但是负载一旦上来就不可能不卡了。

iOS 26 就是让卡的这个临界点往下调了，这是不以人主观意志转移而转移的。

@frankkly TF 版本 + tg ，这个组合属于知识盲区。

@CodingIran App 卡不卡，主要看有没有接入液态玻璃，用的多不多了，tg 我看还没接吧。

iOS App 开发者飘过，App 升级到 iOS 26 液态玻璃后，老设备上（ 12 ）不管咋优化就是跑不到 60 帧。

液态玻璃有着客观存在的性能损耗。

@stinkytofux 我对什么设计原则没有那么大感觉，我现在比较想知道有没有可能自己开发什么东西放上面折腾。

所以说，有些时候，钱是真的难赚。

@MacsedProtoss 内存问题在现在 8G 时代不该成为瓶颈，功能设计是给人用的，不是让设备在用户手上养老的。

用户如果愿意花更大的内存更多的资源换更好的体验，厂商就该尽可能满足，语音输入就是这么基础的需求，退一万步，系统输入法就能实现语音输入，为什么不能让第三方键盘用一样的语音输入识别流程。

这件事上显然苹果并没有尽全力，甚至连尽 1/100 的力都没有，在这种情况下，再谈什么 OOM 和实现之类的细节，我感觉意义很低。