Home Sign Up Sign In
V2EX = way to explore
V2EX 是一个关于分享和探索的地方
Sign Up Now
For Existing Member  Sign In
V2EX  ›  sujin190  ›  全部回复第 54 页 / 共 127 页
回复总数  2533
1 ... 50  51  52  53  54  55  56  57  58  59 ... 127  
❮ ❯
2021 年 3 月 12 日
回复了 alpha1155 创建的主题 › Android › 声波通信怎么实现？需要掌握哪些技术？希望成品是一个 zai 安卓手机上可以运行的 app
直接播放事先录制好的不同频率声音代表不同信息，手机听筒接收到声音文件后按不同频率解码到对应信息就行了吧，不过能传输的信息应该比较少
2021 年 3 月 11 日
回复了 Simle100 创建的主题 › Java › 群发消息已读未读如何设计才能降低数据库的压力
@wennew #16 我的意思用 redis 的 set 数据结构比用 redis 的 hashmap 数据结构操作复杂，都是 redis 。。
2021 年 3 月 11 日
回复了 Simle100 创建的主题 › Java › 群发消息已读未读如何设计才能降低数据库的压力
如果你觉得直接用 hashmap 太耗内存，那么就在发消息式给个再当前消息内部有效的自增 ID，redis 这边就能用 bitmap 来存是否已读了啊，查的时候直接取出哪些位置没读，然后结合消息 ID 就直接能查除用户了，这个应该式最省内存也不是很消耗性能的方式了吧
2021 年 3 月 11 日
回复了 Simle100 创建的主题 › Java › 群发消息已读未读如何设计才能降低数据库的压力
@jacobsun #5
@wennew #8 set 操作比直接用 hashmap 麻烦吧，而且直接写数据库就是了，redis 就是个缓存，统计已读有问题不是写已读数据有问题

其实直接发的时候都把发送用户 ID 己到 redis 消息 ID 对应的 hashmap 里就是了啊，读了就从里边删了，看哪些用户没读直接读整个 hashmap 就是了，设置一个合理过期时间也都不用清理，读不到再从数据库加载就是了，发消息和读消息都先写数据库再写 redis 就是了
2021 年 3 月 9 日
回复了 Tdy95 创建的主题 › 投资 › 基金巨亏要不要跑路？
@TypeError #112 别太认真，其实跌个 30%、40%、50%啥的，国家根本无所谓，反正也不会影响经济基本盘，对国家重要的是只要控制着别跌太快就行，反正明年后年又涨回来了，人家才不怕呢，再说吧你以为今年行情是疫情结束经济向好股市涨么，想多了
2021 年 3 月 9 日
回复了 Tdy95 创建的主题 › 投资 › 基金巨亏要不要跑路？
@wqhui #136 去年底就感觉年后要杀估值了。没啥大跌的理由。。其实理由感觉不少，不穿 3300 能刹得住的可能似乎比较小啊
2021 年 3 月 5 日
回复了 genal 创建的主题 › 问与答 › xdm, 现在黄金值得入手吗
感觉可以 320
2021 年 3 月 5 日
回复了 xiaoshouchen 创建的主题 › 问与答 › Golang 开发 Web 做发送短信、调用 API 之类的耗时用协程还是用 MQ？
非常建议用队列，虽然协程性能完全够，但是不能重入啊，重启崩溃啥的都坑死个人
2021 年 3 月 4 日
回复了 zhangyanwen2 创建的主题 › Google › 如何看待谷歌相册的新政策
这个应该”是看待个鬼，人家商业公司，自己服务爱收费的就收费关你啥事，爱用不用滚”


@123jiayue #24 我觉得应该来个关键词屏蔽，禁止发这个，又没收他钱，谷歌想咋样就咋样，天下没有免费的午餐，关他啥事，看待个锤子
2021 年 3 月 3 日
回复了 wheelg 创建的主题 › 问与答 › 能不能用纯 canvas 实现一个组件框架
flutter web 的 canvas 渲染是编译成接近原生的 wasm 的，如果用 js 在 canvas 上绘制，想做出比现有浏览器渲染效率更高还是比较有难度的
2021 年 2 月 26 日
回复了 devswork 创建的主题 › 路由器 › 将 mysql、redis 坐到软路由上需要什么配置？
@devswork #7 但是高性能的软路由其实就是服务器，同样很占地方，普通的当开发机确定不会影响开发效率？
2021 年 2 月 26 日
回复了 devswork 创建的主题 › 路由器 › 将 mysql、redis 坐到软路由上需要什么配置？
实在不行随便弄台电脑当服务器也行啊，反正现在单渣主机电脑也不贵吧，软路由真是。。
2021 年 2 月 24 日
回复了 lesismal 创建的主题 › 分享创造 › 发布个 golang 高性能异步网络框架 nbio，单击百万不是梦！
@lesismal 协程就是在线程池的基础上封装来的，要啥协程池，再说基础架构不意味着就提供一个很丑的接口，既然协程的消耗本来就很低，为了简洁性可靠性抛弃 callback 直接提供协程接口是完全有必要的，再说既然都需要再在 callback 基础上封装适配协程，你这高性能岂不是白白浪费了，现实场景中只通过 callback 转发数据不使用协程的情况几乎不存在吧
2021 年 2 月 24 日
回复了 lesismal 创建的主题 › 分享创造 › 发布个 golang 高性能异步网络框架 nbio，单击百万不是梦！
go 辛辛苦苦做了协程解决异步化编程难题，然后你又把他变成 callback 了。。。

其实吧相对于带来的编程简洁性协程带来的性能消耗还是值得的，追求极致性能不管编程便利性真的那么重要么？
2021 年 2 月 23 日
回复了 viosey 创建的主题 › 问与答 › 租车违章能否自己处理？
@AA5DE3F034ACCB9E #21 这个世界没有明文规定但是又允许的事情不是很多么，再说规定也是对租车公司的规定，也许是发给了租车行，不公布也没啥啊，重要的是是否真的方便又不存在重大漏洞损害大众利益

国内有很浓重的应该先有法规再才能这么干，但这其实是根本不合理的，法律法规的出现应该是把符合大众利益的行为公开规定下来并且堵上可能存在的漏洞，是后置的
2021 年 2 月 23 日
回复了 viosey 创建的主题 › 问与答 › 租车违章能否自己处理？
@mrhhsg #7
@viosey #11
@AA5DE3F034ACCB9E #17

估计租车应该是有特定规定渠道的，就像出租、滴滴专车这样的，整天在路上跑难免意外情况多，12 分显然不够扣吧，租车也是人都离开了很可能不在以城市了，忽然发现违章了，让别人回来处理显然不现实，所以很可能是和交通局统一走的流程，毕竟就算他们能卖分，神舟这种那么多车也不太可能弄到那么多分卖吧，就算真能弄到也早被交管局盯上了

更可能的情况是交管局规定租车行审核违章信息不是明显故意瞎来的，并且分数在 3 分及以下的可以交罚款抵扣，当然交罚款的时候交管局肯定也是要再看是否合理，其实大部分估计也就是租车路不熟意外违章，也不是故意的，再要回去处理确实不合理，这个应该算是人性化管理才对
2021 年 2 月 22 日
回复了 calvincc 创建的主题 › 职场话题 › 开发同事各种不配合我的测试工作，是我的问题吗？
你提出来反馈好就进入下一个流程了啊，你要做的是尽量分好类，交互问题、流程问题、需求不一致问题等等，做好追踪是否修复就好了，及时给领导开发产品反馈进度就好了，开发不改本来就不是你的问题吧，否则这领导也太推卸管理责任了，要不要改怎么改啥时候改本来就是领导的管理责任，他不能推卸责任啊
2021 年 2 月 21 日
回复了 gozfree 创建的主题 › 程序员 › 有没有搞嵌入式或者流媒体的同学
流媒体门槛有点高的，所以想做啥呢？但是楼主真是厉害，这么多东西都自己实现了
1 ... 50  51  52  53  54  55  56  57  58  59 ... 127  
❮ ❯
About   ·   Help   ·   Advertise   ·   Blog   ·   API   ·   FAQ   ·   Solana   ·   1159 Online   Highest 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 31ms · UTC 23:33 · PVG 07:33 · LAX 16:33 · JFK 19:33
♥ Do have faith in what you're doing.