由于 Android GC 性能而改变编码风格，多远才算太远？
我一直听说 Android 应用程序应该尝试限制创建的对象数量，以减少垃圾收集器的工作量。您可能不希望在有限的内存占用量上创建大量对象来跟踪，这是有道理的，例如，在传统服务器应用程序上，在几秒钟内创建 100,000 个对象并非闻所未闻。
问题是我应该走多远？我见过很多 Android 应用程序依赖静态来“加速”的例子。将需要垃圾收集的实例数量从数十个增加到数百个真的会产生那么大的差异吗？我可以想象改变我的编码风格，现在创建了数十万个对象，就像在成熟的 Java-EE 服务器上一样，但依赖一堆静态来（据说）减少要垃圾收集的对象数量似乎奇怪的。
为了创建高性能 Android 应用程序，您的编码风格到底需要改变多少？
I keep hearing that Android applications should try to limit the number of objects created in order to reduce the workload on the garbage collector. It makes sense that you may not want to created massive numbers of objects to track on a limited memory footprint, for example on a traditional server application created 100,000 objects within a few seconds would not be unheard of.
The problem is how far should I take this? I've seen tons of examples of Android applications relying on static state in order supposedly "speed things up". Does increasing the number of instances that need to be garbage collected from dozens to hundreds really make that big of a difference? I can imagine changing my coding style to now created hundreds of thousands of objects like you might have on a full-blown Java-EE server but relying on a bunch of static state to (supposedly) reduce the number of objects to be garbage collected seems odd.
How much is it really necessary to change your coding style in order to create performance Android apps?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
“避免分配”建议通常是关于游戏循环的。 VM 必须暂停以收集垃圾，并且您不希望在游戏以 30 fps 的速度播放动画时发生这种情况。如果不分配任何对象，虚拟机将不需要收集垃圾来释放内存。如果您的游戏需要在没有用户可见的问题的情况下运行，那么您应该考虑更改相关部分的代码以最小化或消除分配。
如果您正在制作一个包含食谱或显示照片的应用程序，我不会担心它 - 用户可能不会注意到 GC 打嗝。
Dalvik GC 的未来改进（例如分代收集）应该会减少这个问题。
The "avoid allocation" advice is usually with regard to game loops. The VM has to pause to collect garbage, and you don't want that happening while your game is animating at 30fps. If you don't allocate any objects, the VM won't need to collect garbage to free memory. If you have a game that needs to run without user-visible hiccups, then you should consider changing the code in the relevant parts to minimize or eliminate allocation.
If you're making an app that holds recipes or shows photos, I wouldn't worry about it -- the GC hiccup is not something the user will likely notice.
Future improvements to the Dalvik GC (e.g. generational collection) should make this less of an issue.
我想说这实际上取决于您正在做什么以及您现在的编码风格。记住移动设备和相应程序的硬件限制总是有必要的，但话又说回来，无论您的应用程序将在哪里运行，认识到这一点都是很好的做法。如果您正在执行大量需要实时更新的密集计算或类似游戏的操作，那么您可能会考虑使用 NDK，但如果您只是执行正常的用户驱动的操作，那么它应该不会那么糟糕。我的建议是尽量节俭，但不要太担心优化，直到您了解它的运行方式。
I'd say that really depends on what you're doing and what your coding style is now. It's always somewhat necessary to keep in mind the hardware limitations of a mobile device and program accordingly, but then again, it's good practice to be cognisant of that no matter where your app is going to run. If you are doing a lot of really intensive calculations that need to update in real time or something like a game, then you may look into using the NDK, but if you are just doing normal user-driven stuff it shouldn't be that bad. My advice would be to try to be frugal but not worry too much about optimisation until you get a feel for how it runs.