Only iPad

https://apps.apple.com/us/app/pixelmator-photo-pro-editor/id1444636541
https://apps.apple.com/cn/app/pixelmator-photo-pro-editor/id1444636541

iOS App

一般情况下换卡不需要重启手机
但是 有些功能“可能”由于没有重启手机出现一些奇怪的问题
一般是系统或者软件出问题 可能由于缓存了之前 sim 卡的信息之类的情况

关键你要看要用多久了 如果你打算用超过 2 年 最好还是 32G

16G 虚拟机+Docker 不超过两个 应该够了 IDE
8G 不开虚拟机 应该也够了

@JamesR “重构不漂亮的代码” 确实是浪费时间 但是 “除非这个代码功能彻底用不成，否则不论写得多烂，我不会去重构代码”也是不应该的 有时候可能会导致浪费更多时间
@ericgui 完美主义心里可以有 但是行动上要克制 过度浪费时间和生命在这些上面不值得 而且 bug 和问题反而可能会更多

我觉得产品代码是否需要重构要看“可维护性”和“可扩展性”
如果代码过于混乱 /过时 /局限太大 导致当前要修 bug 或者加 feature 过于困难 在时间允许的情况下就一定要重构
如果是多人大项目 当代码混乱到别人接手看不懂没办法下手 最好也要重构一下 如果时间允许
如果没有时间 那么就应该给项目管理或者上层提出重构的需求 然后安排时间 可以说如果不重构以后维护和加功能会多么多么困难需要多花多少多少时间这样
而且重构不应该是一股脑儿彻底重构 最好是是局部的和渐进的 如果有足够的 unit test 就更好了

重构是很花时间的 也是很危险的 可能之前的 bug 修好了反而产品坏了 以及可能引入很多新 bug
但是如果拖太久 后期的可维护性就会越来越低 可能会拖到整个项目不得不砍掉重来就得不偿失了

同时如果有比较全面的 unit test 或者自动 test 重构的难度和风险会降低很多

@Cryse 关键要看 USB 的速度吧 一般情况下这个才是瓶颈
SSD 或者 SSD 级别的 U 盘 本身速度应该都够快过 USB 的速度 除非接的是 gen2 / 2x2 / USB4 / TB3
SSD 的话 如果是 NVMe 的话 应该会快过 gen2 了 SATA 的话 gen1 就可以了
也要看你的主机支持的怎么样

等 Electron 更新就好了

很正常 在多学几门语言就习惯了
比如 Python / JS / Go
然后你大脑就会慢慢习惯这种不停的切换

专门给 Windows 用的那个需要破解（便宜的）
另外一种通用的不用破解

@huijiewei HyperKit 基于原生的 Hypervisor 框架 但是还是虚拟机 稍微轻量一些 但是本质没有改变 所以 @CEBBCAT 说的仍然没有错 只是 Docker for Mac 帮你做好了这些
虚拟机占多少资源 在本地宿主机只会占用更多 而且性能也有不小的损耗
@Achilless 内存和磁盘空间不会比开了动态分配的其他虚拟机少多少 除非你同时开了很多 VM
但是优点是启动速度快和使用灵活 缺点是对 GUI 支持的不好 以及网络设置要更加的复杂

@Vhc 是正式版 但是不是基于 Chromium 内核的新 Edge
老 Edge 是微软自研发的内核 虽然 UI 里面有 WebKit Chrome 和 Safari 但是仅仅是为了兼容性 就像 IE 里面还有 Mozilla

目前新版 Edge 正式版官方还没有正式发布 更没有开始推送 所以你要自己下载安装
这个安装包应该是属于稳定版 偷跑已经好一会儿了
但是应该还没有正式发布 不过功能上应该是一样的 可能将来正式发布的时候小版本号会更新一点

@siknet 看你楼下 你 2 米的 USB-C 线估计是 USB 2.0 充电线吧 长到 3-5 米应该都还可以用
最多是 3.0/3.1 Gen1 5G 的线 一般最多也就 2-3 米
3.1 Gen2 10G 的线一般也不超过 1 米
TB3 的线 20G 无源貌似就半米多的样子 有源带放大器可以再长但是一般就是 10G 的了

@azh7138m 超长 TB 线都是不带电源的 转光纤的 理论上可以做到非常长
当初 Thunderbolt 还是研发原型的时候就叫 Light Peak 本来设计打算直接用光纤的 但是不带电真的很有局限性 加上实用性和兼容性问题 就用 Mini DP 的接口了

我记得没错的话 USB-C 线 不管是 Gen2 还是 TB3 都没办法做太长超过 1 米的

@shaoyaoju 这么麻烦 要等待用 for of + await 就是了 非要用 forEach/map 或者 reduce 干嘛
并行用 Promise.all + array.map 就是

@ChristopherWu “RESP (REdis Serialization Protocol) ”这样写不算是 typo 啦
只是说明一下 RESP 是 “RE”dis “S”erialization “P”rotocol 的缩写
取自 Redis 里面的 RE 加上 Serialization 的 S 和 Protocol 的 P
因为 Redis 里面取了两个字母 所以大写了一下

@maomaomao001 Chrome App 不是已经有了吗 虽然没有移动端支持 但是桌面系统都支持了啊
也可以访问本地文件 可以授权访问任何网址
即有应用商店 也可以手动载入自己写的

主要问题还是安全性
发布的 app 经过审查 加上签名校验 安全性还可以有点保障

否则就算你给用户来选择 不是所有用户都知道这些

更重要的是要防止被黑客利用 通过复杂的手段钻漏洞 彻底攻破系统的安全性

@maomaomao001 首先 PWA，web assembly 以及 文件和网络权限 其实没有什么关联
不同的技术和 API 罢了

PWA 就是可以离线运行和安装的网页版小程序 目的是用户体验看起来像本地程序 同时又不需要应用商店来分发
Web Assembly 是除了 JS 以外一个全新的基于二进制的运行时 一方面运行效率高 同时可以把各种现有的程序直接移植到 Web 平台 又可以支持任何可以编译到 WASM 的语言
文件和网络权限或者 API 这个是浏览器提供的功能罢了
这几个其实没什么相互的联系
至于 WebApp 的开放生态 也就 Google 有兴趣 其他厂商巴不得让所有 App 都建在自己的封闭围墙里面（其实就算是开放的 Web 其实也可以算是 Google 的围墙）每个厂商都有自己的如意算盘 要想让系统或者各大浏览器统一来支持是很困难的事情

“为什么缺迟迟不开放网络能力和文件能力”
之所以不给 WebApp 文件和网络权限 是因为安全问题 就算你可以加上权限管理和沙盒 但是总有办法绕过的
你没办法给一个随便可以打开运行的网页随便访问文件系统 以及随便链接其他网络 这样黑客得笑死
本地 App 还好控制一点 可以用签名来做一些保护 另外现在还到搞封闭花园和沙盒什么的

“微软他们为什么不考虑这么搞”
你说的小工具一个 html 就可以了 其实微软早在 IE5/Win98 的时代就有了
就是 HTA 可以用 html/css 写 UI 用 js+vba 访问几乎所有本地系统 API 文件读写访问网络什么都可以
结果并没有什么正经的软件在用 倒是各路病毒木马用的很欢

“谷歌为什么不考虑这么搞”
Google 一直在尝试做安全又实用的文件系统和文件访问 API 给浏览器
最早有 FileReader API 现在也可以用
同时还有 FileSystem API 沙盒的文件系统 但是被标准否决了 同时也很难用 局限性太大
最近又出了了新的 Native File System API 我觉得这个应该就是你想要的吧
但是要推成标准 让 Firefox 和 Safari 支持可就难了
最近 Firefox 疯狂注重安全和隐私 自然不想要这种高风险的 API 而 Safari 东家 Apple 希望 App 强大 并不希望 WebApp 可以强大到取代 Apps

“感觉现在开发跨平台桌面应用太费劲了”
对于跨平台的 UI 你想要保证兼容性问题 你就得自带浏览器引擎 否则就算是相同的浏览器或者相同 web 核心 不同版本也可以弄的你够呛 所以 Electron 这种虽然好几百 MB 但还算不错的选择 只不过应该还可以通过组件化来优化一下体积 不用的功能应该可以丢掉（貌似可以精简到 80-100MB 左右）
如果非常在乎体积 兼容性要求低一些 其实各大系统都有系统自带 web 核心来用 做出来的 app 都可以非常的小 效果也还过得去

用 import 来导入组件 然后用 webpack 之类的打包在一起