做3D渲染图用那个处理器好、AMD？酷睿？好在哪里..

实际用起来 AMD 的要好 。
配AMD 7750 还是很好的 ，inter酷睿的实际上不是很快 ，而且有点反应迟钝
AMD 游戏还是做处理都快些
T6400 和我 T4200VISTA 下都是49分 ，
AMD 4000＋ 都有 51 超频53分虽然AMD 的 跑圆周率慢，但是实际快inter 的跑圆周率快，实际上慢。
AMD公司专门为计算机、通信和消费电子行业设计和制造各种创新的微处理器（CPU、GPU、APU、主板芯片组、电视卡芯片等)、闪存和低功率处理器解决方案，AMD致力为技术用户——从企业、政府机构到个人消费者——提供基于标准的、以客户为中心的解决方案。
AMD是目前业内唯一一个可以提供CPU、GPU、主板芯片组三大组件的半导体公司，AMD提出3A平台的新标志，在笔记本领域有“AMD VISION”标志的就表示该电脑采用3A构建方案。

本文主要介绍 UmiJS 的预渲染功能。

服务端渲染（Server-Side Rendering），是指由 服务端 完成页面的 HTML 结构拼接的页面处理技术，发送到浏览器，然后为其绑定状态与事件，成为完全可交互页面的过程。

服务端渲染，首先得有后端服务器（一般是 Nodejs）才可以使用，而没有后端服务器的情况下，可以使用 预渲染 。

预渲染与服务端渲染唯一的不同点在于 渲染时机 ，服务端渲染的时机是在用户访问时执行渲染（即实时渲染，数据一般是最新的），预渲染的时机是在项目构建时，当用户访问时，数据不一定是最新的（ 如果数据没有实时性，可以直接考虑预渲染 ）。

预渲染在构建时执行渲染，将渲染后的 HTML 片段生成静态 HTML 文件。无需使用 web 服务器实时动态编译 HTML，适用于 静态站点生成 。

Umi3 在 SSR 上做了大量优化及开发体验的提升，具有以下特性：

默认情况下，服务端渲染时关闭的，可通过配置开启：

服务端渲染的数据获取方式与 SPA(单页应用) 有所不同，为了让客户端和服务端都能获取到同一份数据，Umi 提供了页面级数据的预获取。

每个页面可能有单独的数据预获取逻辑，这里我们会获取页面组件上的 getInitialProps 静态方法，执行后将结果注入到该页面组件的 props 中，如：

getInitialProps 有几个固定参数：

为了结合数据流框架，我们提供了 modifyGetInitialPropsCtx 方法，由插件或应用来扩展 ctx 参数，以 dva 为例：

然后在页面中，可以获取到 store ：

同时也可以在自身应用中进行扩展：

同时可以使用 getInitialPropsCtx 将服务端参数扩展到 ctx 中，例如：

在使用的时候，就有 req 对象，不过需要注意的是，只在服务端执行时才有此参数：

则在执行 getInitialProps 方法时，除了以上两个固定参数外，还会获取到 title 和 store 参数。

关于 getInitialProps 执行逻辑和时机，需要注意：

执行 umi build ，除了正常的 umijs 外，会多一个服务端文件： umiserverjs （相当于服务端入口文件）。然后在后端框架中，引用该文件：

render 方法参数和返回值如下：

完美兼容客户端动态加载，配置如下：

@umijs/preset-react 插件集中已内置对标题的渲染，通过以下步骤使用：

@umijs/preset-react 插件集中已内置 dva

这时候 getInitialProps(ctx) 中的 ctx 就会有 store 属性，可执行 dispatch ，并返回初始化数据。

Umi 同时支持对服务端和客户端包大小的分析

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 主要搞什么微服务，也是为了抢后端还没注意的市场。

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

---