MessagePort是HTML5中新增加的一个API，它能完成不同上下文之间的消息传递，例如Worker上下文与Document上下文之间的通信就是通过MessagePort来实现的，也可以利用MessagePort来实现浏览器中多个标签页之间的通信。MessagePort对象一般封装在MessageChannel中使用，当开发者申请一个MessageChannel对象时，就得到了配对的两个MessagePort，暂且称为port1和port2，此时往port1中发送数据postMessage(“Hello.”)，在MessageChannel的另外一个端口port2中就可以通过onmessage函数收到信息”Hello”。熟悉Unix进程间通信的同学们，可能会想到该通信方式与Pipe（管道）很类似。进程或者上下文保留通道的一个端口，另外一个进程或上下文则保留另外一个端口，然后端口的发送和接收功能完成消息的传递。
由于Chromium的多进程架构，每个标签页运行在各自的Render进程中（当然这里有例外，当一个标签页是从某个页面跳转而来，并且在同一域名下时，这时多个标签页可能共享同一个Render进程），这里说一般情况是每个标签页运行在一个Render进程中，现在假设其中一个标签页中的MessagePort需要与另外一个标签也中的MessagePort发送消息时，该如何实现呢？由于每个Render进程不能与其他的Render进程通信，只能与Browser进程发生进程间通信，所以MessagePort之间的消息传递就必须通过Browser进程来周转。
正因如此，Chromium在Browser进程中分配了一序列类似MessagePort的对象，由MessagePortService统一管理，它们与Render进程中的MessagePort一一对应，当Render进程中的MessagePort往另外一个Render进程中的MessagePort发送消息时，MessagePort先把消息通过IPC发送给Browser进程，Browser进程中的MessagePortService根据源Port和目的Port找到相对应的Port，然后再通过IPC把消息传递给另外一个Render进程，此时就完成了多个标签页中的消息传递。
流程图如下：
从上图可知，每次MessagePort的消息传递都需要经过两次IPC，，当传输的数据流太大时，就会影响到程序的性能。由于WebWorker也利用了MessagePort来实现Document上下文和Worker上下文的数据传递，所以也会因为传输数据量太大而带来性能的下降。所以当我们需要利用WebWorker去执行复杂的计算，而又设计到大量数据传输时就要留意了。
版权声明：本文为博主原创文章，未经博主允许不得转载。
我要准备好行李启程了，谢谢关心我的家人和朋友，
