开源Windows应用SumatraPDF作者分享的15年的经验教训

wy168 · 发表于 2024-1-10 19:04:46

我发布了第一个版本的SumatraPDF是在2006年。那是15年前的事了，这似乎是进行回顾的好时机。

该应用程序

SumatraPDF是一个适用于Windows的多格式（PDF、ePub、Mobi、漫画书、DjVu、XPS、CHM）阅读器，目前看起来像这样：

准则

SumatraPDF是一个用于Windows的开源文档阅读器。它一开始是一个PDF阅读器，所以叫这个名字。随着时间的推移，我增加了电子书格式（epub、mobi）、漫画书（cbz、cbr）、DjVu、XPS、图像格式等。

这大约是12.7万行的C++（不包括其他人写的库）。

它是根据Win32 API编写的，没有使用Qt这样的GUI抽象库。这有助于使它尽可能地小而快。

几乎所有的内容都是由2个人写的，偶尔也有其他人的贡献。

编写的代码量实际上更高。这是长期运行的代码库的性质，代码被写入和重写。我们删除、增加、改变。

这是一个副业，在工作之余完成，不是全职工作。在一个应用程序上工作的日常磨练是怎样的？

它看起来像这样：

你也可以偷看一下我的开发日志. 我一年前才开始写，所以只涵盖了15年中的1年。

我为什么创建SumatraPDF

SumatraPDF是我称之为意外的成功。

我从未想过要为Windows写一个PDF阅读器。

2006年，我在Palm工作，我的工作职责之一是为Foleo编写一个PDF阅读器。 Foleo，这是一款由ARM和Linux驱动的迷你笔记本电脑。你大概从未听说过Foleo，因为它在发布前几周就被取消了，原因我不清楚。

当时我不知道PDF很流行，但Palm管理层知道，这就是为什么他们决定PDF阅读器是一个必须的应用程序。我最终成为这个项目的（唯一的）开发者。

编写一个PDF渲染库是一项多年的工作。我们没有几年的时间，所以我用开源的渲染库。

我的工作是写一个基本的PDF浏览器，使用Poppler将PDF页面渲染成内存中的位图，并将这些位图显示在屏幕上。

PDF是一种复杂的格式，一些PDF的渲染速度很慢。我想提高速度，因为杰夫-贝佐斯告诉我，速度是客户永远关心的东西。

意外的应用程序

提高速度的方法是对代码进行剖析，看看结果。

不幸的是，用于未发布的ARM硬件的工具链并不是很好。忘掉剖析器吧，孩子，庆幸你有一个C++编译器，不用像Steve Wozniak那样通过输入十六进制来输入汇编。

Windows有体面的剖析器，所以我为Windows编译了Poppler。

一旦我有了在Windows上工作的库，我就写了一个最简单的GUI应用程序，可以显示页面并允许在页面之间进行导航。

你知道什么？我有一个用于Windows的简单的PDF阅读器。

我在我的网站上发布了它。它不能做什么，所以我把它标记为0.1版本。

如果你不为你的应用程序感到尴尬，那么你已经等了很久才发布它。

这个智慧的小插曲不是我想出来的，但我同意它。

获得早期用户，了解他们最想要的功能，这比辛苦几个月或几年，在你知道有人关心之前实现很多功能要好得多。

剖析、性能优化和对开放源码的贡献

回到剖析：我的计划成功了。

我对渲染时间最长的文件进行了分析，并进行了一些简单得出奇的、有效得出奇的优化。

如果说内存服务器，2个优化的效果是最大的：

优化字符串类，使用所谓的 "小字符串优化"，即在字符串类中添加一个小的缓冲区，以容纳内联的小字符串（而不是总是为字符串分配内存）。字符串被频繁使用，而且大多数是小字符串通过将其转换为批量读取的方式来修复逐个字节的i/o。在一些代码路径中，代码的结构方式是为每个字节做一个虚拟的C++调用和一个C read()函数调用。这些都是非常便宜的，但当你做500万次的时候就不一样了。

作为一个好孩子，我确实向Poppler提交了我的修改。

就像我为开源项目做贡献的经验一样，这更像是一次失误而不是一次成功。

是的，我得到了13个提交，但这个项目并不活跃，维护者也不急于接受除小改动以外的东西。忘记任何重大的重构。

我不是一个自愿用头撞墙的人，所以我不再尝试。

(如你所见，我是一个出色的团队成员）。

代码质量

我想要它，你也应该想要它。

如何在大多数情况下独自工作，没有人做代码审查，没有专门的QA团队的情况下保持高的代码质量？

下面是方法：

自己测试代码。在调试器中浏览新添加的代码，验证新添加的功能是否符合预期，并在一般情况下经常使用该应用程序。自动崩溃报告。不幸的是，它的构建很麻烦，但这是你为提高软件质量所能做的最重要的事情。简而言之：设置异常处理程序来捕捉应用程序中的崩溃，在崩溃处理程序中从服务器上下载符号以获得可读的callstack，创建一个崩溃报告，包括所有线程、程序和操作系统信息的callstack，记录并提交给服务器。在服务器上，处理这些文件并生成网页以方便查看崩溃情况。就像我说的：建立它是一件很痛苦的事情。一旦你有了崩溃，就偶尔看看它们，并试图找出出错的地方并加以修复。assert()。断言是C++代码中公认的做法：只在调试构建中执行的额外代码，验证某些条件为真。如果不是，就说明出了问题，你应该进行调查。我写了我自己的类似断言的函数，在非调试的预发布版本中启用，这样我就能自动收到人们碰到这些条件时的错误报告。相信我：你自己做再多的测试，也无法与一千多人在使用该应用程序时做的所有不同事情相提并论。记录。在调查问题时，了解导致崩溃的事件序列是有帮助的。我的小型日志模块将日志记录到一个内存块中。这将与崩溃报告一起被发送。我也有一个选项，可以将日志记录到一个文件中，最近我还通过命名的管道将日志记录到一个单独的日志应用中。这很完美，因为大多数时候我并不关心日志，但当我关心时，我不想重启应用程序来启用日志。有了独立的日志应用，SumatraPDF一直在记录日志，当它检测到日志应用正在运行时，它也会向它记录。实施起来很简单：日志应用程序创建一个命名的管道，记录器打开这个管道（就像一个文件），如果打开成功，就意味着日志应用程序正在运行，它将读取我们写到管道中的日志。静态代码分析：C++编译器的最大警告级别，将警告变成错误，Visual Studio的`/analyze选项，cppcheck，clang-tidy，GitHub的CodeQL。偶尔运行这些，并修复错误和警告ASAN (地址消毒剂)，是非常棒的。在Visual Studio 2019的某个点版本中被添加。以很小的性能代价，它可以检测你是否过度写入内存或试图读取未初始化的内存。我有一个启用了ASAN的配置。它的速度足够快，可以作为常规构建使用。压力测试。Sumatra的工作主要是渲染复杂的文件格式。由于格式的复杂性，在特定的文件中经常出现崩溃的情况。为了确保没有崩溃，我写了一个压力测试代码，读取并渲染一个目录中的所有文件。在发布之前，我通常会在我多年来积累的大量测试文件上运行它。单元测试。我没有太多的单元测试，它们主要用于测试低级功能的边缘情况，如字符串格式化。他们偶尔会发现错误。内存泄漏。令人惊讶的是，很难找到一个容易使用的内存泄漏检测工具。我正在开发一个非常简单的内置泄漏检测器。在此期间，我正在使用 Dr. Memory.它可以工作，但速度超慢。

频繁发布

当你没有很多功能的时候，改进应用程序是快速而简单的。实现 "转到 "对话框（在0.2版中实现）并不费力。

一方面，我不想太频繁地发布，但我也确实希望用户能尽快获得新的功能。

我对新版本的政策是：当至少有一个明显的、用户可见的改进时才发布。

网络应用程序将其发挥到了极致（一些公司每天都会向生产部署多次）。

在桌面软件中，这就有点复杂了，我必须建立一些功能来使它变得简单，即添加一个新版本的检查，编写一个可以更新程序的安装程序。

BTW：我的意思是 "与编写的新代码的数量成比例的频繁"。SumatraPDF的发布在绝对意义上并不频繁，但如果你考虑到它是一个兼职的、下班后的项目，就会很频繁。

像对待商业软件一样对待开源项目

大多数开源项目可能不属于这个类别，但如果你想让你的开源项目尽可能地成功，就像它是一个软件公司的商业产品那样行事。

它在实践中意味着什么？

从第一天起，我就为这个应用程序创建了一个网站。它有屏幕截图，有文档，很容易下载和安装。当然，Reddit上的一个好心人称它是 "一个6岁孩子做的网站"。这里的教训是双重的：

无视仇恨者和混蛋一个由6岁儿童建立的网站总比没有网站好。它不一定要漂亮，但一定要有功能。

我做了基本的SEO。没有超出谷歌 "SEO 101 "文件的内容：只要注意URLs，放置正确的元数据，使用正确的关键词。

我有一个论坛，供用户提出问题、提交功能请求，偶尔也会相互支持。

我使安装过程尽可能地简单。

凡是促进商业软件的好主意，对开源项目来说也是一个好主意。

在汽车运行中切换发动机

在某种程度上，我决定从Poppler切换到 mupdf因为mupdf更好，并且得到了积极的维护。

改变应用程序以使用完全不同的库，这不是一个下午就能做到的。

在甚至不能编译的代码上工作很长时间，这让人士气低落。

为了保持东西的编译，同时也为了支持替代的渲染引擎，我为渲染引擎开发了一个抽象。

该引擎将提供用户界面所需的功能：获取文档中的页数、每页的尺寸（以计算布局）、将一个页面渲染成位图等。

我比大多数程序员（至少是那些喜欢在Hacker News上发表意见的人）更不热衷于抽象，但在这种情况下，它对我很有帮助。

我能够逐步将程序形式从使用Poppler API转换到通过引擎抽象使用Poppler，再到通过引擎抽象使用mupdf。

有一段时间，我同时支持这两个引擎，但最终我改成只支持mupdf，以保持应用程序的小型化。

这为通过相同的抽象来支持其他格式打开了大门。

简单性与可定制性

简洁性是卖点。

我从Mozilla Firefox的历史中学到了这一点。

在Firefox之前，有一个Netscape Navigator。它是一个集网络浏览器和电子邮件客户端于一身的应用程序的怪兽。

网景公司无法控制自己，不断增加功能，导致了非常复杂的用户界面。

Mozilla内部的一小群叛徒分叉了代码，专注于简单的用户界面。

简单的Firefox比复杂的Navigator更受欢迎，最终完全吃掉了它。

从一开始，我的目标就是要让SumatraPDF的用户界面尽可能的简单。一个80 ⁄20 应用程序：80%的功能和20%的用户界面。

这需要解决。我不断收到在工具栏上添加更多图标的请求，而我不得不不断地说 "不"，因为为满足10%的用户而在工具栏上添加2个图标，会使100%的用户的应用程序变得更糟。

另一个陷阱是额外设置的警笛声。有时人们建议，程序不应该做X，而应该做Y。他们不愿意删除X，而是建议添加一个新的用户界面设置"[ ]做Y而不是X"。

设置对话框有100个设置，这不是一个好的解决方案。它使每个人的应用程序变得更糟，因为他们的选择太多，而且把重要的选项隐藏在非重要的选项的海洋中。

更不用说每一个条件行为都需要更多的代码，更多潜在的错误和更多的测试。

话虽如此，我也相信可定制性是很重要的。我相信，Winamp之所以成为一个占主导地位的音乐播放器（在当时），很大原因是它有能力给整个用户界面换肤。

一些高级功能可能只有20%的用户使用，但这些用户很可能是权力用户，他们会比其他80%的用户更多地宣传该应用。

我对用户界面的简单性与可定制性的解决方案：高级设置文件。

我设计了一个简单的、人类可读（和人类可写）的文本格式，用于高级设置.想象一下JSON，但要更好。

我懒得写用户界面来改变这些高级设置。我只是用该文件启动notepad.exe。当用户改变设置并保存文件时，我重新加载并应用这些改变。

水，我的朋友

变化是唯一不变的。我们必须适应世界的变化。

我无法相信有多少流行的项目仍然使用蹩脚的Sourceforge作为源码库或邮件列表。

实际上，我可以相信：改变事物需要努力，阻力最小的途径是什么都不做。

我从Sourceforge开始，转到code.google.com，然后到github.com。

我换了三次论坛软件。

我已经添加了一个浏览器插件，然后在浏览器停止支持此类插件时将其删除。

我把存储偏好的格式从二进制改为人类可读的文本。

Windows XP从大多数用户使用的操作系统变成了不再被支持（在微软停止支持它很久之后）。

起初我只有32位的构建，现在我两者都有，但强调的是64位的构建。

跳出框框思考

跳出盒子思考是很难的，因为盒子是看不见的。

SumatraPDF并不是有史以来第一个PDF阅读器应用程序。

但大多数PDF阅读器并没有成为多格式的阅读器。

事后看来，支持尽可能多的文档格式是一个明显的想法，但我花了5年时间才意识到这一点。

大多数阅读器仍然是单一格式，我相信多格式有助于SumatraPDF的普及。

我不能说这是完全独特的想法。在SumatraPDF之前，早就有多格式图像查看器，我可能是受到了它们的启发。

小而快--两者兼得

按照现在的标准，SumatraPDF很小（安装程序小于10MB），而且可以立即启动。

我相信个头小、看起来快是采用的一个重要原因。

这又回到了杰夫-贝佐斯的智慧：永远不会有用户想要臃肿和缓慢的应用程序的时候，所以小而快是一个永久的优势。

我如何保持SumatraPDF的小型化？

我避免不必要的抽象。Window的控件系统在编程时是个巨大的麻烦。我可以使用Qt、WxWindows或Gtk等包装器。它们更容易使用，但会导致即时的、巨大的臃肿。

我并不害怕自己写东西的实现。我有自己的JSON、HTML/XML解析器，其大小仅相当于这些任务的流行库的一小部分。

我积极地利用Windows中包含的丰富功能。

比方说，我需要做一个网络请求。我可以包括一个像curl这样的怪物库，或者我可以使用win32 APIs写300行代码。我写了300行代码。

没有臃肿是很难注意到的，因为它不在那里。

我最讨厌的是过度使用XML来存储数据。

当我在Palm工作时，我参加了一个关于手机自动更新系统的设计会议。它的一部分是在图像中存储关于当前版本的信息，下载关于最新版本的信息并进行比较。

开发者决定使用XML来存储这些信息。对于存储版本号这样的简单信息来说，这似乎是一个很大的臃肿。仅仅是一个符合要求的XML解析器就是大量的代码。当然，一个简单的二进制格式会更容易实现，我建议说，但被忽略了。

如果你没有权力解雇某人，你的想法就会被忽视。

(如你所见，我是一个伟大的团队成员）。

为了存储高级设置，我设计并实现了一种文件格式，它比XML小，人类可读可写，只需几百行代码就可以实现。它和JSON一样强大，甚至更具可读性。

它是如此简单，以至于在实现它之后，我有时间为C++对象实现一个序列化系统和一个Go代码生成器。要增加更多的设置，我不需要写更多的C++代码。我只需将数据定义添加到Go生成器中，重新运行它，就能自动生成数据驱动的C++解析。

这是我的项目，我就像这样做。

当有人付钱让你写代码时，你必须按照他们喜欢的方式来写。

从事没有报酬的代码工作的一大吸引力是，没有人可以告诉你该做什么或怎么做。

我的代码不会通过谷歌的代码审查，不是因为它不好，而是因为它经常是非正统的。在公认的教条之外。

(如你所见，我是一个伟大的团队成员）。

我总是把SumatraPDF作为我测试疯狂想法的游乐场。

通过不使用STL来最小化代码大小？这很疯狂，但我做到了。当然，在2006年，STL还不是很好。

我了解到Plan 9的C代码有非传统的#include文件方案，他们不在每个.h文件中放#ifdef包装器，以允许多次包含，而且.h文件不包含其他.h文件。因此，.c文件必须以正确的顺序包含他们需要的每一个.h文件。这有点麻烦，据我所知，没有其他现代C++代码库保持这样的纪律。

但这是我的项目，所以我做了，而且一直在做。它可以防止.h文件之间的循环依赖，也不会因为不小心重复包含相同的文件而导致C++构建时间的增加。

我实现了一个受CSS启发的UI系统。不是很好，但却是我的。而且我打算用一个不同的来代替。

因为我可以。

因为没有人可以告诉我不要这样做。

跨平台被高估了

SumatraPDF是一个毫不掩饰的毫不掩饰地说，它是一个仅适用于Windows的应用程序。

支持其他平台（Linux、Mac、Android）是最频繁的要求之一。一个我不得不拒绝的请求。

首先，有一个务实的原因：我只是没有足够的带宽为3个平台写代码。

第二，我相信一个平台的优秀应用可以比3个平台的平庸应用更受欢迎。

回到第一个原因：我没有足够的带宽来编写三个优秀的应用程序。SumatraPDF之所以小，部分原因是我在用户界面上使用了win32 APIs。

一个人要想尝试跨平台的应用，唯一的办法就是使用Qt、WxWidgets或Gtk等UI抽象层。

问题是，Gtk很丑，Qt极其臃肿，WxWidgets几乎不能用。

测试是没有必要的，代码审查也是如此

我不是说测试不好，也不是说你不应该写测试或做代码审查。

我是说，它们是没有必要的。

教条是强大的。在我的公司生活中，有时我觉得写测试只是在进行运动。也许我们应该花更多的时间来写代码，我想？

但是，如果你试图向你的同事们提出关于更多测试和更多代码的细微观点，你会被烧死在木桩上，你燃烧的尸体会被扔给野狗。村里的孩子会用你的头颅来踢足球。

(如你所见，我是一个伟大的团队成员）。

然而，我确实知道，你可以在没有测试的情况下写出复杂的、相对没有错误的代码，因为我做到了。

我确实知道，你可以写出复杂的、相对没有错误的代码，而不需要任何人查看你的代码，因为我做到了。

如果没有人使用你的应用程序，那么谁会在乎它是否崩溃。

如果很多人使用你的应用程序，它崩溃了，他们会告诉你，然后你会修复它。

一夜成功需要十年时间

SumatraPDF是比较受欢迎的。不是Facebook的流行，也不是DOOM的流行，但比大多数应用程序更流行。这是一个可敬的流行水平。

这一切都从0.1版和涓涓细流的下载开始。在很多很多个月里，它一直是涓涓细流。

我不确定这里是否有一个教训。

成功往往需要很长的时间。

不幸的是，在这个阶段，它与（最终的）失败是无法区分的，所以如果你正在进行一个尚未成功的项目，并在争论是否应该继续或放弃时，这种智慧并不能帮助你。

钱

开源不是一个好的商业模式。

如果你想赚钱，可以做其他事情：尝试销售软件、做咨询、建立SAAS并按月收费、抢劫银行。

我确实做过赚钱的实验，也赚了一些。

曾经有一段时间，AdSense会支付体面的CPM，所以我把AdSense广告放在网站上，赚了一些钱。我不再这样做了，因为费率确实急剧下降，而且不值得去烦扰别人。我的灵魂是有价格的，AdSense再也负担不起了。

现在我正在尝试使用Patreon和Paypal的捐款。每个月能赚到100多美元，但不会超过这个数字。

就像我说的：不要带着赚钱的目的去启动开源项目。

你很少能同时拥有：做你想做的事的自由和高薪，所以要选择对你更重要的东西。开放源代码给你自由，但不给你钱。

走向未来

我需要继续像水一样。

多年来，我一直抵制增加编辑功能。"我说："它只是一个阅读器。但为什么不增加编辑功能呢？如果人们需要它，就给他们吧。

所有软件的未来都是作为一个网络应用。为什么不把SumatraPDF的精神带到网络上呢？

这些只是我今天的一些想法。

像水一样意味着5年后我将会有其他的想法，并以当时的情况为依据。

本文由闻数起舞翻译自

https://blog.kowalczyk.info/article/2f72237a4230410a888acbfce3dc0864/lessons-learned-from-15-years-of-sumatrapdf-an-open-source-windows-app.html

开源Windows应用SumatraPDF作者分享的15年的经验教训

相关推荐