OpenHarmony硬件调试三板斧：日志、调试器与硬件工具实战

硬件调试三板斧说白了就是我在OpenHarmony系统开发实战中最常用的三套手段日志、调试器、硬件工具。搞过嵌入式或者操作系统开发的朋友应该都有感受在系统级开发里硬件调试跟普通应用调试完全不是一个难度等级。你面对的不只是逻辑错误还有可能是启动时序问题、内存访问异常、外设通信不稳定、电源纹波过大导致的偶发抖动……这些问题光靠看代码是看不出来的必须有一套系统的调试方法。这套“硬件调试三板斧”是我在实际开发OpenHarmony过程中整理出来的方法论。第一板斧是日志系统用来快速定位软件层面的逻辑错误第二板斧是调试器用来深入分析崩溃、死锁、异常跳转这些日志看不出来的问题第三板斧是硬件工具——示波器、逻辑分析仪、万用表——用来验证时序、电平、通信协议这些物理层信号。本文基于OpenHarmony系统实战开发场景面向三种读者刚入门OpenHarmony开发、手里有开发板却不知道怎么调试的新手已经能跑通demo但遇到疑难bug无法定位的中级开发者以及准备在x86电脑上跑OpenHarmony、需要掌握系统级调试技巧的进阶玩家。无论你是哪种这套方法论都能帮你省下大量排查时间。1. 内容整体设计与思路拆解1.1 为什么硬件调试比应用调试难这么多先聊一个很实际的问题同样是写代码为什么在PC上写个Java程序出bug顶多就是加个System.out.println、打几个断点的事而在OpenHarmony这种系统级开发里调试成本却高出一个数量级原因有三层。第一OpenHarmony是面向全场景的分布式操作系统代码栈深。从Bootloader到内核再到系统服务最后到应用层的Ability每一层都可能出问题而问题往往不局限在某一层。举个例子你写一个分布式软总线相关的应用数据传不过去可能是应用层参数传错了也可能是内核协议栈的缓冲区设置问题还可能是Wi-Fi驱动的DMA描述符没配对光靠应用层的日志根本看不到全貌。第二硬件调试涉及并发和时序问题。操作系统的运行是高度并发的而并发问题有个恐怖的特性——bug的复现概率和触发条件强相关。同一个崩溃可能跟中断抢占时序有关跟Cache一致性有关跟DMA搬运数据的时机有关。这种问题是日志很难打出来的因为一旦你加了日志去观测系统的时序就变了bug可能就不再出现——这就是著名的“观察者效应”在系统级调试中的体现。第三软硬件的耦合度高。系统跑在真实硬件上信号完整性、电源质量、时钟稳定性都会影响系统行为。有时候代码逻辑完全正确但就是跑不稳定这时候你就得从物理层面去查会不会是某个引脚在高速翻转时产生了串扰会不会是电源在SoC满负荷运行时跌落超过了阈值这些问题必须靠硬件调试工具来解决。所以我一直跟团队里的人说会写OpenHarmony代码只是一个起点真正拉开差距的是调试能力——如何在最短时间内定位到问题的根因。1.2 调试三板斧的定位与选择逻辑我总结的“三板斧”对应的是一条完整的调试链路先看日志定位方向再用调试器深挖细节最后用硬件工具验证物理层。第一板斧是日志它解决的是“大概在哪”的问题。OpenHarmony的HiLog日志框架提供了从内核到应用的全链路日志输出能力通过日志可以快速判断系统启动到了哪个阶段、某个功能是否被调用、报错信息是什么。日志调试的优势是侵入性小、信息量大、对时序影响相对可控当然也有影响适合作为第一排查手段。第二板斧是调试器它解决的是“具体怎么执行”的问题。通过JTAG/SWD调试器连接开发板可以做到断点暂停、单步执行、读写寄存器、查看内存、回溯调用栈。当日志显示某个线程崩溃了但信息不足时调试器可以把当时的现场完整还原出来看看程序到底执行到了哪条指令、寄存器值是什么、栈上有什么数据。第三板斧是硬件工具它解决的是“信号到底对不对”的问题。示波器看电平与时序逻辑分析仪看数字信号协议万用表测电压通断。这一板斧负责兜底——当软件层面看起来一切正常但系统就是不稳定时硬件层往往是最后真相。这三者的关系不是替代而是互补。我见过不少开发者上来就掏示波器一顿猛测结果测了半天发现是软件配置错了也见过只打日志不看硬件的最后被一个硬件虚焊折磨了一周。正确做法是自顶向下先用日志缩小范围再用调试器或者硬件工具精准定位。2. 核心细节解析与实操要点2.1 第一板斧OpenHarmony日志系统实战日志调试是OpenHarmony开发中最基础、也是最高频使用的调试手段。OpenHarmony的日志体系有三层内核层的dmesg、系统层的HiLog、应用层的hilog命令输出。先说内核日志。当你的系统在启动阶段就挂了比如卡在Logo界面、内核panic、文件系统挂载失败这时候第一件事就是抓内核日志。使用串口终端或者HDMI接显示器在启动过程中观察内核打印信息。内核日志有固定的格式形如[ 0.123456] module_name: log message其中方括号里是系统启动后经过的秒数module_name是打印日志的模块名后面是具体信息。定位启动问题时要重点关注几个关键节点Bootloader运行阶段、内核解压阶段、设备驱动初始化阶段、根文件系统挂载阶段、init进程启动阶段。每个阶段都有标志性的日志输出如果日志在某一个节点戛然而止问题基本就锁定在那个模块了。系统层的HiLog是OpenHarmony特色日志框架它的接口非常丰富。在C/C代码中可以使用HiLogPrint或配套的宏接口在ArkTS代码中则可以调用hilog相关的JS接口。我在实际项目中使用HiLog的感受是它的日志级别设计得很合理DEBUG用于开发调试、INFO用于记录关键流程、WARN用于标示异常但可恢复的情况、ERROR用于严重错误。我建议团队在执行关键路径时把日志级别提到INFO以上这样即使线上环境不开DEBUG日志也能看到核心链路。日志的过滤功能是我比较喜欢的地方。在开发板上执行hilog命令可以按域、标签、级别过滤日志。比如有一条日志是用OHOS::HiviewDFX::HiLog::Label定义的标签你在命令行就能用hilog -e 指令做正则匹配在海量日志中精确挑出目标模块的打印信息。这套体系比Linux内核传统的printk要高效不少定位问题时能把搜索范围大幅缩小。还有一个实用技巧把日志输出到文件里。OpenHarmony的hilog支持持久化存储把hilogd的配置打开之后系统会把日志写入到指定分区文件中这样即使在出问题后系统挂掉你也可以用另一个备用系统进去把日志取出来分析或者在重启后读取落盘日志复盘现场。我在实际调试中遇到过一次非常典型的日志定位案例。现象是运行OpenHarmony的Hi3516开发板在启动到桌面阶段偶发黑屏重启几次就能复现一次。从串口观察日志发现系统在启动WindowManager服务时偶尔会出现gralloc buffer分配失败的ERROR日志而且伴随dmabuf内存泄漏的WARN信息。顺着日志追到代码层发现是某个GPU渲染线程在异常分支提前return没有回收已经申请的Buffer。这个问题如果不用日志先定位到模块和函数光靠看代码几乎不可能找到——因为黑屏这个表象跟根因之间隔着好几个层次。实操给新手的建议拿到一块新的OpenHarmony开发板第一步不是跑demo而是把串口线接好确认串口日志能稳定输出。我每次拿到新板卡都会先烧录标准系统镜像、验证串口连通、跑一遍完整的启动流程把启动日志完整保存一份作为基线。以后任何改动只要对比启动日志就能快速发现哪个模块的行为变了。2.2 第二板斧调试器深入分析日志能定位问题的范围但真正要深入分析Crash、死锁、内存踩踏这类问题就必须靠调试器了。OpenHarmony支持两种主要的调试方式内核层面的GDB调试、以及硬件层面的JTAG/SWD调试。前者通过GDB stub配合串口或者网络连接可以调试内核代码后者则通过调试器硬件比如J-Link、DAP-Link连接开发板的调试接口对SoC内部的CPU核心进行完整的调试控制。我在这里重点推荐使用JTAG/SWD调试器尤其是当你在开发Linux内核驱动或者OpenHarmony的系统服务时这套工具能让你彻底看清CPU的执行路径。以我常用的J-Link搭配Hi3516开发板为例使用方式如下先确认开发板上有JTAG接口一般是标准的20针或者10针排针把J-Link的连接线按照引脚定义接好SWD接口则只需要SWDIO、SWCLK、GND、VCC四根线。在电脑上启动GDB Server然后配置好Coredump文件和符号表。调试流程的关键在于符号表匹配。你在编译OpenHarmony的时候需要保留带有调试信息的ELF文件而不是烧录之前经过strip处理的版本。我在实战中踩过一个大坑编译时开了strip结果调试器连接上之后反汇编看到的全是地址没有函数名根本没法定位。后来我强制在编译脚本中保留符号通过GDB的“list”和“info functions”命令就能准确看到当前执行到哪个函数。当时看到调用栈的瞬间问题原因其实已经很清楚了。断点的使用也有一些心得。在内核态调试时不要随意下断点有些关键路径比如中断处理、调度器、锁相关的代码被断点打断后系统行为会发生剧烈改变极容易出现假象。我在调试一个偶发死锁问题时遇到过一个非常典型的假象在下断点观察线程状态发现两个线程互相等待——看起来是死锁但去掉断点继续跑问题却不再出现。反反复复试了很多次才发现是断点导致的中断延迟改变了锁的获取时序让一个原本不会发生的路径被激活了。所以调试过程要尽量多做“无痕观测”用“暂停-查看-继续”的交互方式避免在热点路径上长时间停留。另一个调试器的高价值用法是查看调用栈和寄存器现场。当系统发生panic时把崩溃现场的PC值、LR值提取出来再配合反汇编和符号表能非常精确地知道程序执行到了哪一条指令。比如一次经典的非法内存访问崩溃panic日志显示PC在某个地址用GDB执行“disassemble”反汇编后发现指令是str r3, [r5]这样的写操作再看r5寄存器值是0xdeadbeef马上就能判断出是某个野指针被解引用。再往上回溯LR寄存器调用栈就出来了——整个过程比单纯看日志高效得多。额外补充一点x86平台上运行OpenHarmony的调试。“电脑版x86 OpenHarmony”是很多开发者的关注点。在x86电脑上调试OpenHarmony你会发现JTAG这种硬件调试方式不太适用因为你面对的是一个PC主机。我的经验是使用QEMU虚拟机的GDB调试接口在启动QEMU时加上“-S -s”参数然后在GDB里通过“target remote localhost:1234”建立连接就可以像调试普通Linux内核一样调试x86版OpenHarmony。这个方案用在代码逻辑调试上完全够用而且因为QEMU的运行环境是确定性的比真实硬件还更容易复现bug。2.3 第三板斧硬件工具在现场的关键作用到了第三板斧就该动硬件了。很多纯软件背景的开发者对示波器、逻辑分析仪有畏难情绪觉得这是硬件工程师的事。我在实际调试中体会到系统级开发和纯应用开发最大的区别就在于——你必须对物理信号有感知否则很多问题你会误判为软件bug花大把时间改代码却毫无效果。先把三件工具的角色分清楚万用表解决的是“有没有”的问题。测电压是否正常、地线是否连通、电阻值是否符合预期。系统上电前先用万用表测量电源轨的对地阻抗——这一步能帮你避免烧板子的惨剧。我有一次拿到一块新做的底板直接上电才发现3.3V和GND短路当时那个心情……从那以后我每次拿到新板子第一件事就是打阻值。这个习惯后来帮我拦住过至少三次会烧板子的低级错误。示波器解决的是“长什么样”的问题。看波形形状、幅度、上升沿、频率、时序关系。系统调试中最常用的场景有三个第一个是电源时序验证。SoC的启动对电源时序有严格的要求不能同时上电必须按规定的延迟顺序依次拉高各路电源轨。如果电源时序不对SoC可能会进入异常状态表现为无法启动或启动后随机死机。用四通道示波器同时抓取各路电源轨的上电时序和SoC手册里的时序要求对比基本一眼就能看出问题在哪。第二个是时钟信号检查。OpenHarmony对系统时钟精度是有要求的——Wi-Fi、蓝牙、以太网、USB这些外设都需要精确的时钟源。如果晶振频率偏了网络通信就会不稳定。示波器看时钟波形用频率测量功能直接读数值和标称频率做对比偏差超过一定范围基本就能锁定是晶振选型或电路设计的问题。第三个是通信波形分析。比如调试I2C设备时系统日志显示I2C通信异常到底是总线被拉死、地址不对还是速率过高等问题用示波器抓SCL和SDA两路波形一看便知。此时要注意设置好触发电平否则波形触发不稳定抓到的数据很难看。我在调一个sensor驱动时SDA线上总是多出一个毛刺导致偶尔读到错误数据就是用示波器的单次触发模式抓到了那根毛刺的波形最后定位到是上拉电阻没焊好。逻辑分析仪解决的是“序列对不对”的问题。当你要分析UART、SPI、SDIO这类数字协议的数据内容时示波器的通道数往往不够用而且手动解码协议耗时耗力。逻辑分析仪的16通道起步配置能同时观察多路信号配合协议解码功能直接就能把SPI的MOSI、MISO、CS、CLK四根线的数据同步解出来。我常跟人说逻辑分析仪是你“眼睛的延伸”——它让那些以极高速度运行的数字信号变成了肉眼可读的时序图与数据流。在OpenHarmony的Wi-Fi模组调试中我遇到过一次只有硬件工具才能破案的僵局设备连接Wi-Fi后丢包率高达30%软件日志检查了协议栈、驱动配置、天线功率参数都正常。当时我还怀疑是RF匹配电路的问题最后是逻辑分析仪抓取Wi-Fi芯片和主控之间的SDIO总线信号发现偶尔会出现CRC错误标志位。顺着SDIO的电气特性查才发现是板子上SDIO信号线跨分割走过的参考平面不连续引起信号质量问题。换层走线后丢包率直接降到0.1%以内。这个案例让我彻底意识到系统级开发需要同时驾驭软件和硬件两种语言。3. 实操过程与核心环节实现3.1 从零开始搭建OpenHarmony调试环境以Hi3516DV300开发板为例我详细拆解一套完整的调试环境搭建过程。熟悉这套流程之后你可以把它迁移到润和、DAYU等不同厂家的开发板上思路完全一致。第一步准备硬件。开发板、电源适配器注意核对电压电流要求、串口转USB调试线、J-Link或DAP-Link调试器、若干杜邦线、以及一个靠谱的示波器或逻辑分析仪——预算有限时可以先买一个USB逻辑分析仪价格不高但解协议非常实用。第二步搭建串口调试。OpenHarmony的调试信息通常从UART0输出。把串口模块的TX接到板子的RX串口的RX接到板子的TXGND互联。用MobaXterm或minicom连接串口波特率设置为115200标准镜像默认。开电后应能看到完整的启动日志。如果看不到日志大概率是TX/RX接反了对调一下就行。第三步烧录系统镜像。OpenHarmony的烧录方式和Android有些类似通过fastboot或者专用的烧录工具将镜像写入开发板存储。在Hi3516上我习惯先进入fastboot模式然后用fastboot flash命令依次烧录bootloader、kernel、ramdisk和系统分区。烧录完成后重启第一次启动会比正常启动慢一些因为系统要做分区的初始化。第四步配置HiLog日志环境。在系统启动完成后进入shell执行log相关的命令验证可见即可。如果要调整日志级别可以通过命令行设置比如hilog -L D会把全局日志设为DEBUG级别打印更细粒度的信息。第五步处理调试器连接。给J-Link接上SWD四根线在PC上运行J-Link GDB Server用arm-none-eabi-gdb或gdb-multiarch客户端连接。需要注意调试器连接的稳定性——我建议使用质量好一些的杜邦线组线材太长或者接触不良都会导致调试器识别不到芯片核心。连接成功后使用monitor halt命令让CPU暂停再用load命令加载带符号的ELF设置断点此时你就拥有了完整的调试能力。3.2 用一个实例串起“三板斧”为了让大家更直观地理解这三板斧怎么配合我拿一个实际案例完整过一遍。场景是OpenHarmony系统启动到一半卡在启动动画阶段偶发死机。第一板斧上日志。通过串口观察启动日志定位到“init: Service camera_service is not started”一类的报错搜索错误信息后发现是camera service在拉起时发生崩溃重试。此时日志已经把问题范围从全系统缩小到camera service这一个模块接下来决定用调试器深挖。第二板斧上调试器。连接JTAG调试器在camera service拉起入口打一个断点配合日志中崩溃函数的符号信息继续追踪发现service在初始化camera pipeline的时候访问了一个空指针导致crash。这种问题其实已经很好定位了用“bt”命令查看调用栈能清楚地看到是在camera device枚举环节出问题。再用“print”命令查看相关结构体指针发现某个设备的hal层句柄初始化失败返回了空值但上层没有做空指针保护。第三板斧上硬件工具。为什么一个空指针会让系统“偶发”死机而不是必现我在这个案例中拿逻辑分析仪抓取了camera device外部通信的I2C波形发现部分上电时序下I2C上的ACK信号不稳定导致驱动获取到的设备ID时好时坏。再用示波器看I2C供电轨的纹波发现某次上电时电源轨爬升不够快让From-0V到工作电压这段期间器件工作在不稳定状态。最终修复方案是优化电源的软启动时间并在驱动中增加了重试和超时保护——软件硬件双双加固问题彻底解决。从这个案例能看出来三板斧是层层递进的关系日志定位到模块调试器找到代码层根因硬件工具挖出物理层诱因。真正棘手的系统级bug往往都需要这样三层穿透才能真正解决。3.3 x86平台OpenHarmony的调试配置要点关于电脑版x86 OpenHarmony的开发与调试我在这里单独写一节因为它的调试方式跟ARM板卡有不小的区别。x86平台上跑OpenHarmony一般有两种方式裸机安装和QEMU虚拟机。裸机安装对硬件兼容性要求高需要驱动适配到位QEMU方式则更灵活、更适合日常代码开发和调试。我个人的建议是日常写代码、做应用逻辑调试用QEMU要测真实硬件交互、验证驱动正确性再换ARM开发板。这样能最大化调试效率。QEMU调试x86 OpenHarmony的具体操作启动QEMU时挂上“-s”参数等价于“-gdb tcp::1234”让QEMU打开一个GDB调试端口。此时QEMU默认会在启动时暂停执行配合“-S”参数你可以在GDB侧连接后设置断点、手动continue。以下是一个简化的调试命令序列qemu-system-x86_64 -m 2048 -smp 4 -kernel path/to/bzImage \ -initrd path/to/initrd.img -append root/dev/ram0 consolettyS0 \ -nographic -S -s启动后另开一个终端运行GDB客户端gdb-multiarch (gdb) file vmlinux (gdb) target remote localhost:1234 (gdb) hbreak start_kernel (gdb) continue这里有一个GDB的坑要提醒大家当调试内核时如果用“break”命令在还未加载到地址处的函数上下断点断点往往不会命中。使用“hbreak”硬件断点或者先执行“hb start_kernel”的方式可以提高命中率。对于内核启动过程由于相关代码和数据还不可寻址这个细节非常实用。我在x86 QEMU环境调试分布式软总线跨设备通信时就用了这套方式。用hbreak在软总线的消息发送函数和接收函数上下断然后同时观察收发顺序和内容很快找出了由于字节序转换不一致导致的控制字错误——在ARM板上跑没问题在x86上暴露。这种跨架构问题只有靠调试器逐指令对比才能高效定位。4. 常见问题与排查技巧实录4.1 日志相关日志不输出怎么办串口看不到日志是新手最常遇到的第一个拦路虎。我从实际经验中总结了排查顺序先万用表量电压确认板子真的上电且核心电源正常再示波器看晶振引脚有没有起振波形接着确认串口线和软件配置波特率、COM口号最后也是容易被忽略的一点——确认烧录的镜像本身就是开了串口日志的版本。有些量产固件为了性能会关闭串口输出这时你需要在构建配置里打开相关编译开关。遇到过最离谱的一次是某块开发板串口芯片工作正常但怎么都不输出日志折腾了一圈发现是串口芯片的TXD引脚虚焊补焊后才正常。4.2 日志定位启动卡住该怎么判断阶段当发现系统启动卡在某处先不要慌。对照启动日志的关键节点逐步检查日志里有没有打印Bootloader的启动信息有没有打印内核解压完成的提示有没有出现SMP: Bringing up secondary CPUs这类多核启动信息有没有打印root filesystem mount的结果跑完init进程后就进入了系统服务启动阶段。如果卡在hang之前的最后一条日志通常问题就在那条日志对应的模块附近。此时要配合时间戳判断是真卡死还是慢——比如一个模块初始化要等硬件响应超时时间设长一点就过去了。如果需要更精确的定位可以打开内核的Ftrace功能跟踪内核函数调用过程或者使用perf工具查看热点函数能帮助你更快发现卡住的函数调用路径。4.3 调试器连接不上的几个隐藏原因J-Link连接不上的原因很多提示“Cannot connect to target”通常意味着调试器没找到有效电压参考。用万用表量一下VCC引脚电压是否正常如果连接时好时坏多半是杜邦线接触不良或者线序错误。另外板上可能有多个JTAG设备——比如SoC内嵌调试器与外部调试器并存——要先确认跳线帽把调试接口切换到正确的路径。如果调试器能连上但无法读写内存多半是内核设置了访问权限保护或者CPU在Secure World状态。此时需要在调试器侧执行解锁操作或通过GDB命令设置内核调试权限。还有一个经验是不要在SoC刚上电时就立刻建立调试连接最好先让系统稳定运行一小段时间后再attach——早期boot阶段的调试连接比较容易失败。4.4 信号完整性问题如何用硬件工具确认当系统出现偶发死机、数据错乱、外设时好时坏怀疑信号完整性的话用万用表和示波器排查是两个方向。万用表检查电源轨电压是否在规格范围内、纹波是否偏大——测量纹波要用示波器AC耦合模式带宽限制在20MHz这样才能看到有效纹波而不是噪声。逻辑分析仪抓数字总线波形时注意采样的有效边沿设置、触发电平校准避免把正常的信号误判为毛刺。一个实用的排查步骤先看信号电平是否满足芯片的输入规格再看上升时间是否过快导致过冲、振铃最后对比该信号与附近时钟、数据线的时序关系是否满足相关规格要求。我记得一次排查SD卡不稳定问题用逻辑分析仪看完CMD和DATA线时序发现CMD线上升沿后到了DATA线的建立时间不满足SD规格要求的几纳秒调整主控端drive strength后问题消失。4.5 参考速查表现象第一板斧日志第二板斧调试器第三板斧硬件工具系统完全无法启动检查串口是否输出启动日志判断卡在哪个阶段JTAG连接后检查CPU是否运行、PC寄存器值万用表测电源对地阻抗、示波器看电源时序系统启动后随机死机查看内核panic日志或看门狗超时信息调试器挂载后抓取崩溃现场调用栈示波器观察电源轨纹波、逻辑分析仪看总线CRC错误外设驱动异常查看对应驱动模块的HiLog输出在驱动的初始化函数设置断点逐步执行示波器看通信波形、万用表量供电是否正常分布式通信数据错误查看软总线模块日志中的报错码调试器对比收发两端结构体内容逻辑分析仪抓取物理层通信波形分析协议在排查时必须牢记一条原则永远先确认物理层正常再去怀疑软件。哪怕是软件bug也要先确认它的运行环境是健康的——否则你会在一个被硬件问题反复干扰的软件环境里折腾很久。5. 我的实战心得与后续拓展建议最后分享一点个人体会。我在实际项目里见过太多同学拿到一块新开发板上来就闷头编译、烧录、跑软件出问题后陷入“改代码-烧录-测试”的死循环。真正高效的调试流程一定是从环境建设和工具准备开始的。把串口、JTAG、示波器、逻辑分析仪都接好待命把日志输出做到位把编译过程的符号表完整保存——前期这些准备工作虽然看起来“麻烦”但对于后面快速定位问题会起到决定性作用。我宁可多花半小时搭环境也不愿后续为了一个疑难bug耗上一天。关于OpenHarmony系统开发的学习路径如果你已经能熟练跑通标准系统的编译和烧录那么下一步我建议把注意力放在这些方向深入阅读内核态的调度与内存管理代码理解分布式软总线的数据通路尝试给不同架构的板卡移植OpenHarmony——比如在x86平台上跑OpenHarmony以理解架构差异带来的调试变化再有就是研究如何编写和调试一个完整的硬件驱动把设备驱动模型的框架给吃透。当你把“硬件调试三板斧”——日志、调试器、硬件工具——都掌握得足够熟练之后再回去看很多之前觉得玄乎的问题会发现其实都有章可循。调试不是一个不可言传的“感觉”而是一套方法论和工具链的综合运用。把这套流程变成习惯你的OpenHarmony开发效率会有一个质的提升。