前端和用户直接打交道，他们把各种创意做成现实。豆瓣阅读中大量的使用HTML5、CSS3 等特性，通过复杂而又精细的编码实现优雅的阅读体验。在6月27日的 Adobe创意技术沙龙中，豆瓣阅读的前端工程师石岩将做主题为「Type is Beautiful」的分享，介绍使用前端技术为电子书实现专业的字体、版式等工作。借此机会，InfoQ 对他做了采访，聊聊豆瓣阅读产品在前端构建过程中的一些感受：

\

InfoQ：请您先做下自我介绍？

\

\

石岩：大家好，我叫石岩，是豆瓣的前端工程师，在豆瓣工作有四年的时间；最近两年主要做豆瓣阅读这个产品，专注于阅读器以及改进用户 Web 阅读体验方面的工作。我本人对于设计，特别是字体与版式设计比较敏感，所以在做这方面的前端工作时很有心得。

\

\

InfoQ：豆瓣阅读作为一个前端导向的产品，您认为它和之前所做过的前端工作有哪些不同？

\

\

石岩：首先豆瓣阅读所涉及的是一个较新的领域，同时在我之前所做的项目中没有触及类似 typography 这类专业领域（之前它们并不属于前端开发或是 Web 设计的范畴）所以我们在动手前需要跟设计师、产品经理去讨论如何用 Web 的方式去实现。

\

\

InfoQ：比如哪些方面？

\

\

石岩：主要是字体排印以及传统印刷品中的各类版式呈现，细节来讲，包括标点禁则、标点压缩、注释、插图的处理等。所以需要我们更细致地去探究 Web 中文本的展示。

\

\

InfoQ：在豆瓣阅读的前端设计中会有哪些设计理念，怎么把信息更好的呈现给用户？是利用拟物风格的，就是完全图书的那种形式呢？还是你们有自己的一套方式？

\

\

石岩：豆瓣阅读分为自出版和电子书两个平台。对于自出版平台中的排版系统，功能是第一位，所以视觉和交互更多地是考虑如何帮助用户更好地完成文字编辑工作。出于对特殊用户群以及复杂需求的考虑，排版系统在前端实现方面也是破天荒地只支持高级浏览器，这样大大降低了开发成本，同时也让用户体验到前沿技术所带来的丰富功能。电子书平台面向读者，支付和阅读体验是设计重点。至于设计理念，我本身不是设计师，所以也讲不出什么专业观点[笑]，我想应该是延续了豆瓣一贯的凸显内容价值的质朴风格。

\

\

InfoQ：刚才你谈到会用一些像 typography 方面的一个开发，那这块有哪些重点？你们遇到一些问题是怎么来做解决的？

\

\

石岩：首先是字体渲染这一块，渲染引擎在不同操作系统、浏览器上差别很大，显示屏幕的类型更是决定着实际显示效果。所以需要我们了解字体在不同条件下的渲染方式，这样才能着手做分别的处理和优化。再一个重点就是刚才提到的文字版式处理。具体会在我 27 号的 分享 中介绍。

\

面对这些问题，我们最主要是查资料、求助社区，有机会的话会当面询问专业人员，听取他们的建议。通过权衡现有技术以及实现成本来评定解决方案。在参考纸书优秀版式的同时，还要突出电子阅读的优势，比如代码高亮、运行，大尺寸插图、多媒体组件等。

\

\

InfoQ：豆瓣阅读其实是面向两种人群：读者和作者。在读者阅读时，你之前的分享中提到“会进行一些预渲染的工作”，这样主要是为了提高性能吗？

\

\

石岩：对于 Web 阅读，用户设备的屏幕尺寸以及缩放后的浏览器尺寸无法预知，所以我们不得不在阅读页版心调整后做重新分页。你提到的预渲染可能是在分页前进行的一个必要步骤。

\

\

InfoQ：比如说用户改变他们屏幕大小的时候，豆瓣阅读会相应的去更新渲染，这样实时的过程会不会特别占用浏览器的资源？

\

\

石岩：以目前的实现方式，要根据一本书的长度而定。对于在 IE8 下渲染长篇作品，用户确实会觉得第一次渲染很慢。随着后端作品结构重构完毕，我们已经打算着手进行前端优化，从根本上解决这个问题，做到真正的按需加载按需分页。

\

\

InfoQ：目前的用户呈现方面还在做哪些工作？

\

\

石岩：像刚才提到的，速度肯定还是有优化的空间。一些同类产品，比如 Cloud Reader、Google Books，看得出他们在这方面就做了很多工作，和他们相比还是有一定差距。当然一部分是因为中国的国情，豆瓣阅读要支持更低端的浏览器，所以在实现方面有点束手束脚，所以我们也打算将特性开关应用到分页及渲染上，但所涉及的问题有些复杂，得需要些时间。

\

\

InfoQ：所以你们也会主动去做一些努力把低端的浏览器的量减少？

\

\

石岩：对，现在低端浏览器的访问比例已经很小了。豆瓣阅读会对 IE6、7 用户做提示升级，同时建议国产双核浏览器用户切换到极速模式。

\

\

InfoQ：之前沟通你提到在面向作者的功能中，数据的保存、同步、文档多人共享协作还有一些需要解决的问题？

\

\

石岩：多人协作暂时还没有实现，这也是在人员配备和工作重点两方面权衡后做出的决定。其他的问题，大多已经有了方案，但要一个一个解决。豆瓣的排版系统在不断发展、演化的过程中肯定是要朝更专业的在线文字处理系统去转变，你看现在 Word 和 Pages 都相继推出了各自的 Web 版，所以这方面还是有很多发展空间的。

\

\

InfoQ：豆瓣阅读需要能够在浏览器端保存用户阅读的进度，目前是用 sessionStorage 来做的？

\

\

石岩：进度是后端同步的，前端主要是记录段落 ID 以及跨页时文字的偏移量。这样就可以实现在不同设备上的进度同步了。

\

\

InfoQ：之前豆瓣阅读的一次更新有一个比较大的调整，当时好像是用户不能使用了，你们会不会通过一些方式实现静默升级？

\

\

石岩：之前有太多东西放在 localStorage 里，虽然包含了更新提醒机制，但只考虑了文章的内容，忽略了阅读器本身的一些特性升级，从而造成了数据上的不一致。现在我们已经完善了这个功能，只要有影响到前端展示的功能上线，就会做本地数据的更新。

\

\

InfoQ：行，问题就到此结束。