我看了 android 的示例项目，说白了还是走的 RN 和 Weex 那一套，运行时解释 js 代码，转换成原生控件，但是这个提供了官方开发插件，让打包和开发更傻瓜，不过这样也隐藏了开发细节，特别需要接入一些原生 sdk 时，让不了解原生的分钟钟裂开，一些隐藏的问题可能很难排查。
原生 app 性能这里就不说了，因为实现方案没有突破，和 RN 、Weex 都差不多。
而且这个方案玩玩可以，别想用于商用项目，隐私授权合规铁定不通过。

https://gitee.com/mirrors
码云一直在做这个事情🐶，同步都是各大热门项目

这命名是加注释能解决的了吗，我保持怀疑🤨

微信内置了 5 个 activity-alias 坑位，专门留给小程序用的，根据你最近打开的小程序动态替换名称和图标。这几个坑位的别名不一样，这样系统就会把它当成不一样的任务，Android 系统本来就是支持的，这不是什么黑科技

如果你的 product 就这几个，你可以直接运行./gradlew assembleRelease
如果是只需要运行着 5 个 product ，那就在后面拼接就行了，gradle 会按顺序执行的，./gradlew assembleProduction1Release assembleProduction2Release assembleProduction3Release ...

对我来说也是装饰品，基本没有什么使用场景

正在用 WF-1000XM4 ，之前用的 AirPods Pro ，奈何良品率太低了，太容易坏了

Chrome + IDE 直接爆内存，显然不够

索尼 zve10 不拍 4k 的话 vlog 微单性价比之王

好活，当赏🪙🪙🪙🪙🪙🪙🪙

@kun775 无痕模式啊，一看就没有经验🐶

我手机之前也出现过，占用着空间但是看不了，现在这部分坏的数据还在呢

实际上省电是多方面导致的。最关键的是架构升级带来的指令集性能提升，然后就是硬件制造工艺的提升，这两部分就可以大大提升芯片性能并降低发热量；然后还有一部分软件方面的调教，通过控制芯片供电、频率等方式来降低功耗。
实际上 cpu 的消耗的电量可以说全部用来发热了，性能的提升会缩短运行代码的时间，运行时间越短发热也就越小，从而更省电。
但是这只是大部分场景下，还有一些特殊情况，比如芯片都有侧重点，比如最常见的 CPU 和 GPU ，如果使用 CPU 进行图像渲染，显然会很低效，所以 CPU 进行逻辑运算浮点运算等，GPU 进行图像运算，只有各司其职才可以更加高效。

对纯 JAVA 应用来说没有区别，因为全部运行在 ART 虚拟机内，区别也是虚拟机指令集性能的差异。
对于 Native 应用（涉及到 JNI ，NDK ）来说会有一定影响，总体来说 arm64 会比 arm v7a 性能更好，但是一般无法更好来对比，因为硬件的发展导致新架构就算以兼容模式运行老架构代码，性能上也有很大的提升。还有性能上的影响很大一部分和代码编写有关，好的代码在老架构也是很高效的。

电脑上啥膜都没必要用

Java 的 io 操作就按着模版代码写吧，没有什么好办法，流读写，关闭输入输出流，三次 try-catch 是最基本的，最多使用 StreamUtil.close(stream)。
大部分流都是需要 close 的，只有一部分内存流可以忽略，例如 ByteArrayXxxStream ，StringReader 等。
像文件读写复制什么的，只能靠工具方法来减少模版代码的编写

和语言没关系，主要还是要看团队水平和有什么样的领导

A 司应该是比较少的，说明团队整体水平很好，可能是领导不是做技术的
B 司就不说了，懂得都懂，能干活的就那几个人，甚至是外包进来的
C 司项目外包更简单了，能用就行，反正不管后期维护
D 司研发团队应该是不多不少的那种情况，人力刚好满足现在的业务，但又什么都想尝试，可又没有足够的人力来支持

没有代码审计的小团队国企政企应该比较多，研发就几个人也都是干活的，领导可能就不是做技术的，代码野蛮生长，也会出现大量代码的 copy

感谢，让我发现了一个新 bug ，但是我浏览器不习惯全屏，最大化用着挺好，能看到程序坞