XRING , Software Engineer

Limitations and Privacy

2018.07.06

局限性

MarkEditor 的局限性

任何一个App 都有自己适用的场景和局限性,ME 也不例外,主要是下面的问题。

长文章的性能问题

由于 MarkEditor 本身会实时对文本的结构进行分析,以实现文本的高亮、TOC结构的获取与调整,所以当文本过长的时候,这个基础引擎会不可避免地导致性能的下降。

按照我们的概要性测试,基本上 1 万字以内不会产生性能问题。
在 10 万字左右的时候,不打开同步预览的时候,在连续超快速的输入时,会有不是很明显的时滞感,但基本上没有什么性能上的波动。
在 10 万字左右并且开启了同步预览的时候,能够感觉到卡顿,但基本上也勉强可用。

某些弹窗界面首次显示的时滞感

MarkEditor 因为功能比较多,并且通过设计规整,在多数时候,使用者并不会感知到自己不常用的功能存在。
而每个功能、设置界面,都是需要 UI 渲染的,考虑到很多界面,在整个 MarkEditor 启动的周期内可能都不会被呈现,所以,默认并不直接构建,以节省 App 启动的时间。而只有在它们被第一次显示的时候,才会实时构建。这个 构建 过程,会消耗 1 秒不到的时间,有时会给人一种时滞感。
不过,这是正常的,并不会导致或者因为 MarkEditor 卡住了。

打开 App 的时间比较长?

MarkEditor 会尽可能记住其最后一次打开时候的状态,比如有多少个标签栏同时打开的,那么,下次 MarkEditor 打开的时候,又会重新开启这些标签栏。
如果 MarkEditor 启动的时间超过 3 秒以上,一般来说,都是多标签栏每栏内都需要处理载入的逻辑而导致的。
可以关闭不使用的 Tab 栏,那么下次重新打开 MarkEditor 的时候,速度会有比较明显的加快(呃,其实如果不是十来个 Tab,加速还是不明显的,估计也就几秒吧)。

Markdown 的局限性

Markdown 作为基础,可以带来非常高效的写作体验。但是它并非万能的,根据我们的经验,建议书写的过程中可以参考以下建议:

  • 保持清晰的结构: 比如一个 table 语法中,每个字段都是长文本,那么建议考虑用 list 的方式,或者 # xx ## xxx这种层级标题的方式。
  • (多行文字间)避免多重语法嵌套: 比如在一个 list 内嵌套代码并不是推荐的方式。
  • 保留适当的空格: 特别是# 标题这种语法,最好是#后面加上一个空格。
  • 按需保留适当的空行: 比如在层级标题之间,保留合适的空行,虽然于解析结果而言没有任何意义,但是自己预览原文时的体验会好很多。

另外,Markdown 本身不会让使用者变得更酷,除非自己本来就很酷。:)

隐私相关

本地文件路径的暴露

在导出为HTML 格式(相关) 页面的时候,如果文档内包含插图,则在原始的 HTML 源码中,会曝露插图位于当前操作系统内的图片的文件路径。
这个设计的目的,是因为使用者在当前电脑内呈现 HTML 页面的时候,可以无差别地呈现对应的插图。
一般不会有特别问题,除非所在目录本身是一个敏感的地方,比如暴露了使用者自己的 username。

网络请求

MarkEditor 会在以下情况产生网络请求:

  • License 的激活、升级、校验
  • 版本更新的检查
  • MarkEditor 云端 (包括 ME 自身提供)同步数据的时候

云端同步的请求,仅仅包含文件信息本身,不包含系统级的信息。
License & 版本检查的请求,除了 License 与 当前版本 这些基本信息外,还会包含操作系统、操作系统版本、设备类型等几个基本的信息外,不会包含其它系统级、账户级的信息。
MarkEditor 除了在 自动版本检查 (可关闭)时会主动地产生请求,其它时候,都是使用者的行为而产生具体的网络请求。

如果你发现有其它(主动的)网络请求发生,请确保 MarkEditor 是从我们的官网上下载的,因为,这意味着当前 App 已经被修改了,是不安全的。

Comments
Write a Comment