阅文前端技术选型

10,265 阅读12分钟
原文链接: mp.weixin.qq.com

原创声明

本文为阅文体验设计 YUX 成员出品,请尊重原创,转载请联系阅文体验设计微信公众号 ( id: YUX_design ) 获取授权,并注明作者、出处和链接。

介绍阅文,了解阅文,包括团队,包括技术。

一、技术选型总策略「 企业收益最大化」

对于前端团队,可以实现企业收益最大化的要点概括如下:

保证产品质量

1. 功能稳健:网页不白屏不错位不卡死,操作正常,数据精准;

2. 体验优秀:加载体验、交互体验、视觉体验、无障碍访问「 搜索引擎、辅助设备 」…

降低人力成本

1. 降低前期开发成本;

2. 降低后期维护成本;

几乎所有的项目的技术选型都是基于上面的策略和要点来制定。

由于不同项目的用户群体、平台以及场景都有所差异,在技术选型上的侧重点也不一样。对外的站点更侧重用户体验,对内的站点更侧重操作敏捷和人力成本的控制。

二、前端开发模式选型

阅文用户体验设计部前端组目前人数接近 20 人,我们支援着阅文各个产品线。

阅文产品线的开发模式

1. 纯前端开发;

2. 前后端分离开发;

3. 后端主导开发;

1. 纯前端开发

主要针对静态页面,没有模板和框架机参与,基本上前端小伙伴一个人 Hold 全场。例如:阅文官网、招聘站以及一些设计感强烈且重要的运营活动页面等。

由于自主权全部在我们前端开发者自己手里。因此很容易使用自研的 Node.js 工具进行辅助开发,上线「 压缩、统计和分享注入 」等。

目前用得比较多的工具是「 波波桌面版 」:https://github.com/yued-fe/bobo-electron

▲ 波波桌面版

2. 前后端分离开发

阅文超过 8 成以上大中型项目均是采用前后端分离开发模式。根据项目特性,要么 Node.js 进行模板渲染,要么 Web 侧进行模板渲染,但本质上都是 JavaScript 对页面进行构建,控制权都掌握在前端手中。

集团下各类小说阅读站点 PC 站,Mobile 站,以及对应的后台系统等均可归为这类项目。

其中,直出模板渲染采用自研框架机「 Ynode 」:https://github.com/yued-fe/yuenode

还有前端开发工作流工具「 Yworkflow 」:https://github.com/yued-fe/Yworkflow

这和大多数前端团队工作流大同小异,就不再赘述。

3. 后端主导开发

由于不可抗拒的历史原因,阅文这边仍有类似内部行政系统之类的产品线,采用的是后端渲染页面的开发模式。在和这些项目进行合作的时候,前端在交付原型时会有很多克己的行为:

1. 不使用类似 Sass ,Less 之类的前端预处理器

2. 不使用类似 Seajs 之类的模块化组件库,而是采用效率更低的人工模块整合

3. 不自嗨不追新立异,如 Vue 很火自己就随随便便用起来是要被挑战的;

在这些项目中前端属于支援角色,后期维护通常是其他合作部门同事「 偏后端的开发 」。前端工程化的东西,流行的新技术,对于这些同事而言应付起来是相对比较吃力的。结果就产生了维护很痛苦,然后去知乎回答「 维护公司前人写的烂代码是什么样的体验? 」 这种问题。

前后端分离以及前端工程化确实让开发更便利。但是在这些项目中,需要主动放弃自己的舒适区,使用更基础代码采用更传统手作方式,通过良好代码设计来保证品质「 如参数接口全部暴露在外,后端可以轻松配置,而非通过约定,耦合在 JS 中 」。

这些处理确实给前端开发增加不少人力成本,但是最终成果是项目可以持续健康维护下去,这种克己与一定的「 自我牺牲 」 来保证合作上顺畅,才是真正职业的体现。

三、具体的前端开发技术选型「 上海团队 」

上海团队主业务为各个阅读站点。对于同一个类型的项目,目前所采用的开发模式、使用的基本框架都是一致的。

前端技术选型「 项目类型 」

1. 用户群为外部用户的 PC 站;

2. 用户群为外部用户的 Mobile 站;

3. 用户群为外部用户的 Native App 开发;

4. 用户群为内部员工的管理后台;

1. 用户群为外部用户的PC站

例如: 起点中文网、起点女生网、起点海外版、红袖添香、小说阅读网、言情小说吧…

前后端分离开发,页面直出渲染,基于 jQuery 开发。

采用直出渲染原因

1. 更好的加载体验;

2. 更好的 SEO ;

使用 jQuery 开发原因

1. 需要兼容 IE8 ;

2. 受众群体是外部用户,视觉体验非常重要,权重较高。因此,更适合先有形,再有行,也就是视觉和行为要尽可能分离,是会牺牲一点开发成本,但显然这里用户更重要;

3. 绝大多数页面交互如此轻量根本用不到数据驱动;

使用的 UI 框架为 LuLu UI「 http://l-ui.com/ 」,尤其后期项目,LuLu UI 全面接管。

▲  LuLu UI

LuLu UI 是一个设计驱动,对用户侧产品更友好更灵活的 UI 框架。

2. 用户群为外部用户的 Mobile 站

例如:起点中文网 M 站、起点女生网 M 站、起点海外版 M 站、红袖添香 M 站、小说阅读网 M 站、言情小说吧 M 站…

这里 Mobile 站以浏览器访问为主,因此,页面切换还都是传统链接跳转,属于传统 Web 页面,前后端分离开发,页面直出渲染,因此选型上采用 Zepto.js 开发。

 ▲  React

值得一提的是,起点海外版由于在海外,你懂的,因此已经上线了 AMP 以及 PWA ,同时目前正在尝试 React 进行重构。为什么会考虑采用 React 进行技术选型呢?下面来看看主创人员飞飞是怎么说的:

大致内容为:选用 React 是为了和 APP 端的 React Native 保持同步,以及介绍了起点海外版在 AMP 以及在 PWA 上的探索。

3. 用户群为外部用户的 Native app 开发

阅文这边前端组有直接参与 Native APP 开发的项目,使用的是 React Native 进行开发。

▲  React Native

为何会选择 React Native ?以及有没有什么经验分享?来看看主创人员文康是怎么说的:

大致意思是:之前 Hybrid 模式开发有性能瓶颈,采用 React Native 性能可以突破这个瓶颈,且支持热更新,上手也不算太难,跨平台,iOS 和 Android 代码重用率 90%+ 。适合动画不太复杂的项目,但最终还是要根据项目来。特别指出非常适合快速迭代的项目或者前期需要大量试错的项目。

两点建议

①. 不要随意使用第三方库,后期修改维护不方便,尽量自己写还是自己写;

②. 另外需要客户端同学支持,尤其前期,因为前端对底层理解还是吃力的,需要资深客户端同学帮忙配合;

4. 用户群为内部员工的管理后台

前后端分离开发,页面web侧异步渲染,使用 Vue.js

▲  Vue.js

企业管理后台项目为什么会考虑采用 Vue.js 进行技术选型呢?有什么使用经验呢?下面来看看主创人员成荣是怎么说的:

大致内容是:后台管理系统有大量增删改查操作,适合具有双向绑定的类库或框架进行渲染。同时没有兼容性的要求「 如 SEO ,首屏渲染 」,因此,单页应用是合适的。可供选择的是 Angular ,React 和 Vue 。之所以选择 Vue.js 是因为 Vue.js 对 API 、文档等对开发者更友好。

然后分享了使用 Vue上 的一些经验,包括选用好的 UI 组件、规范贯彻、拆分和按需加载。提到了自动化测试还有待建设。

四、北京团队所使用的前端技术及场景

北京团队产品和业务线几乎和上海团队完全独立,因此,前端技术选型这一块会有一些自己的实践。下面是赵冉带来的相关介绍:

Vue.js

提供了一个类似于 React 的虚拟 DOM 视图层,可以与其他库集成,它也能支持单页应用程序,轻量级,易于上手。适合需要短期开发的活动页面和交互较复杂的端内页面。但是 Vue 的页面渲染方案导致了首屏加载过慢,初次加载耗时较多,为了解决这个问题,我们考虑在首屏使用服务端渲染,目前还没有线上项目。

React Native

使用 JavaScript 高效开发媲美原生的跨平台 App 。目前我们在 「 QQ 阅读V6.6.1 版本 」迭代中,首次采用了 RN 「 React Native 」 框架来开发勋章馆和单个勋章详情页,在客户端同学接入 RN 并成功完成 APP 版本迭代后,前端开始逐步介入 RN 开发。

Template.js

前端只需要写一个模板文件即可根据传入的不同数据,生成对应数据产生的HTML片段,渲染不同的页面效果。在前后端分离之前,客户端内嵌页面一直采用这种模板技术方案。

NPM

便于下载项目中用到的各种 Node 模块,Scripts 功能可以用于通用的任务执行,目前我们是配合 Webpack 一起使用。

Yarn

会缓存它下载的每个包,无需重复下载。还能并行化操作以最大化资源利用率,安装速度比 Npm 快一些。

Webpack

有 Browserify 和 RequireJS 的全部功能,把项目当做一个整体,通过一个给定的主文件「 如:index.js 」,Webpack 将从这个文件开始找到项目的所有依赖文件,使用 loaders 处理它们,最后打包为一个或多个浏览器可识别的 JavaScript 文件。目前使用 Webpack 来进 Js 、Less 、Sass、.vue 等文件的编译、提取和打包压缩,实现项目的自动化构建。

CSS 预处理器

使用动态样式语言方便快捷的书写项目中的 CSS ,便于编写可复用的 CSS 模块。根据项目需求,目前较多地使用了诸如变量,混合宏,类占位符,嵌套等。也在尝试使用 PostCSS 的 CSSnext 插件来处理 CSS 样式。

Bodymovin

▲  Bodymovin 动效

通过和设计师配合,设计师使用 AE 做出动效后,导出带有矢量动画信息的 Json 文件,在 Web 页面上,前端通过渲染 Json 文件还原动效。在 App 开发过程中,适当的使用动画可以提升用户体验,使我们的产品锦上添花。对于一些简单的动画,我们很容易就能实现,但是对于一些比较复杂的动画,我们可能要选择合适的实现方案,Bodymovin 是一个比较好的选择,它的优势在于开发效率及动画本身的流畅度和高还原度。我们在「 658 宣导活动 」中使用了该技术,不仅节约了动效实现的时间而且 100% 还原了设计师的动画需求。

Lottie

Lottie 是 Airbnb 开源的一个支持 Android、iOS 以及 React Native,利用 Json 文件的方式快速实现动画效果的库。在使用 RN 开发之后,复杂的动画效果我们将尝试使用 Lottie 来实现。目前 「 QQ 阅读 V6.6.1 」勋章详情页的动画效果,客户端开发小伙伴一开始看了设计的动画要求是犹豫的,因为第一次使用 RN 来做开发,且开发周期有限。前端将 Lottie 库推荐给他们后,只需简单的代码就可以实现动画效果。

五、总结

对于比较正式的项目,阅文这边的前端技术选型策略一定是产品收益最大化用户放在首位,考虑到亿级的用户量,自然技术选型要更谨慎,于是优先选择成熟、经典的解决方案。

但这并不意味着排斥热门技术。相反,就算是还不成熟的新技术,只要能对产品带来明显收益的,一定是鼓励应用的。例如起点海外版中 AMP 和 PWA 的实践。

但这也会带来另外一个问题,技术人员对新技术有着天然的学习与实践诉求,因为这有助于降低内心的焦虑和不安全感。

尤其是对技术有着狂热爱好的小伙伴。这些成熟项目由于规范的约束,不能随便乱来,很容易让开发人员有报国无门的感觉,这又当如何平衡

通过边缘项目,实验性质项目,以及团队会自发发起一些有价值的内部项目来满足这样的诉求,同时积累宝贵经验。相当于嵌入了非常重要的一块板,让产品、团队和个人都达到非常好的平衡。

另外,个人觉得,阅文前端相对要更谨慎更低调些。实际上一个团队对于技术选型的气质风格往往企业的文化基因有着密切关系。

产品驱动的文化下,心中想的更多是把用户和产品做得更好,让技术服务于产品,因产品而技术,而非因技术而技术。

运营驱动的文化下,本质上是吆喝做买卖,因此站在风口浪尖,成为前沿技术的弄潮儿就和企业文化比较契合。再进一步,其实就是企业创始人的风格。

原创声明

本文为阅文体验设计 YUX 成员出品,请尊重原创,转载请联系阅文体验设计微信公众号 ( id: YUX_design ) 获取授权,并注明作者、出处和链接。