SquareLine_Studio这个工具刚火起来的时候我一度觉得它就是个“给Arduino玩家画界面”的玩具直到自己动手把一个SPI接口的1.8寸TFT小屏从裸机驱动一路做到多页面交互UI才发现这套工作流对嵌入式开发者的改变比想象中大得多。很多人卡住的点根本不在“会不会用工具”而在“画完界面之后怎么让它真正跑在单片机上”尤其是SPI屏这种带宽有限、内存受限的场景坑一个接一个。这篇就按我实际走过的路把从零构建SPI TFT UI界面的全过程拆开讲重点说清楚哪些地方值得投入、哪些地方必须绕开。1. 为什么我放弃了纯手写LVGL改用SquareLine Studio搭SPI屏UI1.1 这套组合到底解决的是哪类需求先给个定位SquareLine Studio SPI TFT MCU这个组合最适合的是那些“需要界面但不能上Linux级GUI”的场景。典型如智能家居控制面板、充电桩显示终端、小尺寸仪表盘、温控器、桌面小摆件屏幕甚至是DIY的歌词显示盒、离线翻译器、体感控制器。这类项目的共同特点是屏幕分辨率不高——常见1.8寸128x160、2.4寸320x240接口是SPI主控是STM32F103、ESP32、GD32这类中等性能MCURAM和Flash都精打细算。在这个前提下你要做的界面通常包含几个固定页面、若干按钮/滑块/进度条、少量简单动画以及一些由传感器数据驱动的实时刷新区域。如果纯手写LVGL不是不能做但代价非常具体你得手动计算每个控件的位置坐标、处理不同分辨率下的对齐、反复调整样式参数还要维护一堆零散的UI回调函数。界面简单时还好一旦页面超过三个控件超过二十个手写代码的定位和调试成本就会肉眼可见地上升。SquareLine Studio这类可视化拖拽工具把“画界面”和“写逻辑”拆成了两个独立环节设计时所见即所得导出代码后只需要专注业务逻辑这个工作流上的优化对实际项目效率的提升非常明显。1.2 纯手写与可视化拖拽的真实差距拿我之前做的一个温控器界面举例三个页面主页面、设置页、统计页主页面有温度数值、模式切换按钮、运行状态指示灯设置页有温度滑块加减、定时开关统计页有近七天的温度柱状图。总控件量大概三四十个。纯手写LVGL的情况下我粗略统计过光是控件创建、对齐设置、样式定制这部分代码就要600行以上其中大量是重复的坐标微调。而且每调整一次控件位置就得编译烧录一次看效果、再改来回折腾非常费时间。用SquareLine Studio的话拖拽对齐、实时预览、改样式即时可见整个界面设计阶段半天就能完成生成的代码也有800行左右但这些代码是自动生成的改起来不用手写坐标在工具里改完重新导出就行。这里我想特别强调一个观点用UI工具不等于不懂底层。很多人担心SquareLine Studio导出代码的自动化程度太高会让自己“失去对项目的控制力”。实际上工具生成的是基本可读的C语言代码控件属性、事件回调、样式设置全部能看到。你完全可以在此基础上手写扩展工具只负责你“不想画”的那部分。把工具当工具不神化也不排斥是这套方案能顺畅落地的前提。2. SPI TFT的选型与驱动链路准备2.1 屏幕选型1.8寸128x160这种小屏到底够不够用先泼一盆冷水不要在选屏幕上花太多时间纠结“哪个型号最好”SPI接口的TFT彩屏基本就是那几个主流方案1.8寸用ST7735驱动2.4寸/2.8寸常用ILI93411.3寸以下可能是ST7789。分辨率从128x160到320x240不等接口几乎都是四线SPI加若干控制脚。只要不是特别冷门的屏驱动代码和LVGL移植方法都是通用的关键看你的具体需求。分辨率这件事我建议用“内容需求”反推而不是“参数追逐”。128x160的分辨率看起来不高但做单页面信息展示完全够用——能显示8行左右的中文数字混排或者一个进度条加三个状态图标。真正的瓶颈不是分辨率而是颜色深度和缓冲策略。16位色RGB565是SPI TFT最主流的配置单个像素两个字节那么一帧完整画面需要的缓冲就是128 × 160 × 2 40960 字节 40KB对STM32F103这类RAM只有20KB~64KB的MCU来说40KB的整帧缓冲基本是灾难。所以LVGL在这种小屏上不会让你直接分配整帧而是用局部缓冲区加上“脏矩形刷新”机制这个后面会详细讲。选屏的时候除了分辨率我更看重的是背光控制是否独立、模块是否自带电平转换、排针封装是否方便接线。很多人忽略了屏幕模块的电源逻辑有些屏的背光引脚是直接5V驱动的和MCU的3.3V逻辑电平混在一起轻则显示异常重则烧引脚。2.2 接线与通信链路从MCU到像素点的完整路径SPI TFT的接线说简单也简单说坑也坑尤其第一次接触的人很容易在DC引脚数据/命令选择上翻车。标准四线SPI传输的是纯数据流而TFT屏幕需要区分“这是一条命令”还是“这是一笔像素数据”于是就有了DC引脚也叫RS引脚。初始化屏幕、设置窗口、发命令时DC拉低传像素数据和文本时DC拉高。这个引脚虽然不参与SPI时序但它的电平切换时机必须对齐尤其是在DMA连续传输像素数据时DC要在整笔DMA开始前设置好中途不能抖动。我常用的接线方式以ST7735 1.8寸屏接STM32F103为例屏幕引脚功能接MCU引脚备注SCL/SCKSPI时钟PA5 (SPI1_SCK)硬件SPI速率可调SDA/MOSISPI数据PA7 (SPI1_MOSI)屏幕不读MCU数据无需MISODC/RS命令/数据选择PB0普通GPIO输出CS片选PB1 或硬件NSS软件片选更灵活见下文RST复位PB2普通GPIO低电平复位BL背光PB3PWM调光可选VCC/GND电源3.3V/GND注意背光供电差异关于“SPI硬件片选与软件片选”的选择我的经验是点亮屏幕阶段用软件片选也就是把CS当普通GPIO手动拉低拉高排查问题更直观跑稳定之后再考虑要不要切硬件NSS自动控制。原因很简单硬件片选虽然省事但在DMA传输的边界处理上容易出时序毛刺如果SPI外设的NSS配置不当会在不恰当的时机产生假片选信号屏幕偶发花屏你都不好排查。软件片选配合DMA中断时序完全可控优先级最高实测稳定跑18MHz没问题。2.3 时钟与延时SPI时序里最容易翻车的三个点SPI驱动TFT屏硬件链路看着简单但时序细节直接决定显示是否稳定。我实测下来最容易翻车的三个点如下第一个是CPOL和CPHA的配置。ST7735和ILI9341等主流驱动IC都支持SPI模式0或模式3大多数例程默认配置成模式0CPOL0, CPHA0也就是空闲时钟为低、数据在上升沿采样。如果你复制的驱动代码和CubeMX配置不一致屏幕要么完全不亮要么显示花屏但不完全黑。最稳的做法是先按驱动IC数据手册确认支持的模式再在CubeMX里把SPI参数中的Clock Polarity和Clock Phase设到一致。第二个是分频系数。STM32F103的SPI1挂在APB2总线上时钟是72MHz经过分频后得到SPI时钟。SPI1可选的时钟是72MHz除以2、4、8、16、32、64、128等。很多人为了画面刷新快一上来就把分频设成2也就是36MHz。但SPI TFT模块往往有自身的工作频率上限尤其是杜邦线连接、模块布线一般的情况下36MHz信号完整度很差。我实测1.8寸ST7735在18MHz下稳定升到36MHz就开始偶发性花屏。所以稳妥的做法是先按较低的18MHz跑通整个UI再逐步提高频率测试稳定性而不是一上来就极限超频。第三个是复位时序。TFT屏幕的复位引脚必须在上电后保持一段时间低电平再拉高然后延时一段时间等待驱动IC内部初始化完成。我看到很多初学者直接把RST接MCU的复位引脚图省事结果屏幕初始化经常失败因为两者复位时机没有对齐。老老实实单独用一个GPIO控制屏幕复位初始化的时序就掌握在自己手里了。可以用CubeMX生成一个初始化序列上电延时50ms、拉低RST、再延时50ms、拉高RST、再延时120ms等待稳定。2.4 用CubeMX配置SPI和DMA的前置思路热词里反复出现“stm32f103 spi通过dma方式读取芯片数据 cubemx”这里多提一句虽然TFT屏幕主要是单向写数据但DMA在刷屏场景里的意义非常大。SPI刷一屏128x160的像素数据按40KB算如果用CPU阻塞方式发送整个MCU都会卡在数据搬运上什么传感器读取、按键扫描、动画计算全都别想做了。DMA可以把SPI发送这个操作交给外设自己干活CPU只需要在传输完成中断里处理后续状态。CubeMX配置DMA的关键是SPI1_TX选择一个DMA通道方向是内存到外设模式是正常模式Normal而不是循环模式因为每次刷新画面的数据长度不同。数据宽度内存和外设都设成Byte或Half Word要匹配——颜色数据是16位的建议都设成Half Word一次DMA搬运两个字节。开启DMA传输完成中断在回调里处理缓冲区回收和下一段数据的准备。这里埋个伏笔DMA和LVGL的搭配有一处细节容易踩后面专门用一小节讲。3. SquareLine Studio的界面搭建与资源管理3.1 新建工程时就要想清楚的几个配置项打开SquareLine Studio新建工程第一眼是屏幕分辨率、颜色深度、平台选择。很多人随手选了Arduino平台加默认分辨率后面导出代码才发现不适应自己的MCU工程被迫做一堆手动修改。我的建议是即使你实际用的是STM32平台选择里也可以先选通用平台Generic或者和你的最终环境最接近的选项因为SquareLine Studio导出的核心代码是UI控件和样式平台相关的只是初始化脚手架反正这部分你最终都要改。分辨率一栏务必填成和实际屏幕一致。128x160的屏幕就填128x160不要填大分辨率再指望缩放LVGL的缩放不是这么玩的。颜色深度选16 bitRGB565和SPI TFT屏一致避免颜色转换带来的额外开销。如果你用的是ESP32这类带更多RAM的芯片也可以选32位颜色加抗锯齿黑魔法但走SPI小屏就别想了老老实实16位。屏幕方向也要提前想好。SquareLine Studio里有屏幕方向设置1.8寸屏默认是竖屏128x160如果你的产品是横屏布局硬件上直接转90度摆放然后在Screen Settings里把分辨率横向设置成160x128。注意有些屏幕驱动IC对横竖屏切换有特殊初始化命令你需要在底层驱动里配合修改SquareLine Studio只负责UI布局不负责屏幕驱动的显示方向初始化。3.2 控件布局与样式设置的实操思路SquareLine Studio的控件面板里最常用的几个是Label、Button、Arc、Slider、Bar、Image、DropDown、Checkbox。我建议新手从Label和Button开始先搭一个“点按钮改变文字”的Demo跑通整个流程再逐步加复杂控件。布局上SquareLine Studio提供对齐指南、间距参考线和分组功能比手写代码舒服太多。我的习惯是每个页面先用一个Panel做背景容器然后在这个容器内部放内容控件这样调整整体位置时不会破坏子控件的相对布局。LVGL的控件树层级关系在这个工具里表现得非常直观保持了背景容器、内容控件、事件回调三者分离的结构。样式设置是最容易让人沉迷微调的部分但我要提醒一句不要在工具里给每个控件堆太多圆角、阴影、渐变效果。SPI TFT屏的MCU性能有限尤其是128x160这种低分辨率屏幕渲染带透明度的阴影和圆角非常耗时。LVGL的每个样式属性都会影响重绘性能复杂的阴影效果在小内存设备上甚至可能导致近200ms的单帧渲染时间UI直接卡成PPT。我一般只在按钮按下状态、进度条填充、当前页高亮等关键交互位置使用不同的背景颜色或边框宽度变化这些简单属性的渲染开销很低但视觉反馈已经足够。真正让界面显得高级的是布局的对齐、间距统一和字体的选择而不是花哨的样式效果。这个道理和网页UI设计差不多但在嵌入式屏幕上更明显因为性能余量太小任何过度设计都会以卡顿形式报复你。3.3 多页面跳转与交互事件的挂接SquareLine Studio里创建新页面很简单点击Add New Screen就行。每个Screen在生成的代码里对应一个独立的初始化函数比如ui_Screen1_init()、ui_Screen2_init()。页面跳转的API是lv_scr_load()工具生成的事件回调里会自动帮你写调用不用手动管。事件挂接这块要特别注意SquareLine Studio的事件系统基于LVGL的lv_obj_add_event_cb()每个控件可以绑定多个事件。双击控件在Events面板里选择事件类型比如Clicked、Value Changed、Pressed然后工具会生成对应的事件回调函数原型。真正需要在回调里添加的是你的业务逻辑。举个例子滑块值变化后要实时显示当前数值你需要在Value Changed事件里读取滑块值然后更新Label的文字。SquareLine Studio不会自动绑定传感器数据或业务逻辑它只负责把“控件发生了某个动作”这个信号传递给你剩下的还是自己写。但这里有个重要的性能约定事件回调里绝对不能做耗时操作比如阻塞式等待传感器数据、长延时、大循环。LVGL的事件回调运行在GUI线程上一旦阻塞整个界面就卡死了。正确做法是在回调里只更新标记、缓存临时数值真正耗时的工作放到主循环或独立任务里处理。比如温度传感器的读取如果走的是I2C且速度慢就放到主循环周期采样采样结果更新到全局变量UI回调里只负责把全局变量最新值刷新到Label上。4. 导出代码后在嵌入式工程里的接入与改造4.1 生成文件结构与LVGL版本对齐SquareLine Studio导出后会生成一个UI文件夹里面至少有这几个关键部分ui.c和ui.h是根入口负责所有Screen的初始化ui_events.c和ui_events.h是事件回调ui_helpers.c是工具内部封装的一些辅助函数fonts文件夹放自定义字体images文件夹放图片资源UI界面里用的图标、背景图等。把生成的文件加入工程时最先要确认的是LVGL版本号是否匹配。SquareLine Studio在创建工程时可以选择LVGL版本常见的是v8.x或v9.x不同版本之间的API差异非常大比如v9里事件函数名、样式属性名、颜色表示方式都改了。你从网上找的各种LVGL例程也大概率是v8的混用必然编译报错。最省事的方式是用CubeMX或者直接下载和你SquareLine Studio版本匹配的LVGL源码包不要用最新版去强行适配否则你会花大量时间在API迁移上。4.2 自定义SPI驱动的对接点在哪SquareLine Studio只管生成UI控件代码它不关心你的屏幕具体用什么接口、用什么驱动程序。界面控件要显示到屏幕上最终都要经过LVGL的显示驱动层也就是lv_conf.h配置和lv_port_disp.c实现移植。LVGL的显示驱动核心是一个flush_cb回调当UI需要更新画面时LVGL会把需要重绘的区域脏矩形对应的像素数据准备好然后调用你注册的刷新回调。这个回调要做的事情非常明确把你收到的像素数据通过SPI接口写到屏幕驱动IC对应坐标区域。注意flush_cb里的buf是LVGL内部填好的颜色数据它对应一个矩形区域你要做的是设置屏幕的显示窗口set window / set address告诉驱动IC接下来画的像素起点和终点坐标把DC引脚拉高表示数据模式启动一次SPI DMA传输把整块buf数据发给屏幕在DMA传输完成中断里调用lv_disp_flush_ready()告诉LVGL“这笔画完了可以继续下一笔”。第四个步骤关乎稳定性。很多人的第一次移植都会卡在这里画面要么只刷新一部分要么整体白屏或花屏。最常见的原因就是忘了在DMA传输完成后调用lv_disp_flush_ready()。LVGL是“请求-应答”模型它给你buf让你刷新你只有告诉它刷新完成它才会认为这块区域可以重新绘制。如果你漏了这一步LVGL会认为刷屏一直处于Pending状态后续的重绘请求全部排队等着表现出来就是UI卡死或者半屏刷新。4.3 局部刷新与双缓冲的取舍刚才算过128x160整帧需要40KB绝大多数MCU扛不住。LVGL从设计上就没打算让你准备整帧缓冲它用局部缓冲区加脏矩形机制。你只需给LVGL提供一个或两个局部缓冲区比如每块20行高LVGL会把需要更新的区域切分成多个小矩形逐块交给flush_cb去刷新。单缓冲模式LVGL先往buf里画内容DMA把buf发出去发送期间CPU等着只有发送完成才能画下一块。优点是内存占用少缺点是刷新期间CPU空转动画和交互会掉帧。双缓冲模式LVGL有一个buf在DMA发送的同时CPU可以往另一个buf里画下一块两个buf交替使用。这能把传输和渲染重叠起来刷屏性能大幅提升但代价是内存占用翻倍。我的建议STM32F103这类RAM在20KB以下的先用单缓冲画简单的静态页面足够ESP32或RAM超过64KB的芯片直接上双缓冲。双缓冲模式下SPI DMA和LVGL渲染是并行工作的UI流畅度会有一个质的提升。实测上测试一个带滑块进度条的界面单缓冲时滑块拖动明显卡顿切到双缓冲后流畅度提升非常明显几乎感觉不到延迟。4.4 LVGL的Tick和心跳不能忘接入LVGL到MCU工程时还有一个极常被忽略的配置lv_tick_inc()。LVGL内部有个概念叫LVGL Tick所有动画、按键长按、控件计时都依赖它。你必须周期性调用lv_tick_inc(x)来告诉LVGL“过了x毫秒”通常放在一个1ms或5ms周期的定时器中断里。如果你忘了喂tickLVGL的动画会完全不动触控点击有反馈但动画停滞按钮按下去的动画永远卡在中间状态。这个问题的排查可以用一个很直观的特征来判断控件能响应事件、能切换状态但所有动画都不会“动起来”。遇到这种情况先检查tick喂了没大概率就是这个原因。5. 实测中的UI卡顿定位与优化链路5.1 卡顿根因排查从现象倒推瓶颈热词里高频出现“ui界面卡顿”“刷屏卡顿”这几乎是每个SPI TFT UI项目都会遇到的必经之路。我早期做的一个温控器项目用STM32F103 1.8寸ST7735跑三个页面跳转页面时明显感觉卡顿滑动滑块时甚至能看到屏幕从上往下逐行刷新观感很差。当时我以为是屏幕驱动不完善把SPI时钟一升再升结果花屏问题冒出来了卡顿却没什么改善。后来我把问题重新拆开分三步排查第一步检查LVGL内部渲染耗时。LVGL本身有帧率统计功能在lv_conf.h打开LV_USE_PERF_MONITOR后屏幕上会显示一个FPS计数器和CPU占用率。我实测发现静态页面下FPS有30左右但一旦触发页面切换动画FPS会瞬间跌到10以下。这说明渲染阶段本身出现了瓶颈。第二步检查flush_cb耗时。我在flush_cb入口和DMA完成中断里用GPIO引脚翻转做了个简易的波形测量用逻辑分析仪看SPI传输时间。结果发现一次整屏刷新大概要传输40KB数据在18MHz SPI时钟下理论耗时大概22ms而实际波形显示一次flush耗时接近30ms因为中间DMA触发中断、设置窗口等操作都有额外开销。第三步分析渲染和传输是否重叠。单缓冲模式下渲染和传输是串行的总耗时就是渲染时间传输时间。我用上述方法实测一次完整页面切换的总耗时有将近200ms这放在用户体验上就是明显卡顿。5.2 缓存、DMA与刷新策略的组合优化定位到瓶颈后优化方向就非常明确了要么降低渲染耗时要么降低传输耗时要么让两者重叠。我建议按优先级顺序来第一开启LV_COLOR_16_SWAP。这个配置在lv_conf.h里用途是让LVGL输出颜色字节序直接匹配屏幕驱动IC的BGR/BGR顺序。很多TFT屏幕的RGB565字节序和LVGL默认输出不一致不对齐的话你会发现颜色偏蓝或偏红。如果颜色空间不对不要先在应用层做转换先把这一个开关打开从源头保证数据字节序正确避免CPU在flush过程里做额外的字节交换。第二看SPI时钟是否还有余量。我测试的ST7735在18MHz下稳定换用短的杜邦线和优化地线连接后能上到36MHz也不花屏。SPI时钟翻倍传输时间直接减半这是零成本优化前提是验证信号完整性。第三用双缓冲把渲染和传输重叠起来。这一个改动对卡顿的改善最直接。双缓冲模式下LVGL渲染下一块区域的同时DMA在后台传输上一块区域理论上总耗时从“渲染传输”变成“max(渲染,传输)”加切换开销。实测中页面切换动画的FPS从10帧提升到20帧以上滑块拖动也从“逐行刷新”提升到基本流畅的水平。第四调整LVGL的buffer大小。在lv_conf.h和lv_port_disp.c里LVGL允许你定义buffer的行数。我的经验是buffer高度尽量覆盖整个屏幕高度的1/4到1/2。拿128x160的屏来说设置一个128x40的缓冲就比128x10好很多因为每次flash区域更少DMA启动次数更少总开关开销也就更低。当然buffer越大内存占用越高需要根据芯片RAM余量折中。第五优化UI设计本身。减少大面积透明效果减少圆角裁剪避免在一个页面堆太多不可见控件能显著降低LVGL的渲染负担。SquareLine Studio里可以做的是尽量用纯色背景不用复杂的渐变背景图按钮阴影效果关掉能不用的动画尽量不启。5.3 撕裂、白屏和花屏的专项处理SPI TFT UI的显示异常千奇百怪有些是驱动问题有些是LVGL配置问题还有一些是硬件接触问题。我整理几个高频率案例花屏分两种情况一种是颜色错乱但画面能识别通常是RGB565字节序问题去lv_conf.h调LV_COLOR_16_SWAP另一种是画面整块错乱、甚至出现条纹状噪点多半是SPI时序不对或者时钟过高恢复模式0、降频重试。撕裂感tearing出现在传输速度快、刷新区域切换快的时候。原因是LVGL正在刷新某一块区域时屏幕驱动IC开始扫描显示导致屏幕上出现了更新区域和旧区域交错的横线。解决办法是开屏幕的TE引脚同步或者把整帧刷新改成“一条一条水平线”的行缓冲模式代价是刷屏时间变长。对小项目来说如果撕裂现象不明显可以不管如果看着难受优先开双缓冲撕裂感会减轻很多。白屏是另一个典型的首冲问题。上电后屏幕亮但全白一般说明初始化命令没有正确下发。先检查DC引脚在发送初始化命令时是否拉低、RST时序是否正确再检查SPI的CPOL/CPHA配置。还有一个非常隐蔽的点如果你用的是软件片选初始化序列里CS拉低和发送第一条命令之间要有微秒级延时否则SPI从设备可能没来得及进入准备状态直接丢包。我当时在这上面卡了两天最后用逻辑分析仪看波形才发现CS拉低和SCK首个上升沿之间几乎零间隔加了10微秒延时后问题消失。5.4 几个值得长期保留的调试技巧善用GPIO翻转测量耗时在flush_cb入口置高一个GPIO在DMA完成中断里拉低用逻辑分析仪看高电平持续时间这就是一次flush的真实耗时。这个方法不用任何额外库任何MCU工程都能做定位性能瓶颈非常高效。打开LVGL自带的Perf Monitorlv_conf.h里LV_USE_PERF_MONITOR置1屏幕上会常驻显示FPS和CPU占用配合GPIO波形测量可以快速判断瓶颈是在渲染还是传输。保持SPI屏幕驱动的独立性把屏幕初始化、设置窗口、设置DC/CS电平这些接口单独封装成一个tft_driver模块LVGL的flush_cb只调用这个模块的接口。这样你在排查问题时可以脱离LVGL单独测试屏幕驱动用一段简单的循环发纯色RGB数据验证屏幕本身是否正常。这个习惯帮我过滤掉了很多“底层驱动问题”和“LVGL适配问题”互相混淆的情况。像素点定位测试屏幕驱动验证阶段画一个单色背景再画一个白色边框或一条对角线确认屏幕坐标系和LVGL坐标系是否一致。很多屏出厂时的屏幕方向和LVGL坐标定义相反如果不对齐UI界面上会显示镜像或旋转过的内容。直接用这个测试图能快速发现方向不一致的问题比等UI设计做完再发现要省事得多。写在最后关于这套方案的长期体会这套方案跑通之后我最大的感受是工具和手工之间的边界不是固定的而是根据项目阶段动态变化的。UI设计阶段用SquareLine Studio快速迭代代码生成后手动接入LVGL和SPI驱动后期优化再回到工具里微调布局——这个来回切换的工作流效率确实比纯手写或纯拖拽都高。如果你正准备做一个SPI TFT小屏项目我建议第一次跑通尽量保持最简单一个按钮、一个标签、一个滑块先完成“SquareLine Studio画界面 - 导出代码 - 移植LVGL - SPI刷新显示 - 交互事件响应”的完整闭环再逐步加页面、加动画、加业务逻辑。最快的路不是一上来就搭复杂界面而是先让一个像素点在屏幕上按你的心意亮起来、动起来。另外一个小技巧值得分享SquareLine Studio的字体管理里可以导入ttf字体生成自定义字体文件但中文全量字库非常大占Flash也很多。如果你只需要显示固定的几十个汉字比如“开”“关”“温度”“设置”可以新建一个只包含这些字符的ttf按需生成小字号字体能省出大量Flash空间同时也能保证界面文字风格统一。这个操作官方文档里有说明实际操作时记得把Unicode范围限制到你需要的字符区间生成出来的字体文件越小越不容易在链接阶段出现Flash不足的问题。