2个浏览器窗口间通信

1.localStorage

一个窗口更新localStorage,另一个窗口监听window对象的“storage”事件,来实现通信

注:两个页面要同源

//本窗口的设置代码
localStorage.setItem(‘aaa‘, (Math.random() * 10).toString())
//其他窗口监听storage事件
window.addEventListener("storage", function(e){
   console.log(e)
   console.log(e.newValue)
})

2. WebSocket

所有的WebSocket都监听同一个服务器地址,利用send发送消息,利用onmessage获取消息的变化,不仅能多窗口,还能跨浏览器,兼容性最佳,只是需要消耗点服务器资源。

var ws = new WebSocket("ws://localhost:3000/")
ws.onopen = function(event){
  //或者把此方法注册到其他事件中,即可与其他服务器通信
  ws.send({now: Date.now()});  //通过服务器中转消息
};
ws.onmessage = function(event) {
  //消费消息
  console.log(event.data);
}

3. postMessage

借助iframe 或 window.open

回顾一下API

otherWindow.postMessage(message, targetOrigin, [transfer]);

1) otherWindow

其他窗口的一个引用,比如iframe的contentWindow属性、执行window.open返回的窗口对象、或者是命名过或数值索引的window.frames.

2) message

将要发送到其他window的数据。它将会被结构化克隆算法序列化。这意味着你可以不受什么限制的将数据对象安全的传送给目标窗口而无需自己序列化。

3) targetOrigin

通过窗口的origin属性来指定哪些窗口能接收到消息事件,其值可以是字符串“”(表示无限制)或者一个URI。在发送消息的时候,如果目标窗口的协议、主机地址或者端口这三者的任意一项不匹配targetOrigin提供的值,那么消息就不会被发送;只有三者完全匹配,消息才会被发送。这个机制用来控制消息可以发送到哪些窗口;例如:当用postMessage传送密码时,这个参数就显得尤为重要,必须保证它的值与这条包含密码的信息的预期接受者的origin属性完全一致,来防止密码被恶意的第三方截获。如果你明确的知道消息应该发送到哪个窗口,那么请始终提供一个确切值的targetOrigin,而不是,不提供确切的目标将导致数据泄露到任何对数据感兴趣的恶意站点。

4) transfer可选

是一串和message同时传递的Transferable对象。这些对象的所有权将被转移给消息的接收方,而发送一方将不再保有所有权。

/*
 * A窗口的域名是<http://example.com:8080>,以下是A窗口的script标签下的代码:
 *
 */

var popup = window.open(...popup details...);

//如果弹出框没有被阻止且加载完成

//这行语句没有发送消息出去,即使假设当前页面没有改变location(因为targetOrigin设置不对)
popup.postMessage("The user is ‘bob‘ and the password is ‘secret‘", "https://secure.example.net");

//假设当前页面没有改变location,这条语句会成功添加message到发送队列中去(targetOrigin设置对了)
popup.postMessage("hello there!", "http://example.org");

function receiveMessage(event) {
    //我们能相信信息的发送者吗?(也许这个发送者和我们最初打开的不是同一个页面)
  if(event.origin !== "http://example.org") return;

//event.source 是我们通过window.open打开的弹出页面 popup
//event.data 是 popup发送给当前页面的消息 "hi there yourself! the secret response is: rheeeeeet!"
}

window.addEventListener("message", receiceMessage, false);
/*
 * 弹出页 popup 域名是<http://example.org>,以下是script标签中的代码:
 *
 */
function receiveMessage(event) {
   //我们能信任信息来源吗?
  if (event.origin !== "http://example.com:8080") return;

   //event.source 就当前弹出页的来源页面
   //event.data 是 "hello there!"

   //假设你已经验证了所收到信息的origin(任何时候你都应该这样做),   //一个很方便的方式就是把event.source作为回信的对象,并且把event.origin作为targetOrigin
  event.source.postMessage("hi there yourself! the secert response " + "is: rheeeet!", event.origin);
}
window.addEventListener("message", receiveMessage, false);

4. cookie + setInterval【差】

在页面A设置一个使用 setInterval定时器不断刷新,检查Cookies的值是否发生变化,如果变化就进行刷新的操作。

由于Cookies是在同域可读的,所以在页面B审核的时候改变Cookies的值,页面A自然是可以拿到的。

这样做确实可以实现想要的功能,但是这样的方法相当浪费资源。虽然在这个性能过盛的时代,浪费不浪费感觉不出来,但是这种方案,确实不够优雅。

5. SharedWorker

HTML5中的Web Worker 可以分为2种不同的线程类型,一个是专用线程 Dedicated Worker,一个是共享线程 Shared Worker。

1) Dedicated Worker 直接使用 new Worker() 即可创建,这种webworker是当前页面专有的。

2) SharedWorker 可以被多个window、标签页、iframe共同使用,但必须保证这些标签页都是同源的(相同的协议、主机和端口号)

6.直接引用

其实就是直接获取对方DOM,适用于2个页面在同一域;可以传递对象数据(对象数据使用 instanceof 做类型判断时有坑);参考window.open;

例:

//父页面获取iframe
document.getElementById("iframe的id").contentWindow.document

//子iframe获取父页面
window.parent.document

7. window.name

浏览器窗口有window.name属性。这个属性的最大特点是,无论是否同源,只要在同一窗口里,前一个网页设置了这个属性,后一个网页可以读取它。

父窗口先打开一个子窗口,载入一个不同源的网页,该网页将信息写入window.name属性

window.name = data

接着,子窗口跳回一个与主窗口同域的网址

window.location.href = "http://parent.url.com/xxx.html";

然后,主窗口就可以读取子窗口的window.name了

var data = document.getElementById("iframe的id").contentWindow.name;

这种方法的优点是,window.name容量最大,可以放置非常长的字符串;缺点是必须监听子窗口window.name属性的变化,影响网页性能。

原文地址:https://www.cnblogs.com/starrk-01/p/9945608.html

时间: 2024-11-08 03:57:22

2个浏览器窗口间通信的相关文章

node-webkit 新建实例窗口间通信问题解决办法

终于弄明白这问题了,只要在js文件里加上段代码,就可解决两窗口间通信问题. var str = { username: User.name, userrole: User.role };// var new_win = Task.openWin('home.html'); var new_win = gui.Window.get(window.open('home.html', {focus: true}) ); new_win.on('loaded', function (User) { ne

JavaScript通过更改Web Storage实现页面间通信

这个API的作用是,使得网页可以在浏览器端储存数据.它分成两类:sessionStorage和localStorage. sessionStorage保存的数据用于浏览器的一次会话,当会话结束(通常是该窗口关闭),数据被清空:localStorage保存的数据长期存在,下一次访问该网站的时候,网页可以直接读取以前保存的数据.除了保存期限的长短不同,这两个对象的属性和方法完全一样. 它们很像cookie机制的强化版,能够动用大得多的存储空间.目前,每个域名的存储上限视浏览器而定,Chrome是2.

架构设计:系统间通信(32)——其他消息中间件及场景应用(下2)

(接上文<架构设计:系统间通信(31)--其他消息中间件及场景应用(下1)>) 5-3.解决方案二:改进半侵入式方案 5-3-1.解决方法一的问题所在 方案一并不是最好的半侵入式方案,却容易理解架构师的设计意图:至少做到业务级隔离.方案一最大的优点在于日志采集逻辑和业务处理逻辑彼此隔离,当业务逻辑发生变化的时候,并不会影响日志采集逻辑. 但是我们能为方案一列举的问题却可以远远多于方案一的优点: 需要为不同开发语言分别提供客户端API包.上文中我们介绍的示例使用JAVA语言,于是 事件/日志采集

线程间通信和线程互斥

线程间通信 1> 线程间通信分为两种 主线程进入子线程(前面的方法都可以) 子线程回到主线程 2> 返回主线程 3> 代码 这个案例的思路是:当我触摸屏幕时,会在子线程加载图片,然后在主线程刷新UI界面 视图布局我就不写了,大家自己来吧,线程间通信代码如下: #pragma mark - 添加响应方法触发创建子线程并加载数据 - (void)touchesBegan:(NSSet<UITouch *> *)touches withEvent:(UIEvent *)event

系统间通信(8)——通信管理与RMI 上篇

1.概述 在概述了数据描述格式的基本知识.IO通信模型的基本知识后.我们终于可以进入这个系列博文的重点:系统间通信管理.在这个章节我将通过对RMI的详细介绍,引出一个重要的系统间通信的管理规范RPC,并且继续讨论一些RPC的实现:再通过分析PRC的技术特点,引出另一种系统间通信的管理规范ESB,并介绍ESB的一些具体实现.最后我们介绍SOA:面向服务的软件架构. 2.RMI基本使用 RMI(Remote Method Invocation,远程方法调用),是JAVA早在JDK 1.1中提供的JV

HTML教程-各窗口间相互操作(Frame Target)

由Frames分出来的几个窗口的内容并不是静止不变的,往往一个窗口的内容随着另一个窗口的要求而不断变化,这就提高了Frames的利用价值.为了完成各窗口之间的相互操作,我们必须为每一个窗口起一个名字,这个名字用属性Name来定义. 窗口标识(Frame Name)  <frame src=url name="窗口名"> 例如: <frame src="frame/a.html" name="left"> 定义了窗口名称,还

架构设计:系统间通信(28)——Kafka及场景应用(中1)

(接上文<架构设计:系统间通信(27)--其他消息中间件及场景应用(上)>) 在本月初的写作计划中,我本来只打算粗略介绍一下Kafka(同样是因为进度原因).但是,最近有很多朋友要求我详细讲讲Kafka的设计和使用,另外两年前我在研究Kafka准备将其应用到生产环境时,由于没有仔细理解Kafka的设计结构所导致的问题最后也还没有进行交代.所以我决定即使耽误一些时间,也要将Kafka的原理和使用场景给读者详细讨论讨论.这样,也算是对两年来自己学习和使用Kafka的一个总结. 4.Kafka及特性

架构设计:系统间通信(23)——提高ActiveMQ工作性能(中)

(接上文<架构设计:系统间通信(22)--提高ActiveMQ工作性能(上)>) 6.ActiveMQ处理规则和优化 在ActiveMQ单个服务节点的优化中,除了对ActiveMQ单个服务节点的网络IO模型进行优化外,生产者发送消息的策略和消费者处理消息的策略也关乎整个消息队列系统是否能够高效工作.请看下图所示的消息生产者和消息消费者的简要工作原理图: Producer既是消息生产者,作为一个发送消息的客户端它既可以使用同步消息发送模式,也可以使用异步的消息发送模式.另外,消息生产者在Acti

架构设计:系统间通信(31)——其他消息中间件及场景应用(下1)

接上文:<架构设计:系统间通信(30)--Kafka及场景应用(中3)> 5.场景应用--电商平台:浏览记录收集功能 事件/日志收集系统是大中型软件不得不面对的话题.目前第三方业务系统对 事件/日志收集系统 的集成思路主要有两大类:侵入式收集方案和非侵入式收集方案.侵入式收集方案,是指任何需要使用事件/日志收集系统的第三方系统,都需要做有针对的编码工作,这个编码工作或者是新增代码用于调用 事件/日志收集系统 提供的客户端API,又或者是修改已有的代码,以便适应事件/日志收集系统的调用特性. 侵