xylophone21

感谢大家的意见,问题解决了,总结如下:
1.审核确实会看线上所有有效的版本,也就是说线上版本 A 如果有问题,试图更新一个版本 B 去掉这个功能是不行的.我们有一次审核被拒明确说明了原因,A 版本有问题,B 版本 OK.
2.按照被拒邮件的提示,提供的视频链接 *并且* 在应用说明增加使用这个权限的原因. 原因解释的稍微有一些牵强,好在通过了.
3. 新版本设置了自动发布(即关闭自管式发布模式),不确定是否有影响.

@wujianhua22 即使开发了,也上不了线,审核不通过.

@joke2032 审核不过,没法发布


@kokutou 上架一遍 FOREGROUND_SERVICE_DATA_SYNC 版本的 带什么样的说明呢? 我们的 App 用这个权限确实用错了,不应该用

> 毕竟出厂后增减传感器的几率不大
看起来像深坑

不好意思，写到一半想岔了，目标是防止多端登录，写着写着想成了如何实现多端登录。
第一种情况不变，第二种情况下实际上就变成了第二个端登录时，如何吊销第一个端的 JWT ？好了标准答案来了，标准的 JWT 不支持提前吊销。那怎么办？当然是非标准的 JWT ，比如前面提到的把 JWT 存到 Redis ，以及如果你更多的搜一下可以找到的优化方案--只存吊销列表的布隆等

你如何定义多端登录？至少在上面的讨论中看到过两种定义
1.用第三方的客户端多端登录，别说 jwt ，即使是 session ，你也拦不住对方多端交换 sessionid/token ，然后把这些塞到 HTTP 头里。除非你每个接口都刷新，但这样万一失败一次，登录就被踢了，体验恐怕很难做好。
2.用你的客户端，浏览器多端登录。那把客户端 Id 塞到 JWT 不就可以了

可能我们这一代人赶上了几次技术的大突破就把这个当成习惯了,互联网,移动互联网,AI. 8 年过去了, 别说智能家居行业,就是整个大互联网行业, 有几个 8 年前后的对比，有很多惊喜的? GPT 可能算一个, 其他呢?

扫地机,基础的场景早就稳定了, 后续上下水基站可能算一个创意突破, 再往后就是拼算法了,可不是创意和代码可以解决的.
再说门锁,用户最核心的需要场景其实就那么几个,再往后拼的可不就是你说的稳定性这些"玄学"? 以及指纹识别,人脸识别这些算法上?

这些算法如果没有显著的技术进步,这些体验都很难有质的提升. 但是很可惜,这几年算法的进步都往大模型走了, 这方面的进步似乎并不多.

另外说到互联互通, 如果仅仅是通,可以国内可以看看小米或者百度的生态,海外可以看看 Matter 和 HA 生态. 但通了之后,除了少装一个 App 外(现在手机存储大了,这个问题好像也不是那么痛了), 互动的场景又有多少是真的需求?

总结一下, 能用创意解决的场景,需求枯竭,包括苹果在内都没有好的场景;痛点方面,技术(基本都是算法)又跟不上. 所以这可能根本不是"代码和创意"的问题. 移动互联网到来之前,互联的的创意已经非常少了,移动互联网一来,创意就如雨后春笋了. 这个世界的发展本来就是螺旋上升.

这样做有一个限制,就是设备和设备之间的互发消息必须少,而且需要你通过业务来转发实现.如果这种转发太多且无规律,实际上你就是一个 Broker 集群了. 一般来说,需要通过你的业务来简化这个模型.比如一般的物联网场景下,设备和设备之间是不需要相互发消息的,但如果你有网关类设备,就又不一样了,需要特殊处理.

@laters 有这个问题是因为你的两个 Broker 没有组成集群,这要看你问题规模.
1. 如果规模小,就建集群,往哪个 broker 发另一个都能收到的.你可以想象成 Client A 连接了 Broker A,订阅了 a topic, B 连 B,然后给 a topic 发 pub. 问题是集群是有上限和代价的,特别是社区版.
2. 如果规模大,集群搞不定或者不想买商业版,那就自己控制路由.设备连 Broker 之前,通过接口拿到节点的域名(如何分配看你的业务),然后再连接.这样 Broker 之间没有联系,集群规模的大小就只受你业务能力的限制.当然,为了高可用,实际上你的每个节点还是一个小集群,但这是另外一个故事.