感冒两周加 Effie 开发赶进度，小说断更了一个月 。现在 Windows 版 Effie 完成了支持 10 种主题色的新版，看着这么舒服的屏幕，小说新章节已经在艰难继续了，会抓紧了。

赶在2023年内，完成了 Effie for iOS v3 with Effie AI，在 iPhone/iPad 上也可以用 Effie AI 啦。

两个月的开发，Effie for Windows v3 with Effie AI 终于上线。

简单问了她一句 “Windows 版 Effie Al 上线，你有什么想说的？” 没想到洋洋洒洒给我写了一千字的小作文。也不知道谁教她的。

Effie for macOS v3.1 with Effie AI for 思维导图。

• 思维导图 AI 拓展节点

• 思维导图 AI 生成文章

Effie for macOS v3 with Effie AI 终于上线了。海外版在8月初已经上线，国内版由于监管政策原因，拖了很久，现在终于也上线了。

用 Effie AI 给自己的小说章节做摘要、做翻译，都得心应手。

Effie 是一款跨平台（macOS、Windows、iOS、Android）的集严肃写作、随手笔记、大纲和思维导图于一身的极简写作 App。

写作笔记 App 市面上已经非常多，跨平台也早已属于标配。抛开产品设计和云端同步层面，就客户端实现来说，Effie 与一众的套浏览器（Chromium 或者 WebKit）以 JavaScript 实现的编辑器最大的区别，或者说独步江湖的特性，就是所有平台均以原生技术实现。

原生实现的劣势

所有平台都用原生实现，最大的劣势，就是开发成本极高。产品的核心功能，需要在每个平台上单独实现一遍。比如编辑器本身的交互、排版、渲染等功能，需要使用平台提供的特定的 API 或者框架，编写大量的基本上无法在其它平台复用的代码。只有一些算法性的代码可以在不同平台上用不同的开发语言实现一遍，这已经算是最大程度的“复用”和“共享”了。

即便都是 Apple 的 iOS 和 macOS，两套框架（UIKit 和 AppKit）的差异，也远超过最初的预期。UITextView 与 NSTextView不能说一模一样，可以说毫不相干。如果你认为改造完 UITextView，接着改造 NSTextView 会比较轻松，那你必然大失所望。接着面对 Windows 时，Win32 提供的基础组件 richedit32.dll，基本还是停留在上世纪的水准，在 Windows 平台另起炉灶是更明智也是无奈的选择。再来看 Android 的 EditText（TextView）时，又是一个全新的世界。

如果在大厂，选择这样的技术路径，必然会成立多个平台的开发小组，各自在不同平台开发产品。这样的实现方式，其实也很难保证，同一个产品在不同平台上有非常一致的内在逻辑和使用细节上的一致感受。而现实中，即便是大厂，也大多选择用所谓前端技术（套浏览器的 JavaScript 实现）来降低开发成本。

Effie 是个创业团队，不是大厂。Effie 所有平台的客户端的核心模块，是我一个人完成的，花了两年多时间，近30万行代码，这是一个看似非常“任性”的决策。Effie 在不同平台上，既能和平台本身风格完全融合，又能给跨平台使用的用户，带来使用上的一致感受。

Effie 为什么选择原生实现

其实，最早的 Effie 桌面原型，也是使用前端框架 Electron 来实现编辑器的。但随着原型的日渐丰满，越走越发现使用 JavaScript 实现带来的问题——无论如何优化，那种“不丝滑”的感觉——始终挥之不去。Effie 的产品经理李自然对于这个问题，也越来越无法忍受，即便市面上的同类产品皆如此。

在我加入 Effie 团队后，我在 iOS 平台尝试用 Objective-C/UIKit 实现了编辑器和思维导图的基础功能。李自然试用后，对这种“丝滑”再也欲罢不能。

之后，我用 Objective-C/AppKit 重写了 macOS 的客户端，与 iOS 版一起发布了 Effie 最初的公开版本。

再之后开发 Windows 版，也选择了 Native Win32，而没有考虑 .NET 框架。原本打算使用 Lazarus/Free Pascal 作为开发工具的，但 Lazarus 的 LCL 框架对触摸屏的支持尚不完善，另外，对多显示器的 DPI 处理也有问题，遂放弃。最终还是用我最熟悉的 Delphi，基于一套第三方付费编辑器组件，完成了 Windows 版的编辑器。而用户界面，全部使用 GDI+ 来渲染，并自己实现了所有过场动画（Win32 API 对动画几乎没有任何支持）。有用户反馈在 Windows 版 Effie 的安装包中，也带有 Chromium 库的文件，以为 Effie 也是套了浏览器内核的 JavaScript 实现。Effie 中带的这些 Chromium 库文件，是为了支持苹果登录的，与编辑器以及其它功能的实现没有关系。

最艰难的可能还是要数最后的 Android 版了，相对其它平台，Android 是我个人使用最多的（一直使用 Android 手机），却又相对最陌生的（开发层面）平台。Android 的“碎片化”也带来不少麻烦，不同的版本，不同的 Android 分支，有时简直就是另外一个系统。可能这也是为什么我使用 Android 这么多年，也基本上找不到一个趁手的笔记 App 的原因吧——现在有 Effie 了。

原生实现的优势

原生实现的优势，就是能在不同的平台，最大化的利用平台本身的特性，无论从界面元素的风格、还是交互，都带给用户最“地道”的感受。同时，编译生成的本地二进制代码（除了 Android 的 Java 不算）的执行效率，也给用户使用时带来不可忽略的所谓“丝滑”感受。

另外，对于一些极端情况，比如超大文本的情况，JavaScript 实现依赖浏览器处理，经测试，大部分这类实现的产品，都无法在人类忍受时间范围内处理好。我做过一个测试，在 Windows 版 Effie 中，将整部《三国演义》大纲化，每个段落作为一个列表项，一共2617项，生成思维导图。Effie 整个过程中占用内存不超过50M（作为对比，XMind 占用大约2G左右的内存），滚动思维导图，过程中完全跟手不卡顿，切换风格2秒内完成。

也有人问，为什么不选择跨平台的原生框架，比如 Qt。个人觉得，跨平台框架，为了跨平台，一定需要牺牲很多平台特性，去迁就共性。这样是无法做出 Effie 这样风格的产品的。Qt 这类框架只是让你可以用同一种语言，而语言对我而言，并不是一个多大的困扰。

既然选择了原生

归根结底，JavaScript 的实现受制于浏览器内核是其最大的“缺陷”。就目前的机器性能来说，纯 JavaScript 实现还是很难摆脱这个“缺陷”，即便强大如 Visual Studio Code。开发决策没有绝对的对错，只是不同的团队做出的不同的选择。

今年，Effie 已经实现了全平台覆盖（除了 Andriod 版还没有支持思维导图），也增加了全平台的图片支持，已经是一个成熟可用的，体验绝佳的写作、笔记、思维导图 App。

Effie 既然“任性”地选择了原生，作为 Effie 的开发者，我会尽可能让 Effie 永远保持这份“丝滑”。

前所未有的艰难，近两年写的第四个平台的编辑器，终于完成了。

封控在家已近一个月，开发效率多少受到点影响。不觉已春深，物我两相忘。

Effie v2.0 还是完成了，多平台（iOS/iPadOS/macOS/Windows）原生开发完美支持图片。暂时还不能说“全平台”，因为还差一个 Android，以及 Linux？

iPad 演示设备上都预装了 Effie 演示版。