为什么能在 App 中看到 Python 的影子
MarkEditor 中为什么有 Python 的影子？
你可能注意到了，在 error.log 之类的日志文件中，会出现 Python 的影子。
MarkEditor 的实现机制是:
- 在 Objective-C 中调用 Python，从而让整个 GUI 用 Python 的脚本文件跑起来
- 在 Python 的脚本中再调用 Cocoa (苹果的 GUI 框架)
为什么采用这种开发方式？
MarkEditor 是效率工具，其中的功能非常多，虽然在不同的场景下，彼此隔绝，使用者未必会感觉到 繁多。
很多功能的实现，使用纯 Objective-C 或者 Swift，可能性很低，相对而言，Python 作为一种胶水语言，其生态非常好。另外一方面的原因，MarkEditor 2.0 的部分功能继承于 MarkEditor 1.0 (基于 Python)，比如 PDF 电子书的导出、Wiki 的导出。
那 MarkEditor 是原生的 App 吗？
当然是呀……
仍然是 Cocoa (苹果的框架) 在起作用，相当于原本用 Objective-C 调用的，改成 Python 调用了。
这跟 Electron、Qt，或者基于纯 Webview 有本质的不同，这种区别在于: 是否直接调用苹果 GUI 相关的 API。
打开 MarkEditor 时候感觉不够快，是因为 Python 的影响吗？
MarkEditor 1.0 是基于 Qt 开发的，其 App 打开的速度，由于载入框架等各种原因，明显得慢，启动时间接近 10 秒。
而 MarkEditor 2.0 则速度提升非常明显，大约 2~3 秒的时间。但我们也无法做到 1 秒打开，这并非 Python 的问题，胶水语言此时并不会有什么性能上的瓶颈，因为底层不是 C 就是 Objective-C。
MarkEditor 有两个特性: 一个是大量的界面重绘，一个则是基于本地文件系统(无数据库)。这两个特性就决定了，打开 App 的时候，会有额外的 GUI 渲染，以及基本的(目录&文档)数据查询、遍历、读取、解析时候的开销。
这些 background 的工作，就决定了额外 2 秒是无可避免的。
另外，如果 Tab 栏中栏数的增加，也会增加这些额外的工作时间(会线性增加渲染开销，但不是简单的倍数相乘)。
如果未来有移动端，也会采用这种开发模式吗？
未来的移动端不会使用这种 Python+Cocoa 的方式。
一来不现实；二来移动端并不需要桌面端这么复杂的功能，用不到 Python。