Live data from Hacker News

App sizes are out of control

trevore.com

381–390 of 455 posts

Re: App sizes are out of control

#381
post #359

I am surprised at all of the app developer shaming in this thread. Is it really likely that every developer working on a popular BigCorp app is an idiot who imports 10MB libraries every time he/she faces the slightest challenge? It's much more likely that app developers are optimizing for many things, including app size, but reducing app size has a bad cost/benefit ratio. Here are some decisions that may bloat your a…

Mobile platforms should really do something about vector graphics. Shipping raster image which has much larger size than vector image is stupid. Shipping 3-5 raster images is beyound stupid. Surely there could be a way to render images on demand or roll some simple vector format which would be fast to render (it's not like decompressing PNG is that easy, it takes processor time as well).

Android offers VectorDrawable for this purpose, and Android Studio will automatically convert SVGs for you. It works great for icons and other "material" stuff, anything where flat colors and simple paths are sufficient. I believe there is also a support library to use it on older OS versions but have no experience with that since we're happy with 5.0+ for our app. I highly recommend it over making all those PNGs for different screen densities.

Re: App sizes are out of control

#382

Earlier quoted context omitted.

GPUs do not like SVGs. They don't handle them well at all. Most SVGs are CPU-rasterized as a result.

May be SVG is not the best vector format after all. May be we need something simpler, where every item directly maps to GPU graphics calls, also binary would help.

GPUs have graphic calls anymore. At best they have fragment and pixel shaders. Converting a vector graphic into a good shader is not trivial, compared to using the built in functions of texturing.

It gets even worse once you realize how limited older mobile GPUs are or what are the incompatible subsets of features supported at decent performance.

Re: App sizes are out of control

#383
post #147

Earlier quoted context omitted.

This happens a lot, especially with dynamic linking. I have a project that uses Qt, OpenCV, CUDA, PCL and VTK - fairly standard stack for 3D imaging and visualisation. Since you normally need to bundle dependencies to account for different versions, this adds up quite fast. Qt adds 20MB for OpenGL, 15MB for the VC++ redist, about 30MB for other core libraries. Some stuff in OpenCV requires Nvidia's performance primit…

I had a fun time with this once. The Jetbrains Toolbox app is written using Qt and is 150mb. I opend the .app package on mac, deleted the frameworks directory, and symlinked it to my system's Qt install. It's now 6mb.

And it will break at random due to API or ABI incompatibility. Have fun gluing the pieces back together.

Re: App sizes are out of control

#384

It's pretty rich how these companies are well known for the rigor they apply to interviewing candidates on technical subjects, yet actually drop the ball in production with poor engineering like this. Where does that rigor go after the interviews are done? Are there any examples of well-known apps from large organizations that aren't excessively large in size?

Not exactly large organisation, but the slack app is 80MB. For reference, discord is 17.

Please also count in server side data downloaded for identical functionality. It does not help if 80% of the app is downloaded after installation.

Re: App sizes are out of control

#385
post #34

Folks: there's a built-in technology on your phone that allows you to load and run an app on-demand over the internet without dedicating any internal storage at all! It allows clean integration with many of the "native" features you expect like camera and notification and timers and stuff. And it's based on completely open standards with multiple, competing open source implementations. No, seriously: uninstall that j…

  > It works much better than you think
Thanks, but we do have smartphones and we are aware of this thing called browser. We are also aware how it works. Not "much better" for sure, if better at all.

Re: App sizes are out of control

#386
post #329

In several interviews I've been questioned about the importance of my contributions throughout my entire career because the apps sizes were so small (typically 8 - 12 mb) When asked it was clear they'd already made up their mind, and discussions about optimizations, how the app actually did anything, MVC, MVP or SVGs didn't change that. And thats how you have large apps!

To paraphrase Bill Gates, that's like measuring an aircraft designers skill based on the final weight of the aircraft. Any idiot can create something bloated and complex, creating something small and simple requires much more effort.

But when you think about it, final weight of the aircraft does say something? I guess an amateur could design something like Cesna and have it flying, but designing An-225 is a different matter.

Re: App sizes are out of control

#387

Earlier quoted context omitted.

The Spotify app is dog slow on a Samsung S8+. Do you know how ridiculously overspecced this phone is and it can't load a Winamp clone with a terrible UI! Hell, all of Android is far, far slower than it should be. I won't move to iOS but what Apple can do with a dual core phone is pretty amazing (and yes, I know that newer OS builds get slower).

I really wish android came with better tools to let you know what is bogging down the machine. If only they hadn't gutted the linux part of it, we could have much better tools at our fingertips.... Does anyone know of a good process-viewer/resource watcher for android?

Google killed all of the outside tooling by messing with their own variant of IntelliJ and build system. (Especially the latter. Eclipse plugin for gradle w/ android support is hopelessly incomplete, killing eclim which was the one reasonable code completion software.)

Apparently writing an IntelliJ plugin of a reasonable quality is much harder than a Python or other script. Who would have thought. And a glorified text editor takes GBs of RAM, likewise a glorified Makefile.

(The resource watcher is built into Android Studio, but ignores GPU memory. To do that you have to run GPU debugger, a separate memory hog.)

Re: App sizes are out of control

#388

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…

Well here is an application that defies your approach: the Android clock. 17Mb update to that just now, vanilla android. Plus Google do some diff. style updates so that is probably a lot more and for a clock. Presumably it has 17Mb of updated alarms in surround sound and presumably these are needed however I can't see any other obvious bloat potential as the clock should use Android UX. How can a clock need the equiv…

These clocks did not have high fidelity long ringtones and billion of options. And especially no Google calendar support. ;)

Re: App sizes are out of control

#389

Earlier quoted context omitted.

I'm sincerely curious what would be the worst offenders for app bloat.

It varies, but for most apps I'd wager it's library bloat, but in my experience doing iOS dev here are the common culprits: - For games assets are a big issue. Some do not compress their assets, and unfortunately most image-authoring tools make it easy to output PNGs that are much larger than they can be. I think a lot of people by default assume bloat comes from images/icons/etc, but IMO this is a red herring for mo…

Congratulations, now you cannot use any app on an intermittent or slow network connection.

This "cure" is worse than the disease.

Re: App sizes are out of control

#390
post #256
post #212

Earlier quoted context omitted.

>1024x1024 SVG Vectors don't have pixels.

However, they usually are designed around a target size. And it's quite possible that, scaled too small, much of the detail is lost. Hence why you'd still want different vector files for different resolutions.

Considering the topic of this post (apps), I would argue assets are usually designed around a physical size of the image; even when you have multiple target display sizes, it becomes a part of the requirements to design assets the way that looks decent on all phones. Moreover, I find this whole branch of discussion a bit funny because assets are already designed to be high res and later downscaled for target dimensions, so simply using vectors literally just pushes that task to phone instead of build server.
Post reply on HN