开发者

Overriding the default Activity stack

开发者 https://www.devze.com 2023-01-18 15:27 出处:网络
Is it advisable to create your own Activity stack (which contains only the activity names rather then the complete activity as in the default stack) to improve the memory consumption of the applicatio

Is it advisable to create your own Activity stack (which contains only the activity names rather then the complete activity as in the default stack) to improve the memory consumption of the application.

What im basically doing is maintaining a string stack containing the activity names and override the back button functionality to launch Intent with the stack top and finish the current activity. I also add a parameter to decide if the current activity should go into the stack or not (useful in certain situation). So basically I do a startActivity every time I have to launch a new activity and finish the current one so that there is nothing in the default stack and on back press also start the activity from my stack and finish the current activity.

Ques 1: Is it advisable to do it this way? What are the possible problems that could happen开发者_如何学Go?

Ques 2: Can someone give me an idea of the memory usage of the default Android activity stack so that I can compare it with my own implementation?


Is it advisable to create your own Activity stack (which contains only the activity names rather then the complete activity as in the default stack) to improve the memory consumption of the application.

Generally no, no more than a Web app typically hacks into the browser to change the browser history and delete items out of the browser cache.

What are the possible problems that could happen?

You lose your state on every operation. Normally, the BACK button takes the user back to the previous activity, with its state intact. There's even a framework for maintaining this state (onSaveInstanceState()) if Android elects to close up an activity to free up memory.

You also force more garbage collection than is necessary, by finishing activities that the user is not yet done with and forcing their re-creation, which wastes CPU time and battery life.

I have some nagging concerns about the impacts of your strategy on configuration changes (e.g., rotation, dock), but I can't put my finger on any specifics.

Can someone give me an idea of the memory usage of the default Android activity stack so that I can compare it with my own implementation?

You are asking the wrong question. The question you should be asking is: What is the evidence that there is a problem in the first place?

It is entirely possible that there is something rather unusual about your application that makes your strategy a sound one (e.g., lots of memory-intensive bitmaps). However, in general, unless there is a demonstrable problem, things like what you are doing fall under the heading of "premature optimization". Even then, there may be better solutions to whatever the actual problem is...but you won't know that unless and until you determine there is, indeed, a problem.

0

精彩评论

暂无评论...
验证码 换一张
取 消

关注公众号