App sizes are out of control

Post by RodericDay » Tue, Aug 01, 2017, 4:45 PM UTC

cyphar wrote: post #70

Swizec wrote: post #52

Earlier quoted context omitted.

> I wonder if it's possible to get major open-source libs to move towards more fine-grained build targets and internal dependency management, so that devs don't pull in a gigantic binary when they're only using a small slice of the functionality. Fwiw, this is already a trend in JavaScript land. Libraries are moving towards many small packages so you can import only the parts you need either manually or using a tool…

I don't think that's the right solution to the problem. Nobody wants libleftpad.so, and as someone who works on a distribution the very concept is horrific (making distribution packages for every three-line package does not make anyone happy). What I think GP was arguing for is that you have libstring.so which you can strip down to just having leftpad or w/e with Kconfig or similar configurations (preferably at link…

Post by Swizec » Tue, Aug 01, 2017, 4:48 PM UTC

cyphar wrote: post #70

Swizec wrote: post #52

Earlier quoted context omitted.

> I wonder if it's possible to get major open-source libs to move towards more fine-grained build targets and internal dependency management, so that devs don't pull in a gigantic binary when they're only using a small slice of the functionality. Fwiw, this is already a trend in JavaScript land. Libraries are moving towards many small packages so you can import only the parts you need either manually or using a tool…

I don't think that's the right solution to the problem. Nobody wants libleftpad.so, and as someone who works on a distribution the very concept is horrific (making distribution packages for every three-line package does not make anyone happy). What I think GP was arguing for is that you have libstring.so which you can strip down to just having leftpad or w/e with Kconfig or similar configurations (preferably at link…

Post by spcelzrd » Tue, Aug 01, 2017, 4:51 PM UTC

Twirrim wrote: post #106

dallamaneni wrote: post #82

I have been replacing traditional apps with PWA's or mobile websites wherever possible (on Android). They hardly take up any space and also seem to behave well (drains less battery) compared to traditional apps. I could replace the following with PWAs: - Twitter - Uber - Lyft - Google news - Instagram - Flipboard - Shopping sites like Walmart, Wish and many more. Facebook and Amazon have no PWA's but have mobile webs…

PWAs? Public Welfare Assistance schemes?

Post by mikeash » Tue, Aug 01, 2017, 4:51 PM UTC

Retric wrote: post #94

mikeash wrote: post #73

Earlier quoted context omitted.

Depends on the language. If you're using something like C++, you can probably remove a lot of dead code. But with more dynamic languages, like Objective-C or Ruby or JavaScript, it becomes difficult or impossible to prove that a given chunk of code is never used. In Objective-C (which I'm most familiar with), the linker will keep all Objective-C classes and methods because it has no idea if you might be looking thing…

You could use static analysis to find out if anything calls objects dynamically by name at run time which could be a useful optimization. To be safe this would be one bool value for the entire code base, but with some care it would help. A larger issue is size is simply not considered a significant issue.

Post by lcnmrn » Tue, Aug 01, 2017, 4:53 PM UTC

whowouldathunk wrote: post #43

TeeWEE wrote: post #18

Normal apps are around 10 to 20mb, which is still big. But the reason for this is support for different screen resolutions. Images of different sizes are bundled with the app, even though the phone only needs on of them. Vector graphics will solve this, but is not mainstream yet. The facebook android app is 88MB (zipped), i did check the APK of why its so big: 90mb of code 30mb of assetes (javascript, metadata, librt…

> Vector graphics will solve this, but is not mainstream yet. Then you're trading off battery life vs. space. Vector graphics can be far more expensive to render than bitmaps.