用Kivy打造跨平台移动应用：Python开发者的Android/iOS实战指南

去年年初我接到一个特别拧巴的需求业务方有一套用 Python 写的库存预估逻辑想快速做成一个移动端工具要求 Android 和 iOS 都有但团队里没有人为两套原生重写一遍的预算。我翻了一圈方案最后把目光落在一个老牌项目上——Kivy。说它老牌是因为它很早就实现了“用一套 Python 代码打包成移动应用”这件事只是这几年讨论热度远不如 Flutter 和 React Native。这一试就是大半年踩了不少坑也积累了一些只靠读文档很难得到的经验。这篇文章就围绕 Kivy 做移动应用的完整链路展开它到底适合做什么、环境怎么搭、KV 语言和事件循环怎么理解、一个真实项目怎么落地、打包 APK 有哪些硬骨头以及我遇到的高频问题排查思路。如果你是 Python 背景、想低成本做移动端工具或内部系统这篇应该能帮你少走不少弯路。1. Kivy 到底在解决什么问题Python 开发者的移动端新选项1.1 一台设备接口的真相Kivy 的输入事件不是“点击”很多初学 Kivy 的人把它当成“Python 版本的 Flutter”这其实忽略了它最底层的一个设计Kivy 不是为了复刻原生控件而生的。它的渲染基于 OpenGL 一类的图形接口界面上的一切都是“画出来”的Android 上的按钮不会长得像系统按钮iOS 上也不会变成 iOS 风格。换句话说Kivy 的控件树本质上是图形指令的集合系统的原生控件在这里面是不存在的。这套设计带来的一个好处是同一套界面在 Android 和 iOS 上看起来完全一致不会出现“左边字体大一点、右边按钮位置偏了一点”这类原生适配问题。另一个容易被忽略的特点是输入端。Kivy 里最基础的事件类型不是鼠标的 click而是更底层的 Touch。鼠标、触摸屏、手写笔在进入事件循环之后都会归一化为触摸事件流每个触点带着自己的 id 和坐标走完 down、move、up 三个阶段。这让多点触控的实现变得非常自然——多指缩放、手势旋转这类交互在 Kivy 里不是靠平台 API而是靠事件流自己判断。不过副作用也很直接当你写了一个 Button它并不是“系统按钮”所以系统级的无障碍服务、系统级输入法联想、系统级返回手势这些能力Kivy 都要自己想办法对接有些能对接好有些则要看场景。理解这一点之后你才不会对 Kivy 抱有不切实际的期待。1.2 一套代码的复用边界界面、逻辑与服务层“一套代码到处跑”听起来很美好但真实项目里要拆开看。我习惯把 Kivy 项目的复用分成三层界面层、业务逻辑层、设备服务层。界面层基本可以做到 90% 以上复用。KV 文件写布局Python 文件写交互Android 和 iOS 共用同一套 UI 描述这部分是 Kivy 最舒服的领域。业务逻辑层也与平台关系不大文件读取、网络请求、数据计算、状态管理只要你不用那些平台特定的 API这部分几乎 100% 复用。真正的变量在设备服务层。拍照、读取系统相册、获取定位、调用传感器、推送通知这些能力不在 Kivy 核心范围内需要额外封装。以读取设备电池信息为例Android 上往往要通过 JNI 机制直接调用 Java 类iOS 上要用另一种桥接方式最终封装成一个统一的battery.get_percent()接口业务代码才不用改。所以“一套代码”并不是字面上的零改动而是“业务逻辑零改动、设备能力封装一次”。我在做项目时给自己定了一个规则凡是涉及设备能力的功能先查有没有现成的跨平台库没有就单独写一个平台适配层把接口固定好不让平台相关代码散落在业务文件里。这条规则后来帮我省了很多事。1.3 对比 Flutter、React Native 和原生怎么选经常有人问我“既然都要跨平台为什么不直接用 Flutter”答案要看你的起点和终点。方案开发语言渲染方式界面一致性打包复杂度生态活跃度更适合的场景KivyPython自绘图形很高中等相对小众内部工具、原型验证、逻辑密集的应用FlutterDart自绘引擎很高较低很活跃商业 App、追求高流畅动效React NativeJavaScript / TypeScript原生控件桥接有限中等活跃已有 Web 前端团队的工程化项目双端原生Java/Kotlin Swift系统原生控件各自独立高很强极致体验、深度操作系统能力Kivy 的独特位置在于它是唯一一个让你用 Python 写完整移动应用的主流方案。如果你的核心逻辑本来就是 Python 代码比如数据分析、算法调度、内部业务系统那么用 Flutter 意味着你要把几百上千行业务逻辑用 Dart 重写一遍这个成本往往比做两个原生壳还高。反过来如果你的产品面向海量 C 端用户需要极度流畅的转场动画和系统级沉浸体验那 Kivy 确实不适合硬上也只会把自己折腾到崩溃。2. 环境准备与工程骨架十分钟先跑起桌面窗口2.1 安装 Kivy 时最容易忽略的三件事第一件事是虚拟环境。Kivy 的依赖链不短SDL2、音视频解码、图像处理这些库都会装进来如果直接装到系统 Python 里换一个项目可能就会因为版本冲突头疼。我习惯新建虚拟环境后再安装环境独立、出问题删掉重来也快。第二件事是 Python 版本不要刻意追求最新。Kivy 的预编译依赖在个别新版本 Python 上不一定同步选择稳定的、官方文档里推荐的版本反而省事。我记得有同行在新版 Python 上安装失败回退一个版本后一分钟就装好了这种问题很难通过改代码解决不如直接选对版本。第三件事是确认图形环境可用。Kivy 在桌面上运行依赖 OpenGL 2.0 以上的驱动能力Windows 上如果出现黑屏或者渲染异常可以先查显卡驱动也可以尝试修改图形后端环境变量。Linux 虚拟机里如果跑不起来多半是因为虚拟显卡驱动太弱。这些情况不属于代码问题没必要硬调试换个环境就好。安装命令很常规在虚拟环境里执行即可pip install kivy[base]如果后续需要处理音频、视频或更复杂的图像解码比如用 Kivy 自带的视频组件可以换成kivy[full]。但我给你的建议是先装base用到了再补别一上来就把所有功能装全否则后面打包 APK 时这些依赖都会变成包体积的负担。2.2 最小工程结构main.py 与同名 KV 文件Kivy 的最小工程不需要复杂的脚手架。一个main.py文件就够了运行时会在当前目录找与 App 类同名的 KV 文件自动加载。比如类名是DemoAppKivy 会尝试加载demo.kv。命名规则是类名去掉App后缀并转为小写。下面是最小的启动代码直接在命令行跑python main.py就能弹出一个窗口from kivy.app import App from kivy.uix.boxlayout import BoxLayout from kivy.uix.button import Button class DemoApp(App): def build(self): box BoxLayout(orientationvertical) box.add_widget(Button(text点我)) return box if __name__ __main__: DemoApp().run()窗口弹出后你会看到 Kivy 在桌面上的真实渲染效果按钮不是系统按钮而是一个画出来的、带阴影和过度色块的图形。鼠标点击时会模拟触摸事件整个交互逻辑与手机上的行为一致。这正是我喜欢用 Kivy 做桌面原型的原因——你在电脑上看到的样子基本就是手机上看到的样子。2.3 先桌面后真机调试链路该怎么搭我见过不少新手一上来就研究怎么打包 APK然后在一个很基础的错误上浪费一整天。正确的做法是桌面端开发调试真机只做验证。Kivy 桌面运行与移动端跑的是同一套渲染路径这意味着绝大多数 UI 逻辑和交互逻辑都可以在桌面窗口里验证。我的日常开发节奏是改 Python 代码运行窗口观察界面看控制台日志。窗口一关再次运行即可整个反馈周期在几秒以内。真机调试则放在关键节点做比如一个模块跑通了、准备联调设备能力时才打包成 debug 版安装到手机。安装后通过 adb 抓取日志能直接看到 Kivy 的 Python traceback。很多只在真机出现的问题比如中文输入法、系统字体缺失、屏幕适配、权限弹窗都是在桌面端无法暴露的。另外要提前说一句Android 的打包过程在 Windows 上相对曲折最稳的方式是在 Linux 环境或持续集成服务里构建这部分我会在后面专门讲。3. KV 语言与事件循环理解这两块才能写好界面3.1 KV 语言为什么能把布局和逻辑分开第一次看到 KV 文件的人通常会觉得它像 CSS 和 XML 的结合体。它存在的意义确实类似把界面布局与 Python 逻辑分开让代码更容易维护。KV 文件的核心套路是“用缩进表示层级”控件作为节点属性用冒号赋值事件用冒号绑定回调。比如一个列表页的骨架BoxLayout: orientation: vertical padding: 16 spacing: 8 Label: text: 支出管理 TextInput: id: amount_input hint_text: 金额 Button: text: 保存 on_release: root.save()在这个片段里root.save()指的是该 KV 规则对应的 Python 控件类中的save方法。id是同一个 KV 规则内访问子控件的凭据Python 代码中通过self.ids.amount_input.text就能拿到输入框内容。KV 文件的名字匹配规则省去了大量样板代码。只要DemoApp存在Kivy 启动时会自动寻找并加载demo.kv。这种“约定优于配置”的体验非常舒服。真正需要小心的是KV 表达式本身是声明式的很多新手以为它是按顺序执行的过程式代码在 KV 里写了复杂的循环或条件判断结果和预期完全不同。KV 更适合描述结构真正的逻辑应该放到 Python 方法里。3.2 卡顿的根源事件循环与 Clock 调度Kivy 的事件循环平时是透明的但你一旦写了阻塞操作它立刻就会让你明白什么叫“界面冻住”。原因很简单Kivy 的主循环负责所有事情输入事件、界面刷新、动画推进都在这一个线程里跑。任何长时间的time.sleep或同步计算都会让整个窗口停止响应。看一个典型反模式def on_press(self): import time time.sleep(3) # 界面会僵住 3 秒正确做法一般有两条路。第一种是把大任务拆成小片用Clock.schedule_interval每帧做一小块界面可以获得喘息机会第二种是把任务丢到线程里计算完成后再回到主线程更新界面。第二种方式要注意一个铁律UI 控件不能在工作线程里直接修改需要借助Clock.schedule_once把更新动作调度回主线程。我曾经在处理一个上万条记录的清洗任务时踩过这个坑当时直接在按钮回调里同步跑结果用户点完按钮界面就卡死了。后来改成线程加队列实现界面保持流畅进度提示还能实时刷新。Kivy 的Clock模块是调度系统的核心掌握它比背多个 API 都重要。3.3 属性绑定声明式 UI 在 Python 里的具体长相Kivy 的属性系统是它最容易被低估的部分。KV 里写Label: text: str(root.count)这里的count是 Python 侧定义的一个NumericProperty当它变化时上面的文本会自动更新你不需要手动调用类似label.set_text()的方法。这个机制的实现原理是属性依赖跟踪KV 表达式执行时会记录它读取了哪些属性之后这些属性一旦变化表达式就会重新求值。Python 侧也可以显式绑定def update_label(self, instance, value): label.text str(value) root.bind(countupdate_label)两条路各有优劣。KV 里的声明式绑定代码量少但数据流相对隐蔽调试时有点费劲Python 里的显式绑定更直观适合处理复杂的联动逻辑。我的经验是常规展示用 KV 属性绑定业务联动用 Python 方法处理不要让一个界面层文件里堆满跨控件访问的逻辑。4. 实践项目一个能跑在手机上的记账本4.1 先把需求拆成能落到代码的结构做 Demo 最忌讳一上来就写界面。先把需求拆清楚这个记账本要能记录金额和备注能显示总支出能在首页看到最近记录列表数据要能持久化不丢失。搞清楚这些之后数据模型就出来了一条记录包含金额、备注、时间戳结算逻辑是对金额求和持久化方案用 JSON 文件就够了不需要引入数据库数据量小的场景用 JSON 非常合适代码简单出问题容易排查。这个阶段我还会顺手想想哪些功能可能在未来扩展比如分类、统计图表但不会真的提前实现——过度设计比欠设计更容易拖垮项目。4.2 界面层 KV 实现两个 Screen 的导航与表单结构上我用了两个界面页首页和添加页。用ScreenManager做切换这是 Kivy 里最直接的多页面方案。ScreenManager: id: sm HomeScreen: name: home AddScreen: name: add单个添加页的布局这样写AddScreen: BoxLayout: orientation: vertical padding: 24 spacing: 16 TextInput: id: amount_input hint_text: 金额 input_filter: float TextInput: id: desc_input hint_text: 备注 Button: text: 保存 on_release: root.save() Button: text: 返回 on_release: app.root.current home这里有一个小细节input_filter: float会让金额输入框直接拒绝非法字符比等用户输完再校验省事很多。按钮的on_release是抬起事件比on_press更符合日常交互直觉避免误触。4.3 逻辑层实现新增记录、动态列表与 JSON 持久化Python 侧的核心逻辑拆成三个部分保存记录、刷新列表、读写 JSON。from kivy.app import App from kivy.uix.screenmanager import Screen from kivy.uix.label import Label from kivy.uix.boxlayout import BoxLayout import json import os from datetime import datetime class AddScreen(Screen): def save(self): amount float(self.ids.amount_input.text or 0) desc self.ids.desc_input.text.strip() app App.get_running_app() app.add_record(amount, desc) self.ids.amount_input.text self.ids.desc_input.text self.manager.current homeApp 类负责数据存取这样多个页面可以共享同一份记录列表class ExpenseApp(App): def __init__(self, **kwargs): super().__init__(**kwargs) self.records [] self.load_records() property def data_file(self): return os.path.join(self.user_data_dir, records.json) def load_records(self): if os.path.exists(self.data_file): with open(self.data_file, r, encodingutf-8) as f: self.records json.load(f) def save_records(self): with open(self.data_file, w, encodingutf-8) as f: json.dump(self.records, f, ensure_asciiFalse, indent2) def add_record(self, amount, desc): self.records.append({ amount: amount, desc: desc, ts: datetime.now().isoformat(timespecseconds) }) self.save_records() self.root.current home首页列表我刻意没有用RecycleView而是用一个ScrollView套BoxLayout在数据量不大时最直观也最容易调试。动态追加标签的写法很朴素class HomeScreen(Screen): def on_enter(self): self.refresh_list() def refresh_list(self): container self.ids.list_container container.clear_widgets() app App.get_running_app() total sum(item[amount] for item in app.records) self.ids.total_label.text f总支出{total:.2f} for item in app.records: container.add_widget(Label(textf{item[desc]} {item[amount]:.2f}))一个新人容易忽略的点是on_enter这个钩子每次进入页面都会触发所以列表能始终保持最新状态比手动调用刷新方法可靠得多。数据量如果涨到几千条再换成RecycleView或列表虚拟化方案即可这个记账本骨架本身保留了足够的替换余地。5. 打包 APK 的硬骨头Buildozer 配置与体积优化5.1 三种打包路径与主机环境限制目标平台主要工具链主机要求复杂度Android APK / AABBuildozer、python-for-androidLinux 或 macOS 较顺Windows 需要绕 Linux 环境或持续集成中等iOS 应用Kivy-iOS 配合苹果开发工具链只能使用 macOS高桌面可执行文件PyInstaller 等与目标系统一致即可低你不需要一开始就研究全部最常见的需求是 Android。打包 iOS 需要完整的苹果开发工具链和签名配置如果只是做内部工具Android 版本往往已经够用。5.2 buildozer.spec 里的关键项与首次构建项目根目录执行buildozer init会生成一个buildozer.spec文件之后所有构建配置都在这里改。我的常用配置大致是[app] title 记账本 package.name expenseapp package.domain org.example requirements python3,kivy android.permissions INTERNET android.archs arm64-v8a [buildozer] log_level 2 warn_on_root 1解释几个容易踩坑的点package.domain和package.name组合成应用的唯一包名org.example是保留示例域名实际项目请换成你自己的标识。requirements默认会包含 kivy如果你用了 KivyMD 或其他纯 Python 库要在这里显式声明。android.archs只保留arm64-v8a能显著减小体积现代安卓设备基本都支持 64 位老旧的 32 位设备可以按需加回。warn_on_root 1是提醒你不要在 root 用户下构建权限问题会导致后续安装 Android SDK 时各种奇怪报错。首次构建很慢因为要下载 Android SDK、NDK 等工具链网络环境差的话可能要等很久。构建命令是buildozer -v android debug deploy run-v是 verbose 模式第一次建议开启方便看到日志。构建失败时先不要慌绝大多数问题都能从日志开头找到根因。常见的有 SDK 或 NDK 版本与当前工具链不匹配、缺少某个系统依赖库、某个 Python 扩展包在移动端没有对应的构建方案。这里必须说一个很多 Python 开发者容易低估的问题如果业务逻辑依赖 Pandas 这类重型的科学计算库打包成本会急剧上升甚至直接失败。移动端不是不能装而是依赖链太长、包体积爆炸、兼容问题多。我在实际项目中会尽量把核心逻辑改用纯 Python 或轻量库重写这笔前期投资非常值得。5.3 包体积和启动速度怎么做减法Kivy 打出来的 APK 天生就偏大因为它内置了 Python 解释器、图形渲染依赖、SDL 运行环境以及各类相关模块。几十 MB 是很正常的。做减法时优先级如下第一控制依赖。安装时用kivy[base]而不是kivy[full]不要在代码里 import 自己用不到的大库。有些库只要被 import 就会被一起打包哪怕你只用了一个函数。第二精简架构。只打arm64-v8a比同时打 32 位和 64 位体积小得多如果你的目标用户集中在近几年的手机这个选择几乎没有代价。第三启用 AAB 格式。如果计划发到应用市场用 Android App Bundle 提交会按设备配置分发用户实际下载的体积更小。但要注意AAB 不方便直接发给别人侧载内部工具阶段用 APK 更灵活。启动速度方面Kivy 应用冷启动会比原生慢一些因为要先初始化 Python 运行时和控件树。最容易做到的一点是延迟 import不要在主模块顶部一口气加载所有功能模块把重库放到真正执行到的方法里再引入首屏会快不少。另外要准备启动画面避免出现长时间黑屏。6. 生态补强组件库、原生接口与适用场景判断6.1 KivyMD 到底值不值得引入Kivy 自带的控件风格比较克制一眼就能看出是 Kivy。如果想做对外展示的 Demo通常需要一套更现代的视觉方案这时候 KivyMD 几乎是绕不开的选择。它提供 Material Design 风格的表单、导航栏、对话框等一系列组件能让应用观感提升一个档次。但引入 KivyMD 之前需要认清它的成本。首先是版本兼容问题Kivy 在升级时偶尔会调整底层 APIKivyMD 如果不及时跟进就会出现控件无法渲染、属性名失效的情况。其次是包体积增加MD 组件本身包含大量样式定义和图片资源。最后是维护压力KivyMD 相对核心库来说社区规模更小出问题时要做好自己看源码的准备。我的建议是先做基础功能界面骨架用原生 Kivy 控件跑通真正发布前再评估是否值得引入 KivyMD。如果只是内部工具原生控件反而更稳定如果需要做成演示级产品给客户看那么 KivyMD 的投入是划算的。6.2 跨平台访问设备能力plyer 与 pyjnius 的组合移动应用几乎绕不开设备能力相机、通知、剪贴板、传感器。Kivy 核心不提供统一接口但生态里有两个重要工具。plyer是跨平台设备能力封装库接口简单适合大多数常规场景。比如弹一个通知、触发一次震动、读取剪贴板用 plyer 写一遍就能在 Android 和 iOS 上共用。它的问题是覆盖的接口有限遇到冷门能力就没有办法。pyjnius是更底层的工具可以直接在 Python 中调用 Android 的 Java 类。比如你想拿到外部存储目录可以这样写from jnius import autoclass Environment autoclass(android.os.Environment) root_path Environment.getExternalStorageDirectory().getAbsolutePath()这个能力几乎是“万能钥匙”但使用成本也高——你要懂一点 Android API 和 JNI 类型转换规则。我的做法是优先查 plyer 有没有现成方案没有再用纯逻辑实现最后才引入 pyjnius 直接调 Java 层。封装原则是一致的提供一个稳定的 Python 接口平台细节藏在内部。6.3 从三个真实案例看 Kivy 适合做什么第一个案例来自某仓储公司。他们的核心需求是让仓库人员用手持终端查看入库记录、选择货位、提交盘点结果背后是一套现成的 Python 库存算法。如果改用 Flutter算法重写成本极高用 Kivy 只把算法接进来加一个简单的表单界面三周就交付了跑在一批旧平板上也很稳定。第二个案例是某物联网设备公司的展示现场。设备通过串口传来实时数据需要在大屏和手机端同时显示趋势曲线。他们用 Kivy 写的窗口在展会上跑了一整天界面统一、部署简单后续改成触屏交互也没费多少功夫。第三个案例是一位独立开发者给孩子做的认字卡片应用。本地方案素材打包在应用里支持滑动翻页和简单的发音反馈。他没有学过 Java 和 Swift但用 Kivy 把想法变成了能装在手机上的真实应用。这三个案例的共同点很清晰逻辑密集、界面复杂度中等、用户群体固定、不需要极度丝滑的系统级动效。反过来如果你要做的是需要实时音视频、高性能绘图、深度系统集成的 C 端产品Kivy 大概率不是最优解。7. 绕不开的坑三个高频问题的排查思路7.1 按钮点了没反应覆盖、尺寸与事件坐标这是新手最常见的问题按钮明明放在界面上点击就是没反应。排查顺序很重要不要一开始就怀疑 Kivy 的 bug。第一步检查按钮的实际区域。Kivy 的坐标原点在左下角打印按钮的坐标和尺寸看看是否真的落在可视区域内print(pos:, self.button.pos, size:, self.button.size)如果尺寸是 0多半是size_hint被设成了None却忘了指定固定宽高。如果按钮被挤出屏幕检查父容器的布局逻辑。第二步检查是否有其他控件盖在上面。Kivy 里后出现的控件默认在更上方opacity为 0 的控件仍然会拦截触摸事件透明并不代表不响应。如果你把一个全屏透明布局放在按钮上层按钮永远点不到。第三步确认事件名正确。Kivy 的按钮是on_press和on_release不是其他 GUI 框架里常见的on_click。写错事件名不会报错只会静默无效。7.2 中文显示方块与输入法异常Kivy 的默认字体基本不含中文字符直接显示中文往往是一排方块这是打包后最容易遇到的问题。解决方法是在应用内置一份授权宽松的中文字体文件并在 KV 中指定Label: text: 支出管理 font_name: data/fonts/your_cn_font.ttf注意字体文件路径要放在 APK 能访问到的位置。如果很多控件都要用中文字体给每个控件写font_name会非常繁琐更好的办法是找到一个统一设置默认字体的时机在 App 初始化时载入字体配置。中文输入法的问题是另一类麻烦。不同安卓厂商的输入法框架差异很大Kivy 的文本输入框与系统输入法协作时偶尔会出现候选词不显示、拼音预览异常等情况。这类问题在桌面上很难复现真机测试一定要覆盖两款以上的不同设备遇到问题后先抓日志再针对特定输入法做兼容处理。不要指望一个通用方案通杀所有机型。7.3 界面卡顿定位从 FPS 到纹理管理的优化链路界面卡顿的原因通常集中在几个位置频繁创建控件、图片加载过大、透明层级过多、主线程被重型计算阻塞。定位卡顿最直接的方式是看实时 FPSfrom kivy.clock import Clock def show_fps(dt): print(fps:, Clock.fps) Clock.schedule_interval(show_fps, 1)稳定低于 30 就说明有优化空间。我发现最容易被忽视的问题是图片资源一眼看上去只有几百 KB 的图加载进纹理后可能占用了好几 MB 的显存。解决方案是提前缩放图片到实际显示尺寸而不是把大图直接交给 Kivy 缩放。另一个常见性能陷阱是大量小控件的真实绘制成本。界面上一屏塞进几十个 Label 通常还好但塞进几百个就会开始掉帧。与其一个个 add_widget不如用RecycleView按需渲染或者用 Canvas 直接画文本和图形。移动 GPU 上减少状态切换和过度绘制同样重要大量带透明通道的控件叠在一起很容易让低端机发热掉帧。打个比方Kivy 的界面像一张画布每一帧要重新画一遍。控件少的时候画家很轻松控件多了、纹理大了、图层复杂了画师的手速就跟不上了。优化方向说白了就是让每一帧要画的内容更少、更简单。说实话做完这几个项目之后我对 Kivy 的适用边界已经有了比较清晰的感觉它不是用来做爆款 C 端 App 的框架却是一个很契合 Python 工程师团队做内部工具、行业应用和原型验证的方案。如果你决定用它我最后想强调两件事第一桌面端永远是你最高效的调试环境别让打包流程拖累迭代速度第二把平台相关的调用尽量封在独立层里这样即使某一天你要换框架业务逻辑也不用重写。上面的坑和技巧是我真实试错后的记录剩下的事情就是打开命令行让第一个窗口弹出来。