ScreenConductor causing lags between screens

[wuman]

We have started using the ScreenConductor class in the mortar sample project in our own app. At first we were impressed with its simplicity. We were especially delighted to find a surprising side-effect of using this class to switch between screens: a smaller memory footprint due to the fact that at any one time, only views for one screen is present.

However, as our app grows to become more mature and each screen becomes more heavyweight, we are starting to see problems.

1. Going back to the previous screen is like creating the entire screen altogether. No states (like previous scroll position) from the previous screen can be easily remembered.
2. A bigger problem for us is that switching from one screen to another involves removing an old screen from the view parent, which in turn causes a huge GC (to free the object graph as well as views for that screen). The GC is done on the main thread and will cause a noticeable lag.

I was wondering if you guys could share with us whether you guys are also using ScreenConductor in your production apps at Square. If so, are you also running into the problems that we have observed?

[rjrjr]

ScreenConductor was created specifically to preserve scroll position, so
there I suspect a problem in your code. Android view persistence requires
ids on persisted views, including scroll views, could that be your problem?

Re jankiness, we are indeed fighting that. What makes you think it's GC
though? Have you profiled? We saw some problems creating Object Graphs, not
destroying them. Still working on it.

---

Tiny keyboard has opinions on speling.
On May 13, 2014 6:05 AM, "David Wu" [email protected] wrote:

We have started using the ScreenConductor class in the mortar sample
project in our own app. At first we were impressed with its simplicity. We
were especially delighted to find a surprising side-effect of using this
class to switch between screens: a smaller memory footprint due to the fact
that at any one time, only views for one screen is present.

However, as our app grows to become more mature and each screen becomes
more heavyweight, we are starting to see problems.

Going back to the previous screen is like creating the entire screen
altogether. No states (like previous scroll position) from the previous
screen can be easily remembered.
2.

A bigger problem for us is that switching from one screen to another
involves removing an old screen from the view parent, which in turn causes
a huge GC (to free the object graph as well as views for that screen). The
GC is done on the main thread and will cause a noticeable lag.

I was wondering if you guys could share with us whether you guys are also
using ScreenConductor in your production apps. If so, are you also
running into the problems that we have observed?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/86
.

[wuman]

Regarding view persistence, we are calling takeView() at onFinishInflate() and calling dropView() at onDetachedFromWindow() like the sample project. At the time when we go from screen A to screen B, the screen A's presenter's onDestroy() gets called; when we click on the back button to go from screen B back to screen A, screen A's presenter's onLoad() gets called again. In this case, the scroll position does not get preserved because the screen is basically destroyed and created from scratch. The only scenario in which the screen's state is preserved is when we perform an orientation change, in which case the onDestroy() doesn't get called.

Regarding jankiness, we did profile. We are seeing jankiness in both re-creating and destroying the object graph.

[rjrjr]

Sorry, hallucinating. Internally we save and restore screen state as
screens are swapped in, forgot that hasn't been open sourced yet. Should be
coming soon (weeks), stay tuned to the Flow project.

In the meantime if you want to do it on your own, see this for a discussion
of our technique: square/flow#11

---

Tiny keyboard has opinions on speling.
On May 13, 2014 6:45 AM, "David Wu" [email protected] wrote:

Regarding view persistence, we are calling takeView() at onFinishInflate()and calling
dropView() at onDetachedFromWindow() like the sample project. At the time
when we go from screen A to screen B, the screen A's presenter's
onDestroy() gets called; when we click on the back button to go from
screen B back to screen A, screen A's presenter's onLoad() gets called
again. In this case, the scroll position does not get preserved because the
screen is basically destroyed and created from scratch. The only scenario
in which the screen's state is preserved is when we perform an orientation
change, in which case the onDestroy() doesn't get called.

Regarding jankiness, we did profile. We are seeing jankiness in both
re-creating and destroying the object graph.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/86#issuecomment-42956209
.

[pyricau]

Also worth noting that you could implement a cache on top of Mortar to keep those views and scopes around. @loganj has done something like this in one of our apps.