Java 首选项 API 吞吐量
我正在使用 Java Preferences API 来存储 Swing 应用程序的窗口位置和大小。此时，我正在侦听窗口调整大小/重新定位事件，并在每次更改时存储位置和大小。然而，这意味着如果用户慢慢地将 200 像素宽的窗口调整为 400 像素宽，我可能会在很短的时间内写入大约 200 次新的窗口大小。
首选项 API 使用主机系统上可用的任何数据存储（Windows 的 Windows 注册表等） - 但问题是，属性 API 的限制或最佳实践是什么？可以吗，还是只在用户完成调整大小后才编写会比较明智？有人有过在不同平台上使用 Properties API 的经验吗？
I'm using Java Preferences API to store window position and size of Swing application. At this moment, I'm listening to window resize/reposition events and storing the position and size every time they change. However, that means that if user slowly resizes window which is 200px wide to 400px wide, I'll probably write new window size about 200 times during pretty short time.
Preferences API uses whichever datastore is available on the host system (windows registry for Windows etc.) - but the question is, what are limitations or best practices for properties API? Is it OK, or would it be smart to write only when user has finished resizing? Anyone had experiences with Properties API on different platforms?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
只是重新阅读并意识到您正在谈论应用程序本身而不是对话框，但这个概念可能仍然适用：仅在成功关闭应用程序时记录尺寸。我认为这对于大多数用户/情况来说是完美的。
为什么不只在“确定”或“取消”按钮事件上记录新尺寸？即不要动态存储它。
如果它是模态的，那么这样做您不会丢失任何东西，这只是您想要的最终值。谁在乎一毫秒是否是 307 像素？
Just re-read and realised you're talking about the app itself not a dialog, but the concept probably still applies: record the dimensions only on successful application shutdown. I think this would be perfectly fine for most users / situations.
Why not record the new size only on "OK" or "Cancel" button event? I.e. don't store it dynamically.
If it's modal, you cannot lose anything by doing this, it's just the final value you want. Who cares if it was 307 px for a millisecond?