最近一直在折腾团结引擎接OpenHarmony这套组合前前后后踩了不少坑也攒下了一堆值得记录的东西。说实话网上关于团结引擎的资料不少但专门针对OpenHarmony适配的内容还是比较零散很多问题都得自己翻源码、试配置、看日志一点点趟出来。这篇就当作一个持续更新的实践日志把环境搭建、打包配置、渲染适配、性能调优这些环节里我实际遇到的问题和解决办法都写出来给正在做同样事情的朋友一个参考。先说清楚这套方案是干什么的。团结引擎是Unity中国推出的引擎分支针对国内开发者的使用习惯和本土平台适配做了大量优化其中比较重要的一项就是原生支持OpenHarmony。OpenHarmony是一个开源的、面向全场景的操作系统不仅跑在手机上还可以跑在平板、电视、车机、IoT设备上。把团结引擎接上OpenHarmony意味着游戏或者3D应用可以直接打包成HAP格式OpenHarmony的应用安装包运行在开源鸿蒙生态的各种设备上不需要额外套壳或者走WebView。对于做内容开发、又想在鸿蒙生态里落地的团队来说这是一条比较顺的路径。这篇记录适合谁看呢适合两种人。一种是团队里接到了“把现有Unity项目适配到OpenHarmony”任务的开发者你可能已经有Unity基础但对OpenHarmony的工程结构、打包流程不熟。另一种是打算从零开始用团结引擎做鸿蒙原生应用的开发者想提前知道这条路有哪些坑、需要准备什么。我默认你有基本的Unity使用经验对OpenHarmony只需要了解基础概念就行。1. 整体适配思路与方案选型1.1 核心需求什么项目适合走团结引擎OpenHarmony先聊一个可能困扰很多人的问题到底什么情况下值得把项目往OpenHarmony上搬我的判断标准很简单看你的目标设备跑的是什么系统。如果你的应用要发布到开源鸿蒙生态的设备上包括搭载OpenHarmony的开发板、教育平板、行业终端甚至是未来可能出现的各种鸿蒙设备那原生适配就是绕不开的。另一种情况是公司有信创或者国产化适配的需求需要把现有内容迁移到国产操作系统上跑团结引擎OpenHarmony就是一条相对成熟的技术路线。那什么样的项目不适合呢如果你的目标平台只是Android和iOS那目前完全没必要引入OpenHarmony这条链路团结引擎虽然能导出OpenHarmony工程但多一条打包链路就多一份维护成本工具链的成熟度也不如Android。还有如果你的项目重度依赖Google Play服务、GMS这些OpenHarmony上没有的底层能力迁移成本会很高需要先做能力盘点再决定。1.2 方案对比原生开发、Web方案还是游戏引擎接到需求之后我第一件事是在原生开发和引擎方案之间做对比这个选择直接影响后面几个月的开发节奏。原生开发的意思是用OpenHarmony自家的ArkTS语言加ArkUI框架写应用界面再配合Native C做底层逻辑。这套方案的优势是系统API调用最直接、包体最小、性能上限最高但缺点也很明显不适合做3D渲染密集型的内容。如果你要交付的是一个带场景漫游、粒子特效、物理模拟的3D应用纯用ArkTS写渲染逻辑基本不现实工作量会爆炸。Web方案比如H5套壳、小程序容器上得快但性能天花板低复杂的3D场景在低端设备上会卡得很难受而且很多系统能力比如传感器、剪贴板、文件系统要通过桥接层才能拿到调试起来挺麻烦。游戏引擎方案也就是团结引擎这条路线等于用引擎帮你把渲染、物理、动画、资源管理这些底层全做了你只需要把注意力放在业务逻辑和内容创作上。团结引擎针对OpenHarmony做了专门的导出和运行时适配输出的是真正跑在系统上的原生应用不是Web套壳。我自己选这条路线核心就是看中它对3D内容的高效支持和相对完整的工具链。1.3 团结引擎版本与OpenHarmony版本的匹配关系这里有一个很容易被忽略的点团结引擎的版本和OpenHarmony的SDK版本是绑定的关系不是随便拿一个版本就能编过。我实测下来的组合是团结引擎1.0.X系列搭配OpenHarmony SDK 9或者10效果比较稳。团结引擎官方在发布说明里会标注对应的OpenHarmony API Level你要严格按照这个对应关系来装SDK。版本不匹配的典型症状是编译时报一堆莫名其妙的链接错误或者运行时直接崩溃在引擎初始化阶段。我第一次踩这个坑的时候换了三个SDK版本才搞清楚是版本对应关系的问题。建议你在开始之前先去团结引擎官网看一下当前版本的Release Notes确认它支持的OpenHarmony SDK版本再结合你目标设备的系统版本OpenHarmony 3.2对应API 94.0对应API 10做选择。开发调试阶段我建议用API 9或者10的较新小版本兼容性和稳定性都更好。2. 环境准备与工具链搭建2.1 开发工具全家桶清单工欲善其事必先利其器。这套开发链路涉及的工具比较多我列一个清单每一项都是必须的少一个就可能卡在某个环节。团结引擎Unity中国版必须装支持OpenHarmony导出的版本不是所有团结引擎版本都带OpenHarmony模块装的时候要确认勾选了OpenHarmony相关组件。DevEco StudioOpenHarmony的官方IDE主要用来打开导出的OpenHarmony工程做编译、签名和安装。我用的是DevEco Studio 3.1及以上版本对应API 9/10都支持。OpenHarmony SDK在DevEco Studio里通过SDK Manager下载包括API 9和API 10的SDK。Native编译器工具链在OpenHarmony工程里编译C代码需要用到DevEco Studio一般会带但如果遇到NDK版本问题需要手动配置。hdc命令行工具OpenHarmony的设备连接调试工具类似ADB在DevEco Studio的SDK目录里能找到。装应用、看日志全靠它。一台OpenHarmony真机或者x86模拟器调试必备模拟器虽然方便但很多渲染相关的问题必须真机才能复现。2.2 SDK、NDK与编译环境配置细节环境配置是整个流程里最容易出问题的地方尤其是SDK路径和NDK版本。打开DevEco Studio的SDK Manager你会看到OpenHarmony SDK有几个组成部分API版本对应的platform、toolchain、还有native SDK。native SDK里包含了交叉编译需要的sysroot和编译器团结引擎导出的工程在编译C部分时会自动调用这套工具链。如果SDK路径配置不对典型错误是找不到arm-linux-musleabi相关的编译器解决办法是在DevEco Studio的SDK管理里确认native SDK已经安装并且在工程的local.properties里正确指定hwsdk.dir路径。NDK版本方面我用的是随OpenHarmony SDK自带的Native工具链尽量不要自己去装Android NDK来替代两套工具链的ABI和系统库不一样。如果你在编译时看到类似“cannot find -lclang_rt.builtins-aarch64”这类错误基本就是SDK没有完整下载让它重新下载一次就好。还有一点是环境变量。在命令行里用hdc和编译脚本时建议把DevEco Studio的toolchain目录加到PATH里省得到处找命令。我是把/opt/DevEco-Studio/tools/ohpm/bin和/opt/DevEco-Studio/sdk/default/openharmony/toolchains都加进去了命令行操作会顺手很多。2.3 x86模拟器与真机调试的差异调试OpenHarmony应用绕不开设备选择。先说x86模拟器在开发早期它的价值很大因为可以快速验证逻辑、调UI启动速度和日志查看都比真机方便。但模拟器有一个明显的坑很多图形渲染的问题在模拟器上是复现不了的或者表现和真机完全不一样。我遇到过一个典型的例子某个Shader在x86模拟器上显示正常颜色、光照都对但一到ARM真机上就出现画面撕裂和闪烁。原因是模拟器走的是宿主机的GPU虚拟化路径对图形API的容错性比真机高很多一些不规范的渲染调用被模拟器“容忍”了真机上却被底层严格校验出来。所以我的建议是逻辑和UI调试用x86模拟器渲染效果、性能测试、内存占用评估一律用真机。这也是为什么我在前面强调一定要准备一台真机。不过模拟器也不是完全没用在CI流水线里做自动化构建和冒烟测试还是很合适的。我的习惯是代码逻辑改动后用模拟器快速冒烟涉及渲染和性能的改动立刻上真机验证这样能把问题尽量前置。3. 打包OpenHarmony工程的关键配置3.1 从团结引擎导出到DevEco Studio的完整流程这一节是整个流程的核心动作我尽量把步骤讲细。首先在团结引擎里用File - Build Settings打开构建面板在Platform列表里选择OpenHarmony。如果看不到这个平台选项基本可以确定你装的团结引擎版本不对或者安装时没有勾选OpenHarmony模块。选好平台之后点击Switch Platform引擎会做一次资源导入和平台相关的编译。接下来是Player Settings这一块直接影响导出工程的属性。有几个关键项包名Package Name必须是反向域名格式比如com.company.gameMinimum API Level要和你目标设备的系统版本匹配Target API Level同理Orientation按需设置。我建议在导出之前把Project Settings里的公司名Company Name和产品名Product Name也设置好这些会直接写入到OpenHarmony工程的bundle信息里。都设置好之后在Build Settings里点击Build选择一个导出目录。引擎会在这个目录下生成一个完整的OpenHarmony工程里面有entry模块、build-profile.json5、oh-package.json5这些文件。然后打开DevEco Studio用Open Project选择这个目录就可以加载工程了。第一次加载会自动同步依赖和构建可能比较慢耐心等。加载完成之后先不要急着直接跑。建议先在DevEco Studio的File - Project Structure里确认Signing Configs的配置然后连接设备点击Run按钮DevEco Studio会自动完成编译、签名、安装HAP的流程。3.2 HAP签名、包名和权限配置的避坑指南签名这块是很多新手会卡住的地方。OpenHarmony的应用必须经过签名才能安装到设备上不同于Android调试用的debug签名OpenHarmony需要你在DevEco Studio里配置签名信息。实际配置分为两步。第一步是在Project Structure - Signing Configs里勾选Automatically generate signature如果登录了华为开发者账号IDE会自动生成签名文件.p12和.cer。如果你没有企业签名证书用自动生成的调试证书在开发阶段就够了。第二步是在工程的build-profile.json5里确认signingConfigs的引用是否正确有时候同步工程之后这个配置会丢失需要手动重新选择。权限配置很容易被忽略。OpenHarmony的权限声明不是写在AndroidManifest里而是写在entry/src/main/module.json5文件的requestPermissions字段里。如果你的应用需要联网、访问存储、使用相机这些能力必须在这里显式声明。我在第一次打包一个需要联网的项目时明明Unity里设置了Internet权限但OpenHarmony工程里没加结果真机上网络请求一直失败排查了很久才找到是module.json5的问题。包名一致性也是个大坑。团结引擎里设置的包名会作为OpenHarmony应用的bundleName但注意OpenHarmony对bundleName的格式要求更严格必须是小写字母、数字、点和下划线不能有大写字母。Unity项目的Application Identifier如果包含大写导出时会在编译阶段报错解决办法是提前把包名改成全小写。3.3 IL2CPP与Mono的选择以及渲染后端配置这是运行性能和兼容性的分水岭。团结引擎在导出OpenHarmony工程时Scripting Backend可以选择IL2CPP或者Mono实测IL2CPP是更稳的选择。原因有两方面一是IL2CPP在编译期把C#转成C再编译成原生机器码运行时没有JIT和AOT解释开销性能更好二是OpenHarmony对JIT的限制比较多Mono这种依赖即时编译的方案在某些系统版本上可能被限制导致运行异常。代价是IL2CPP的编译时间明显变长第一次构建可能要多等好几分钟但为了稳定性和性能值得。Graphics API这一项决定了引擎用什么底层接口去和GPU打交道。团结引擎在OpenHarmony上支持OpenGL ES和Vulkan两条路径。我建议开发期先用OpenGL ES它的兼容性最广在模拟器和各种真机上都能正常运行很少出莫名其妙的问题。上线或者做性能调优阶段再切换到Vulkan。Vulkan的底层控制力更强Draw Call开销更低某些场景下帧率有显著提升但它对Shader的兼容性要求更高不是所有自定义Shader都能直接跑在Vulkan后端。具体渲染这块的细节我在下一节展开说。还有一个Color Space设置建议用Linear能让光照计算更准确画面更真实。但Linear会导致Shader里的颜色处理逻辑发生变化有些在Gamma空间写死的Shader会出现偏色这个要测试阶段重点验证。4. 渲染异常排查与图形适配4.1 画面渲染异常的表现与成因分析“openharmony画面渲染异常”这个话题在开发者社区里讨论得很多我自己的项目也遇到过好几次这里把典型的表现和排查方向整理一下。最常见的异常有三类。第一类是“黑屏但UI正常”。这种通常是相机渲染目标出了问题比如相机的Target Texture在平台切换后引用丢失或者某个Shader在目标GPU上编译失败导致相机渲染结果全黑。排查方法是先用Frame Debugger逐帧查看Draw Call看是哪个物体的渲染没通过。我之前遇到过一次黑屏最后定位到是一个后处理特效Shader在OpenGL ES 3.2下语法不兼容编译失败后引擎直接跳过了整条后处理链。第二类是“画面闪烁、撕裂、错位”。这类问题大多是渲染时序和交换链SwapChain设置不对。OpenHarmony设备和Android一样有垂直同步和缓冲区轮换的机制如果Unity的质量设置里关掉了VSync或者选择了不支持的缓冲模式画面就可能出现撕裂。解决方法是把Quality Settings里的VSync Count设置为Every V Blank保证每帧同步一次。如果问题还在检查一下是否在代码里手动调用了Screen.SetResolution频繁改变分辨率会干扰交换链的稳定性。第三类是“偏色、泛白、曝光异常”。这个基本是色彩空间和纹理格式的锅。Unity项目如果默认用Linear色彩空间导出的Shader在采样纹理时做了sRGB解码而OpenHarmony的某些环境对sRGB纹理的支持不够完善就会出现泛白。解决方案是把纹理资源在导入设置里勾选sRGB选项并且确保Shader里用了正确的Unity内置函数来处理颜色。另一个常见原因是纹理压缩格式不被真机支持我在下面专门说。4.2 Shader与纹理压缩格式的适配要点这是渲染适配里最磨人的部分。OpenHarmony设备和Android的GPU生态接近主流GPU是ARM Mali和Qualcomm Adreno系列理论上支持ETC2和ASTC纹理压缩。但不同设备和不同系统版本对纹理格式的支持仍有差异尤其是部分低端设备或者模拟器可能只支持ETC2不支持ASTC。实际项目中我建议纹理格式以ASTC为主ETC2做兜底。在Unity的Texture Import Settings里Android平台的Format选择ASTC同时勾选Override for OpenHarmony如果没有Override for OpenHarmony选项就在Android的分支下设置因为团结引擎导出OpenHarmony时默认复用Android平台的纹理设置。然后确保在Player Settings的Texture Compression Format里选择了ASTC。如果项目里某些纹理是从外部下载的运行时要用Texture2D.LoadImage加载这种动态加载的纹理默认是RGBA32未压缩格式在低端设备上容易吃满内存尽量加载前自己转一次压缩格式。Shader的兼容性是另一个大坑。OpenHarmony的OpenGL ES实现跟Android的OpenGL ES基本一致但有些高级特性比如Shader Model 5.0级别的功能不一定完整支持。如果你的Shader用了比较高阶的语法比如StructuredBuffer、RWTexture、几何着色器在OpenHarmony上大概率会编译失败。我的经验是宁可Shader写得“土”一点也要保证在移动端GPU上能稳定编译。用Unity内置的Standard Shader在OpenHarmony上通常没问题但在URP管线里要额外验证URP的Shader是否全部兼容。我自己的项目里用了一部分URP的特性实测在Mali GPU上有几个特效Shader会报错后来是用Shader变体的方式做了降级处理才在真机上跑通。4.3 Vulkan与OpenGL ES切换的实测数据与选择建议渲染后端的选择直接影响性能和兼容性这个值得单独写一段。我在同一台OpenHarmony真机上用同一个场景分别测试了OpenGL ES和Vulkan后端场景里大概有50万三角面、120个Draw Call、8个实时光源。OpenGL ES的帧率稳定在40帧左右Vulkan则能跑到50帧以上提升幅度接近30%。在Draw Call密集的场景里Vulkan的优势会更明显因为Vulkan的底层API架构允许引擎更高效地提交渲染命令减少CPU侧的调用开销。但Vulkan不是没有代价。切换到Vulkan之后两次出现比较棘手的问题。一次是部分粒子Shader出现颜色不正原因是粒子系统里的某些渐变材质用了Gamma空间的颜色计算在Vulkan的线性色彩空间下颜色产生偏移。另一次是屏幕后处理特效在Vulkan下出现边缘锯齿和网格状瑕疵后来确认是PBR材质里一个自定义Shader对UV的计算在Vulkan下精度不够修改了采样方式才解决。这些问题在OpenGL ES后端下都不会出现因为引擎对OpenGL ES的兼容做得更成熟。我的建议是如果项目里有大量自研Shader和复杂特效开发期用OpenGL ES保证基础稳定等主要功能全部验证完毕再切换到Vulkan做性能优化并且针对Vulkan下的显示效果做一次全面回归测试。不要一上来就用Vulkan不然你分不清问题是出在业务逻辑还是渲染后端上。5. 性能调优与常见问题速查5.1 帧率、内存与启动时间的调优实践先把结论放前面团结引擎导出的OpenHarmony应用在调优之后可以达到Android同项目的八到九成性能启动时间能控制在一秒五左右这个数据在适配初期我是没预料到的但确实做到了。帧率优化方面最大的瓶颈在Shader复杂度和OverDraw。OpenHarmony设备通常没有iOS设备那么强的GPUShader的ALU压力要严格控制。我做过一次激进的优化把所有PBR材质的采样次数从4层降到2层并把实时光源的像素计算改为仅对最近的两个光源做完整计算其余的降级为顶点光照结果帧率提升了15%。所以不要只盯着画质看OpenHarmony目标设备很可能是中低端GPU。内存占用方面动态合批和纹理压缩是两块大头。把场景里的静态物体全部标记为Static让引擎做静态合批能显著减少Draw Call也降低每帧的内存分配压力。纹理方面上文说了用ASTC一个2048x2048的RGBA纹理从16MB直接降到2MB左右实际内存占用对包体和运行时都非常友好。启动时间的优化核心是减少启动场景的加载量。我建议把启动场景里的加载任务尽量后置先加载UI壳再异步加载3D资源。另外关闭不必要的引擎模块也能减少启动时间。在Player Settings里一般不用的模块比如Multiplayer、Physics里的某些子模块可以关掉实测能减少300ms左右的启动耗时。还有一个容易忽略的点是IL2CPP的代码裁剪在Build Settings里勾选Managed Stripping Level为Low以上可以显著减小包体也能加快启动时的代码加载。5.2 常见编译与运行问题排查速查表这里把我在实际开发中遇到的高频问题整理成一张表方便大家对照排查。这张表里的每一个问题都是我在不同设备、不同版本上亲眼见过的不是纸面推测。问题现象可能原因解决办法编译时报找不到Native编译器OpenHarmony SDK的Native组件未安装DevEco Studio SDK Manager中安装Native SDK并确认local.properties路径正确安装HAP时报签名错误签名配置缺失或证书过期Project Structure里重新自动生成签名或导入合法证书运行时黑屏UI正常某个Shader编译失败或后处理链异常用Frame Debugger定位失败物体简化Shader切换GLES后端验证画面闪烁或撕裂VSync设置不当Quality Settings中设置VSync为Every V Blank画面偏色或泛白线性色彩空间与纹理sRGB标记不匹配纹理导入设置里勾选sRGB检查Shader颜色计算网络请求失败module.json5未声明网络权限在requestPermissions字段添加ohos.permission.INTERNETx86模拟器正常真机渲染错乱渲染调用不规范模拟器容错高以真机渲染表现为准排查Shader绑定与Buffer同步IL2CPP编译时间过长工程大、增量缓存失效构建机上保留Library缓存目录避免频繁清缓存5.3 真机与模拟器测试的合理分工测试策略看起来是个管理问题但在实际开发和问题排查里它直接影响效率。我现在的固定流程是这样的日常功能和UI改动在x86模拟器上先验证一轮主要是快启动和日志都省时间。改动涉及渲染、Shader、大片内存分配时立刻提交到真机验证不等模拟器结果。真机测试我准备了两种中端ARM设备一台用于性能评估低端或兼容性设备一台用于画质和稳定性验证。有条件的团队建议至少备两真一模拟。还有一个建议是在CI流程里加上“模拟器冒烟真机定时构建”的组合。模拟器冒烟保证代码基本闸门真机定时构建每天凌晨跑一次保证渲染和性能不回归。我在实际项目里这样配置之后渲染问题被发现的平均时间从三天缩短到了半天这个提升非常可观。6. 延伸团结引擎打包微信小游戏时WebGL模板配置6.1 为什么这个话题会和OpenHarmony适配放在一起看到这节你可能有点奇怪标题不是团结引擎OpenHarmony吗怎么扯到微信小游戏了。其实这两件事在实践里高度相关。团结引擎的目标之一是“一次开发多端发布”OpenHarmony是其中一个原生出口微信小游戏则是另一个高频出口。很多团队在调研团结引擎能力的时候会同时评估OpenHarmony和小游戏这两条路线而这两条路线的渲染底层都涉及WebGL所以在配置上有不少可以相互借鉴的地方。更重要的一点是微信小游戏的WebGL模板配置过程中遇到的问题和OpenHarmony的渲染适配有相似性。两者的图形栈都是基于OpenGL族API都要求开发者对Shader和纹理格式有比较好的掌控而且两者的调试工具链都不如传统iOS/Android成熟。所以把微信小游戏的WebGL模板配置经验总结出来对做OpenHarmony适配的团队同样有参考价值。6.2 正确配置WebGL模板的步骤细节如果你用团结引擎打包微信小游戏WebGL模板很多时候决定了一个游戏能不能正常跑起来。默认模板能跑但坑不少而且这些坑大多是文档里不写的。首先在Project Settings - Player - Publishing Settings里找到WebGL Template不要直接选默认模板选Memory Growth模板或者创建自定义模板。内存增长模式在移动端小游戏里很重要因为微信小游戏运行环境的内存上限比较动态如果模板锁死了一个固定内存游戏在低内存设备上会直接崩溃。模板的index.html里有几个关键项要改。一个是UnityLoader的初始化参数要设置webglContextAttributes的preserveDrawingBuffer为true否则WebGL画布在部分Android真机上会出现画面残留和闪烁。另一个是devicePixelRatio的处理微信小游戏的屏幕适配很敏感建议在模板里加上根据设备DPI动态调整canvas尺寸的逻辑否则在部分高分屏上字号和UI缩放会乱。还有加载进度条。小游戏对首包大小很敏感而模板里的Logo和加载动画会增加首包体积。我建议把启动画面和加载动画做成轻量级的资源走远程CDN加载本地只保留最核心的引擎loader。实测这样配置之后小游戏首包从3.5MB降到1.2MB冷启动时间缩短了30%以上。6.3 WebGL模板与OpenHarmony渲染适配的关联点回到OpenHarmony的话题上来。团结引擎的OpenHarmony导出虽然不走WebGL但很多底层的图形问题的排查思路是相通的。比如帧率低你可能第一反应是换更好的设备但我在两个平台上的排查经验都告诉我先看Draw Call和Shader复杂度这两项在任何图形API下都是性能的命门。又比如gles下只能跑OpenGL ES 2.0的低端设备和微信小游戏iOS端强制只用WebGL 1.0的场景很像。在这两种受限环境下你的Shader都必须写得更保守功能更强的版本要通过宏定义做渐进增强而不是做功能降级。我现在做项目都会主动在每种目标平台上检查一遍Shader的Feature Level提前把GLES 3.0能跑高配、GLES 2.0只能跑低配的逻辑写在同一个材质里。所以在团队评估多端发布时我的建议是让做OpenHarmony适配的同学和做小游戏的同学结对评审两份配置和两套坑互相看一遍往往能提前发现很多跨平台的共性问题。这比各自闷头解决效率高得多。7. 写在最后一些个人心得和后续更新计划这套适配方案我前后做了快两个月最深的体会是团结引擎OpenHarmony这条路是真实可行的但别指望零成本迁移。工具链成熟度、社区资料丰富度都不如Android/iOS生态遇到问题难过的时候要有自己翻源码和试错的心理准备。我建议接手这类任务的同学第一周不要急着写业务代码先把环境、打包、真机调试这条链路完整跑通所有的坑都在这个阶段踩一遍后面会省很多事。继续记录这条路目前还有几个方向是我在持续跟进、后续会更新到这篇记录里的一是同一套项目资源在OpenHarmony和Android平台的表情包体与首帧耗时对比二是一些中低端OpenHarmony设备上的FPS与内存稳定性测试三是团结引擎在OpenHarmony上的URP管线兼容性验证这块刚跑通基础渲染但后处理和自定义Pass还有不少边界情况没理清楚。如果你也在搞这套方案欢迎在评论区把你的设备型号和遇到的问题发出来大家一起把坑填平。