V2EX › thinkershare 的所有回复 › 第 43 页 / 共 54 页

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

1 ... 39 40 41 42 43 44 45 46 47 48 ... 54

❮

❯

2022-07-13 16:37:02 +08:00

回复了 aglsv 创建的主题 › Vue.js › vue 打包后的资源地址

@aglsv 正常情况, 这 2 种写法, 浏览器应该发起的都是同一个路径, 也就是:protocol://host:port/$index_html_path/static/js/app.e6cc3797.js, 服务器收到的请求地址应该是同一个才对

2022-07-13 16:34:51 +08:00

回复了 aglsv 创建的主题 › Vue.js › vue 打包后的资源地址

@aglsv 没有抓不到一说, 你在浏览器的调试控制台看下, 它实际的请求路径是什么, 服务器不知道有相对路径这回事. 你看下浏览器实际发起请求的完整 URL 地址. 服务器发起的地址都是绝对地址, 找不到应该返回 404 或者其它重定向.

2022-07-13 16:23:55 +08:00

回复了 aglsv 创建的主题 › Vue.js › vue 打包后的资源地址

@aglsv 你的服务器是怎么配置的, 正常情况下: static/main.js 和./static/main.js 应该是一样的, 而使用域名+statc, 应该是必须写成 /static/main.js

2022-07-11 16:36:18 +08:00

回复了 andyskaura 创建的主题 › 程序员 › ffmpeg.wasm 关于 rtsp 推流

@novolunt 你和我们说的不是一个东西, 而且根本不是解决问题的办法

2022-07-11 15:13:28 +08:00

回复了 andyskaura 创建的主题 › 程序员 › ffmpeg.wasm 关于 rtsp 推流

@churchill 你这个说法, 我严重不同意, 针对互联网项目, 这样搞的确不大合适. 但政企很多项目, 在客户端直接好维护的多. 完全不需要搭建一套后端找人长期维护.

2022-07-11 15:11:36 +08:00

回复了 andyskaura 创建的主题 › 程序员 › ffmpeg.wasm 关于 rtsp 推流

浏览器是没法解析 rtsp 的, 我目前用的是 hls 的流, 延迟 1-3s, 用的 H265, 在浏览器上使用 ffmpeg 的 wasm 解码 H265, 大部分浏览器都不支持直接播放 H265.

2022-07-11 15:10:21 +08:00

回复了 andyskaura 创建的主题 › 程序员 › ffmpeg.wasm 关于 rtsp 推流

不明白你究竟想要做什么? 使用 ffmpeg 在客户端直接解码 rtsp 协议的流, 还是准备干嘛?

2022-07-10 01:00:47 +08:00

回复了 zhengjian 创建的主题 › 数据库 › 数据库应该使用单独列存储计数吗？

方式一: 有很多种办法可以保持事务一致性, 这个是数据库并发写入时保证一致性的基本操作了.
方式二: 并不会, 因为你这个结构就不可能有太多数据, 只要索引设计的正确, 不会有啥性能问题
书籍嘛: 我想到的有: 数据库概论(本科的教材), 高性能 MySQL, 数据库索引设计与优化, MongoDB 相关的设计原则, 对照一下关系数据库和 NoSQL 数据库的差异, 然后思考在 2 种模式下如何平衡性能 /一致性, 每一种选择都有自己的缺陷, 要根据你的业务场景寻求最佳 Schema. 有时候并不要求最佳, 甚至只需要有效就行. 等性能出了问题再去有针对的优化, 看的稍微远一点, 但不要太远.

2022-07-03 21:15:33 +08:00

回复了 erquiasz0825 创建的主题 › MySQL › MySQL 用 uuid 作为主键会导致“页分裂”，这种影响可以忽略吗？

@makelove 2 倍的 long, 16 字节, 打错了, mysql 用了 char32, 它应该是没提供原生的 uuid 支持

2022-07-03 00:43:49 +08:00

回复了 erquiasz0825 创建的主题 › MySQL › MySQL 用 uuid 作为主键会导致“页分裂”，这种影响可以忽略吗？

@makelove uuid 并不浪费内存, UUID 在很多数据库的实现中使用了 8 个字节, 也就是 2 倍 long 的长度, uuid 完全可以做到高效, 除非性能特别重要, 而且单个表数据极大, 否则选择 uuid 是一个很不错的选择, 性能是一个需要基准测试问题. 绝大部分系统的性能问题都不会因为你使用了 UUID 而导致. 反而我非常推荐使用 UUID 作为 id.

2022-07-02 19:45:17 +08:00

回复了 erquiasz0825 创建的主题 › MySQL › MySQL 用 uuid 作为主键会导致“页分裂”，这种影响可以忽略吗？

@erquiasz0825 因为按照分页查询时候, 数据会分散到不同的页, GUID 这种如果要作为主索引, 一定要支持自增, 否则插入 /查询都会有不小的性能损失. GUID 有自增的算法版本

2022-07-01 18:26:55 +08:00

回复了 helee9199 创建的主题 › Java › 请教一下大佬.我们这个情况应该如何设计

非常麻烦, 我们的很多项目也是这个性质, 一个 core 分支, 每个人一个 dev 分支, 一个 main 分支(合并每个人的开发), X 个定制分支, 非常烦, 每次为 core 做 fix 或者 feat 都要重新 rebase, 然后重新测试. 一直没找到好办法. 但项目性质决定了, 赚的就是给客户定制软件的费用, 维护麻烦也是要做的.

2022-06-30 17:19:23 +08:00

回复了 wdc63 创建的主题 › 程序员 › 对于有插入（范围插入）、删除（范围删除）、下标获取要求性能最好的数据结构是什么？

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

2022-06-29 13:36:09 +08:00

回复了 among 创建的主题 › Vue.js › 前端源码中需写死后端服务的地址吗

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

2022-06-29 13:33:47 +08:00

回复了 among 创建的主题 › Vue.js › 前端源码中需写死后端服务的地址吗

取决于你的前端是否和后端部在再同一个 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 这种, 没啥问题

2022-06-29 12:24:05 +08:00

回复了 feller 创建的主题 › 程序员 › 怎么才能用自带的 Terminal 终端， rz 上传命令时，会唤起文件选择器的窗口

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

2022-06-27 18:25:12 +08:00

回复了 AndroidManger 创建的主题 › Android › Android 如何展示 3D 模型

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

2022-06-25 02:40:52 +08:00

回复了 FuzeTheHostage 创建的主题 › 程序员 › 有没有计算机领域的类似技能树的知识点梳理？很多概念新入行不太熟悉先后次序

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

2022-06-22 15:41:18 +08:00

回复了 thinkershare 创建的主题 › Python › 如何在 Python 存在多个事件循环时正常使用 mayavi 绘图?

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

2022-06-21 14:32:54 +08:00

回复了 thinkershare 创建的主题 › Python › 如何在 Python 存在多个事件循环时正常使用 mayavi 绘图?

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

1 ... 39 40 41 42 43 44 45 46 47 48 ... 54

❮

❯