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 是即时性非常高的，所以会一直发送心跳，服务端也要有一个线程来维持这个连接。

云上贵州不是苹果运营的，苹果只是在云上贵州跑它自己的软件而已。实际上就是磁盘坏道导致数据丢失了，可以恢复，但是对面不想费时间查罢了。因为这种“敏感”的操作肯定是没有公开程序或者手册的。

safari 有优化，chrome 没有

可能是域名证书过期了

//直接下载
let a = document.createElement('a')
a.href = "blob://xxxxx"
a.setAttribute("download","xxx.jpg")
document.body.append(a)
a.click()


//在脚本中处理
fetch("blob://xxxx")
.then(res=>res.blob())
.then(blob=>{
return new File( [blob] , "xxx.jpg" , { type:"image/jpeg"} )
})
.then(file=>{
// do some thing as file
})

会，建议不要分享。