›

Unity mobile deployment slow? (2+ mins)

NickWiggillNickWiggill
edited in Questions and Answers
Hey guys,

I was checking out Unity 5 today and decided to do a little frame rate test on my Samsung Galaxy S1 and Sansui Lifepad, both fairly low-spec devices. The Sansui is probably a lot newer and is running Android 4.0, while the Galaxy S is running 2.3.3. Dev machine is a Macbook Pro 2012, which is an i7 with plenty of RAM etc. So in general, things are smooth and quick in the IDE. And on both devices, I get similar frame-rates with a basic, single-mesh scene - just under 60fps.

But... It takes about 2 minutes to deploy this baseline app to either device. I recalled the last Unity game I developed for a client in 2012 using Unity 4... same deployment time, roughly, for Android & iOS, IIRC. Is it safe to assume the deployment time to mobile devices has not improved, between then and now? (Confirmed USB 2.0 port for the deployment, and tested several times on both devices.)

What is your average time to deploy via Unity, and is it a problem for you / your teams? Do you consider this an acceptable cost of doing business in the mobile arena? Granted one can test a lot of things in Unity IDE or desktop build, but even so...? I am guessing this is due to the large executable size due to inclusion of the Unity engine package(s).

Any thoughts welcomed.

Comments

  • ElyaradineElyaradine
    Yeah, there was a Unity guy at a CT meetup a couple of months ago who spoke a bit about this after @dislekcia mentioned it being a huge pain in the ass for Desktop Dungeons. As far as I remember it had something to do with their builds switching to using l2cpp because of the new iOS standards and in preparation for doing 64-bit builds, how they're converting the codebase multiple times during the build, and that it was something that they're aware of that they're trying to address.
    Thanked by 1NickWiggill
  • dislekciadislekcia
    edited
    You should try compiling IL2CPP for iOS ;)

    -edit- Oh, hah, I see @Elyaradine signposted that already...

    I envy a 2 minute deployment cycle on iOS, I really do. At the moment I'm looking at roughly a 30 minute round trip from Unity build start to Xcode build to running on iOS device. I can cut that down to 12 minutes with a Mono build, but that's no longer a thing you can ship, so it's not worth testing with. This is with a 2.2Ghz build machine, but it's not the beefiest thing in the world...

    Random iOS deployment tip: Poke the Xcode progress bar to see what task Xcode is currently spending time on and if your copying to device is really slow, just reboot the device and watch that plummet to mere seconds. That might be fixed since iOS 8, but I haven't really been doing time sensitive builds recently.
    Thanked by 1NickWiggill
  • NickWiggillNickWiggill
    edited
    Thanks guys - not just me, then! I've a lot of respect for the way they've opened things up in Unity 5, it's a huge step for indie dev. But... iteration time is so critical. I did wonder about larger builds @dislekcia; now have an idea of how long.

    How about Unity Remote? Does it improve this at all?

    By comparison, I've nigh-zero times to recompile + link + transfer C code. But deploying cross platform is much harder.
  • dislekciadislekcia
    The issue with iOS deployment is that Xcode is a horrible pile of crap. You have to go through it in order to get onto a device. IL2CPP making everything more complicated from a compilation front just slows down an already fiddly process...

    As for Unity Remote, no idea. We never managed to get it working. I also never successfully managed to get the game running on simulators, but that's probably because OSX makes me angry in places I didn't know I could get angry.
  • NickWiggillNickWiggill
    You'll hear no disagreements from me about XCode. I'm presently trying to find a way to cut it out of the loop altogether and do my development with a pure GNU toolchain under OS X (similar to MinGW/cygwin), though from what I've heard, it's no longer possible, or if it is, you still have to get onto the app store somehow. :P What a load of bollocks.
  • ElyaradineElyaradine
    How about Unity Remote? Does it improve this at all?
    I've worked with Unity Remote before. (But this was over a year ago, though I don't think there's been much development on it since.) All that really happens is you run the game in the editor, and the editor streams whatever's on your game camera to your mobile device as a video (so you might get the wrong aspect ratio, and depending on how fast the connection is between your device and your computer might only be running at ~2-10fps), and reads any touch/device input from your mobile device into the editor.

    So it's super quick to iterate on things, but depending on what you're trying to evaluate it's arguably not useful at all (e.g. performance, or mobile-specific rendering problems, or anything that needs realtime responsiveness). But it's pretty useful for checking if your buttons are large enough to be comfortable to press on a tiny screen, or that multitouch input works.
    Thanked by 2NickWiggill mattbenic
  • FanieGFanieG
    edited
    or that multitouch input works.
    I couldn't get multitouch to work with Unity remote 4. When I build the multitouch worked fine, so when I wanted to test the multitouch I had to build to device? Had something to do with the standalone input module component.
    Thanked by 1NickWiggill
  • NickWiggillNickWiggill
    edited
    I've now pushed native C code to Android - a minimal application that just preps an OpenGL ES context and does glClear() - from Android Studio 1.2.2 to the two rather weak 'Droids I mention above. Transfer time / package size:
    • Unity app including all engine packages: 20+ MB, transferred in 130 seconds for a minimal app via "build and deploy".
    • NativeActivity + C / OpenGL "fat" .apk: 1.02 MB, transferred in 11 seconds for a minimal app. (incl. 200kB of /res PNGs)

    Maybe your figures will differ a little, but for me this is clear enough for my current project, since assets are really small. If you don't plan to re-transfer your assets every time you deploy code (makes sense!), native is again perhaps a better route.
  • dislekciadislekcia
    Yeah, I'm not sure you're measuring a worthwhile signal there... A deployment that's a 20th of the size is only 13 times quicker.
  • NickWiggillNickWiggill
    edited
    @dislekcia That's a simplistic view! You'll find a fair proportion of that 10 seconds is just setting up the adb connection, installing the app etc. and that a much smaller fraction is copying the data. Meg / sec, I think we'd see Android Studio's faster if we had to really look into it in detail. This is just speculation though.

    After all, once the Unity app gets installed, it still takes an age to start up, typically. I am not even factoring that in here.

    Will post back here on sending larger sets of assets across... say, 20MB? ;)
Sign In or Register to comment.