可以在 for of 里用 awit 顺序执行

@GreatAuk 新架构主要解决性能方面的问题，问题是 RN 就不是一个主打性能的方向，RN 能挖掘的深度也有限。

不会拉黑，你可以在更新说明那里解释一下你只是换名字。

@darkengine 对。0.7 之后模版默认开启新架构，但是你可以不用 turbo native modules 和 fabric 相关的功能就行。用了之后一些第三方库还没适配会出错，浪费时间。

一般确诊心肌梗塞就不让患者出院了，准备好 3 ～ 5 万块钱做手术。
药物治疗除非患者症状真的很轻。

急性期就两种手术方式，微创手术就是心脏支架，从手臂或者大腿的血管放一根金属丝到心脏附近血管堵塞处放一个金属支架，撑开血管保障血液流通量。这样心肌恢复供血，恢复心肌功能。这个金属支架国内之前做改革已经不卖外国的了。国内的比较便宜，但就是金属支架，国外的是高分子材料，会随着时间慢慢溶解消失。

心脏支架是微创手术，出血少，时间快，最快半个小时做完。主要看病人要放几个支架，支架数量越多风险越大。

另外一种开放性手术是心脏搭桥，就是切大腿的一段血管给替换掉心脏附近堵塞的血管，这种手术风险很极大。一般作为微创手术的后备方案，即微创手术过程中血管破裂之后的应急手段。或者患者血管过于狭窄，金属丝无法抵达患处。

然后这个病年轻化趋势也比较明显，上次看见一个 20 ～ 30 的男人去做手术，叫前女友来陪的。

React Native 你如果只是部分迁移，一部分页面用 RN ，大部分用原生。实际上操作可能需要你建两个工程的。
正常 RN 开发你可能也需要两个工程。简单的说就是两边依赖的版本可能不一样，安卓可能某个依赖能工作，但是 iOS 那边不行，你得切换版本。如果你不想切换的时候重新 yarn 安装依赖。你可能需要建两个工程。

就算你在一个工程里做双端的，你也是 xxx.android.js xxx.ios.js 这种分开处理的时候会比较多。两边好处是逻辑代码大部分一样，但是具体代码还是要分开来修改的。

但是相比原生的每次修改都需要编译才能看效果，RN 的动态预览将效率提升了太多。而且因为你用的是 js ，不用每次都编译，电脑也会凉快不少。如果是 iOS 那种预览，电脑得卡的要死，而且超过一定的代码量，就不给你预览了。

如果你决定了用 RN ，千万不要马上使用 RN 的“新架构”，现在坑还很多。

一种就是作品借画师的名气，画师会按他的想法和参考你的要求画出来，但是你提意见的地方不多，也不会后期给你确认反复修改。
一种，画师只是个没名气的代工，自己没有流量，批量作画的机器人。甲方要求贼几把多，画出来总是达不到要求要经常修改。AI 作画就是要挤兑这部分工作者的资源。

这类问题隔一段时间就会有人问。
对于前端来说，网络连接问题是最优先的，其次才是后端返回的各种数据异常问题，反正异常处理就这样分层了。

请求成功返回 200 ，前端就知道网络请求成功了，然后再去判断这个请求是否业务上成功。
异常提示字符串直接从后端返回 json 里取，这样大大减轻了前端的工作量。
后端只返回几种意义不明显的状态码，前端还要了对照这些状态做不同的显示，没点效率。

@tool2d 我麻了

现在主要是两个阵营，chrome like 和 safari like 。
chrome 播放 mp4 一般发起一个请求下载整个文件的数据。
一边接收数据一边解析，如果达到可以播放的缓冲就开始播放。
快进的话会从视频帧对应文件位置请求。

safari like 播放 mp4 有两种模式，其中一种和 chrome 类似，只需要一个请求就开始播放。
但是这种模式出现的时机比较苛刻。

另外一种是彻底的 safari 模式。播放视频时候需要请求非常多次。
第一次会请求两个字节，要求服务器返回 mp4 文件长度。
接下来会：
第二次请求会请求文件全长度（服务器不一定会返回全部长度,可能只会传输几 M ）
第二次请求文件尾部几 MB 字节 (服务器应该返回这部分的全部长度)
因为 mp4 文件结构中视频信息在文件尾部，所以要先请求到这部分数据解析后播放。
之后 safari 会重复多次请求，一边播放一边请求接下来要播放的部分。

不同平台 webview 处理逻辑差异：例如 windows10 上的 webview 就会有不同的反应，有时候两种模式都可能会出现。

没有人在客户端搞这种东西的。你可以再服务端抓取数据，没必要在客户端做这种事情。

网站打不开，电信 中国南方

牛逼啊，盗图还拿来卖钱？还订成计划来？你这也太害人了吧？

快捷指令就可以改图标

iOS 开发这么多年了，技术路线都几条了，你入场的时机晚了。官方确实没做从零到一的指南，或者说那个指南很难看懂。

Debian 10 + Guacamole + xfce4 + TightVNC 我在用的方案。也是 oracle 的机器 1c1g 。浏览网页肯定不流畅的，用来下载文件还可以。

灰度更新

@Features websocket 是即时性非常高的，所以会一直发送心跳，服务端也要有一个线程来维持这个连接。