★ FEATURED ARTICLE 鸿蒙开发这几年确实火但市面上大多数教程要么停留在“能跑个Hello World”的层面要么直接甩出一堆API文档让你自己啃。真正从技术底层逻辑讲到实战能力构建的内容少之又少。这篇文章我想从一个开发者的视角把鸿蒙系统的技术架构、开发环境、核心语言、UI框架、分布式能力这些关键点拆开揉碎讲清楚同时结合我实际踩过的坑和项目经验聊聊怎么从零构建一套真正能打的鸿蒙开发能力。不管你是刚接触鸿蒙的新手还是想从其他移动端平台转型的开发者这篇文章应该都能给你一些参考。1. 鸿蒙系统技术架构不只是换了个壳的安卓很多人第一次接触鸿蒙第一反应是“这不就是安卓套壳吗”。说实话如果只看应用层开发确实会有这种感觉——你写ArkTS、用ArkUI、调API流程跟安卓开发有相似之处。但如果你真的深入到底层会发现鸿蒙的设计思路跟安卓有本质区别。鸿蒙最核心的设计理念是“一生万物万物归一”。这句话听起来玄乎翻译成技术语言就是它从一开始就不是给手机单独设计的操作系统而是要覆盖手机、平板、手表、电视、车机、智能家居等各种设备。为了做到这一点鸿蒙采用了分布式架构把不同设备的能力抽象成统一的资源池。简单来说你的手机和你的手表不再只是两个独立的设备而是通过分布式软总线连接成一个“超级终端”。这里有个关键概念叫“原子化服务”。传统App的模式是下载、安装、打开、使用而鸿蒙的原子化服务可以做到无需安装即用即走。比如你在手机上看到一个任务提醒可以直接把它流转到平板上继续处理这个过程中开发者不需要关心数据同步、设备连接等底层细节因为系统已经帮你搞定了。从技术架构分层来看鸿蒙从上到下大致分为应用层你写的ArkTS代码、UI组件、业务逻辑都在这层。系统服务层包括分布式软总线、分布式数据管理、分布式任务调度等核心能力。内核层鸿蒙采用多内核设计支持Linux内核和LiteOS内核的弹性部署不同设备按需选择。这套架构带来的直接好处是开发者可以用一套代码适配多种设备同时设备之间还能协同工作。但代价就是学习成本变高——你不仅要学怎么做界面还要理解分布式能力的调用方式和数据流转机制。从实际开发体验来说鸿蒙目前的开发框架已经从早期的Java UI演进到了ArkUI声明式开发再加上方舟编译器的加持应用性能在提升的同时开发效率也有明显改善。对于新入行的开发者我建议直接上手ArkTS和ArkUIJava UI基本可以跳过了。1.1 鸿蒙与安卓、iOS的关键差异有移动端开发经验的读者对比着看会更直观。安卓和iOS的定位是“单设备操作系统”所有功能都围绕一个设备展开。鸿蒙则是“多设备协同操作系统”它天生要考虑设备之间怎么连接、怎么通信、怎么协同。拿数据共享举例。安卓和iOS上两个不同应用之间共享数据要么通过系统剪贴板要么通过服务器中转。鸿蒙的分布式数据管理则可以让不同设备上的应用直接读写共享数据手机上的应用可以直接读取平板上的数据不需要网络请求不需要手动同步。另一个关键差异是开发语言。安卓原生开发用Java/Kotlin苹果用Objective-C/Swift鸿蒙则主推ArkTS。ArkTS基于TypeScript做扩展对前端开发者非常友好。如果你有TypeScript经验上手ArkTS基本没有障碍。还有一个实用层面的区别鸿蒙的原子化服务支持服务卡片功能用户可以在桌面上直接看到应用的核心信息不需要打开App。这个能力在传统移动开发里是没有对应的做得好可以大幅提升用户触达效率但前提是你要学会把应用“拆小”而不是把整个App塞进卡片里。1.2 HarmonyOS Next与兼容层的历史包袱聊鸿蒙开发绕不开HarmonyOS Next这个概念。早期版本的鸿蒙为了兼容安卓生态保留了AOSP兼容层很多开发者偷懒直接在这个兼容层上跑安卓应用。HarmonyOS Next则去掉了这个兼容层纯血鸿蒙只能跑鸿蒙原生应用。从技术纯洁度来说HarmonyOS Next是好事系统性能和安全性都有提升也摆脱了对安卓生态的依赖。但代价是短期内应用生态跟不上很多安卓应用无法直接运行。如果你是开发者我的建议是如果你准备长期深耕鸿蒙生态直接基于HarmonyOS Next开发纯血应用虽然前期麻烦一点但未来收益最大。别贪图一时的兼容性去依赖AOSP层等生态完全切换的时候你会很被动。从面试角度来说懂HarmonyOS Next的开发者也更吃香因为企业需要的是能构建原生应用的人而不是往兼容层里塞安卓包的搬运工。2. 开发环境搭建与项目工程结构工欲善其事必先利其器。鸿蒙开发的主战场是DevEco Studio这是华为基于IntelliJ IDEA定制的IDE。你如果之前用过Android Studio或者WebStorm上手DevEco Studio几乎没有成本。DevEco Studio目前的版本已经比较成熟集成了代码编辑、调试、性能分析、模拟器管理等全套工具链。下载安装后你需要做的第一件事是配置SDK。IDE会引导你下载对应版本的HarmonyOS SDK这里不建议勾选太多旧版本SDK留一个最新的稳定版就行用不到的API纯粹是占硬盘空间。新建项目的工程结构值得花点时间搞明白。一个标准的鸿蒙工程包含AppScope存放应用级配置包括应用图标、应用名称、签名信息。entry应用的入口模块这个模块会被编译成HAP包HarmonyOS Ability Package。pages页面目录存放ArkTS页面文件。resources资源文件目录包括字符串、颜色、图片等。module.json5模块配置文件声明Ability、权限、依赖等信息。我刚接触这个结构的时候最大的困惑是搞不清“Ability”到底是什么。简单理解Ability是鸿蒙应用的功能单元类似安卓的Activity和Service。鸿蒙应用可以有多个Ability其中EntryAbility是应用启动时进入的入口。具体到页面开发ArkTS的页面结构跟现在主流的前端框架很像。一个页面文件主要由三部分构成装饰器Entry、Component、状态管理变量State、Prop等和UI构建方法build()。这种声明式的写法写过Vue或者React的人一定会觉得非常亲切。2.1 DevEco Studio配置要点与常见坑环境配置这块有几个实战中容易踩的坑我单独拎出来讲。第一个是签名配置。鸿蒙应用安装到真机必须签名跟苹果的证书机制类似。DevEco Studio支持自动签名前提是你的开发者账号已经实名认证并且登录了IDE。我遇到过的情况是有些开发者跳过签名配置直接跑模拟器模拟器不校验签名但部署真机的时候就会报错。建议从一开始就配好签名免得后面手忙脚乱。第二个是SDK版本管理。DevEco Studio允许你安装多个版本的SDK但不同版本API之间的差异还挺大的。比如早期版本的API和HarmonyOS Next版本的API在组件的属性、方法名上都有调整。如果你照着网上的旧教程敲代码很可能会碰到“找不到这个组件”的报错。解决办法很简单创建项目时选择最新的稳定版SDK代码中如果用到新API就查官方文档确认。第三个是模拟器性能。鸿蒙的模拟器跑起来比安卓模拟器要流畅一些但桌面模拟器对电脑配置还是有要求的特别是内存至少16G否则IDE加模拟器一起跑风扇会像飞机起飞一样。如果没有高配电脑优先用远程模拟器或者直接找台真机做调试。2.2 第一个“Hello World”背后的技术链路创建一个Hello World项目技术链路其实挺长的了解这条链路对后续开发有帮助。创建项目后入口是EntryAbility这个类它继承自UIAbility。应用启动时系统调用EntryAbility的onCreate、onWindowStageCreate这种方法。在onWindowStageCreate里系统创建了一个窗口舞台WindowStage然后通过loadContent方法加载主页面。主页面是一个.ets文件里面用Entry装饰器标记为入口组件用build()方法声明UI结构。比如你在build()里写一个Text(Hello World)框架会把它翻译成系统的渲染指令最终通过方舟渲染引擎绘制到屏幕上。整个链路可以总结为应用启动 - Ability创建 - WindowStage创建 - 加载页面 - 解析ArkTS - 渲染UI。理解这条链路后你要排查启动问题就有方向了。比如应用闪退第一步看Ability的onCreate有没有异常页面白屏大概率是loadContent路径配错了页面加载慢可能要看渲染引擎的绘制性能。3. 核心语言与UI框架ArkTS和ArkUI实战拆解ArkTS是鸿蒙开发的主语言它是TypeScript的超集在TS基础上加了一些限制和增强。说实话如果你有TS基础ArkTS的上手难度低得令人发指但你千万别觉得“这不就是个TS嘛”然后就跳过重点知识直接开写。ArkTS对TS做了几个重要限制最典型的是取消了任何类型的使用。在TS里你可以写let x: any 1但在ArkTS里这是不允许的。为什么因为鸿蒙要保证类型安全在编译期尽量消除运行时类型错误。这对大型项目的稳定性和性能都有好处但对习惯了TS灵活性的开发者来说一时半会儿会不太适应。另一个ArkTS的特性是“状态管理”。你用State标记一个变量后这个变量就成为了状态驱动UI的源头。当状态的值变化时UI会自动刷新。这个机制对开发效率提升非常明显你不再需要手动去findViewById然后更新UI数据一变界面跟着变。拿一个最常见的场景举例做一个计数器。传统命令式编程需要找到按钮、给按钮加监听、点击时找到控件、修改显示文本。这是四步。ArkTS的声明式开发只需要声明一个State count变量按钮触发事件时修改count值Text组件里直接引用count。UI的更新交给框架处理你要关心的只是数据本身的逻辑。3.1 状态管理的进阶玩法从State到StorageLink状态管理是ArkUI框架的灵魂理解它等于掌握了UI开发的核心。基础状态管理由三个装饰器撑起来State组件内部的私有状态变量值变化时当前组件的UI会重新渲染。Prop从父组件传递给子组件的单向数据流。父组件传什么子组件就用什么但子组件不能反向修改这个值。Link父子组件共享的双向数据。子组件修改了值父组件的数据也会跟着变。我打个比方。State是房间里自己管自己的物品Prop是别人递给你的文件你只能看不能改Link是你和老爸共用的一个储物柜你放东西进去老爸打开柜子也能看到。这三个装饰器的使用原则很简单能用State解决的就别用Prop能用Prop解决的就别用Link越简单越好。我之前在项目里遇到过小伙伴图省事所有变量都用State结果组件内部状态跟全局状态混在一起找bug找到怀疑人生。进阶一点的状态管理是AppStorage和LocalStorage。AppStorage是应用级的全局状态存储所有组件都能访问适合存用户登录信息、全局配置等数据。LocalStorage是Ability级的存储能力范围在页面栈之间共享。再配合StorageLink装饰器可以把AppStorage中的数据直接绑定到组件状态上数据哪里变了界面全链路跟着变。合理的状态管理分层是组件内部数据用State跨组件用Prop/Link全局共享用AppStorage。别一上来就全局变量满天飞状态管理最怕的就是“全局滥用”。3.2 ArkUI核心组件布局、列表与路由ArkUI的组件库说多不多说少不少核心组件掌握十几个就能应付绝大多数开发场景。布局类组件里最常用的是Row、Column和Flex。Row是横向排列Column是纵向排列Flex是灵活的弹性布局。这套布局理念跟前端的Flexbox非常相似前端转过来的开发者基本无缝切换。还有一个相对布局叠着用可以做到绝对定位的效果但日常开发中能少用绝对定位就少用因为它容易在屏幕适配的时候翻车。列表类组件是ListView也可以理解成是前端那套虚拟滚动机制。鸿蒙的List组件也是懒加载的数据量大的时候性能表现不错你只需要给它提供数据源然后关注item的创建逻辑即可。路由这块系统提供了页面栈管理能力。用router.pushUrl可以跳转到新页面router.back返回上一页。跳转时可以在params里携带参数目标页面通过router.getParams()获取。这里提一个开发习惯很多新人搞不清自定义组件和页面的区别。简单说页面是路由可寻址的完整界面自定义组件只是页面内的一个UI片段。页面用Entry标记自定义组件用Component标记。如果某个UI片段需要在多个页面里复用那它一定是一个自定义组件。做一个实际的列表页面你会发现核心代码量远比你想象得少。数据源声明、List容器、item的自定义组件、点击事件处理就这么几个部分。3.3 从页面到服务的生命周期管理UI界面只是鸿蒙应用的表层真正撑起应用运转的是Ability生命周期。一个UIAbility从创建到销毁一共经历onCreate、onWindowStageCreate、onForeground、onBackground、onWindowStageDestroy、onDestroy这几个关键阶段。这些生命周期回调对应着应用的不同状态。比如来了电话或者用户按了Home键应用进入onBackground这时候你该保存现场数据。用户切回来应用进入onForeground这时候该刷新界面数据。这个逻辑跟安卓前台的Activity生命周期很类似但鸿蒙在多设备协同场景下生命周期更复杂。比如应用流转到另一台设备时原设备页面的生命周期状态变化就要额外考虑。开发的进阶能力就体现在这些边界场景的处理上面试时面试官也往往会问这些场景的问题。另外别忘了鸿蒙还有一个后台任务机制。应用退到后台后为了防止被系统回收可以申请短时任务或者长时任务权限。短时任务一般用于保存用户数据、发送消息等临时性操作长时任务则要求配合后台服务一起使用。这个机制的细节比较多我建议初学者先把生命周期搞明白后台任务等实际遇到需求时再深入。4. 分布式能力与跨设备协同开发鸿蒙系统最与众不同的地方就是它的分布式能力。这套能力让“跨设备协同”从概念变成了可用的开发手段不过它也是初学者最容易“看不懂文档”的部分。鸿蒙的分布式基础是分布式软总线。它负责设备发现、连接建立、数据传输。从这个角度理解软总线就是一个虚拟的数据通道把不同设备拉进同一个网络里。基于软总线向上延伸系统提供了三个核心能力分布式数据管理、分布式任务调度、分布式硬件虚拟化。这三个能力各有各的用处。分布式数据管理解决的是“数据在多设备间共享”的问题它的运行机制有点像云同步但延迟和数据安全完全是由本地局域网通道保证。分布式任务调度解决的是“任务在多设备间流转”的问题比如手机上一半的任务可以让平板接着完成。分布式硬件虚拟化解决的是“设备能力共享”的问题比如手机上调用平板的摄像头平板调用手机的麦克风。这个场景用民宿类比比较好懂。软总线是民宿的公共走廊把各个房间连接起来。分布式数据管理是公用的储物柜每个房间的客人都能存取东西。分布式任务调度是客串服务员谁有空谁来干活。分布式硬件则是共享公共厨房房间A没有烤箱可以用房间B的。4.1 跨设备迁移与多端协同的实现机制跨设备迁移和协同是分布式能力的两个重要应用场景。跨设备迁移是一个流程A设备上的应用在运行你把它迁移到B设备上A设备界面关闭B设备界面接管。背后的实现是系统把A设备上相关的任务状态、页面堆栈、数据上下文都打包迁移到B设备然后B设备恢复执行。对用户来说整个过程至少在外观上看是连贯的。在代码层面你需要给Ability配置“跨设备迁移”的意图。当一个Ability支持多个设备类型时系统在目标设备上会创建一个新的任务。迁移的触发有两种系统级别的拖拽、应用内通过代码调起。多端协同比迁移更进一步它不是一个任务给一台设备而是一个任务的多个部分同时运行在不同设备上。比如手机上展示控制界面平板上展示大屏内容手表上展示统计数据。三者是一个整体。多端协同在开发上的复杂度比迁移高非常多因为它涉及不同设备间的通信与数据一致性。你要用分布式数据管理来做数据同步或者通过公共事件机制传递消息。这里我必须提醒一句协同开发对设备状态变化非常敏感设备离网、断连、回连你的应用都要有相应的处理策略。这也是面试时分布式能力的高频考察点。4.2 跨端数据同步在实战项目中的选型建议做跨端项目时核心是数据同步方案。我接触到的方案主要有三种各有优劣。第一种是使用系统自带的分布式数据库。它的优点是接入简单、同步逻辑由系统处理缺点是强绑定了“在线局域网”这个前提设备离线后就只能靠单机数据缓存。第二种是后端中转配合消息推送。这种方案稳妥设备间数据通过服务端中转不依赖本地局域网但需要在服务端加一套基础设施处理消息实时性的问题。第三种是在端侧把两种方案结合设备在线走分布式数据库直连同步设备离线走服务端排队转发。这是最完整但也最复杂的方案。对于新手做Demo我建议先用第一种方案写一个简单的跨端数据共享Demo把分布式数据库的增删改查跑通。等真正做商用项目时再根据业务场景对数据实时性和可靠性的要求决定要不要引入服务端中转。别一上来就上高复杂度的混合方案分布式数据同步一旦出问题排查难度成倍上升。5. 从工程能力到职业成长构建鸿蒙开发者核心竞争力技术深度是一回事但把技术能力转化为职业竞争力又是另一回事。鸿蒙开发领域现在还很新新到“会的人少、需求的人多”这时候能不能构建自己的核心竞争力决定了你在这个赛道能走多远。我的观察是现在企业对鸿蒙开发者的要求正在发生明显变化。早期只要会写ArkTS界面能跑Demo就算“鸿蒙工程师”。现在企业更需要的是能独立完成整个鸿蒙应用架构设计、理解分布式协同、熟悉性能优化与调试的人。单纯停留在“会调用API”层面的竞争力会越来越弱。所以构建工程能力的核心在于三个方面第一完整的项目实战经验而不是零散的Demo第二对未知问题的排查能力第三理解框架底层的原理意识。这里推荐一个成长路径第一步上手核心UI组件和状态管理能实现中等复杂度的界面。第二步理解生命周期和Ability的运作机制完整做一个小应用。第三步深入分布式能力做跨设备协同Demo。第四步回头系统看官方文档把API扫一遍补漏。第五步参与开源项目或者找实习/项目机会在真实需求中打磨工程经验。实操层面上准备一套自己的组件库很有用。把你项目里反复用到的按钮、列表、对话框封装成公共组件存到自己的工具库里下次做新项目直接拿来用。这个习惯能极大提升你的开发效率也会让你对组件化建设有更深的理解。5.1 鸿蒙开发的典型面试考察点面试是检验技术储备最直接的方式。结合我在行业里听来的反馈现在鸿蒙开发岗位的面试基本围绕几个核心板块展开。首先是UI能力。面面试官会给你一个新的UI界面题目让你分析应该拆成哪些组件、用哪些布局方式去实现主要考察你对组件化和状态管理有没有底层认知。其次是应用生命周期。问到具体的场景比如App退到后台运行几分钟后需要做什么很多候选人就答不全了。考察的其实就是你对鸿蒙任务调度和生命周期机制的理解。然后是分布式能力。这问题通常会这么问“有一个跨设备协同的功能你会怎么设计”这时你要从软总线、分布式数据、任务迁移、网络状态处理等多个维度给出完整方案而不是只堆API名称。最后是工程能力。比如单元测试有没有写过、性能分析工具会不会用、应用崩溃日志怎么排查。这些东西没有实战经验确实是回答不出来的靠面试前临时抱佛脚很难生效。5.2 个人技术成长规划的几个建议技术路线的规划我个人的体会是走“T字型”路线——横向上理解整体纵向上深入局部。横向把应用开发的全流程走一遍。从需求分析、架构设计、编码实现、测试联调到性能优化、打包上架每个环节至少要知道它在干什么、由谁负责。即使你的岗位只是一个模块的编码也必须对整个产品生命周期有概念。纵向找两三个方向深入研究。可以考虑的方向包括ArkUI组件底层实现、分布式数据一致性、性能优化的监控与调优、自动化测试与质量保障。深挖一个方向再在这个方向上积累案例这会成为你在职业市场中真正的护城河。还有一个持续积累的方法是写技术笔记。我给自己立过一个要求每踩一个坑就把它记录下来包括问题的现象、原因、解决思路和最终方案。俗话说好记性不如烂笔头这项习惯坚持下来后你会拥有一套记录下来、属于自己的避坑手册。面试的时候也很有用聊问题就能显现出真实的深度和经验。5.3 社区与开源生态的参与方式有相当一部分开发者容易忽略社区的价值但鸿蒙生态处于快速成长期社区参与恰恰是一个成本低、收益高的成长方式。你可以从这几件事开始做起。第一参与官方开发者社区的问题解答在解答别人的问题过程中会倒逼你自己把知识体系梳理清楚。第二把练习项目开源出来让别人看到你的代码。哪怕只是很基础的项目也是你工程能力的证据。第三参与开源贡献。你可以在开源日志里找到标注了“鸿蒙适配”的issue尝试修复。这个过程比你在本地写一百个Demo成长都快。开源参与也是个人品牌的加分项。招聘时如果候选人有一份长期维护的开源项目通常比简历上写“熟悉鸿蒙开发”更有说服力因为它说明你有真实落地的能力而不只是背了概念。让我再提醒一点社区参与要真正动手不要只做围观群众。我曾经见过不少开发者加了十几个技术交流群但半年后还在问最基本的问题。知乎刷得再多看再多帖子不亲手敲代码技术的成长永远都是缓慢的。6. 常见问题与排查技巧实录鸿蒙开发过程中踩坑是常态。我把这几年实际工作中常见的几个大坑梳理了一遍整理成一份速查表按问题现象、原因分析、解决方案的顺序来写大家可以收藏备用。开发过程中最常碰到的问题其实是“模拟器安装不上/启动报错”。DevEco Studio的模拟器是独立组件用之前需要单独下载。常见原因是网络问题导致镜像下载中断或者本地SDK版本与模拟器镜像版本不匹配。解决方案是检查SDK的版本号与模拟器镜像版本号是否一致不一致就重新下载镜像。也可以考虑直接用真机调试其实真机在性能和I/O上会比模拟器顺手很多。数组越界和空指针问题在ArkTS开发里也不算罕见。跟TS一样ArkTS运行时的某些边界检查没有编译期那么严格。当你遇到“Cannot read property of undefined”之类的报错时优先去排查接口返回的字段是否为空、列表数据的长度是否为零。养成对后端返回数据做防御性校验的习惯这类问题能少掉一半我的经验是“永远不要相信服务端的返回体构造一个默认兜底值再使用”。还有一个经常被忽略的问题是系统权限配置。做定位、相机、文件读取的时候新手经常忘了在module.json5里声明权限。有时就算声明了也忘了运行时动态申请权限。在鸿蒙里地理位置、相机这类敏感权限是要动态申请的很多初学者直接调API没弹窗才会发现少写了申请逻辑。建议在工程模板初始化时就把该用的权限梳理好。如果录制深水区的问题那就绕不开性能与崩溃。页面卡顿的第一个排查手段是按系统的HiLog抓取主线程日志模式上跑一下自带的性能分析工具看CPU和内存占用分布。如果是滚动页面卡顿优先检查列表组件是否用了LazyForEach并且item组件里有没有重复创建对象。崩溃日志就要学会看HiLog窗口的标准格式找到带Fatal字样的记录那里通常有崩溃堆栈。这些问题的排查套路其实背后都是一个思路先定位是哪一层出了错再往下钻。调用链、日志、工具三者配合大部分问题都能找到根因。下面用一张表格把一部分高频问题汇总一下问题现象常见原因排查手段真机安装应用失败签名信息未正确配置检查签名文件与IDE登录状态页面加载白屏loadContent路径错误检查Ability的页面路径配置网络请求失败缺少网络权限或未申请动态权限检查module.json5权限声明应用闪退空数据未做兜底处理查看崩溃日志定位堆栈跨设备传输不成功设备网络不在同一局域网检查设备是否处于同一网关/网络6.1 一次分布式数据同步问题的完整排查过程挑一个我印象最深的案例完整走一遍排查过程。某次做跨设备协同Demo手机端写入一条数据平板端迟迟刷不出来。数据同步链路完全不通我第一反应是分布式软总线没连上。打开日志看软总线的连接状态显示已连接。那么问题应该出在数据同步层。第二步检查数据库和表是否创建成功。在两端各打印了一次数据库打开结果都显示成功了。这就排除了建库失败的可能。第三步在手机端写入数据后检查了对应同步回调是否触发结果发现这个回调压根没执行。这时大致可以判断写入这条链路有问题同时平板端也根本没收到同步通知。虽然看起来系统状态正常但实际同步并没有被初始化。反复看了几遍初始化代码才发现问题的根源平板端的同步订阅逻辑写在了Ability的onForeground里而Ability在onCreate阶段就会触发首次的同步拉取等于初始化时机晚了一步。数据在Ability初始化完成后才写入但订阅因为时机问题没有生效。我把订阅逻辑整体移到onWindowStageCreate里重新注册之后问题解决。这个坑非常典型也可以看出分布式数据结构在初始化时机的把握上有多重要。出了问题不用怕按链路一层层排查每层留下验证日志是找到问题最快的方法。6.2 提升开发效率的几个小习惯最后分享几个实际开发中提升效率的小习惯虽然不复杂但用好了省时省力。创建项目的时候把工具类、网络请求封装、基础UI组件仓库这些基础工程一次性搭好。不要到写功能的时候才临时去补通用模块那会让你每个项目都要把基础工事重做一遍。写代码的时候立刻同步写注释和关键流程文档不要拖。鸿蒙的API更新速度不慢很多API在下一个版本就变了没有注释的话两个月后你自己都看不懂自己的代码逻辑。别高估记忆力低估文档价值。定期跑一下性能分析工具。鸿蒙自带的性能分析工具能发现内存泄漏和主线程卡顿问题不要等用户上报卡顿再去排查。性能问题越早发现修复成本越低。还有就是多写插件和模板。DevEco Studio支持代码模板和快捷键配置把高频代码片段做成模板能省下大量重复劳动。我常跟小伙伴讲每次写重复代码的时候都应该想到这是“当前重复写这么多遍未来还会写更多遍”那今天就值得花一点时间把模板里面的片段抽象出来。写在最后说到最后我还是忍不住啰嗦几句个人经验。鸿蒙开发这个方向技术水平跨度其实很大会做一个演示用的小应用和能力过关、能扛住真实商业项目并有跨设备协同能力的人在市场里的价值完全不在一个量级。现在入场还不算晚但成长关键还是回归到“多写代码、多踩坑、多复盘”这九个字。把基础工程一遍遍做扎实把分布式能力吃透再深入理解框架底层原理形成自己的一套体系这条路几乎没有别的捷径。希望这篇文章能让准备学习鸿蒙的开发者在起步阶段少走一些弯路也欢迎在评论区交流你们踩过的那些坑。
阅读完成 · 觉得有帮助？
