1. 项目概述1.1 为什么我开始做“智能屏上的HMI开发”先交代一下背景。我前几年一直在做传统工业控制项目用的都是那种带物理按键的老式文本屏、按钮屏。后来客户要求越来越高要动画、要数据曲线、要配方管理还要远程监控老式屏做起来非常痛苦。于是我决定转向智能显示屏上的HMIHuman-Machine Interface人机界面开发。所谓“智能显示屏”在我的语境里指的是那些基于嵌入式Linux或Android系统、带触摸功能、分辨率普遍在800×480以上、甚至支持HDMI和以太网接口的工业显示屏。常见的包括西门子Smart系列、威纶通cMT系列以及国内很多厂家基于A53/A72核心板做的安卓屏。这类屏的核心优势不是“能显示”而是“能计算”——你可以在屏侧直接跑脚本、做逻辑处理、连数据库甚至跑轻量级Web服务。这篇内容适合谁看呢如果你是刚接触HMI开发的电气工程师、自动化集成商或者手头正好有一个人机交互需求但不确定怎么选型那么这篇从项目立项到功能落地再到踩坑排障的完整记录应该能帮你少走不少弯路。我会把方案选型的思考逻辑、核心功能怎么设计、关键步骤怎么实现以及我在实际项目里遇到的几个典型问题都展开来讲。一句话概括这个项目在一块工业级智能触摸屏上用成熟的HMI组态软件快速搭出一套能对接PLC、能显示变频器参数、能做配方管理、还能画趋势曲线的人机交互系统。它解决的核心问题是“如何在设备端用最少的代码量交付一套稳定、好用、后期好维护的交互界面”。1.2 这个项目到底解决什么问题传统HMI项目里最常出现的几个痛点我猜老工程师都有共鸣屏端逻辑与PLC逻辑耦合太深。很多项目把大量业务逻辑全写在PLC里屏只是被动显示。一旦画面要加个字段或改个交互流程PLC程序和画面程序都得同步改两个工程师来回扯皮。画面效果与数据实时性不可兼得。老式文本屏只能显示字符无法展示趋势曲线和动态图形有些组态软件虽然能做动画但在数据刷新频繁时又会卡顿。调试效率低。传统HMI仿真功能弱或者仿真按钮是灰色根本点不了导致画面逻辑必须反复下载到真机上验证一次轮回十几分钟一天能折腾十几回。所以我在这个项目里换了个思路把屏当成一个“轻量级边缘计算节点”——它不只负责显示还承担一部分数据处理和交互逻辑PLC只提供最基础的IO和工艺控制两边通过标准协议比如Modbus TCP、S7协议解耦通信。这样画面改版不碰PLCPLC改逻辑不影响画面项目整体交付效率高了很多。2. 智能屏HMI的整体设计与方案选型2.1 智能屏与传统屏的本质区别先别急着选型我们搞清楚智能屏到底“智能”在哪。传统工业屏比如早期的西门子OP系列、三菱GOT 1000系列本质是一个“协议转换器位图显示器”。它内部有一颗MCU负责把PLC发来的数据按地址映射到画面变量上刷新率不高能做的东西很有限。智能屏则完全换了一个底层架构。以我用的屏幕为例它主控芯片是四核Cortex-A53跑Linux系统内存1GB起步存储8GB eMMC。屏幕端自带一个组态运行时Runtime但它不再是一个“封闭的固件”而是一个可以扩展的平台。你可以用组态软件拖拽控件做画面用内置脚本类似JavaScript或Python变体处理业务逻辑直接连接数据库把历史数据存到本地SQLite支持OAuth、MQTT、HTTP等现代协议可以实现设备入云甚至可以SSH到屏幕里手动装一些轻量级的工具如果你清楚自己在做什么。这意味着HMI开发模式从“画面上放几个按钮、绑几个地址”变成了“画面上放控件写脚本做数据存储设计交互流程”的全栈式开发。它不再是梯形图的附庸而是独立的一方。2.2 方案对比一体机方案、屏网关方案、纯云端方案在真正动手之前我梳理了三种可落地的技术路线分别是一体机方案、屏网关方案、纯云端方案。方案核心组成优点缺点适用场景一体机智能屏屏内集成Runtime、协议驱动、脚本引擎部署简单、响应快、成本可控算力有限复杂模型跑不动中小型设备、单机交互屏网关屏仅作显示端网关负责协议转换和数据采集扩展性强支持多设备接入多一层网关故障点多部署复杂现场有多品牌PLC、设备分散纯云端屏只负责画面呈现业务逻辑全在云端服务器可以集中管控支持远程迭代依赖网络断网就瘫远程运维、多站点监控我最终选了“一体机智能屏”方案主要原因是这个项目是一个单机设备控制对象是两台变频器和一个温控模块逻辑不复杂但客户要求画面好看、操作顺畅、还能存三个月的历史数据。一体机方案在性能和成本之间最平衡。如果你的项目现场设备很多、协议很杂那屏网关会更合适但在做智能屏开发时你得额外考虑网关的带宽和协议适配问题。2.3 为什么我选择这款屏幕和组态软件市面上的智能屏和组态软件很多我选型时主要看四个维度协议兼容性。能不能直接对接我项目里的S7-1200 PLC和两台丹佛斯变频器。最好是不用写驱动或者驱动配置足够成熟。脚本能力。我需要能在屏端写一些业务逻辑例如根据配方号自动下发参数、异常时弹窗提醒。如果脚本语言太简陋很多逻辑实现起来会非常痛苦。仿真调试能力。这一点非常重要。因为我平时开发不可能每次都在真机上验证必须要有可靠的离屏仿真功能。售后与社区资料。屏幕可以不是大牌但组态软件必须好用、文档必须齐全。关键是出了问题时要有地方查。最终选了一款国产工业智能屏和与之配套的组态软件屏幕型号这里就不点名了免得有广告嫌疑。但我可以说它在协议库里内置了西门子S7驱动和Modbus TCP主站完全覆盖我的需求组态软件支持离线仿真而且仿真按钮一直有效——这一点对比某些国外大牌“按钮是灰色、必须连PLC才能仿真”的体验简直是天壤之别。2.4 从“按钮绑地址”到“面向交互设计”的思路转变这个项目让我最大的收获是智能屏HMI开发核心不是画控件而是设计交互流程和数据流。传统做法是电气工程师打开组态软件放一个按钮然后在属性里填一个PLC地址比如M0.0完事。但这种做法在智能屏上会很快失控因为画面一旦超过50个变量你根本记不清哪个地址对应哪个按钮更不用说还要处理配方、报警、趋势等数据。我采用的方式是“数据字典先行”第一步把设备所有需要交互的数据列成表格包括信号名称、数据类型、PLC地址、读写权限、触发条件第二步在组态软件里统一建立变量表而不是边画界面边建变量第三步在画面上只引用变量名不再直接填地址第四步所有业务逻辑通过脚本和变量表驱动而不是把逻辑塞进按钮的“按下事件”里。这样做的直接好处是后期客户提出“这个数值要加一位小数”“那个按钮要改成确认后才执行”我只需要改变量属性或者改脚本完全不用动画面布局。3. 核心功能拆解与开发细节3.1 数据字典先行——被很多人跳过的关键一步很多HMI项目做到后期出现“变量对不上、地址重复、精度丢失”等问题根因就是前期没有梳理数据字典。我自己以前也吃过亏项目上线前夜发现一个温度测点被两个画面重复绑定但精度设置不同导致两块屏显示不一致。所以在这次项目中我上来就用Excel做了一张完整的数据字典表包含下面几列字段示例说明变量名Freq_1_Actual统一命名用于画面和脚本引用功能描述1号变频器运行频率简单说明用途数据类型FLOAT必须是PLC侧的实际类型PLC地址DB100.DBD4精确到数据块偏移读写属性只读 / 读写决定画面控件类型单位Hz显示时使用量程0~50用于生成曲线时归一化报警阈值高报警45Hz用于报警功能刷新周期500ms决定数据采集频率这个表不仅是开发依据后面测试、验收、售后也都是拿它对照客户问某个数据哪来的直接查表即可。这里我要强调一个细节数据类型的精确性远比看起来重要。比如变频器的运行电流有些变频器用UINT表示0.1A有些用FLOAT表示安培。如果你不核对清楚在屏上读到的值可能是真实值的10倍。这个坑我踩过不止一次。3.2 画面结构设计从用户视角倒推画面设计我建议不要从“我能显示什么”出发而要从“用户在工作时会怎么操作”出发。我这次设计的是典型的五页面结构首页概览展示设备总状态、当前启停状态、主要运行参数频率、电流、温度、一键启停按钮。参数监视页详细展示两台变频器和温控模块的所有实时参数带曲线趋势。控制操作页启停按钮、正反转、频率设定、点动模式、故障复位。配方管理页新建配方、加载配方、保存配方。报警记录页实时报警、历史报警查询、报警确认。这里面有一个设计原则一屏一主操作一操作一确认。比如启动按钮按下后会弹出确认对话框显示“确认启动1号变频器”防止误操作。又比如频率设定输入框在上下限范围内才允许写入超出范围直接弹窗提示。这些逻辑看似简单但在工业现场能省很多事。另外就是触摸目标尺寸问题。工业现场工人有时候戴着手套操作按钮如果太小点按精度会很低。我这边要求所有触控按钮最小尺寸不低于48×48像素实际上我普遍做到64×64以上间距至少8像素。这样就算操作员手上有油污也不会频繁按错。3.3 报警与事件处理不能只做个弹窗报警功能是HMI项目的重中之重但很多人只是简单地在画面上放一个报警条生成报警记录就完事了。实际上一个完整的报警体系应该包括报警检测从PLC地址或屏端变量持续读取状态变化报警分类分为即时报警和延时报警避免瞬间抖动导致误报报警记录存储记录报警发生时间、恢复时间、报警等级、确认人报警联动报警发生时屏幕弹窗、声音提示、甚至通过MQTT发送到手机报警恢复确认必须有“恢复”和“确认”两个独立状态。我在这次项目里做了一套简单的报警机制在屏端每200ms扫描一次报警变量如果状态满足报警条件立即写入报警记录表并弹窗如果条件恢复自动记录恢复时间。特别需要注意的一点是报警扫描周期与画面刷新周期要分开。如果都用画面刷新周期画面一卡报警检测也会卡这在设备故障瞬间是不可接受的。3.4 配方管理别把配方放在PLC里这个项目客户要做产品切换每个产品对应一组变频器参数频率、加减速时间等所以必须有配方功能。常见的做法是把配方存在PLC数据块里屏端切换时逐条写入。但这样做有个问题配方数量多了以后PLC的数据块容量不够而且切换配方时PLC程序要配合处理程序逻辑复杂。我的做法是把配方直接存在屏端的SQLite数据库里一共50组配方每组配方20个字段。切换配方时屏端脚本从数据库读出对应配方然后通过Modbus TCP/S7协议逐条下发到PLC。这样做的好处有三个PLC负载低不需要保存大量配方数据配方维护方便直接在屏上新增/修改/删除配方实时入库扩展性好如果以后要加配方字段不用改PLC程序。当然这种做法的前提是PLC侧必须有一段标准的参数写入区比如在DB100里预留一个参数缓冲数组屏端先写入缓冲然后再发一个“应用参数”的触发位PLC将缓冲值赋给运行参数。这种握手式通信比“直接改运行参数”安全很多。4. 实操过程与核心环节实现4.1 通讯参数配置S7-1200与屏的握手第一步不是画画面而是先把通讯打通。我用的是西门子S7-1200 PLC屏端用S7协议直接通讯这样就不用PLC侧额外写Modbus映射程序了。在组态软件里新建连接选择“Siemens S7-1200/1500”驱动然后填写PLC的IP地址这里我填的是192.168.0.10。要特别注意S7-1200需要开启“允许从远程对象进行PUT/GET通讯访问”这个选项在PLC属性里默认是关闭的。如果不打开屏端虽然能建立TCP连接但读写数据块时会被拒绝。我在项目里就因为这个选项没开排查了整整半天后面会细讲。通讯参数设置方面我建议把“超时时间”设为3000ms“重试次数”设为3次。超时太短会导致偶发数据丢失超时太长则屏幕卡死感明显。另外数据采集周期也就是变量轮询周期我默认设为500ms对常规显示足够了。如果某个变量需要更实时监控可以单独提高它的刷新优先级。注意S7协议的连接数有限。S7-1200默认支持最多3~4个并发连接。如果你的屏同时开了仿真和真实连接可能会占满连接数导致通讯失败。开发时要注意关闭不必要的诊断窗口。4.2 画面开发第一步从“布局稿”到“控件落位”在开始拖控件之前我习惯先在纸上画一份简单的布局稿标清楚每个区域放什么控件、需要多大空间。这样可以避免边做边挪浪费时间。我这次画面的分辨率是1280×800横向布局。整体分为三个区域左侧固定导航栏宽200px放五个页面的切换按钮上部状态栏高60px显示当前页面名称、设备连接状态、当前时间中间主内容区余下约1050×740像素放具体功能控件。每个页面都保持这个基本骨架用户在切换页面时不会迷失。这个设计虽然简单但在工业屏上非常实用操作员只需认准左侧导航一按就到。放置控件时有几个细节值得注意仪表盘、趋势图等复杂控件不要直接拖到页面上就完事要预先规划好数据源输入控件要启用数值范围校验比如频率设定框范围设为0~50Hz这样即使操作员误输入60屏端也会拒绝下发文本显示控件要设置合适的字体大小工厂现场一般离屏1~2米操作字体建议大于20px否则看不清。4.3 脚本逻辑让屏幕自己“思考”组态软件的脚本引擎一般支持类似JavaScript的语法。我这次主要写了三个脚本模块模块一页面加载初始化脚本当设备上电、屏画面加载完成后自动执行一次初始化操作包括// 初始化页面变量 var initResult { freq1Set: 0, freq1Actual: 0, current1: 0, temperature: 25.0, alarmCount: 0 }; // 将初始值写入画面变量 WriteVariable(Freq_1_Actual, 0); WriteVariable(Temp_Current, 25.0); // 检查PLC连接状态 var connStatus GetConnectionStatus(S7_Connection); SetVariableText(Lbl_ConnStatus, connStatus ? 已连接 : 未连接);模块二按钮点击控制脚本启动按钮的按下事件不只是写一个位而是带确认和保护逻辑// 启动1号变频器带确认弹窗 if (MessageBox(确认启动1号变频器, MB_YESNO) IDYES) { // 检查是否有故障 var fault ReadVariable(Fault_1); if (fault 1) { MessageBox(设备存在故障无法启动请先复位, MB_OK); } else { // 先设置频率再启动 WriteVariable(Freq_1_Set, 30.0); WriteVariable(Start_1, 1); } }模块三配方下发脚本从数据库读取配方数据按顺序写入PLC参数缓冲区// 从配方表读取数据 var recipe ReadRecipe(Recipe1); // 依次写入PLC缓冲区 WriteVariable(DB100.DBW0, recipe.freqSet); WriteVariable(DB100.DBW2, recipe.accTime); WriteVariable(DB100.DBW4, recipe.decTime); // 写触发位PLC程序将缓冲值应用到运行参数 WriteVariable(DB100.DBX10.0, 1); delay(200); WriteVariable(DB100.DBX10.0, 0); MessageBox(配方加载完成, MB_OK);这些脚本看起来不难但有一个关键点写变量后一定要确认返回值。因为网络通讯可能失败如果脚本里忽略返回值会出现“界面提示成功、实际没写进去”的情况。我通常会在关键写操作后读回原地址做校验这个习惯让我免去了很多现场返工。4.4 趋势曲线把历史数据画出来客户要求能查看近一小时的频率趋势曲线。这个功能在智能屏上实现不难核心是数据采样和存储策略。我的方案是从屏启动开始每500ms从PLC读取一次运行频率写入一个环形缓冲区同时每10秒向SQLite数据库插入一条带时间戳的历史记录画面上的趋势图控件每1秒从缓冲区取一次数据绘制最近10分钟的曲线同时提供一个“历史查询”按钮可以查数据库里过去7天的数据可选时间段。这里有一个坑需要注意趋势图控件不适合绑定高频更新变量否则底层的重绘逻辑会导致画面卡顿。我一开始把趋势图直接绑定到变量上刷新周期200ms结果画面掉帧明显。后来改成“每1秒从缓冲区取数一次手动刷新趋势图”就好了很多。另外历史记录入库时要注意时间戳格式统一我全部采用Unix时间戳存储查询时再格式化为本地时间这样避免时区混乱。4.5 仿真调试不连PLC也能把流程跑通开发阶段我基本不碰真机全靠组态软件自带的仿真功能。有一点必须强调仿真不是只能模拟画面显示还能模拟PLC数据变化。我把PLC地址全部映射到仿真变量表然后在仿真环境里手动改变这些值比如把温度从25捏到80观察报警是否触发。这种方式用来验证脚本逻辑和画面跳转非常高效。但仿真有几个限制仿真模型的通讯时序和真机不完全一致偶发的超时问题在仿真环境里很难复现仿真环境不支持一些硬件相关的功能比如USB扫码枪、串口条码枪仿真的实时性比真机好所以真机上出现的卡顿问题仿真环境里往往看不出。因此我的原则是“仿真通过只是起点真机测试才是终点”。我一般留出一整天专门做真机联调把仿真中碰不到的通讯、时序、性能问题全部暴露出来。5. 常见问题与排查技巧实录5.1 博图HMI仿真按钮是灰色点不了怎么办这是很多西门子用户遇到的高频问题网上讨论也特别多。我总结一下可能的原因和排查方法现象可能原因解决方案HMI仿真按钮灰色没有选定HMI设备在项目树中确认选中HMI而非仅选中PLC仿真按钮灰色项目中没有添加HMI设备在项目中添加一个HMI站点仿真按钮灰色使用了精简系列面板不支持WinCC仿真启用WinCC Runtime Advanced仿真而非Basic仿真仿真按钮灰色项目处于离线模式检查项目在线/离线模式仿真按钮无反应仿真运行时与屏的IP冲突检查本机网络和仿真IP段如果做了以上排查仍然不行还有一个终极方案先新建一个只有HMI的空项目添加面板看仿真是否可用。如果空项目能仿真那就是原项目的问题如果空项目都不能仿真大概率是组态软件安装不全或授权问题需要重新安装仿真组件。5.2 智能屏连接PLC后数据一直为0这个问题的排查顺序非常固定先看屏和PLC的IP是否在同一网段。记住子网掩码要一致不能只看IP前三位相同检查PLC侧的PUT/GET通讯访问是否开启用通讯诊断工具监控报文看屏是否真的发出了读写请求检查变量地址是否和PLC数据块实际地址一致。这里要特别注意S7-1200的DB块偏移量是字节偏移但有些组态软件里填地址时按“字”来算容易差一半如果一切正常但数据还是0检查变量类型和PLC侧变量类型是否严格匹配INT和REAL不能混。5.3 画面运行时间长了切换页面越来越慢这个问题的根源多半是内存泄漏或资源堆积。我遇到的情况是趋势曲线控件和报警列表控件在页面切换时没有正确释放旧数据。解决办法是在页面切换脚本里手动清理画面资源// 页面离开前清空趋势图数据 Trend_G1.ClearData(); // 关闭不需要的后台定时器 StopTimer(Timer_DataCollect); // 释放大对象引用 AlarmList_1.Clear();另外如果屏端运行内存不足可以考虑关闭不必要的背景动画和动态效果。智能屏虽然有1GB内存但组态Runtime本身占用不少透明图层和阴影效果都是性能杀手。5.4 变频器参数如何显示到HMI中热搜里有人专门问“西门子PLC怎样将变频器参数显示到HMI中”我在这里一并展开讲一下。这本质上是三层数据链路的问题变频器 --- PLC --- HMI最常见的方案变频器通过PROFINET或Modbus接入PLCPLC程序周期性读取变频器的运行频率、电流、故障状态等参数写入PLC内部的共享数据块HMI通过S7协议读取PLC数据块中的这些数据并显示。以我的项目为例变频器1通过Modbus RTU接到了PLC的串口西门子S7-1200用Modbus RTU主站指令读取变频器的地址40001运行频率和40002运行电流分别存到DB100.DBD4和DB100.DBD8。然后HMI直接读这两个地址每500ms刷新一次。这样做的好处是HMI完全不需要知道变频器协议细节所有协议转换都在PLC侧完成。如果你的变频器比较多建议在PLC里做一个统一的数据映射区比如DB100开始存所有变频器状态DB200存所有设定值这样HMI侧的变量表也清晰维护成本低。5.5 HMI软件和镜像更新工具相关很多人会搜“HMI panel image updater下载”。这里我解释一下智能屏升级固件一般叫“镜像更新”。如果你的屏跑的是Linux系统官方会提供专门的镜像更新工具通过USB或SD卡刷写系统。刷写系统有两个使用场景系统损坏恢复。屏幕变砖或者启动卡在Logo界面需要用镜像工具恢复出厂固件版本功能升级。组态软件发布了新版本支持更多功能或修复已知Bug需要把Runtime镜像更新到新版本。刷机前一定要做的事备份屏内的配方数据库和报警记录确认使用官方对应型号的镜像文件刷错型号会变砖更新过程中严禁断电否则可能永久损坏引导区刷写完成后建议恢复出厂设置并重新配置IP。如果你不熟悉刷机流程不要轻易尝试。我个人建议先联系原厂售后让技术支持远程指导稳妥得多。5.6 博图HMI仿真按钮无反应的其他原因如果仿真按钮不是灰色而是点击后没反应通常问题出在项目中的HMI画面数太多仿真编译时间较长界面假死多等两分钟看看本机防火强拦截了仿真进程需要将仿真工具加入例外组态软件安装在非默认路径可能导致仿真组件无法正常加载重新安装即可。还有一个小技巧仿真启动后如果画面空白检查HMI设备类型是否与所选面板型号一致不一致时Runtime可能无法正确加载。6. 项目落地的注意事项与个人体会6.1 选HMI开发工具时先别迷信大牌我理解很多工程师对西门子、三菱等大牌有深厚感情但现在国产智能屏软件生态已经相当成熟。选型时不要只看品牌而要亲自下载组态软件试用重点测试三个点变量导入导出的效率。如果组态软件不支持Excel变量批量导入我会直接放弃手工敲几百个变量非要命离线仿真可用性。如果仿真按钮是灰色的或者仿真功能残缺开发效率直接腰斩脚本调试工具。有的软件调试脚本需要整机下载有的支持在线单步调试后者体验好得多。6.2 用“变量命名规范”避免后期混乱我在这个项目里定了三条硬性命名规则所有变量名采用“类型_对象_功能”结构例如Freq_1_Actual、Temp_Zone1_SetPLC地址前缀统一用DB开头如DB100.DBD4中间变量和外接变量分开命名空间例如屏端计算值用tmp_前缀PLC下发值用ctrl_前缀。这样做的原因很简单一年后再打开这个项目光看变量名就知道这个变量干什么用的、从哪里来不用翻旧文档。这种好习惯在多人协作的项目里尤其重要。6.3 备份与版本管理的教训项目开发中期有一次我改了一版画面越改越乱想回退到前一天的版本结果发现没备份。当时真的头皮发麻最后只能手工恢复花了三个小时。从那以后我养成了一个习惯每天下班前把项目文件备份一次命名规则如HMI_Project_20250115_v1.3.HMI备份到本地和网盘各一份。如果项目有队友协作再配合一套轻量的版本管理工具例如本地Git虽然组态项目文件有时候合并很麻烦但至少可以保留历史版本。6.4 真机联调时一定要按“最小可运行系统”思路来真机联调不要一上来就把所有页面全下载进去。我建议按以下顺序推进先建一个只有通讯测试页的最小项目验证屏和PLC的通讯链路确认每个关键地址都能正确读写再逐步加入参数监视页面验证数据刷新稳定性再加入控制按钮和脚本仔细检查每次写操作的读回确认最后加入配方、报警、趋势等复合功能。这个思路的精髓在于每一阶段都能稳定运行才进入下一阶段。如果直接一次性做完整套系统再联调出问题时很难定位是三层的哪一层出了问题。6.5 我最后一个核心经验把HMI当产品做而不是当画面做项目做完后复盘我最深的感触是——HMI开发不能停留在“把PLC变量显示到屏幕上”这个层面要把它当作一个面向操作员的产品来设计。这意味着你要思考操作员一天要在屏前站多久哪些功能是高频使用如何让它们一键可达报警出现时操作员第一步该看哪里怎么减少误操作交接班时操作员要不要看统计报表这些数据怎么快速导出设备维护人员要查历史数据界面能不能让他们3秒内找到入口。当你开始思考这些你的HMI就不只是一块“会亮的屏”而是一个真正能提升设备可用性和维护效率的界面系统。项目最终交付后的口碑往往就体现在这些细节里。我在实际项目里还有一个体会不管用什么组态软件、什么型号的智能屏数据流设计永远比控件摆放重要。先把数据从哪里来、到哪里去、怎么处理、怎么存储想清楚再考虑画面好不好看你会发现后面所有工作都会顺畅很多。