为什么现在又流行服务器端渲染html

最开始的页面都是服务端渲染，渲染模板属于后端要做的工作，也就是 mvc 中的 v，各种模板库飞起。
后来出来了一个 ajax 方案，体验效果很好，并且很好的解藕了前后端工作，切图崽（前端岗位的昵称）不需要学习后端模板语法，crud崽（后端昵称）不需要学习 html 语法。并且一套 restful 搞定 web Android iOS 三端。不过呢，切图崽需要用 js *** 作不少 dom 结构。
切图崽不满足于写出那么多接口数据到 dom 结构的不好维护的垃圾代码，于是做了：
1 搞出来前端的 orm，一个后端实体对应前端一个 model，再配五个接口（添加，删除，修改，获取列表，获取单个实体），接口的请求 *** 作统一为 model 实例的方法，再也不用写各种接口请求了。 形成了前端代码中的数据中心。
2 为了 避免 dom *** 作代码繁杂看不懂，于是把数据和 dom 节点绑在一起，dom *** 作变成了配置，清爽不少。形成了前端的数据控制层。
现在我们的前端页面可以直接无刷新增删改查了
当然不够的，我们在切换页面的时候还是会刷新，不行，我们要 spa （单页应用），整个前端我们只需要一个入口，于是前端的路由出来了。
切图崽当然还是不满意的，既然桌面 gui 软件有那么清晰一套 mvc 开发方式，前端作为 gui 开发怎么能没有，再加上之前的工作积累。数据流，数据绑定，ui 组件。方向数据流，数据双向绑定，ui 组件库 满天飞，形成了现在 react angular vue 局势。
至此，似乎已经挺完美了，但是谁知道在这期间 nodejs 出来了，它是什么，就是 JavaScript 的语法啊，我们切图崽天然就掌握一门后端语言语法了
于是我们开始回顾历史，当年我们采用了无刷新提高体验的同时，虽然也去掉了无后端的工作耦合，但是，也放弃了服务端渲染的 seo 啊，如今，我们在不要求后端的情况下，在中间加一个 node 层，就可以解决 seo 问题，也享受 spa 的体验优势…

1 一开始，html 就是后端渲染的。不过后端发现页面中的 js 好麻烦（虽然简单，但是坑多），于是让公司招聘专门写 js 的人，也就是前端

2 前端名义上是程序员，实际上就是在切图（CSS）和做特效(JS)，所以所有程序员中前端工资最低，职位也最低。所以前后端的鄙视链就出现了

3 nodejs 和前端 mvc 的兴起让前端变得复杂起来，前端发现翻身的机会，于是全力支持这两种技术，造成本不该做成 spa 的网站也成了 spa。慢慢地前后端分离运动从大公司开始兴起，目的就是前端脱离后端的指指点点，独立发展。（表面上是为了「代码分离」，实际上是为了「人员分离」，也就是「前后端分家」，前端不再附属于后端团队）

4 spa 之后发现 seo 问题很大，而且首屏渲染速度贼慢，但是自己选的路再难走也要走下去，于是用 nodejs 在服务端渲染这一条路被看成是一条出路

5 其实这是第二个翻身的机会，如果 nodejs 服务器渲染成为主流，其实就相当于前端把后端的大部分工作给抢了，工资压过普通后端指日可待

6 然而结果是 nodejs 服务端渲染始终是小众，因为后端也没那么脆弱，java php rails 十多年沉淀的技术岂是你说推翻就推翻的，已经运行多年的项目又岂是容你随便用 nodejs 重写的，另一方面 golang 等技术的兴起也给 nodejs 不少压力。最终只有少部分前端特别强势的团队成功用上了 Nodejs 做渲染（比如阿里的一些团队），大部分公司依然是用 PHP 渲染 HTML。

7 于是 nodejs 退一步说好好好我不抢你们的工作，我只做中间层（大部分工作就是渲染页面和调用后台接口），绝不越雷池。后端说算你识相。现在 nodejs 主要搞什么微服务，也是为了抢后端还没注意的市场。

你要看一门技术的发展主要应该看背后的人是谁，应用场景是哪些，最后才是技术细节。

Q: 渲染无法连接账户服务器怎么解决 :
1 检查账户服务器的连接状态，确保它处于运行状态。
2 检查客户端与账户服务器之间的网络连接，确保它们之间没有受到阻碍。
3 重启客户端和账户服务器，看看是否能够正常连接。
4 尝试更换不同的客户端，或者尝试使用不同的网络环境。
5 如果以上步骤都无法解决问题，建议联系相关技术人员进行深入排查。

短视频所面临的架构问题：1短视频APP开发时的数据处理需求客户端主要是对于视频的效果叠加、人脸识别和各种美颜美化算法的处理。同时客户端处理还会增加一些必要的转码和水印的视频处理。目前客户端的视频编解码方式，会有软编码和硬编码的方式，软编码主要是兼容性比较好，编码效果好些，不过缺点就是能耗高且慢些。而硬编码借助于显卡等，能够得到比较低的能耗并且更快，不过兼容和效果要差一些，特别是对于一些低配的机型。所以目前往往采用结合的方式。服务端的处理，主要是进行视频的一些审核转码工作，也有一些抽帧生成截图的工作等，目前使用ffmpeg进行一些处理。服务端本身需要考虑的一些点，就是因为资源消耗比较高，所以需要机器数会多，所以在服务端做的视频处理 *** 作，会尽量控制在一个合理的范围。2短视频APP开发中音视频不同步问题媒体内容在播放时，最令人头痛的就是音视频不同步。从技术上来说，解决音视频同步问题的最佳方案就是时间戳：首先选择一个参考时钟（要求参考时钟上的时间是线性递增的）；生成数据流时依据参考时钟上的时间给每个数据块都打上时间戳（一般包括开始时间和结束时间）；在播放时，读取数据块上的时间戳，同时参考当前参考时钟上的时间来安排播放。可见，避免音视频不同步现象有两个关键——一是在生成数据流时要打上正确的时间戳。如果数据块上打的时间戳本身就有问题，那么播放时再怎么调整也于事无补。打时间戳时，视频流和音频流都是参考参考时钟的时间，而数据流之间不会发生参考关系；也就是说，视频流和音频流是通过一个中立的第三方（也就是参考时钟）来实现同步的。第二个关键的地方，就是在播放时基于时间戳对数据流的控制，也就是对数据块早到或晚到采取不同的处理方法。

前端与后端最初的渲染方式是后端模板渲染，就是由后端使用模板引擎渲染好 html 后，返回给前端，前端再用 js 去 *** 作 dom 或者渲染其他动态的部分。这个过程大致分成以下几个步骤：
前端请求一个地址 url
后端接收到这个请求，然后根据请求信息，从数据库或者其他地方获取相应的数据
使用模板引擎（如 java > jsp、php > smarty）将这些数据渲染成 html
将 html 文本返回给前端
在这个过程中，前端的 html 代码需要嵌入到后端代码中（如 java、php），并且在很多情况下，前端源代码和后端源代码是在一个工程里的。
所以，不难看出，这种方式的有这样的几个不足：
前后端杂揉在一起，不方便本地开发、本地模拟调试，也不方便自动化测试
前端被约束在后端开发的模式中，不能充分使用前端的构建生态，开发效率低下
项目难以管理和维护，也可能会有前后端职责不清的问题
尽管如此，但因为这种方式是最早出现的方式，并且这种渲染方式有一个好处，就是前端能够快速呈现服务器端渲染好的页面，而不用等客户端渲染，这能够提供很好的用户体验与 SEO 友好，所以当下很多比较早的网站或者需要快速响应的展示性网站仍然是使用这种方式。

如果你只是一个简单的页面，PHP直接来比较简单。但有一种情况：页面内容较多的长页面；并发量较大。
那么，PHP渲染结构，ajax渲染细节，就体现出威力了。这样可以更快地响应客户端（服务器处理的逻辑少了），用户能更快地看到东西，而不是浏览器转圈圈。
之后的ajax，也只是数据传递，渲染结构还是在浏览器，服务器少了很多字符串的 *** 作，必然比一次性在服务端渲染要好。
更甚至说，你可以把每个区域的请求分发到不同的业务系统，做好跨域就行了。

Arm 服务器侧渲染，是通过GPU虚拟化来做。云手机就是在服务器上，部署容器和安卓系统，在手机侧可以不需要安装就玩游戏、或者24小时在线。PCI-e显卡的开源驱动已经有了，但还需要厂家进一步开发。

---