企业官网建设流程全解析

做这件事的起因其实很简单：我在鸿蒙平板和PC上找过好几圈，想找一个能替代传统notepad的文本编辑器。要求并不高——启动要快、能多标签、能切换编码、能对配置文件或者日志原文做点轻量处理。结果要么只能用系统自带备忘录，要么是早期移植过来的编辑器在触屏环境下交互各种不顺手，要么连最基本的等宽字体都没法设。既然找不到，那就干脆自己做一款，于是就有了NextEditior：一个面向鸿蒙PC和平板、定位“用起来像电脑上notepad一样利索”的原生文本编辑器。

说它是notepad，其实不止是notepad。除了基础文本编辑、多标签页、查找替换、编码转换这些“老本行”，我额外塞了两类更有意思的能力：一是端侧OCR，直接在本地把图片、截图、扫描件里的文字识别成可编辑文本；二是字体选择，不只是从系统自带字体列表里挑一个，而是能从字体文件、自定义目录里加载，支持实时预览并应用到编辑器渲染。此外还有行号、自动保存、历史记录、Markdown快速预览等几十项细碎功能。做这种东西最有意思的地方在于，每加一个功能，你都能真实摸到它在鸿蒙生态里和其他平台的行为差异。

这篇文章适合两类人：一类是在鸿蒙PC、平板或者手机上想找一个“更好用文本编辑器”的用户，你可以看看一个相对完整的编辑器应该长什么样；另一类是有鸿蒙开发经验、想自己拉一个类似工具项目的开发者，我会把整体设计、端侧能力接入方式、上架准备和踩坑记录尽量讲透。下面按从设计到落地的顺序完整展开。

1. NextEditior的定位与整体设计思路

1.1 鸿蒙PC场景下的文本编辑需求缺口

先说需求端。鸿蒙PC版出现之后，设备形态从手机扩展到桌面，这意味着大量需要“打开就写、写完就存”的轻量文本处理场景涌进来了：改配置文件、写脚本片段、编辑JSON、查看日志、整理笔记草稿。这类事情用系统备忘录做会非常别扭——备忘录的强项是富文本和云同步，不是纯文本编辑；用大型IDE又太重，杀鸡用牛刀。真正合适的，就是Windows用户最熟悉的那个“记事本”形态：极快启动、纯文本、无多余界面。

但鸿蒙生态早期恰恰缺这么一个“系统级轻量编辑器”。我在开发过程中观察到很多用户还在用文件管理器直接预览文本，或者在备忘录和文档应用之间来回倒腾。这说明不是需求不存在，而是没有产品把“轻量文本编辑”这件事做对。NextEditior最初的定位就是补上这个缺口：给鸿蒙PC和平板用户一个打开不犹豫、操作不学习、功能不过剩的文本编辑器。

1.2 设计三原则：轻、快、可扩展

立项的时候我给自己定了三条原则，后面所有功能取舍都围绕它们展开。

第一条是“轻”。界面必须干净，启动必须干脆，不能在主界面上堆一堆用户看不懂的按钮。默认状态下就是一块大的文本区域，加上一个不遮挡内容的状态栏。

第二条是“快”。文本编辑器最大的敌人就是卡顿，尤其是打开几MB的日志文件时，如果输入都有延迟，那这个工具基本就废了。所以我在渲染层做了一些针对性处理，后面会详细讲。

第三条是“可扩展”。只做一个纯文本编辑器其实没有护城河，所以要把常见增强能力做成可选模块。比如OCR、Markdown预览、编码检测、字体管理这些功能，平时藏在菜单和侧边栏里，用的时候一键呼出，不用的时候完全不干扰编辑体验。

1.3 功能全景：一个编辑器该有的和不该有的

NextEditior当前版本的功能列表大致可以分成五类：基础编辑、文件管理、视图增强、智能能力、个性化设置。我整理了一个表格，方便你看清楚每类里面具体有什么。

不该有的东西我也列了一个清单：不做云同步、不做社交分享、不做富文本排版、不塞广告。理由是这些功能要么需要服务端，要么会把编辑器拖回“笔记软件”的赛道，跟NextEditior“本地优先、轻量专业”的定位冲突。

2. 端侧OCR：把图片里的文字直接变成正文

2.1 为什么选端侧而不是云端识别

OCR的全称是光学字符识别，核心任务是把图片中的文字区域检测出来、分割成单字、再通过模型映射成可编辑文本。团队在做功能调研时对比过云端OCR和端侧OCR两条路，最终选了端侧，原因有三个。

第一个是隐私。文本编辑器里处理的内容往往涉及配置密钥、个人笔记、聊天记录截图，这些东西如果送到云端识别，用户心里总归不踏实。端侧识别意味着图片不出设备，对隐私敏感场景是无价的。

第二个是可用性。鸿蒙PC和平板很多使用场景是在办公环境或者移动场景，网络不稳定是常态。云端OCR依赖HTTP请求和上传带宽，弱网下体验非常差；端侧OCR只要设备能开机就能用，离线也能识别。

第三个是成本。云端OCR按调用量计费，对个人开发者来说，用户量一旦上来就是持续的资金压力。端侧OCR虽然前期要处理模型集成和性能优化，但运行时不产生服务端费用，对开源项目尤其友好。

2.2 端侧OCR的典型使用流程

在实际产品里，端侧OCR不是孤立功能，而是要自然地嵌入到“读取→识别→编辑”的完整链路中。NextEditior的OCR入口有两个：一个在工具栏直接放“图片转文字”按钮；另一个在新建文件菜单里。

整个流程是这样的：用户点击识别按钮后，系统弹出图片选择器，你可以选相册中的现有图片，也可以直接调起相机拍摄纸质文档或屏幕。图片选定后，应用把图像交给引擎处理，这个过程包含几个内部步骤：首先做方向矫正，识别图片是否横置或颠倒；然后做文本区域检测，定位哪块区域有文字；接着执行文字识别，把每个文字块转换成置信度不同的候选字符；最后把这些结果按照阅读顺序组装成段落文本。

引擎返回的结果会以两种方式呈现：一种是直接插入到当前光标的所在位置，这种方式适合“图片里就是我要的文字，直接转成正文”的场景；另一种是展示在侧边栏的预览面板里，旁边有“全部插入”和“替换选中内容”两个按钮，适合先确认识别质量再决定怎么使用的场景。

这里有一个重要的经验：端侧OCR的识别结果并不是100%准确，尤其遇到手写体、低分辨率截图、复杂背景时错误率会上升。所以不要把OCR结果直接覆盖原文件，而是插入为新增内容，让用户可以比对后再删改。我在NextEditior里默认走的也是这个安全策略。

2.3 端侧OCR的性能与集成注意事项

端侧OCR要做得可用，性能和内存是关键。我在开发时首先踩到的坑是：直接把整张高分辨率图片塞给识别引擎，会导致内存占用飙升，设备明显发烫。后来我加了一个预处理步骤：识别前先对图片做等比缩放，长边限制在2000像素以内。这样做识别速度提升明显，准确性损失控制在可接受的范围内。

第二个坑是旋转问题。手机拍照可能会得到竖图、横图甚至是倒置的图片，如果引擎没有内置方向检测，那就要在引擎之前做好方向校准。我在这个环节也翻过车，后来干脆在UI层面做了一个“旋转图片”按钮，用户可以手动微调，这样即使在引擎漏检的情况下也能保证最终识别方向正确。

第三点是系统权限。图片选择器在鸿蒙上是一个安全组件，应用不需要申请整个相册的读权限，这点比传统文件读取要更规范。但如果你要做“截图后立刻识别”的功能，就涉及屏幕截图权限或者剪贴板图片的读取，这部分的权限弹窗文案要写清楚，避免用户以为是隐私被偷看。

3. 字体选择与数十种功能的取舍逻辑

3.1 为什么字体选择值得做成一个独立模块

传统notepad对字体的支持非常粗浅，多数时候你只能在系统字体列表里选一个，然后一用到底。但对于需要在不同场景切换的人来说，这个需求是真实存在的：写代码时想用等宽字体，做中文笔记时想用黑体或楷体，查看日志时又想用大号行距的字体。字体不仅是视觉效果，还直接影响阅读效率和键入准确性。

NextEditior的字体选择功能起步时就定了三个目标：第一，能浏览系统所有已安装字体，并且每种字体都使用自身字形即时渲染预览文字，而不是用一种字体来显示另一个字体的名字；第二，能加载自定义字体文件，把ttf或otf格式的字体导入应用沙箱，然后在编辑区使用；第三，字体设置要能跟文件类型绑定，比如.md文件自动用无衬线字体，.log文件自动用等宽字体，切换文件时无需手动改动设置。

字体选择这个功能本身不算复杂，但真正做深了就发现有很多细节。比如中文字体文件动辄10MB起步，如果把字体文件整体读入内存再做渲染，对低内存设备是不小的负担。后来我改成按需加载——只提取出编辑区当前需要的字符子集。这项优化做完之后，加载自定义字体的耗时降低了一个量级。

另一个细节是字体回退。如果一个字体文件不包含某些特殊字符，比如生僻汉字或者emoji，那引擎不能直接放弃显示，而是得回退到系统默认字体。鸿蒙系统的字体回退机制是分优先级的，我会确保自定义字体的优先级足够高，同时绝不会覆盖系统的无字库字符。

3.2 “数十种功能”到底是怎么来的

题目里说新增了“数十种功能”，这句话其实不是夸张。我在整理功能清单时数过，现有版本已经超过三十项可感知的功能点。但功能多不等于好用，多一个功能就多一个维护成本和UI入口，所以所有功能都遵循一个规则：被用户真实需要，且无法通过简单组合现有功能实现。

举几个例子。比如“编码转换”，传统notepad在Windows上处理GBK和UTF-8乱码是家常便饭，鸿蒙生态里同样会遇到。这个功能需要做到自动检测文件编码，并在状态栏显示当前编码，用户可以一键把文件另存为UTF-8。再比如“JSON格式化”，编辑器可以识别当前文件是否包含JSON片段，一键缩进并高亮格式错误。还比如“Markdown实时预览”，对写文档的用户来说，左边写Markdown右边渲染成排版好的效果，体验比纯文本好很多。

这些功能并不是我一时兴起堆出来的，而是有清晰的分组逻辑：编辑类功能提升输入效率，文件类功能降低格式成本，视图类功能改善阅读体验，智能类功能扩展编辑边界。每加一个功能，我都会问自己一个问题：如果去掉它，用户会不会觉得缺了什么？如果答案是“不会”，那我就再想想，有时就直接砍掉。

3.3 个人最喜欢的三个被忽视的功能

说实话，字体选择功能和OCR是项目门面，日常使用最多的反而是那些不起眼的小能力。我自己最喜欢的是以下三个。

第一个是“未命名标签页的会话恢复”。很多编辑器崩溃或重启之后，恢复的是已保存文件列表，但新打开的空白标签、敲了一半没保存的内容通常直接丢了。NextEditior做了一个本地草稿箱：每隔30秒把未保存的标签页内容写入缓存，下次启动时提示“发现上次未保存的内容，是否恢复”。这个小功能救了我好几次，写博客写到一半编辑器异常退出的惨痛经历应该很多人都有。

第二个是“统计粘贴文本的缩进方式”。当你把一大段代码从网页或者其他编辑器粘进来时，常常会出现混用空格和Tab的问题。NextEditior会在粘贴后自动检测当前文件的缩进主流方式，并弹一个轻提示问你是否统一转换。不做自动替换，只提供一个选择，这样不会给人“擅自修改内容”的感觉。

第三个是“字符集详情面板”。点击状态栏的编码区域，可以看到当前文件包含的字符分类统计：中文数量、全角字符、特殊符号、换行符类型等。这个功能对处理数据文件和文本清洗非常有用，也是传统notepad里完全找不到的东西。

4. 开发实战：鸿蒙原生实现与跨端框架的选择

4.1 为什么选择原生ArkTS而不是跨端框架

下一个问题可能是：这个项目是用什么技术栈写的？结论先行：核心编辑器是纯鸿蒙原生应用，使用ArkTS和ArkUI开发。热词里有不少人在搜“Flutter鸿蒙适配”“Tauri鸿蒙”“KMP鸿蒙适配”，这说明社区对跨端方案很关注。我也认真对比过，但最终选择了原生，原因有两方面。

一方面是跨端框架在鸿蒙上的成熟度还在上升期。部分框架虽然已经能跑起来，但工程化配套、动态能力调用、崩溃监控、性能分析这些周边工具链还不够健全。对一个小而美的编辑器来说，稳定性和可控性比一次写三端更重要。

另一方面是编辑器场景对平台能力的使用非常深入。比如OCR、字体子集加载、文件系统监控、系统级拖拽，这些都是与系统底层紧密结合的能力。用跨端框架的话，要么框架没有暴露这些API，要么需要写平台层胶水代码，最终还是要维护原生模块，那“一次编写、到处运行”的初衷就打了折扣。

不过如果你要开发的是一款业务型应用，比如商城、内容社区，那Flutter在鸿蒙上的适配进展是值得关注的，它能显著压缩多端开发成本。核心判断标准是：你的应用对设备底层能力依赖有多深。依赖越深，越应该用原生。

4.2 编辑器核心架构：编辑区渲染与文本模型

鸿蒙上做文本编辑器，最核心的两个模块是文本模型和渲染层。

文本模型负责管理文档内容，核心数据结构我用的是一棵分段树（piece tree），而不是一个巨大的字符串。为什么不用简单字符串？因为在大文件里做任意位置的插入和删除，字符串拼接的复杂度随文档长度线性增长，而分段树可以把操作复杂度降到对数级别。分段树维护的是文本的“逻辑位置”到“实际存储块”的映射，每一次编辑操作只修改受影响的分段，其他部分完全不碰。

渲染层则不是一次性把整个文档画出来，而是采用视口渲染机制：只绘制当前屏幕可见区域内的那部分内容。滚动时动态调整绘制范围。这个机制和日常浏览网页时浏览器渲染大量内容的方式是类似的，可以简单理解成“屏幕外面没有字，滚动到哪就画到哪”。这个优化做完，打开几十MB的日志文件也能保持流畅滚动。

界面框架上，编辑区使用的是带滚动能力的文本容器，结合自定义的绘制层来实现行号、当前行高亮和光标状态。行号区域和正文区域是分开绘制的，垂直滚动时行号跟正文同步滚动，这样就能保证行号始终对应当前位置。

注意：千万不要在主线程里做重型文本操作。我在前期开发时吃过亏——解析大文件、分词、正则匹配这些操作有时能阻塞UI上百毫秒，肉眼可见的卡顿。后来我把这些操作全部挪到子线程去执行，通过任务队列和主线程通信，界面就变得非常顺滑了。

4.3 从项目初始化到应用上架需要准备什么

很多刚接触鸿蒙开发的同学对“上架需要准备哪些东西”比较懵，这里也给一份实操清单。

首先是开发者账号和应用的签名证书。上架应用市场必须要有企业或个人的开发者认证，签名证书在AGC控制台生成，和应用包名强绑定。开发调试阶段可以使用自动签名，但上架前一定要单独配置发布证书。

其次是应用图标和宣传图。市场审核要求准备不同尺寸的图标，以及至少几张功能截图，用来展示应用在手机、平板和PC不同形态下的界面效果。

然后是隐私政策。只要应用涉及任何用户数据处理，就必须在应用内提供隐私政策入口。NextEditior虽然强调本地处理，但OCR功能需要处理图片，这就涉及相册读取和可能的图片缓存，隐私政策里必须写清楚这些数据的处理方式。

最后是版本说明和测试信息。提交审核时要填写更新日志、测试账号、测试说明。纯本地应用不需要服务器环境，所以审核相对顺畅，一般只要功能稳定、没有违规内容，过审问题不大。

5. 开发与使用中踩过的坑和解决记录

5.1 打开大文件卡顿，怎么优化都不彻底

文本编辑器没有一个大文件是没灵魂的。很多用户会拿它当日志查看器，一打开就是几十MB的运维日志，如果处理不好，长文件直接卡死应用。

第一次优化我做了视口渲染，效果不错，但滚动时偶尔还是有抖动感。后来排查发现，问题出在光标闪烁上——当文档超长时，系统需要不断重绘整个内容层，哪怕只改动了光标位置。解决办法是：把光标层和文本层拆开，光标闪烁只触发光标层的局部重绘，文本层只在真正需要滚动或修改文本时才更新。改完之后滚动手感明显顺滑了。

另一个大文件相关的优化是延迟加载语法高亮。普通文件不需要高亮，但如果打开的是代码或JSON，用户期望有色彩区分。我会把高亮分析拆成“首屏优先高亮”和“后台全量分析”两步：先保证用户马上能看到内容，再慢慢把高亮铺满整个文档。

5.2 端侧OCR识别率低，问题出在图片预处理

OCR上线之后陆续收到反馈，说“识别率不稳定”。我自己测试时也发现同样一张图片，有时效果很好，有时漏字明显。最终定位到的原因有两个。

第一个原因是图片分辨率过小。用户从聊天工具里保存的图片经常被压缩过，长边只有800像素，文字笔画已经糊了。解决办法是直接在UI上提醒：当图片分辨率低于建议值时，弹一个提示让用户尽量选择原图，而不是默默用低分辨率图片去识别。第二个原因是背景复杂。白纸黑字的印刷体识别效果最好，但手机拍摄时经常有阴影、反光、桌面纹理混进来。我在预处理阶段增加了灰度化和对比度增强，把背景噪点对字符分割的干扰降到最低。

这个方法不能保证100%的识别率，但在绝大多数常见场景下，识别结果的可用性已经达到“复制粘贴后微调即可”的程度。