Android效率:加载时间长问题,浏览量大
好吧,我正在写一个有商店的游戏。这家商店是我遇到问题的地方,因为商店中的每件商品都有几个统计数据,然后有 2 个按钮和一个用于购买/销售的编辑文本。
商店的布局有 3 个选项卡,每个选项卡中有 26 个项目,总计:每个选项卡 130 个 ImageView、364 个 TextView、52 个按钮和 26 个 EditText。因此,如果您仔细数一下,在 3 个选项卡式布局中总共有 1,768 个视图。 (我知道,“天哪!”)
在编写本节时,我并没有真正考虑效率,现在我发现加载此 Activity 平均需要 3-5 秒或更长时间。我希望它加载得更快,但我喜欢商店的布局和总体“外观和感觉”。
我已经分解了侦听器,以便它仅侦听当前选项卡中的元素,并关闭非活动选项卡的侦听器。这有一点帮助,但我认为这不是问题的主要方面。
任何人都可以建议我可以做些什么来帮助缩短此活动的加载时间吗?
编辑:屏幕截图。 我听说过有关回收商的事情?那是什么?它是否适用于此以帮助加载时间?
Ok so I am writing a game that has a shop. The shop is where i am having problems because each item in the shop has several stats and then 2 buttons and an edit text for buying/selling.
The layout for the shop has 3 tabs with 26 items in each tab and that totals to: 130 ImageViews, 364 TextViews, 52 Buttons, and 26 EditTexts per tab. So if you keeping count that is a total of 1,768 views in one 3 tabbed layout. (I know, "HOLY CRAP!")
I wasn't really thinking about efficiency as I was writing this section and now I find that loading this activity takes on average 3-5 seconds or more. I want it to load quicker but I like the layout and the general "look and feel" of the shop as it is.
I have already broke up the listeners so that it is only listening to the elements in the current tab and turns off the listeners for the inactive tabs. This helped a little but i don't think that was a major aspect of the problem.
Can anyone suggest anything else I can do to help the loading time on this activity?
EDIT: Screenshot. I have heard something about a recycler? What is that and would it apply here to help loading times?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
我在设计复杂对话框时也遇到过类似的问题。
基本上,一次需要显示的事物数量并不多,但在所有可能性中,可能显示的事物数量可能会大得令人望而却步。
我制作了一种用于编码复杂对话框的特定于域的语言,此处讨论,基本上,它解决您的问题的方式是根据需要动态创建/销毁对象。人们可能会觉得这在性能方面会付出高昂的代价,但事实并非如此,而且不将内存与可能显示但可能不会显示的内容捆绑在一起的好处是非常显着的。
I've had a similar issue in designing complex dialogs.
Basically the number of things that need to be displayed at one time is not much, but the number of things that might be displayed, over all possibilities, could be prohibitively large.
I made a domain-specific-language for coding complex dialogs, discussed here, and basically, the way it addresses your problem is it makes/destroys objects on-the-fly as they are needed. One might feel that this would be costly in terms of performance, but it really isn't, and the benefit of not tying up memory with things that might be displayed but probably won't is pretty significant.