写点什么

写了 3 万行 SwiftUI 生产代码后的经验:凡事皆有利弊

  • 2023-02-27
    北京
  • 本文字数:2881 字

    阅读完需:约 9 分钟

写了3万行SwiftUI生产代码后的经验:凡事皆有利弊

上手SwiftUI才几个小时,我们就爱上它了,甚至立刻就决定放弃跨平台代码库,并在 iOS 上改成完全原生的架构。1 月份上架 AppStore 的 timing.is 这个应用完全是用SwiftUI构建的。它的开发过程历时数月,要不是 SwiftUI 除了优点外还有很多缺点的话,这个时间还可以更短。(补充一下,这个应用开发阶段就上架 TestFlight 了,基于用户反馈的迭代过程也消耗了我们一部分开发时间。)在开发后期,我们甚至重新审视了当初的决策。最后,出于几个原因我们没有放弃它:我们已经走的太远了,整个计划还严重超期,重启的成本是无法接受的。但这不是主要原因——尽管小问题不断,但我们还是很喜欢它。起码过半的时间它很好用,所以这个决策还是正确的。但本文要谈的是剩下的那不到一半的情况。

 

首先声明,本文的主题并不是“SwiftUI准备好投入生产了吗?”因为我的答案很明确,这是肯定的!起码我们的情况是这样。我们的应用还是要满足非常复杂的需求而设计的(日历应用一般很简单,但我们不想做那种没什么用的东西)。换句话说,如果你构建的是没什么负载压力、比较省事的东西,那我打赌它用起来基本上会更舒服。我们最终成功了,但也做出了很多妥协。SwiftUI 本可以——而且真的应该——变得更易用,特别是考虑到它自 2019 年发布以来已经有过三个重大更新了。问题在于我们遇到的问题并不像我们的需求那样复杂,其实都是些基础的东西。

 

免责声明:我们面临的一些问题完全有可能存在我们不知道的解决方案。但总之我们已经查过了,也没找到办法。这里的重点是这些基础的细节本来应该可以正常用下来的。

ScrollView 地狱

 

深吸一口气吧。这是最让我们纠结的控件。日历应用中需要无限滚动功能,在 SwiftUI 里执行这个操作相对简单,但只能平滑向下滚动,因为尝试按需加载项目时向上滚动会导致明显的抖动。我在 StackOverflow 上问过这个问题,浏览量有两千次,很明显没有有效的原生方案。其实我去年在 WWDC 实验室和一位 SwiftUI 工程师说过这个问题,他们的建议是:1)创建一个 LazyVStack,这就要在两个方向上都做一个大得离谱的数据集;2)滚动到 Today 的 onAppear。这个办法很有创意,不幸的是 scrollTo 在 LazyVStack 中表现不可靠。它甚至经常会远离目标,偶尔会稍微偏离目标,很少落到正确的位置。还好我们最后找到了 Marc Palmer 的这篇精彩文章《你的 SwiftUI ScrollView 是否滚动到了错误的位置?》。引用其中一段:

 

最后我把它隔离了。如果 ScrollView 中有 ForEach,并且要滚动到的视图的 ForEach 主体结果包含其他视图,则 scrollTo(id...)不会滚动到有 id 的视图框架。

 

竟然是这样?

 

他的办法能用,但还是不够可靠(我们会用非常繁忙的日历数据做用户体验压力测试)。我们不得不重新设计,接受现实:在 Agenda 视图里,很遗憾目前你无法回到过去。

 

遇到这种情况的时候你有三种选择:战斗、认输或重新评估。我们很顽固,不肯认输。我们的建议是为战斗设定时间限制,不要拖延,确保开发可控。建议大家基于当前的限制重新调整设计,这样用户就不会察觉到出现了什么局限,而且你的解决方案会让他们感觉是有意为之的!我们解决这个问题的办法就是引入了追溯元素。

 

但 SwiftUI 的 ScrollView 还有其他一些痛点,其根源在于它无法优雅地处理冲突手势,也就是说滚动可能会因为干扰手势而中断,反之亦然。例如,我们希望每个日历项都可以点击和长按。这是开箱即用的功能,但 onLongPressGesture 的最短持续时间被框架忽略了,结果打开速度慢得发指,也没有干净的解决方案。还好 Daniel Saidi 最近提出了一个方案:他的 ScrollViewGestureButton 用了一个隐蔽的 ButtonStyle 来搞定了。类似地,我们的 Day 屏幕有一个水平分页器,该分页器由多个相邻的垂直滚动视图组成。为了让滚动和水平滑动同时工作,Ciaran O’Brien 还巧妙地使用了一个 ButtonStyle 来创建人为延迟,因为在 UIScrollView 上没有 UIKit 的 delaysContentTouches 等效项。

 

除了 ScrollView,我们还经常面临性能和状态方面的问题。当然我们的麻烦更有可能是自己造成的,我们严重依赖 Observables。所以说如果你的架构基础没那么牢固的话,中等复杂度的应用很容易遇到问题。视图经常无意义地刷新,在可以无限滚动的日历中这将导致明显的卡顿。你离触发一个 @Published 属性总是一步之遥。对于这个问题,Martin Mitrevski 的《SwiftUI 性能技巧》这篇文章是必读的。Oskar Groth 最近发的一则技巧推文也引起了共鸣。我们的办法是不再默认随意创建 Publisher,而是加了一堆条件:

 

  1. 如果在更改特定属性的值后必须刷新视图,请考虑为其提供一个 @Published 属性 wrapper。

  2. 如果没有其他可能同时更改的属性也需要刷新视图,则继续执行 @Published 分配。

  3. 如果有这样的属性,则寻找是否有更统一的方法来发布更改,比如说一个单独的 Publisher,一旦导致对象属性发生变化的活动完成,其值就会发生变化。或者采用 Martin 当时对 objectWillChange.send()的建议。

 

同样,@EnvironmentObject 很好用,但这种便利本身也带来了麻烦。如果一个视图引用任何内容,请确保它需要响应其中包含的每个 Publisher 的更改。否则,考虑把引用替换成对它完全关联的一个新对象。

 


之前:当我们大量使用 Publisher 时,滚动时有一大堆时间线插入内容

 


之后:时间线上的 Publisher 数量显著减少

 

一般来说,如果你像我之前那几次一样让自己陷入困境,请不要重蹈我的覆辙:就像我一开始天真地设置一堆不必要/非最优选择的 Publisher 一样,我的做法跟正确路径背道而驰,把那些看起来不重要的东西都删掉了。在你移除任何东西之前,请先研究这个属性的轨迹。我有几个移除示例并没有立即产生什么明显的后果,结果一段时间后视图没有响应特定场景中的变化,这时候问题才浮出水面。最后强调一下,请记住 @EnvironmentObject 将触发一个视图更新,即使视图没有引用其任何属性也是如此。一种找出不必要的重绘的廉价方法是将视图的背景颜色设置为 Color.random,这是 Peter Steinberger 给出的巧妙方法

 

TextField 也值得一提。我们遇到的一些新的磨合例子如下所述。

 

  1. 我们想移动入口 UI,打开一个表并立即关注标题 TextField,但是在弹出键盘之前有明显的延迟,所以这个操作取消了。

  2. 我们支持在不失去键盘焦点的情况下键入一个新条目并点击[Next]添加另一个条目。iOS 16 中的一个新错误意味着当你这样做时,键盘会在滑回原位之前就出现关闭动画。当前版本中保留了这个设计,因为我们觉得放弃添加连续项目的能力会比这个 UI 问题更让用户感到不爽。与此同时我们正在寻找解决方法,目前预计要到夏天才能解决问题。

  3. 当你在编辑条目时,我们希望标题字段的光标位置在开头,结果也做不到。

 

虽然有这些问题,但我们还是坚持使用 SwiftUI,对它也抱有敬意。我们经验丰富,不会让一些挫折,哪怕是频繁出现的挫折影响我们对整体体验的判断。考虑到我们的问题都很明确,相信它们最终都会被解决掉,只是具体的时间就没法预测了。与此同时,每当我们遇到障碍时,我们都会好好战斗。

 

timing.is 现已上架 AppStore,由 SwiftUI 打造。可在Twitter网站上关注作者了解更多开发经验。

 

原文链接https://blog.timing.is/swiftui-production-experience-problems-solutions-performance-tips/

 

2023-02-27 19:2710395

评论 1 条评论

发布
用户头像
Reflecting on the valuable insights from this article about SwiftUI production code, it's essential to recognize the significance of choosing the right tools for your software development needs. For businesses considering a robust ERP solution, exploring options like those offered by [ImpactFirst](https://www.impactfirst.co/id/erp/software-erp) can lead to better integration and efficiency. Balancing pros and cons is crucial in both development and enterprise resource planning.
展开
2024-07-25 16:28 · 印尼
回复
没有更多了
发现更多内容

从0到1教你如何使用 p5.js 绘制简单的动画

海拥(haiyong.site)

大前端 动画 28天写作 签约计划第二季 12月日更

双 11 大促会场开发提效解析:前端智能化落地实践

凹凸实验室

机器学习 大前端 智能代码

如期而至-用户购买时间预测(下)

索信达控股

模型 购买预测 购买行为 精准营销

前端性能优化 24 条建议

编程江湖

大前端

Python enumerate():使用计数器简化循环

华为云开发者联盟

Python 变量 计数器 循环 enumerate

恒拓高科WorkPlus助力南兴装备移动数字化升级

WorkPlus

Flutter 自定义 ACEFoldTextView 折叠文本

阿策小和尚

28天写作 0 基础学习 Flutter 内容合集 签约计划第二季 12月日更

前端开发:npm run serve和npm run dev的区别

三掌柜

28天写作 21天挑战 12月日更

安全办公 |企业级IM即时通讯私有云解决方案

WorkPlus

进程崩溃/应用卡死,故障频频怎么办?|HDC2021技术分论坛

HarmonyOS开发者

HarmonyOS

从 0-15 套存储集群,YRCloudFile 助力 AI 训练效率“超线性增长”

焱融科技

人工智能 云计算 分布式 高性能 文件存储

MySQL性能测试之select&update【FunTester框架】

FunTester

MySQL 性能测试 测试框架 FunTester FunTester框架

【干货分享】研效优化实践:AI算法助力深层BUG挖掘

WeTest

Go语言学习查缺补漏ing Day7

恒生LIGHT云社区

golang Go 语言 编程语言‘

Linux运维,Linux系统学习

侠盗安全

Linux linux运维 运维工程师 云计算架构师

科创人·StreamNative翟佳:开源模式价值为王,基础软件的未来在国内社区

科创人

CANN5.0黑科技解密 | 高并发图片视频处理,为出行保驾,为生活添彩!

华为云开发者联盟

高并发 图像预处理 CANN 昇腾 异构计算

Android C++系列:Linux网络(三)协议格式

轻口味

c++ android 28天写作 12月日更

【LeetCode】最短补全词Java题解

Albert

算法 LeetCode 12月日更

全链路数据血缘在满帮的实践

华为云开发者联盟

sql 图数据库 图计算 全链路数据血缘 数据血缘

数据库事务的三个元问题

Zilliz

数据库 数据库设计

这套神奇的个人信息管理系统,带我一步步进入互联网大厂

博文视点Broadview

大厂面试算法题之数组

程序员学长

数据结构 算法 大厂面试

一文读懂 Apache Pulsar

晓双

云原生 Apache Pulsar 消息系统 数据流 Apache Pulsar 社区

DataPipeline与TiDB推出异构数据实时同步解决方案,共筑安全可信基础设施

DataPipeline数见科技

数据库 大数据 中间件 数据融合 数据管理

高并发多方案秒杀架构

MetaThoughts

浅谈服务网关和联邦云

星环科技

联邦云 服务网关

Java 程序员必须掌握的 10 款开源工具

编程江湖

java编程 java开发工具

让工具成为双手的延伸

Zilliz

数据库 书籍推荐 程序 书籍

为啥你写的代码老有大串的if/else?

华为云开发者联盟

代码 if for循环 else

Java开发之环境搭建基础教程

@零度

Java 开发环境搭建

写了3万行SwiftUI生产代码后的经验:凡事皆有利弊_语言 & 开发_Bardi Golriz_InfoQ精选文章