SwiftUI除Canvas外另一种快速预览方案
当我们用SwiftUI编写界面组件时,Xcode编辑器的Canvas窗是一个非常重要工具,它的地位等同于UIKit时代的Storyboard。还记得曾经使用Storyboard时预览功能失效时,修改界面有多么不便。
如果无法对编写的UI进行实时预览,那么开发工作将变得寸步难行。想象一下,每微调一个颜色或尺寸,就编译、运行到模拟器,再点击进入相应界面去查看目标组件的工作状态,万一还要注入模拟数据,那就更是麻烦。
SwiftUI的Canvas发生错误、预览失效的情况常有发生。无法在编辑器预览,那么只能把思路放到运行模拟器预览了。
从编辑器到模拟器预览,步骤有:
- 编译、运行 【可提高编译速度】
- 进入到对应组件的展示页【可简化】
- 注入模拟数据【可简化】
使用@main注解
xxxApp.swift有 @main
注解,申明了程序的运行入口。
@main
struct YourApp: App {
//...
}
所以,我们大可另外写一个 xxxApp_Preview.swift 文件,只显示要预览的组件。
@main // 当要预览时,打开
struct YourApp_Preivew: App {
//...
}
// @main 并且把原app的@main注释掉
struct YourApp: App {
//...
}
到这里,我们解决问题2.
对于问题1的解决,可以从代码编写方式入手,尽量使得组件轻量、独立,展示所用的数据无需通过网络、数据库查询等耗时。可看文末的建议。
规范PreviewProvider的写法
想象一下,如果我们要预览对应组件时,只需像下述这么调用,是不是方便很多?
@main
struct YourApp_Preivew: App {
var body: some Scene {
WindowGroup {
YourComponent_Previews.Demo()
}
}
}
为了实现这一点,我们需要规范PreviewProvider的写法。
把静态变量previews的内容封装成View。
如:
struct YourComponent_Previews: PreviewProvider {
struct Demo: View {
var body: some View {
ZStack {
YourComponent(number: 0, x: 0, y: 0, textAreaW: 50, textAreaH: 50, textAreaX: 0, textAreaY: 10, textColor: .red)
}
}
}
static var previews: some View {
Demo()
.frame(width: 500, height: 500)
.previewLayout(.sizeThatFits)
}
}
上述预览代码的编写方式,既可以给Canvas预览使用,当Canvas抽风时,又可以给xxxApp.swift调用,很是方便。
其它建议
对于组件的开发,其UI展示数据尽量由外界传入(通常有个父容器组合各个组件,就由父容器负责获取数据并传入),并优先使用简单数据(原生数据、还有比较常用UIKit的CGSize、UIImage等),这样比较容易写预览代码,也不会把组件和大的程序逻辑混在一起。
【推荐】国内首个AI IDE,深度理解中文开发场景,立即下载体验Trae
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· Manus爆火,是硬核还是营销?
· 终于写完轮子一部分:tcp代理 了,记录一下
· 别再用vector<bool>了!Google高级工程师:这可能是STL最大的设计失误
· 单元测试从入门到精通
· 震惊!C++程序真的从main开始吗?99%的程序员都答错了