HarmonyOS开发工程师转型指南：技能拆解、实操路线与面试考点全解析

看到HarmonyOS开发工程师这个岗位的讨论热度持续走高不少朋友私信问我“到底值不值得转”“面试都考什么”。我在移动端这块摸爬滚打了十多年这两年也完整经历了从传统App开发转向鸿蒙生态的全过程踩过不少坑也拿过几个还不错的offer。今天不做任何花哨的展望只把技能体系、实操路线、面试考点这些硬骨头拆开揉碎给你一份可以直接照着准备的指南。这篇文章会回答几个实际问题HarmonyOS开发工程师和安卓/iOS开发到底差在哪、少年宫级别的Demo和能上架的生产级应用之间有哪几道坎、面试官真正想从你嘴里听到什么。如果你正在犹豫要不要转型或者已经投了几份简历但心里没底这篇文章就是给你写的。1. 先搞明白HarmonyOS开发工程师到底在做什么1.1 这个岗位和传统安卓/iOS开发的本质区别先说个最直观的感受你过去写的安卓代码核心是在跟“一套运行在手机上的操作系统”打交道而HarmonyOS应用开发从第一天起就在让你思考“一套代码怎么跑在手机、平板、手表、车机、智慧屏这些完全不同的设备上”。这个差别不是宣传语它直接决定了你的代码组织方式、状态管理方案、生命周期理解甚至调试习惯。具体到技术栈上HarmonyOS应用开发用的是ArkTS语言UI层叫ArkUI是彻底的声明式范式应用模型叫Stage模型组件化程度比传统安卓四大组件更抽象。再加上分布式软总线、元服务、原子化卡片、跨端流转这些能力整个知识图谱比单一平台开发要宽出一大截。很多从安卓转过来的朋友最容易犯的错就是用安卓的思维硬套鸿蒙的API比如拿到Context就new一个Intent结果在API设计上卡半天——实际上鸿蒙的router和want机制完全是另一套玩法。再说说职业定位。现阶段的鸿蒙开发工程师很多时候不是“只写UI”的角色。因为生态还在快速建设中你往往要自己搭工程、处理构建脚本、搞签名上架、调性能甚至兼顾卡片和元服务这种偏系统层的东西。换句话说这个岗位对你的“工具人”属性要求更低但对“能独立端到端交付”的要求更高。这也解释了为什么市面上初级岗少、中高级岗多因为团队要的是能直接解决问题的人不是只会照着文档敲组件的选手。1.2 哪些人转型有优势哪些人要补的课最多根据我接触过的转型案例有三类人上手最快。第一类是原生安卓开发者写过JVM或者Kotlin理解生命周期和跨进程通信只需要把思维从“命令式UI”切到“声明式UI”再补ArkTS的语法约束大概两三周就能进入项目状态。第二类是前端开发者尤其是用过React或者Vue的对组件化、状态驱动、单向数据流这些概念几乎零成本迁移ArkUI的组织方式和心智模型跟前端框架非常像唯一要补的是应用生命周期的系统级理解。第三类是嵌入式或者底层开发转过来的可能在UI上不占优势但碰到分布式、软总线、数据同步这些底层能力时理解速度反而很快。不太建议零基础直接空降的不是学不会而是你要同时补编程基础、系统概念、UI框架、工具链四座大山战线拉得太长。如果你真的是零基础建议先把TypeScript或者Java基础打牢再用OpenHarmony的轻量级Demo练手不要一上来就追最新版本的大项目。还有一类近年来比较热AI应用开发工程师和Agent智能体开发工程师。这些人如果懂一点鸿蒙的元服务和卡片能力能做一个“手机上的AI助手卡片”在面试里会非常加分因为现在鸿蒙生态里AI应用的落地路径还比较空白提前占位的人很吃香。2. 技能体系全景拆解从语言到生态2.1 ArkTS真不是套壳TypeScript那么简单很多教程会告诉你ArkTS是TypeScript的超集这句话对了一半。它确实保留了TS的类型系统和语法糖但加了更严格的约束比如禁止使用any类型、禁止在运行时做类型体操、对象字面量必须符合明确类型等。这种设计是为了保证方舟编译器的静态优化空间代价是开发者的“自由度”低了一些——但实际写下来你会发现大部分限制反而能避免低级bug代码可读性也更稳定。入门时你需要重点吃透这几类装饰器和状态机制Entry和Component一个组件文件里只能有一个Entry作为页面入口Component声明可复用组件。State组件内部状态变化会触发UI刷新这是声明式驱动的核心。Prop父子组件间的单向传值子组件修改不会同步回父组件。Link双向同步父组件状态变化会更新子组件子组件修改也会回传。Observed和ObjectLink处理嵌套对象、数组内部字段的观察经典场景比如列表项里的对象属性修改不刷新大概率是你没用对这两个装饰器。其实归根结底你只需要理解一句话状态是唯一数据源UI是状态的投影。想改UI先改状态不要直接去操作DOM或者组件实例。这个心智模型一旦建立大部分界面问题都能迎刃而解。写一个小例子一个点击次数计数器Entry Component struct CounterPage { State count: number 0 build() { Column({ space: 16 }) { Text(Clicked ${this.count} times) .fontSize(28) .fontWeight(FontWeight.Bold) Button(ClickMe) .onClick(() { this.count }) } .width(100%) .padding(24) } }这个代码里没有任何手动刷新UI的逻辑但你点按钮时页面会自动更新这就是状态驱动的价值。面试时如果让你手写一个类似组件记得把装饰器的选择和传值方向说清楚这是明显的加分项。2.2 ArkUI声明式开发的几个关键认知ArkUI采用的是组件树加布局容器的方式和Flutter、SwiftUI的思维非常接近。基础组件有Text、Image、Button、TextInput、List、Column、Row、Stack、RelativeContainer、Grid等布局时优先用Column和Row做线性排列再嵌套Stack做层叠网格用Grid。布局属性主要是width、height、margin、padding、alignSelf这些语法上走的是链式调用。新手容易搞混两块一是ForEach的key生成二是条件渲染的粒度。ForEach如果你只是简单写ForEach(this.arr, (item) { Text(item.name) }, item item.id)这里的第三个参数是键值生成器如果返回的值不稳定或者重复会导致列表复用错乱出现滚动后内容乱跳的问题。键值必须稳定且唯一一般建议用数据项id不要用index。条件渲染的粒度指的是不要过度使用if (condition) { ... }来包裹超大块UI尽量把条件抽到子组件或者用Visibility属性控制显示隐藏。渲染引擎对条件分支的缓存能力有限频繁切换大块条件分支会产生节点重建开销实测在低端设备上掉帧很明显。再说状态管理。除了装饰器本身的用法你还需要了解AppStorage和LocalStorage这两个用于应用级和页面级共享状态的方案。比如登录态存AppStorage页面内的筛选配置存LocalStorage比到处用StorageLink传值要优雅得多也方便做持久化。很多人在项目里为了图省事把AppStorage当全局变量乱用最后导致启动时数据不一致这是要避免的。2.3 Stage模型与UIAbility生命周期旧版本的FA模型已经基本退场现在的应用开发基于Stage模型。在这一模型下一个应用由若干个module组成每个module里包含若干个UIAbility组件。UIAbility本身不负责渲染UI它只负责拉起页面和处理系统交互实际的界面由加载的页面Page来承载。这个分层设计让“一个Ability可以复用给多个入口”成为可能配合元服务卡片就非常顺。生命周期这里值得细说它是面试必考。主要回调有onCreateAbility创建时执行适合做初始化但此时窗口还没创建不要做UI操作。onWindowStageCreate窗口创建完成UI即将显示通常在这里加载页面内容比如windowStage.loadContent(pages/Index)。onForeground页面即将进入前台可见状态。onBackground页面退到后台适合做数据保存、暂停耗时任务。onDestroy销毁时释放资源反注册监听器。这里有个常见坑很多人把数据初始化放到onWindowStageCreate里导致每次冷启动都会重复请求网络。正确做法是区分“进程创建”和“窗口创建”耗时的初始化逻辑可以放到Application的onCreate或者用单例做懒加载确保只执行一次。module.json5文件是配置核心里面对应着Ability声明、权限、元数据、入口等。很多编译期的神奇报错其实就是这里写错了比如默认导出的图标路径找不到、请求权限没声明、组件export漏写等。调试前先养成检查这个文件的习惯能省下不少时间。2.4 分布式能力与一次开发多端部署分布式是HarmonyOS区别于其他操作系统的最大卖点也是面试时最容易拉开差距的话题。这里的核心概念包括分布式软总线设备间通信底座、分布式数据管理同款应用数据跨端同步、分布式任务调度跨设备调用能力、跨端流转续播、接续。作为应用开发者你不一定要从零实现一套分布式通信框架但需要理解应用层API的用法。最常用的是跨端流转比如手机上播放视频用户可以把任务流转到智慧屏。实现方式主要靠continuation机制需要在module.json5里声明continuable然后在代码里调用续播相关API并处理好状态同步和序列化。一次开发多端部署也不是真的写一套代码就完事。底层是依赖“自适应布局响应式布局”这套设计规范比如拉伸、缩放、隐藏、折行等。你在模拟器上把窗口从手机尺寸拖到折叠屏尺寸再拖到Pad尺寸页面没有错位、卡死、功能缺失才算合格。面试官常见的追问是“如果你做一个支付页面在手表上怎么展示”这时候你要说清楚手表屏幕小、算力弱、输入能力差支付流程要简化成确认和取消而不是把手机页面原样缩放。2.5 生态工具链与调试基本功开发工具链主要围绕DevEco Studio进行。它基于IntelliJ IDEA所以用过Android Studio或者WebStorm的人上手很快。但有几个点值得单独练Previewer预览器可以不跑模拟器直接预览局部组件hvigor构建脚本类似Gradle但很多东西是自动配置的ArkProfiler性能分析器用于查看CPU、内存、帧率SmartPerf调优工具可以做深度性能剖析。另外重要的一点是鸿蒙的开发调试和上架依赖华为开发者联盟的AGC平台。你需要在AGC上创建应用、配置签名证书、上传包、做版本管理、配置崩溃分析等。不熟悉这套流程的人往往会卡在“写完了代码却没法在自己手机上装”这一步。关于这个我后面在第3章会给出详细步骤。3. 从零到一实操路线环境、开发与调试3.1 DevEco Studio环境搭建与工程结构先说环境要求建议用Windows 10/11 64位或者macOS内存16GB起步硬盘至少留60GB空间因为SDK、模拟器镜像、缓存加起来很占地方。安装很简单从官方渠道下载DevEco Studio一路默认下一步即可它会帮你把SDK、ohpm包管理器和相关工具链装好。新建工程时你会看到几种模板Empty Ability、List Ability、元服务卡片模板等。第一个项目选Empty Ability就够了。生成后的工程结构里需要重点关注这几个目录entry/src/main/ets源码主目录页面组件都写在这里。entry/src/main/resources资源文件包括字符串、颜色、图标、媒体等。entry/src/main/module.json5应用模块配置。build-profile.json5构建配置主要在改动包名或签名时用。oh-package.json5依赖配置文件类似前端的package.json第三方库通过ohpm发布和引入。说一个很多新手都会卡住的问题依赖装不上。类Unix系统上如果你通过第三方包管理器来装ohpm依赖可能会遇到各种环境变量、权限和仓库源问题实际上鸿蒙生态有官方默认的仓库源尽量用DevEco内置的ohpm命令不要自行魔改源地址。一旦改了源版本兼容性很容易出问题。创建完工程后先别急着写业务建议用模拟器起一个默认Demo跑通“修改代码-预览-运行-断点调试”的完整闭环。模拟器的启动速度不如安卓快但Previewer预览器的响应很快日常开发我都是先用Previewer调UI再上模拟器做整体验证效率能提升很多。3.2 手写一个待办清单应用状态与交互纸上谈兵没意思这里带你手写一个极简待办清单。这个项目虽然小但涵盖了状态管理、列表渲染、输入交互、组件传值很适合作为入门第一个练手项目。完整业务逻辑是输入框中输入待办事项点击添加按钮把它加入列表点击列表项可以把事项标记为完成点击删除按钮删掉它。先定义一个数据模型在ets目录下新建model/TodoItem.etsexport class TodoItem { id: number 0 title: string finished: boolean false constructor(id: number, title: string, finished: boolean) { this.id id this.title title this.finished finished } }接着在Index.ets里写主页面import { TodoItem } from ../model/TodoItem Entry Component struct Index { State todos: TodoItem[] [] State inputValue: string private nextId: number 1 build() { Column({ space: 12 }) { Row({ space: 8 }) { TextInput({ placeholder: 输入待办事项, text: this.inputValue }) .layoutWeight(1) .onChange((value: string) { this.inputValue value }) Button(添加) .onClick(() { if (this.inputValue.trim().length 0) { return } this.todos.push(new TodoItem(this.nextId, this.inputValue.trim(), false)) this.inputValue }) } .width(100%) List({ space: 8 }) { ForEach(this.todos, (item: TodoItem) { ListItem() { Row({ space: 8 }) { Text(item.finished ? 已完成 : 未完成) .fontSize(12) .fontColor(item.finished ? #999999 : #007AFF) Text(item.title) .fontSize(18) .decoration({ type: item.finished ? TextDecorationType.LineThrough : TextDecorationType.None }) .layoutWeight(1) Button(删除) .onClick(() { this.todos this.todos.filter(t t.id ! item.id) }) } .padding(12) .backgroundColor(#FFFFFF) .borderRadius(8) } }, (item: TodoItem) item.id.toString()) } .layoutWeight(1) .width(100%) } .padding(16) .backgroundColor(#F1F3F5) .height(100%) } }注意几个细节。TextInput的onChange只会在内容变化时触发你用它同步到State变量再通过text属性回填这样添加完成后可以清空输入框。列表用List和ListItem组合比Scroll加Column更适合大数据量和滚动性能。ForEach的第三个参数用的是item.id而不是index避免列表项复用错乱。如果你想让这个项目更上一个台阶可以加一个Prop或Link的子组件来展示单个待办项这样能练习组件通信。再加一个本地持久化用PersistentStorage或者首选项存储把todos存到磁盘重启后数据还在。这个改进在面试里提出来至少能证明你考虑到了“状态恢复”这个工程问题。3.3 元服务与卡片开发新的机会点除了传统App鸿蒙生态还有一个很有潜力的形态叫元服务。元服务可以理解为一个免安装、即点即用的轻量应用它不占据桌面图标而是通过服务中心、桌面卡片、小艺建议等方式触达用户。卡片就是元服务的“门面”比如一个天气卡片、一个日程卡片能在桌面上直接展示核心信息和快捷操作。元服务的技术门槛其实不高核心是把UI拆成一个卡片组件在卡片里通过formBindingData提供数据再配置好卡片的尺寸和更新周期。比较磨人的是卡片尺寸适配和刷新策略。当前端用户对“卡片信息不更新”的容忍度很低你要确保从服务端拉取数据、写入formBindingData、触发刷新这一整套流程是及时的。从岗位价值来说懂得做元服务和卡片开发的鸿蒙工程师目前市场上比较稀缺。很多企业做鸿蒙化改造时第一优先级未必是全量App而是先做一个卡片把核心功能露出。所以“会做卡片”可以作为你面试作品集里的差异化亮点。3.4 签名、上架与发布踩坑记录写完了应用怎么装到真机跑这步卡了很多人。流程大致是在AGC创建项目和应用开通开发服务配置SHA256指纹和包名然后在DevEco Studio里配置本地签名生成证书和Profile文件最后就能在真机上安装调试。这里有几个高频坑。第一个是证书与Profile不匹配报错信息往往很抽象说“signature verification failed”之类的。解决办法是删掉本地配置的旧证书重新申请一套确保AGC里的包名和工程里的applicationId完全一致。第二个是版本号不对AGC平台要求versionCode单调递增如果你测试版版本号比线上还高审核会被拒。第三个是提取包的时候要选择正确的产物DevEco生成的release包在entry/build目录下找到带签名的.app或者.hap文件不要拿debug包去上传。上架审核时也要注意应用不能有纯网页套壳的行为页面必须有一定原生交互权限申请要合理。虽然审核机制现在还在不断变化但基本原则跟主流应用商店是一致的。对独立开发者来说把上架流程走一遍本身就是一次很好的工程能力锻炼。4. 面试指南高频考点与答题思路4.1 简历准备项目经验怎么写才能过关除非你已经有鸿蒙相关的上线作品否则大多数人简历里写的都是安卓、前端或者后端项目。这时候不要直接把旧项目名贴上去而是要明确写出“鸿蒙化改造”视角的部分。比如原来是一个安卓的购物App你可以写“基于ArkTS和ArkUI完成商品列表、购物车模块开发采用Stage模型管理UIAbility生命周期使用State和Link实现多级筛选状态同步。”如果你确实没有鸿蒙项目那就在简历里留一个“个人学习项目”板块哪怕是一个待办清单应用只要你把工程结构、状态管理、持久化、真机调试都做完整就远比写一堆“熟悉HarmonyOS”空洞描述有说服力。面试官特别反感“熟练使用鸿蒙开发”这种话三句一问就露馅不如老实写清楚自己做到什么程度。除此之外建议把技能清单分条罗列ArkTS语法、ArkUI组件与布局、Stage模型生命周期、网络与数据持久化、跨端适配与分布式能力、DevEco调试与性能优化。每一条都对应到真实的项目例子上这样面试官追问时你不会慌。4.2 基础高频题生命周期、状态管理、路由面试基础题几乎必考三类生命周期、状态管理、路由跳转和组件通信。生命周期方面高频问法是“说说UIAbility从启动到销毁的完整流程”以及“onWindowStageCreate和onPageShow有什么区别”。回答时要落到代码UIAbility的onWindowStageCreate负责装载窗口内容页面路由的onPageShow是页面自身显示的回调两者层级不同。另一个高频变体是“App切后台时保存状态应该放在哪里”正确回答是onBackground而不是onPageHide因为onBackground是Ability级别的。状态管理方面必问“State、Prop、Link有什么区别”以及“父子组件怎么通信”。回答时一定要用代码说明不要只背书。另外还可能问“数组里某个对象的属性修改了为什么页面没刷新”这时候就要引出Observed和ObjectLink说明普通对象不会触发观察必须让该对象类加上Observed并在显示的组件里用ObjectLink持有。路由方面新手常犯的错误是只会用router.pushUrl但答不出它与Navigation组件的区别。大家需要知道router方式比较轻量适合简单的页面跳转Navigation是系统级组件支持路由栈管理、转场动画、分栏布局适合中大型应用。面试时能提到“复杂项目建议用Navigation统一管理”会让人觉得你做过工程化思考。4.3 技术与原理题渲染机制、线程模型、内存优化如果你面的是中高级岗位一定会碰到原理题。常见的有ArkUI的渲染管线是怎样的其实要答到“UI描述-构建渲染树-布局-绘制”这个流程以及状态变更后如何最小化更新。没有标准答案但你要能说出“不是简单的全量重绘”最好能提到脏检查、属性更新、局部RenderNode更新这些概念。耗时任务怎么处理标准回答是放到TaskPool或Worker线程里不要在UI线程执行网络请求或大计算。TaskPool适合单次任务并发Worker适合长期异步循环。回答时可以补充线程切换的开销以及传参时注意对象序列化问题。内存泄漏怎么定位可以说用DevEco的Profiler抓堆快照再结合代码查一下是否有定时器未注销、监听器未移除、长生命周期对象持有短生命周期对象等。其实原理题的核心是考察你有没有调过性能建议在准备阶段真的拿一个项目跑一次Profiler记录一次内存抖动或者启动慢的调优过程把它写成一个case。面试官说要举一个优化例子时这个case就是你的王牌。4.4 场景设计题与软素质考察除了八股面试官还会给一个开放式场景考察综合设计能力。高频题目有两种。第一种是“设计一个跨设备音乐播放控制”。你要先拆需求手机控制端、音箱播放端、状态同步。然后说方案通过分布式数据管理同步播放状态通过跨端调用控制远端播放如果网络断开则降级为仅在本地播放同时提示用户。能说出降级方案非常关键面试官喜欢看到你考虑异常场景。第二种是“你在做项目时和产品经理对需求产生了分歧怎么处理”。这种题没有标准答案核心是不要当刺头也不要盲目妥协。可以说先对齐目标再分析数据和用户反馈如果产品坚持就做一个最小可行版本去验证。软素质考察的无非是协作边界、问题升级意识、以及对产品质量的底线。从我的经验看面试官要的不是“标准答案”而是你脑子里的“决策树”。即面对问题时你会先考虑什么、再考虑什么、如何做取舍、如何验证结果。所以面试前建议把自己做过的真实项目从头到尾复盘一遍为什么用这个方案有没有别的选择选它是什么代价后来有没有后悔。5. 常见问题与踩坑实录5.1 环境与构建问题速查现象可能原因快速处理办法SDK下载失败或超时网络环境不稳定、镜像源冲突关闭第三方代理工具切换官方源后重试ohpm依赖装不上ohpm仓库源被修改、版本不兼容检查oh-package.json5中的版本号用官方源重新安装Previewer无法预览组件缺少Entry装饰器或者资源路径错误确认预览目标文件是Entry页面清理Previewer缓存真机连接提示未授权手机未开启USB调试、驱动缺失在开发者选项中开启USB调试使用原装数据线签名报错signature verification failed证书与Profile不匹配删除本地签名配置重新在AGC申请一套证书这里特别提一句很多人在类Unix环境下自己魔改包管理器源结果导致鸿蒙SDK的ohpm依赖死活装不上。我当时也折腾了一天最后发现是源的问题。我的建议是除非你对生态内部非常熟悉否则老老实实用官方默认源。有些看起来像“灵巧”的操作最后都会用更诡异的方式反噬你。5.2 UI与动态渲染问题合集第一个高频坑ForEach的key用的是index结果列表增删后复用的组件带着旧状态。解决办法是换用稳定唯一id。第二个坑用State修饰一个对象结果修改对象内部属性后页面不刷新原因是普通对象不是可观察类型需要Observed加ObjectLink。第三个坑在组件上直接修改一个状态而该状态被多个子组件引用引发连锁重绘性能变差。正确的做法是把变化收敛在最小粒度的组件里或考虑用Provider和Consumer做跨层级数据流。还有图片加载的坑。列表里大量使用网络图片时如果不做缓存和懒加载内存很容易爆。建议优先使用官方Image组件能力再结合合适的占位图和内存缓存策略避免在低端设备上出现白屏。5.3 真机调试与性能问题记录真机调试最常见的坑是“设备列表里看不到设备”原因往往是USB调试没开或者驱动没装好。在Windows上部分杂牌数据线也会导致连接不稳定有条件尽量用原装线。另外HarmonyOS的开发调试默认需要登录同一华为账号并开启“开发人员选项”的“USB调试”这两步缺一不可。性能方面我遇到过启动速度慢、列表滑动掉帧、内存不断上涨三个典型问题。启动速度慢通常是Application里初始化了太多第三方SDK改进方式是把非必要的初始化延迟到首帧后。列表掉帧往往是因为在ListItem里做了耗时计算或复杂的图片加载需要把计算结果缓存图片异步加载。内存不断上涨则要重点排查是否有不断创建无释放的线程、定时器或者监听器。这些坑我大部分都踩过踩完才明白一个道理性能问题不能等到产品快上线才考虑应该在每个功能完成时就去Profiler跑一遍养成“写完就测”的习惯。5.4 学习路线上的一些个人建议最后聊点学习方法。鸿蒙生态迭代速度快版本升级频繁资料鱼龙混杂。我见过很多人买了一堆课程囤着不看也见过有人上来就啃源码结果被劝退。比较靠谱的节奏是先用DevEco跑通默认Demo然后做一个小项目比如待办清单或记账本再把官方文档里的“应用开发”章节通读一遍接着去研究一个开源项目最后定期看看版本更新日志避免知识过期。一定要多做笔记。我之前带过一个小伙伴他每踩一个坑就写一篇几十行的总结三个月下来积累了一百多条面试时聊起这些经验能滔滔不绝面试官反而觉得他很有工程素养。这种积累是任何速成班都给不了的。额外提一句如果你对AI方向感兴趣可以考虑把Agent智能体开发和鸿蒙的元服务卡片结合。比如做一个语音助手卡片后台接大模型前端用ArkUI渲染这既是鸿蒙的新赛道也是AI应用开发的新载体面试时聊这个方向会很加分。我自己的体会是转型鸿蒙开发最难的并不是某个API或某个框架而是要把“多端协同”“跨设备流转”这些抽象概念转化成具体的设计决策。就像你在手机上做一个视频续播功能不能只想着“切后台继续播”还要想清楚如果用户从手机切到平板播放进度怎么同步网络断了怎么降级不同设备分辨率和交互方式不一样控制栏要不要跟着变这些问题只有多动手做、多踩坑才能真正建立起感觉。如果你现在还在犹豫要不要投入我的建议是别把时间耗在纠结上先下载DevEco Studio花一个周末做出一个能跑的Demo。真实写过代码之后你自然就会知道这条路能不能走通也自然能判断自己是不是适合。等你的第一个鸿蒙应用在真机上跑起来的那一刻那种成就感会告诉你答案。