首页   注册   登录
 wly19960911 最近的时间轴更新

wly19960911

V2EX 第 115352 号会员,加入于 2015-05-05 19:11:30 +08:00
今日活跃度排名 19699
目前 react 流行的路由缓存策略是什么 ?
问与答  •  wly19960911  •  197 天前  •  最后回复来自 wly19960911
6
idea 2019.1 加入了定制 theme 功能
分享发现  •  wly19960911  •  235 天前  •  最后回复来自 karllynn
5
pc 版 chrome ,也有 pwa 入口了
分享发现  •  wly19960911  •  243 天前  •  最后回复来自 LAIchimi
9
基于 flutter 做的 yande 第三方 app
分享创造  •  wly19960911  •  275 天前  •  最后回复来自 wly19960911
5
aria2 的 BT 下载真的快吗?
问与答  •  wly19960911  •  163 天前  •  最后回复来自 gkiwi
19
wly19960911 最近回复了
1 天前
回复了 ruandao 创建的主题 问与答 阻塞 非阻塞 ? IO 模型 请教下
状态不好,老打错字,忽略下五楼

”阻塞和非阻塞是相对的,同步代码下面你还是会被阻塞“ => "同步和异步是相对的,同步代码下面你会被阻塞"
1 天前
回复了 ruandao 创建的主题 问与答 阻塞 非阻塞 ? IO 模型 请教下
”同步和异步是相对的,同步代码下面你还是会被阻塞“ => "阻塞和非阻塞是相对的,同步代码下面你会被阻塞"
1 天前
回复了 ruandao 创建的主题 问与答 阻塞 非阻塞 ? IO 模型 请教下
@ruandao 我可能解释错误了,不好意思,阻塞和非阻塞是相对的,同步代码下面你还是会被阻塞,多线程的某个线程你仍然也会被阻塞,但是多线程仍然是异步。而阻塞和非阻塞是因为非阻塞采用了事件队列进行轮询 / event loop,这种非阻塞式 IO 的模型实现的,将事件拆成回调的形式,等辅助用的 IO 线程结束后,才将回调加入队列里面等待执行,最大程度的减少阻塞和线程切换开销。

另外你可以认为 worker thread 就是用户线程,通过队列机制,采用回调机制来安排 worker thread 减少开销。再上面的 协程 就是利用回调链,包装一次回调函数,让回调不用写在回调函数里面而是写成链式或者同步的样子( async await )。
1 天前
回复了 ruandao 创建的主题 问与答 阻塞 非阻塞 ? IO 模型 请教下
@wly19960911 记错单词, 是 worker thread ,工作线程。
1 天前
回复了 ruandao 创建的主题 问与答 阻塞 非阻塞 ? IO 模型 请教下
阻塞和非阻塞指的是 work thread,如果是异步阻塞的话,需要更多的 work thread 带来的开销更大,而异步非阻塞能使用少量的 work thread 来排队,而 io 线程交给线程池处理,减少开更多线程的切换开销,适合 IO 密集型而非 计算密集型。
3 天前
回复了 wysnylc 创建的主题 Java 为什么不建议用 try catch?
@wysnylc 但是我是 rxjs (跑

不过到时候看看 flow 是什么情况,毕竟我也用 Java
3 天前
回复了 wysnylc 创建的主题 Java 为什么不建议用 try catch?
@WenhaoWu rxJava 的 catch 和 trycatch 没什么区别,讨论的核心还是要不要 catch。是我 do/tap/map 里面判断掉然后 filter 还是用 throw Error,来进行流程控制。

我感觉会 Rx Java 就没必要参与这个讨论了…Rx Java 本来就是一套流程控制库,充分使用自然知道会使用自己认为更好的策略
4 天前
回复了 Simle100 创建的主题 Java 方式 1 和方式 2 的却别到底在哪里?
@crclz 跟我想法一样。不过 dalao 还是更简练深刻,我讲的废话多…大佬有兴趣看我回复记录就能看见了。


@wysnylc 难怪开了一贴,原来在这里讨论…哈哈哈
4 天前
回复了 wysnylc 创建的主题 Java 为什么不建议用 try catch?
@wysnylc 其实我这里也没有聊兼容性和扩展性,这个更多需要依赖业务和经验,可惜我也对这块也不是很熟悉。我工作经验还不是很久。

但是我能充分感受到的是,不用 try catch 最大的原因是因为看了一段代码之后,会开始思考究竟需要再哪个流程 try catch,那个流程怎么进行 try catch。但是往往面临的问题是我自己连 try catch 在哪里都不一定能确定下来

比如 一个 (流程 A) 里面执行了 (方法 B) ,B 执行了 (方法 C) ,A 结束之后执行 (流程 H),但是这个时候 C 里面 throw 了 error,我需要在 流程 A 里面处理,但是问题是我需要来自 B 的数据。这时候这个代码就写的一塌糊涂。这还是 3 层,如果是 4 层、5 层呢,怎么处理?


@lcdtyph 在运行效率面前我选择工作效率,如果舍弃了 try catch 还出了性能问题,那么已经是无力挽回了。有流程控制还能想办法优化。
4 天前
回复了 wysnylc 创建的主题 Java 为什么不建议用 try catch?
@wysnylc 最主要的是问题还是一些人代码写的烂,不懂写过程和重构。(以下只针对不懂怎么写流程的新手)

通俗点说,多少人经历过业务逻辑自己来重构的?比如写一个过程,不少人从开始学习就以自己的角度来定义 interface 或者 private method,然后导致的问题就是自己并不是真正把一套流程看清楚然后编写的,比如一个业务流程被分到两个方法里面(当然,更多的还是流程写一个方法不重构的,偶尔写点 Utils 来处理下重复逻辑)。

再简单点说,一个方法分为业务 /流程代码, 以及数据处理代码。流程代码本来就只需要调用重构后的方法为主和业务判断处理就行了,结果一个方法写的和面条一样。最后连流程都不知道,还祈求这些人能进行流程上的 try catch 这个根本做不到...所以我带人的时候建议他们,别写一些自以为是的封装方法和 interface,写完了流程自己整理一下,然后根据流程重构一下,更别在流程代码里面写一些过长的数据处理。

这点我尤其要批评以 vue 和 angular 的部分前端开发, 一个组件下来连个有 return 都没有,连自己的流程都不清楚,还怎么控制流程,更不可能去做 try catch,做下来根本没法控制,只能引用更多的状态来控制多个方法的操作。本来不需要的东西结果越写越复杂。

所以还是强调我第一句,一些人写代码根本没有流程的概念。没有就多写一些面条方法然后自己多看一眼。怎么重构才对。

前端的话,我建议写方法养成一个习惯,一个只有一个异步调用的代码,分三个阶段,声明主要局部变量和把 this 上的数据 赋值 /浅拷贝 给局部变量,然后中间的所有流程不允许调用 this 上面的 data,然后赋值要等所有的操作再赋值(就像 react )。
但是比 react 多的步骤是局部变量,原因还是这块的话能对重构友好,首先对 debug 影响少(因为 debug 的时候你总会去看看谁调用了状态),第二是对重构友好,重构瞬间能产生一个没有副作用的 function。这样的话本身写出来的代码能简洁而且极易 debug 和维护。同时如果需要 try catch 也是很容易的。
关于   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   3172 人在线   最高记录 5043   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.3 · 28ms · UTC 10:18 · PVG 18:18 · LAX 02:18 · JFK 05:18
♥ Do have faith in what you're doing.