其实你就理解为 MPA 是若干个 SPA 组合在一起就行了。 SPA 才是后来有的,在 HTML5 的 history 相关 API 出来之前,哪有什么 SPA?全是 MPA 啊。只不过那个时候大家也没有 SPA/MPA 这种分立的概念,所以没给 MPA 起个名叫 MPA,但人家就是 MPA 啊。 严格来说 SPA 跟 MPA 最大区别就是有没有页面刷新,SPA 都在一个 HTML 文档里,MPA 会有多个。 SPA 在一个文档里你可以搞什么 vuex、组件通信这些东西,这都很简单;MPA 里是跨页面了啊,弄这些东西就很复杂。这看上去 SPA 更胜一筹,全都 SPA 好了。 但你业务避免不了会膨胀啊,比如阿里云的控制台,是典型的 MPA。有上百的云服务,每个云服务都有一个入口页面,每个云服务下还会有几个到几十个不等的子页面,合起来有上千的页面。这肯定不是一个 Team 能完成的能完成的。 假如用 SPA 了,若干的 Team 配合的话,入口文件频繁冲突怎么办?全局变量冲突怎么办?假如 ECS(云服务器)的页面改了、要部署就只重新打包 ECS 相关的就好了啊,你 SPA 不得整个项目全重新打包?何必?好,上述问题你全能克服,可上千个页面,每个页面的 data 全都读到内存里,你这得占多少资源? 这时候,我们就可以按粒度拆分 SPA 到 MPA 了。比如把 ECS 相关的,都放在一个 SPA 里;把 RDS 相关的,放在另一个 SPA 里;这俩 SPA,组合成一个 MPA,彼此之间互不干扰,也就没有冲突了。
其实你就理解为 MPA 是若干个 SPA 组合在一起就行了。
SPA 才是后来有的,在 HTML5 的 history 相关 API 出来之前,哪有什么 SPA?全是 MPA 啊。只不过那个时候大家也没有 SPA/MPA 这种分立的概念,所以没给 MPA 起个名叫 MPA,但人家就是 MPA 啊。
严格来说 SPA 跟 MPA 最大区别就是有没有页面刷新,SPA 都在一个 HTML 文档里,MPA 会有多个。
SPA 在一个文档里你可以搞什么 vuex、组件通信这些东西,这都很简单;MPA 里是跨页面了啊,弄这些东西就很复杂。这看上去 SPA 更胜一筹,全都 SPA 好了。
但你业务避免不了会膨胀啊,比如阿里云的控制台,是典型的 MPA。有上百的云服务,每个云服务都有一个入口页面,每个云服务下还会有几个到几十个不等的子页面,合起来有上千的页面。这肯定不是一个 Team 能完成的能完成的。
假如用 SPA 了,若干的 Team 配合的话,入口文件频繁冲突怎么办?全局变量冲突怎么办?假如 ECS(云服务器)的页面改了、要部署就只重新打包 ECS 相关的就好了啊,你 SPA 不得整个项目全重新打包?何必?好,上述问题你全能克服,可上千个页面,每个页面的 data 全都读到内存里,你这得占多少资源?
这时候,我们就可以按粒度拆分 SPA 到 MPA 了。比如把 ECS 相关的,都放在一个 SPA 里;把 RDS 相关的,放在另一个 SPA 里;这俩 SPA,组合成一个 MPA,彼此之间互不干扰,也就没有冲突了。