<@UD35LNXU6> I would say No architecture doesnt ha...

# android-architecture

[rkeazor]

@Shalom Halbert I would say No architecture doesnt have any correlation with Battery consumption. They will all get turned into bitecode. With that being said, its important to try and write efficient code

[Shalom Halbert]

Thanks for the response, although I think it overlooks how performing more operations should have an impact on a devices resources- be that battery, memory, or something else. @ghedeon’s response covers the question quite well.

[rkeazor]

yea but architecture is really about how you organize your code.For instance I can write hello world app in both MVVM MVI, which would pretty much have zero effect on your battery. so to say that architecture effect your battery , i would still disagree

[rkeazor]

Things that effect your battery performance, are normally hardware interactions , like WIFI connectivity, bluetooth ect,

[rkeazor]

but you can always write code that is less performant and or memory intensive

[ghedeon]

memory churn -> more GC -> more CPU -> more battery.

[ghedeon]

but it's hard to measure a statistically significant impact of MVI solely

[rkeazor]

Sigh @ghedeon memory allocation and deallocation are more related to performance than battery impact. I think you guys are being abit extreme. Future more it's not really about the architecture, it's more really about the code itself

[rkeazor]

I think you can look into developers.android.com for reference to things that directly effects battery

[kevinmost]

It totally stands to reason that the more you're forcing GC events, the more CPU the VM is using, and the more CPU the VM is using, the higher load there is on the system. And the higher load there is on the system, the more battery is used.

In practice, it's really unlikely to matter. The amount of energy used by the GC is very small compared to wireless radios, but it is still non-zero.

[rkeazor]

And how would you actually measure it?

[kevinmost]

Measuring the result of different architectures is not really feasible, because there's would be too many confounding factors in two "equivalent" apps (one made with MVVM, one made with MVI). But you could easily measure the effect of increased GC churn on battery usage by writing two equivalent code blocks (one specifically generating a lot of garbage)

[rkeazor]

Exactly, measuring the results of different architectures isn't feasible . This was the original question, and that was my original answer

[rkeazor]

I don't know why everyone was debating this in the first place lol

[rkeazor]

I would even argue , testing GC churn, isnt as easy you think. But if you believe , by all means try and let us know your results\

[kevinmost]

That wasn't the original question. The original question was whether a stateless architecture like MVI is less battery-efficient than a stateful one like MVVM, and the answers given were that it is less efficient (as running GC more often inherently uses more CPU), but likely not to an extent that matters.

[ghedeon]

@rkeazor your answer wasn't "it's hard to measure", your answer was "different architecture has no effect on battery". But it's probably better to finally archive this thread 😄.

[rkeazor]

I said there is no real correlation, and there isn’t

[rkeazor]

lol

[rkeazor]

@ghedeon And he didn’t say it was hard to measure, he said it wasn’t feasible to measure .

[rkeazor]

Like you do realize that architecture just means in its simplest form ” How you organize your code” . It is completely irrelevant of libraries and or other frameworks

[oday]

who can measure something like this, it’s not even provable, you imagine what you have to test to come up with such a measurement? let alone ask such a general question on whether this or that is the prime cause of it? none-issue really

[kevinmost]

You don't need to measure something directly to be able to prove it. You can prove it inductively. We know:

- MVI churns memory faster than MVVM because it involves `new`ing up more objects
- Churning memory faster triggers GC more often
- GC events cause more CPU usage
- Higher CPU uses more battery

What step of this reasoning do you disagree with?

[kevinmost]

Even if it's a non-issue because other power-consuming components of your application far outweigh GC power usage (which everyone here was always on the same page about), it's objectively true that triggering more GC events will lead to more CPU time used. So what exactly are you arguing?

[oday]

the practicality of going into such a question given what im assuming the asker is trying to achieve “good performance”, there are tons more worthy alleyways to achieve that goal through and architecture is the least of their worries, i am assuming on his behalf on what he was really asking, sure

[kevinmost]

of course, it's nothing but a thought experiment. I doubt there are any scenarios where performance issues would arise due to the use of MVI on a modern device, but I could see it being an issue on a memory-constrained old device if your application is doing, let's say, camera work. Working with a bunch of large bitmaps + the added strain of GC churn is probably not ideal. Hard to prove, but all we really know beyond any doubt is that there would be some non-zero performance impact.