很简单的需求：Safari 里网页广告点击后下载了知乎，要做归因，目前只能是网页把 ID 写入剪贴板，App 启动后在读取剪贴板。

又看了一眼那个英文排行榜
*.md linguist-language=Python
这样你一行代码都没有的项目，就被 Github 识别成 Python 100.0% 了。。

这玩意儿出现在我首页 N 多次了，实在忍不住点进去翻了下。。
这么多 Star 的项目，一个 Poll request 都没合并过
还有这一句是想干嘛：*.md linguist-language=Java 把你这个 md 项目识别成 Java 项目？

翻译权是著作权的一部分，这是很明确的法律说明。

@keymao 你不灰度就切换，那平滑切换就是想当然了。
另外适配 arm64 不代表六七年前的设备用不了，而是代表六七年内的设备体验更好。

@kop1989 拿个实际例子来看看吧，
建行 App ，现在在 lib/armabi-v7a 下面，有 50 个 so ，有 44MB ，看看都有啥功能：
IDCardScan, BankCardScan 、zbar 、ZCode 这都是各种卡片和二维码图像识别
myaudio 、codec 、opus 、yuv 、ProcessImg 、gif 这些都是音视频图像编码相关的库
sqlcipher 、mmkv 、AES 、iconv 数据处理、加密解密相关的
除此之外还有各种三方 SDK 比如百度地图、友盟统计、各种安全库加密库

现在银行 App 远远不是你所谓的 "表单查询和提交" 的范畴，
而且各种功能，包括最基础的扫码、gif 动图、数据存储，甚至启动 App 时代码解密都是依赖底层这些库，
升级能带来各个方面的提升，也并不是你所谓 "没有明显感知"。
同一个包也可以带 v8a 、v7a 两套 so ，也不影响旧用户的使用。

对于以后的 arm64 ，这些底层的 so 都要全部升级一遍，功能都要重新测试，
而且随着时间越久，第三方 SDK 和源码，对于 32 位支持就越弱；同时 API 变动越大，升级代价也越高。
所以从开发者角度，支持时间越晚，成本就会越高，这都是我做移动开发这么多年的切实经验。

无论从开发者还是用户的立场，尽早支持 arm64 都是合适的选择。

@kop1989 如果除开其他的问题，单就用户体验上来讲，ARM64 的性能和安全在现在手机上表现得比 ARM32 要更好。

@kop1989 与时间有关。尽早做适配，时间足够充裕，开发也好测试也好，都可以留有足够的余裕。
出问题的可能当然比匆忙修改上线要小。

@kop1989 啊这。。典型不懂技术又想管事儿的老领导心里。

后年出的 CPU 没有 ARM32 支持，也就是说后年买到的手机，就无法运行现在这些没有改的 App 。。
银行 App 当然是要给尽可能多的人用，用户当然不懂这些，他们 App 跑不起来该怪手机还是怪厂商？
ARM64 已经是很成熟很长时间的技术了，算不上新技术。
没做过适配，deadline 前想当然更新当然有各种问题，不说别的，他们依赖的 SDK 升级就够喝一壶的了。
你自己看看现在不支持 ARM64 的安卓机型还有多少？

@kop1989 本来还以为是装领导反讽，没想到真有人这么想啊。。
arm64 移动端已经快 10 年了，苹果在 6 年前也已经强制 App 64 位才能上架。
对于 Android ，ARM 明年大核就没有 arm32 ，后年就全面停止 ARM 了。

这么多年不改，非要等到 deadline 再去改，不怕到时候出岔子吗，这对稳定性有帮助？
留着 arm32 才是少数人的"情怀"，就像现在还在用 xp 和 IE 的那些 XX 系统一样。

你要愿意接受内存不够时 OOM 杀 App ，那大可以关闭 swap 。。

建议各位善用 https://github.com/explore

空闲内存会被用来做预加载，加速 App 和文件打开速度。快满了会释放缓存的这部分，再不够还会进行内存压缩（ WKdm/LZ4, 不确定 M1 有没有特殊优化），所以内存高不用太过担心。

只是每个人使用程度不一样，总有压缩不下来 Swap 到 SSD 的时候，只是 SSD 速度快，卡得比原来稍轻一点罢。
对我来说，日常使用东西多，16G 照样不够。

这其实是取决于各个端在实际开发中使用的网络请求下层封装是怎样的。

搜 "如何隐藏你的踪迹"，虽然是老文章但至少能简单回答楼主。。

看了下 4 楼的帖子，这敏感度，一碰就炸啊🤣

这些 table 怎么有的带 border 有的 border = 0 啊，还是同一个页面。。

彩蛋是隐藏的、无害的，Code Review 解释清楚当然能过。
至于 HoHoHo ，那种并不是无害的。那是炸弹，不是彩蛋。