thinkershare

@wdc63 没有这种数据结构, 不用找了

前后端不跨域的情况, 都直接使用相对地址发起 ajax 或追 fetch 请求就好了嘛

取决于你的前端是否和后端部在再同一个 IP 的同一个 Port 上.
也就是$protocal://host:port 这个部分只要前后端是一致的, 那么可以使用相对地址. 不过一些复杂的网站的 service 的 url 特别多, 肯定是需要写死在前端, 或追至少要写死一个 1 个获取其它地址的统一入口地址.
例如: Nginx 代理: 192.168.0.1:5001(API+vue public resources), 局域网直接使用局域网地址, 然后 Nginx 使用 https://host 访问, 所有 API 都是以相对地址请求: post: /api/app/token 这种, 没啥问题

@feller 一直使用 scp -r $dir $dist

用过 three.js, Unity3D 结论是效果都不够好. 需要优化的地方太多. 做的漂亮要看设计和美工. 做的顺滑就需要优化上下大力气. 我是没有耐心再搞这个玩意了.

去 github 上搜索, 基本上每个方向都有人做技能树. 但计算机领域实在有太多方向了, 人力有限, 也只能选择几个有限方向, 越是深入, 领域就越是细分. 但最基础也是最核心的, 就是 CS 考研需要考的哪几门.

@LeeReamond 我晚上回去打 log 看下各个地方的耗时, 我现在都没有跨网络, 本机测试延迟都是 1400ms, server, provider, render 都在本机.

2MB 的 base64 str(本来是 bytes, 但因为某些原因, 我需要将其编码为 base64), 然后还原到 bytes-> 然后转换为 numpy, 然后转换为 tensor, 然后使用 mayavi 显示(10W-20W 个 point cloud), 最终就是非常慢. 反序列化这一部分就已经需要秒级了. 最终完成一次窗口绘制, 时间就超过 5s 了. 主要还是二进制序列化太消耗时间了. 不做二进制序列化又太大, 一次网络传输 20MB, 大概需要 10s(香港到大陆). 我想想该怎么优化.

@LeeReamond 2MB 的 base65(本来是 bytes, 但因为某些原因, 我需要将其编码为 base64), 然后还原到 bytes-> 然后转换未 numpy, 然后转换未 tensor, 然后使用 mayavi 显示(10W-20W 个 point cloud), 最终就是非常慢. 反序列化这一部分就已经需要秒级了. 最终完成一次窗口绘制, 时间就超过 5s 了. 主要还是二进制序列化太消耗时间了. 不做二进制序列化又太大, 一次网络纯属 20MB, 都需要 10s(香港到大陆). 我想想该怎么优化.