跟 socks5 没关系……不通过 socks5 直接访问你抓包也是加密的啊……

这个道理我很多年前就自己摸索通了，人家当下要的哪是你的大道理啊？？

...人生三大错觉。检测到你是中国 ip 就会给你推荐，我还从来没遇到过，不过之前看帖子这件事情已经很久了。

对啊，麦当劳比肯德基好吃多了好不！！

@squid157

微信那个过渡动画的实现本来就不是标准的？你开低电量模式下会发现他还能动，关闭系统动画他也能动，所以根本就不是标准动画吧……而且那个动画经常掉帧，缓动也很奇怪。这个问题我已经反馈过无数次了，但是实际上开发人员有多少会这么注意体验呢？

想当年，微信自定义背景图键盘弹起时会被挤压这个问题，我每隔几个月就反馈一次， 1 年多才修复。然而 android 上现在这个背景图还是有很严重的问题：就是会被压缩得很模糊，不管多大的图都会压缩，而且压缩出来的图模糊得不能忍。这个问题我也坚持反应快一年了吧，真是心累。

不知道 1+3T 的系统过渡动画是不是原生的？原生的话还好啊~
如果不是指的动画形式，那么大概是缓动的问题？

1. 差距大；不玩游戏也能感觉出来啊……随便拖拖窗口或者浏览器滚动一下，非常明显。比例林恩的中场战事，不说 120 帧的那种，一般电影院都有 60 帧厅，看起来的差距也是比平常的 24 帧或者 30 帧电影流畅太多了……
2. 还行吧，看你能不能忍了……
3. 感觉还不如买 LG24GM77-B ？

youtube 秒开， photo 感觉要先等一下（大概在鉴权然后获取视频源？），总之没有 youtube 那么快~

@BROWNURSIDAE 5x 卡到日常使用都让人崩溃，不装国产 app 都运行得慢，打开一个 app 等半天，我用了几个月就丢一边吃灰用 6s 了。

@panlatent 2333 不是你啦~只是你们回复得太快了……

活捉楼上果粉一只……话说起来……真的好久没在 v 站看到这种语气的了……

@ZE3kr 我在想, 要是 username 只有不到三位呢? 因为我有两个比较常用的邮箱一个只有 1 位一个有 3 位...

一般很多公司园区内的这些店都会打折的, 不只是星巴克啦~

用过 pixel 之后从此只推荐 pixel 哈哈哈哈哈…… nexus 系列真是不能比……

@limhiaoing 而且由于我不太清楚 C# 里面的 async/await 的实现，然而我简单地搜索了一下，包括 http://developer.51cto.com/art/201305/393992_all.htm 这篇文章，这样如果抛开 nodejs 和 C# 单 /多线程的区别的话，看起来并没有什么不同。文章中有提到 `await 关键处的代码片段是在线程池线程上执行` 并不是 GUI 线程。再者，搜了一下知呼，里面也提到 await 开始的那一刻 async 函数就返回了，其实都是编译器的语法糖而已。是我理解有问题吗……感觉不是很懂你的意思了……

@limhiaoing 兄弟你要结合上下文不是这么断章取义的，我说的是作为 Promise 的一个 API ， then 的执行一会儿是同步一会儿是异步。

给你一个 API readFile 然后告诉你这个 API 有可能是同步的有可能是异步的？

写 Promise 链的时候就不会关心你的业务逻辑具体是怎么执行的，你从缓存里直接读也好你发请求异步读也好，只是在我 method chain 中的一环而已我还要去关心你是同步异步的具体做了什么事？而且这里还并没有显示能够看到是同步还是异步的方法，只是做了一个函数调用而已。

Promise 本来是用来干嘛的，要解决什么问题，所以他这么设计了，把不稳定性和混乱引进来强行可以卡 tick 做很多的事情，关键是这些事情本来不是这么去做的。

@dou4cc 还是那句话啊，你大概在理解上有一点偏离了……

Promise 的设计本来就是需要保证异步的，不然这对使用者来说有极大的不稳定性需要考虑过于复杂的情形，甚至在有些场景下这将对整个代码结构都带来灾难性的破坏。 Promise then 本来就不是阻塞的不是同步代码，本来就是你所谓的 "tick" 模式。

then 把一个任务加入了队列，你的外部世界的语句本来就没处在 Promise 的范畴内，自然和这个任务也没有关系。

我们来看看你想要的结果，你想要的是：

- 对一个 Promise 调用 then(f)，如果这个 Promise 已经 resolve 了，那么 f 是立即执行的而不是被加入队列等当前的任务完成再执行。

如开头所说不这样的原因是，这让 Promise 变得不确定，实际生产中这会带来很大的问题（ V2EX 上就会有一大堆人开始批判这个坑），没人会想用 Promise 。而且说实话，一个函数一会儿同步一会儿异步，这很怪异，我没见过。

可是你偏想要这么做，要提供一个 then2 ，满足这样的效果可以么？可以，当然可以啊（扩展一个 Promise 类，保存 Promise 的状态，调用 then 的时候检查一下然后做处理。对于 await ，虽然可能需要自己写处理器 polyfill 一下，在真正调用 await 之前检查一下 Promise 的状态），可是你真的需要这么做么？这就是大家关注的问题所在，我们可能认为你本来并不需要这样做（比如楼上有人提到你可能需要一个全局的 async 等等），所以认为你的理解是有偏差的。

你所谓的各种卡 "tick" 的好处，不是 then(f) 可以一会儿同步一会儿异步的理由。

await 怎么对 tick 有什么浪费了……
本质上这里涉及到的还是 Promise 的概念， Promise 的 then(f, r) 保证了 f 一定不是立即执行的（看起来像是异步），而是被立即入队。要是 then 一会儿是同步的一会儿是异步的，这对整个系统来说都是灾难好吗？
你都知道 async 关键字的意义，那么如果一定要实现你想实现的，肯定要把你的整个状态机都包含在 async function 内部啊……你想要用 async 的语法糖来让你的代码更方便一些，一会儿又在语法糖外面抱怨语法糖。你所谓的性能影响是因为你用了错误的方式造成了一些“意料之外”的结果，光是 then 将 f 入队本身没有什么严重的开销。