您好我是ID: 熊猫钓鱼十余年深耕技术一线我始终相信优秀的开发如同垂钓——既要对技术生态的「水域」有深邃理解也要对问题本质的「鱼汛」保持敏锐直觉。从架构设计到性能调优从技术选型到团队协作我专注在恰当的时机用最合适的技术钓起最优雅的解决方案。关注我我带你一起研究最新又好玩的热点技术~写在前面这不是一篇API文档也不是什么架构白皮书。就是我一个普通开发者从零开始做一款鸿蒙原生笔记应用——「随记」三个月时间从立项到上架的真实记录。里面有我踩过的所有坑有一开始想错了后来推翻重来的设计有一些可能只有真正做过同类产品才会懂的细节。如果你也在做鸿蒙应用或者想做一个自己的小工具希望这些文字能帮你少走点弯路。一、为什么我要做一个笔记APP其实最开始的想法特别朴素我自己需要一个能快速记东西的工具。市面上笔记APP不少印象笔记、Notion、飞书文档、苹果备忘录……但用下来总觉得哪里不对。最让我烦躁的一个场景是走在路上突然想到一个点子掏出手机解锁找到笔记APP等它开屏广告或者启动加载点新建按钮等键盘弹起来——等这一切都做完那个点子我已经忘了一半。统计过一次从我想记东西到真的能开始打字平均要7秒。而灵感这种东西3秒没抓住就溜走了。后来开始深入学鸿蒙发现鸿蒙有几个能力刚好打在这个痛点上万能卡片不用进APP桌面上直接就有输入框点一下就能写服务中心直达负一屏、服务中心能直接唤起比找APP图标快太多跨端接续手机上写了一半拿起平板可以接着写不用传文件语音转写原生支持不用接第三方SDK系统级语音转写延迟低、识别准当时就想为什么不基于这些能力做一个真正快的笔记呢不是功能最全的但一定是启动最快、记录最顺手的。3月中旬立项7月初上架整整三个半月。这篇文章就是这三个半月的开发笔记。二、一开始我就想错了三件事每个项目开始的时候都会做产品规划我也不例外。但回头看最初的产品设计里有三个大方向完全想错了第一个月基本都在返工。2.1 错把功能全当成产品好最开始列功能清单我洋洋洒洒写了三十多项Markdown编辑、代码高亮、文件夹分类、标签系统、待办清单、图片标注、PDF导出、云同步、多人协作、版本历史……拿给一个做了十年产品的朋友看他只问了我一个问题“你自己平时记笔记这些功能你用几个”我愣了一下诚实回答“好像……真正常用的也就新建、写、存、搜。”他说“那就对了。笔记APP的核心价值不是功能多是你想记的时候它在那里你想找的时候能找到。其他都是锦上添花甚至添堵。”那天回去我把功能清单砍到只剩7项快速新建笔记文字/语音/图片三种输入时间线浏览全文搜索最近编辑置顶回收站本地加密存储其他所有东西什么Markdown、什么文件夹分类、什么多人协作全部推到2.0版本再说。后来事实证明这个决定太重要了。如果一开始就追求大而全我可能到现在还在开发永远上不了架。先做一个能用的、解决核心痛点的最小版本比什么都强。2.2 错把分类整理当用户刚需第二个大错误是一开始花了很大功夫做文件夹系统根目录、子文件夹、拖拽移动、颜色标记……做了快两周结果自己用的时候发现我根本不会去分类。为什么因为分类本身是一件有认知负担的事。你记一条笔记的时候还要想这条应该放在工作还是生活应该打几个标签——思考分类的这几秒钟就打断了记录的思路。我后来观察自己和身边人的使用习惯90%的人记完笔记之后再也不会主动整理。找东西的时候第一反应是搜索不是去文件夹里翻。想通这一点之后我直接把文件夹整个删掉了换成两个东西纯时间线所有笔记按创建时间倒序排列新的永远在最上面不用想放哪轻量标签可选、可加可不加不用提前预设标签体系想到什么词直接打就行界面一下子清爽了开发工作量少了一半用起来反而更顺。这个教训告诉我不要为了看起来专业加功能要为了用户真的会用加功能。2.3 错以为用户会慢慢等你加载一开始我没把启动速度当回事觉得打开慢个一秒半秒的无所谓。直到第一次真机测试从点击图标到能输入用了2.3秒。我自己反复用了几天终于体会到那种烦躁明明已经想好要写什么了APP还在转圈圈那个等待的过程特别消磨使用欲望。后来专门花了一周时间优化启动速度最终压到冷启动480毫秒热启动120毫秒点图标基本就是秒开。具体怎么做的后面性能章节会细讲但这个认知转变很重要对于工具类APP速度本身就是核心体验不是加分项。三、万能卡片看起来简单坑是真多鸿蒙的万能卡片是我这个APP最核心的入口——用户在桌面点一下卡片就能开始写不用进APP。本来以为这个功能一天就能做完结果前前后后调了整整十天踩了无数文档没写清楚的坑。3.1 FormExtension的5秒生死线第一个坑也是最大的坑卡片的FormExtensionAbility生命周期只有5秒。从卡片被点击、到onCreateForm执行完、到UI渲染完成必须在5秒内结束否则系统直接杀掉卡片就卡住不动了。我最开始没当回事在onCreateForm里做了数据库初始化、读了最近十条笔记、还预加载了一下键盘——结果就是卡片经常打不开点了没反应日志一看Extension timeout killed。解决方法就是一句话卡片里什么重活都别干。数据库初始化放到主APP的EntryAbility里做卡片只负责发消息卡片不要直接读数据库要什么数据让主APP更新到formData里卡片只负责渲染卡片上的输入框只是个入口按钮点了就跳主APP的编辑页真的输入在主APP里做不要尝试在卡片里做复杂编辑3.2 卡片不是缩小版APP第二个坑是设计层面的。我最开始想当然地把APP界面缩小放到卡片上2×4的卡片放了按钮、输入框、最近两条笔记预览——结果放桌面上一看字小得像蚂蚁手指根本点不准。后来翻了华为的卡片设计规范才明白卡片的设计逻辑和APP完全不一样卡片是瞥一眼就能获取信息、点一下就能执行操作的不是用来做复杂交互的所有可点击元素的热区至少48vp不能再小了一张卡片只做一件事不要什么功能都往上堆最终我做了三种尺寸卡片每种只干一件事2×2卡片就一个大大的记一笔蓝色按钮点了直接跳新建笔记。就这么简单反而使用率最高。2×4卡片上面一个快速输入框点了还是跳APP只是视觉上感觉直接就能写下面显示最近一条笔记的前30个字。4×4卡片上面是快捷输入区文字/语音/拍照三个大按钮下面是最近三条笔记列表每条只显示一行。上线后看数据2×2卡片的添加到桌面率最高点击率也最高。越简单的东西用户越愿意用。3.3 卡片更新的坑第三个坑卡片数据更新。一开始我以为只要调updateForm就能随时更新结果发现在桌面放久了卡片经常不刷新笔记都新增好几条了卡片上还是旧内容。后来才知道卡片更新是系统批量调度的不是你调updateForm就立刻刷新有几秒到几十秒的延迟应用退后台超过一定时间更新请求会被延迟到应用下次启动如果一次更新超过10张卡片后面的会被限流我的解决方案是卡片不用主动更新改成每次用户打开主APP、或者新建完笔记退出的时候调一次updateForm更新卡片上的预览内容就行。不用追求实时同步卡片上慢个几十秒更新用户根本感知不到。另外有个小技巧formId一定要存好应用升级的时候不要丢否则用户桌面的卡片会变成加载失败只能删了重新加体验特别差。四、编辑器90%的时间都在跟光标较劲笔记APP的核心就是编辑器。看起来不就是一个输入框吗真做进去才发现一个好用的文本编辑器水比我想象的深太多了。这三个月里差不多有一半的时间都在调编辑器的各种细节问题。4.1 为什么我最终用了原生RichEditor没自己写一开始我有两个选择用系统提供的RichEditor组件或者自己基于TextInput封装一个富文本编辑器。我先尝试了自己封装想着不就是加粗、斜体、插入图片嘛。结果做了两周就放弃了——光标位置处理、选区管理、输入法联想、复制粘贴……每一个都是深渊。特别是中文输入法的联想状态自己处理起来简直是噩梦经常输入到一半光标跳走了。最终老老实实转用系统原生RichEditor好处是系统处理了所有输入法、光标、选区的问题不用自己操心性能好大文本也不会卡支持原生的撤销/重做、复制粘贴但坑也不少下面说几个我踩过的4.2 插入图片后滚动位置的bugRichEditor最烦人的一个bug在中间插入一张图片编辑器会自动滚动到最底部用户正在编辑的位置直接跑没了。这个问题官方文档里没提论坛上好多人问解决方案是自己记录插入前的滚动位置插入完之后用scrollTo移回去。看起来简单实际调了很久因为插入图片是异步的要等图片加载完再移早了位置不对晚了用户能看到页面跳一下。最终的处理代码大概是这个思路// 插入图片前先记录当前滚动位置constscrollYthis.scroller.currentOffset().yOffset;// 执行插入图片操作awaitthis.controller.addImageSpan(pixelMap);// 等下一帧渲染完滚回原来的位置setTimeout((){this.scroller.scrollTo({xOffset:0,yOffset:scrollY,animation:false});},16);这个16毫秒的延迟是试出来的刚好是一帧的时间等图片布局完再滚用户看不到跳动。4.3 自动保存3秒一次是最佳平衡点编辑器的自动保存策略我调了好几种最开始每次按键都保存结果打字打快了就卡顿因为写数据库阻塞了UI线程改成30秒自动保存又遇到问题APP被系统突然杀掉的时候正在写的内容丢了试来试去用户停止输入3秒后自动保存是最佳平衡点既不会频繁IO卡打字又能保证最多只丢3秒的内容另外几个关键节点必须立刻保存不能等编辑器页面onPause的时候用户切走APP了用户按返回键退出的时候插入图片/语音之后这种大操作丢了用户会疯还有一个兜底我在内存里一直维护着当前笔记的最新内容就算没来得及存数据库APP下次冷启动的时候会先检查有没有未保存的草稿如果有就先恢复再进首页。上线以来还没收到过丢内容的反馈。4.4 为什么我放弃了Markdown实时渲染一开始挺想做Markdown实时渲染的就是输入# 标题自动变大、输入**粗体**自动变粗那种。后来还是砍掉了原因有两个实现成本太高要自己做语法解析和span替换光标位置特别容易出问题大部分普通用户根本不用Markdown他们就是写大白话实时渲染对他们来说反而为什么我的字突然变大了很困惑最终改成了一个很朴素的富文本工具栏底部几个按钮点一下选中的文字加粗/变斜/改颜色点图片按钮插图片点麦克风按钮转语音。简单、直观、不会出错。我越来越觉得对于大众工具克制比炫技重要。五、语音输入最受好评的功能反而代码最少上线之后看用户反馈最多人夸的居然是语音输入功能。很多评论说走路的时候掏出来说句话就记下来了太方便了。说起来好笑这个好评最多的功能反而是我写代码最少的——因为直接用了鸿蒙系统的SpeechRecognizer没有自己接百度/阿里的语音SDK也没有自己训练模型。为什么用系统API而不是第三方SDK算一笔账系统语音转写不需要联网离线就能用地铁里没信号也能记延迟特别低说完几乎立刻出字第三方SDK要上传音频再等结果慢半拍免费没有调用次数限制不用按量付费不用申请额外的麦克风权限之外的东西隐私风险小5.1 一个很实用的小细节语音输入自动加标点最开始直接拿转写结果往里塞发现系统默认的语音转写是不带标点的一整段话连在一起读起来特别累。后来翻文档才发现原来有个参数可以开标点recognizer.setExtraParam(punctuation,true);就加了这一行用户体验直接上了一个台阶。另外我做了个小处理语音转写结束后自动在最后加一个句号光标移到最后。这样用户说完话不用自己手动点标点可以直接接着做别的事。就这么一个小细节好多用户评论里提到太懂我了。5.2 后台录音的坑还有一个坑语音转写的时候用户如果按了电源键锁屏录音会立刻中断已经转写的内容如果没存就丢了。解决方案是在转写开始的时候申请一个长时任务constbackgroundTaskbackgroundTaskManager.startBackgroundRunning(context,backgroundTaskManager.BackgroundMode.AUDIO_PLAYBACK,// 用音频类型的后台模式wantAgent);不要申请LOCATION或者其他类型的后台模式审核会被拒用AUDIO_PLAYBACK就对了。转写结束一定要记得stopBackgroundRunning否则一直占着后台耗电还可能被系统判定为恶意应用。六、跨端接续看起来很酷但要控制预期“手机上写一半拿起平板接着写”——这是鸿蒙分布式能力最吸引我的点也是我一开始对这个APP期待最高的功能。做之前觉得特别神奇做完之后发现确实能实现但没那么玄乎而且边界情况特别多。6.1 分布式数据同步不是银弹最开始我以为用了HarmonyOS的分布式数据服务DistributedDataObject多设备同步就是自动的什么都不用管。真用起来才发现两个设备要登录同一个华为账号、在同一个Wi-Fi下、蓝牙都开着才能连上并不是真的实时同步正常网络环境下延迟大概500ms-2s能感觉到一点延迟设备休眠的时候连接会断重新连接的时候要处理好数据合并单条数据大小限制是16MB里面插了四五张原图就超了同步直接失败6.2 我最终用的同步策略笔记这个场景其实对实时性要求没那么高不需要像协作文档那样毫秒级同步我最终用了一个很务实的方案笔记正文存在本地关系型数据库RDBStore里读写快、稳定开启RDBStore的分布式同步能力设置成设备上线自动双向同步图片单独存文件同步完笔记正文之后再用分布式文件服务传图片每条笔记带一个updateTime时间戳同步的时候谁的时间新就用谁的版本简单暴力一开始想做复杂的CRDT冲突合并后来发现根本没必要同一个人不可能同时在两台设备上编辑同一条笔记Last-Write-Wins完全够用简单、不会出bug。不要为了技术酷而过度设计。6.3 接续流转的体验细节接续功能我做的很简单手机上正在编辑笔记的时候平板的任务栏底部会出现一个小图标点一下平板直接打开这篇笔记滚动位置跟手机一模一样。技术上实现不难就是用continueAbility传一下笔记ID和当前滚动位置平板端收到之后打开对应笔记、滚到对应位置就行。但就是这么一个简单的功能第一次在真机上跑通的时候那种超级终端的感觉真的很震撼。这里有个小坑接续的时候不要传整个笔记内容就传一个笔记ID就行平板端自己去数据库读——因为传大内容接续容易失败而且ID去读能保证拿到最新版本。七、启动速度优化从2.3秒到480毫秒前面提过启动速度是工具APP的生命线。我前后花了一周时间优化冷启动从最开始的2.3秒最终压到480毫秒。说一下具体做了什么其实都是一些很朴素的方法没有什么黑科技。7.1 启动的时候到底什么东西在拖慢速度先上DevEco的Profiler跑一遍启动耗时发现时间主要花在这几个地方Ability初始化280ms数据库初始化打开450ms读取最近20条笔记320ms首页列表渲染380ms其他杂七杂八870ms主要是各种SDK初始化、主题加载、日志模块等加起来2300毫秒跟实测对得上。7.2 能延后的全部延后优化的核心思路就一句话首屏只加载必须的东西其他全部延后到首屏渲染完再做。具体做了这几件事数据库懒初始化不用在onCreate里就打开数据库改成首页要用的时候第一次调用再初始化。但要注意第一次调用要加loading别让用户看到白屏。光这一项省了400多毫秒。非必要SDK延后初始化什么统计SDK、崩溃收集SDK、广告SDK后来直接没加广告全部放到setTimeout里首屏渲染完500ms再初始化不阻塞启动。列表分页加载首屏只加载最近20条笔记剩下的列表滚动到底部再加载。一开始我加载全部100多条笔记光渲染就卡了几百毫秒。主题资源预加载颜色、尺寸这些常用资源放到AppStartup里提前初始化不要每个页面创建的时候再读。去掉启动页广告这个不用多说启动页广告是启动慢的元凶之一我这个APP免费也不卖会员干脆就不做广告启动页就是个纯色背景logo100毫秒都不到。这一套下来冷启动时间直接到了700毫秒左右。7.3 再榨最后200毫秒剩下的200毫秒是一点点抠出来的把首页的ForEach改成LazyForEachcachedCount虽然首屏只渲染20条但LazyForEach创建组件更快笔记列表项里的小头像、缩略图首屏先不加载等列表渲染完再异步加载图片用户看不到空白EntryAbility的onCreate里不要做任何耗时操作所有非必须的逻辑都移到onWindowStageCreate之后发布版本一定要开代码压缩、去掉debug日志Release包比Debug包启动快大概100毫秒最终在Mate 60 Pro上测试冷启动480毫秒热启动120毫秒点图标基本就是秒开。那种感觉完全不一样——你想记东西掏出来点一下就开始写思路不会被打断。八、搜索最容易被忽视却最影响留存一开始我觉得搜索不就是个SQL的LIKE查询吗结果做的时候才发现搜索做不好用户找不到之前记的东西大概率就会卸载你的APP。8.1 全文搜索不能用LIKE最开始图简单搜索就是SELECT * FROM notes WHERE content LIKE %keyword%笔记少的时候没问题笔记多了几百上千条的时候每次搜索都要几百毫秒打字的时候实时搜就会卡。解决方案是用鸿蒙自带的全文检索FTS模块给content字段建FTS索引CREATEVIRTUALTABLEIFNOTEXISTSnote_ftsUSINGfts5(content,contentnotes,content_rowidid);建完索引之后搜索都是毫秒级返回几千条笔记也秒出结果搜索体验完全不一样。8.2 搜索的几个体验细节几个很小但体验提升很大的细节搜索框自动聚焦点进搜索页键盘自动弹起直接就能输不用再点一下搜索框关键词高亮搜索结果里的关键词用蓝色标出来用户一眼就看到为什么这条笔记匹配最近搜索历史自动记录最近搜过的10个关键词不用重复输入空结果给建议搜不到东西的时候不要只显示无结果提示用户换个关键词试试或者直接显示全部笔记这些细节不费什么事但用户能感觉到你的APP是用心做的。九、一些不影响功能但特别影响体验的小细节做工具产品最后拼的就是细节。有很多东西用户说不出来哪里好但用着就是舒服都是这些小细节堆出来的。列几个我花了很多时间调但几乎不会有人注意到的点9.1 新建笔记不要立刻弹键盘很多笔记APP点新建之后自动弹键盘光标在第一行闪看起来很高效其实特别反人类。我自己用的时候发现很多时候我点新建只是想打个草稿或者先插张图片再写键盘立刻弹起来占了半个屏幕反而要先按一下收起特别烦。改成了点新建进编辑器键盘不自动弹顶部标题栏有个开始写作的提示用户点输入框再弹键盘。就这么一个小改动自己用起来舒服太多了。9.2 编辑器背景不用纯白纯白背景在暗光下看特别刺眼用了一个很淡的米黄色#FAF8F3白但不刺眼长时间记笔记眼睛不会累。这个颜色调了大概十几种最终选了现在这个很多用户评论说看着舒服。9.3 删除不要真删给30天反悔期最开始删除按钮点了笔记就没了后来自己手滑删过一条挺重要的笔记找不回来特别闹心。后来加了回收站删除的笔记在回收站放30天30天之后再真删。回收站里可以恢复、可以彻底删除。加这个功能代码没写多少但给用户的安全感完全不一样。他不会因为怕删错东西而不敢整理笔记。9.4 不要让用户选保存还是不保存最传统的设计退出编辑页弹个框是否保存。这个设计特别糟糕因为99%的情况用户都是要保存的每次都弹等于每次都问一句废话还容易点错不保存丢内容。我直接取消了这个对话框所有退出自动保存没有不保存这个选项。如果用户真的不想要这篇笔记了自己去列表里删。多走一步没关系总比不小心丢内容强。9.5 图片自动压缩用户插的照片动不动就是四五MB甚至十几MB如果直接原图存数据库很快就大了列表加载也慢。插入图片的时候自动压到长边1920像素质量85%压完一张图大概两三百KB肉眼几乎看不出区别但数据库大小能小十几倍加载快了非常多。不要问用户是否压缩图片默认就压设置里给个保留原图的开关就行。大部分用户根本不懂也不关心什么压缩不压缩你帮他选最好的默认值。十、隐私合规上架前我改了三遍权限申请第一次提交应用审核直接被打回来了原因是权限申请不合规。来来回回改了三遍才过这部分给大家提个醒别在这上面栽跟头。10.1 权限不要启动就全要最开始我图省事在module.json5里把麦克风、存储、位置权限都列上启动就申请。结果审核直接拒“用户还没使用相关功能为什么要申请权限”后来改成了场景化申请麦克风权限用户第一次点语音输入按钮的时候再申请存储权限用户第一次插入图片/导出笔记的时候再申请位置权限用户主动打开自动附加位置开关的时候再申请申请权限的时候一定要说明为什么要这个权限不要只弹系统默认的需要麦克风权限要写清楚“需要麦克风权限来进行语音转写所有音频仅在本地处理不会上传”用户才会愿意给。10.2 用户的数据必须能带走应用上架有一条硬性要求必须提供用户数据导出功能。我在设置页加了一个导出所有笔记按钮可以把全部笔记导出成Markdown压缩包保存到用户自己的存储里。这个功能开发没花半天但必须有否则过不了审。而且从用户角度讲这也是应该的——用户写的东西是用户自己的不能被你一个APP锁死。10.3 不要过度收集信息我这个APP从一开始就没打算做账号系统不需要登录所有笔记存在用户本地可选开启云同步用华为云盘用户自己的账号。没有用户注册、没有手机号、不收集设备信息、不做用户画像、连统计SDK我最后都去掉了。结果审核的时候这反而是加分项评论区里很多用户就是冲不登录、不上传、隐私干净来的。做工具产品简单干净反而是最大的竞争力。十一、这三个月踩过的10个大坑最后列一下开发过程中让我印象最深的10个坑这些问题官方文档要么没写要么写的不清楚每个都至少浪费我半天时间卡片FormExtension生命周期只有5秒超时直接被杀不要在里面做任何重操作。这个前面讲过是我踩的第一个大坑。RichEditor插入图片会自动滚到底部需要自己手动滚回去官方没说这个问题论坛里踩坑的人一大堆。键盘弹起的时候默认会把页面顶上去如果页面底部有输入框还好但编辑器页面会把工具栏也顶上去高度计算不对需要自己配置windowSoftInputMode调整。分布式数据同步不要传大图片单条超过16MB直接同步失败图片单独走分布式文件服务。后台录音一定要申请长时任务否则锁屏之后录音立刻中断用户录了五分钟的语音没存上会给你一星差评。TextInput的onChange事件在中文输入法联想状态下会触发多次自动保存不要直接绑在onChange上要做防抖。应用升级的时候不要改数据库版本号但忘了写升级逻辑老用户升级后直接打不开APP这个事故我在线上出过一次紧急发了个版本才救回来。LazyForEach的数据源一定要正确实现getData和count方法不然列表删一项会乱跳删除动画也不对。设置页的Switch开关不要默认开比如自动附加位置默认一定要关用户自己开了才收集位置信息否则审核会说你超范围收集信息。模拟器和真机表现不一样特别是分布式能力、传感器、语音识别这些模拟器根本跑不了一定要用真机测试。不要在模拟器上调完就以为没问题了上了真机各种毛病。最后想说的话从3月中旬开始写第一行代码到7月初上架应用市场三个半月时间一个人从产品设计、UI切图、写代码、测bug到提交审核整个流程走了一遍。说实话比我预想的累但也比预想的有成就感。上架第一个月下载量不多只有几千但有一百多条评论大部分都是好评有人说这就是我想要的笔记APP简单、快、没广告看到这种评论的时候之前熬夜调bug的那些晚上都值了。做这个项目最大的感触是鸿蒙开发没有那么神秘也没有那么难。很多能力系统已经帮你做好了语音转写、分布式同步、全文检索、卡片……你不需要自己从零造轮子只要把这些能力用对地方做出一个体验好的小工具其实没有那么难。难的是把产品想清楚到底要解决什么问题哪些功能是必须的哪些是多余的每个细节为什么这么设计这些东西比写代码难多了。我见过很多开发者一上来就想做一个大而全的超级APP功能列了几十项做了半年还没上架。其实真的不如先从一个很小的痛点切入做一个最小可用的版本先上架再慢慢迭代。先做出来再做好。这是我这三个月最大的心得。如果你也在做鸿蒙开发或者也想做一个自己的小产品希望这篇文章能给你一点启发。有什么问题欢迎评论区交流。