I was lucky enough to be accepted to Apple’s tech talk in London, last monday. So I spent 3 days in London and had some fun. But mostly I “worked”, attending the Apple mini conference.
The city
London is not my preferred european city, and my experience of London hotels got worse this time. It surely wasn’t expensive, but the room was very very small (I could stand up, but barely). I had a shower/toilets combination: if I wasn’t careful taking my shower, falling in the toilets was next. And the hotel was on a really noisy street with cars and trucks all day and all night.
One of the very first things I bought was a box of earbuds to have less noise during the night. I wasn’t successful. I didn’t leave a good review on FutureTap’s WhereTo? app hoping it will help others make a better decision than me.
By the way: don’t read Booking.com comments and reviews.
The venue
The place looked a bit like Moscone, from the outside,butwith a nice atrium inside. We had three rooms downstairs for sessions. The catering, food and drinks was excellent. Wifi was quite good all day except when it got bad in the middle of the afternoon (and then it was really bad).
This might look like something stupid to talk about. But those who remember the venue for last Tech talk in Paris will understand what I mean when I say it was much better.
The program
I mostly stayed in the main sessions room. Except when I missed a session. So I saw all general sessions.
The kickoff was by John Geleynsie who’s proved over the years how good and inspiring he can be. I remember the first videos I saw with him when the Cocoa Touch SDK was launched. The speech was essentially unchanged from last tech talk, only more historical: figures of sales, of money made by developers on the app store, demo of a range of apps from big -studio to indie-dev, and a lot of motivating sentences to push us to adopt quickly new features from iOS 5.
Mark Kawano was next and you can read all about his presentation on Ole Begemann’s blog. That’s exactly it.
Then Michael Jurewitz had his first session on iCloud. Although the subject was arid, and much more technical than the first two, Michael was quite successful in making it entertaining and motivating, underlining the easiest path to iCloud integration and all the benefit users and developers could get from it.
The first session of the afternoon was also with Michael, and he was once again able to keep many of us interested and awake after a pretty good lunch. I don’t know for others, but he motivated me enough that I am now absolutely sure I will drop support of iOS 3&4 in the next version of 321run and upgrade it to Core Data (at last) to take advantage of iCloud integration.
I missed the session from Stefan Lesser on Xcode 4.2 as it was something I had already seen and seen and seen both at WWDC and in WWDC videos.
ARC session was next, also by Stefan and he managed quite well this discussion, but didn’t get as many “oohs” and “aaahs” as I heard in the WWDC sessions. You may need to relax a bit Stefan. I know it’s hard, but you jokes
The last session was by Michael again, and the best one in my opinion, as it was the one in which I wanted the most to take out my Mac and iPhone and do what he was talking about. I had already seen sessions about Instruments, and I use Instruments regularly when needed (don’t fix what’s not broken), mostly for performance and memory issues.
But his session was a real hands on session from someone who has had to do it many times to help other developers. It remembered me my time as a Web Performance specialist, dissecting the issues one page or a particular workflow created for users to improve it, adding caches, minimizing js and so on.
The session
Generally, Michael reminded us of several rules: measure first, analyze, change incrementally and re-test, to measure again if there are improvements (you don’t want to worsen the user experience). Don’t take a global approach to performance, you need quick successes, before you need to re-architect your code for days. Always use a worst case scenario regarding your data: a user who’s got 400 runs with 321run, who’s got 100s of RSS feeds etc, not the simplistic case of a few subscriptions. Then he went in the details about three specific topics: performance, memory and drawing, as these are the most often met.
Performance: das ist wichtig!
Who cares that your app is nice and well designed if the user has to wait 15 Seconds to get to the first screen? Remember your app is jettisoned on launch after 20 seconds. And generally, waiting more than one second is a bad experience.
This waiting could occur both on first “cold” launch or when the app returns from Springboard. Here, dispatch_async is your friend, and generally do whatever you can to return fast and not block the main thread.
He then demonstrated How to use Instruments. Use the Time Profiler to measure what’s happening in your app, and keep the call tree in the right order. Once you are done with the thing that takes time (in his example the launch of the app), you can unfold that tree, starting with main, to find out where you are spending time. You also shoudn’t hide the system libraries calls, to know everything about the performance issues your app might have, where it’s spending time.
The ‘self’ column is very interesting to watch as it gives you a good overview of where time is spent.
If you click the arrow on the right of a call, you’ll recalibrate this column and the time spent (in percent) starting at that call.
In his example he had an easy problem: the app was making a synchronous call to a json iTunes Store URL, and then fetching the images. It was the occasion to remind us that a web connection should never be made on the main thread. Never. Ever. You lose control when you do that, anyway.
Memory
You must be careful about your memory usage, for several reasons. First of all there’s only 512 MB on the device today, less on the older devices, and a lot of that memory is already used by the system. There’s no swap file, so you really only have 512MB.
Apps that use too much memory are killed. Even the frontmost. And when you receive a memory warning in iOS 5 it is really time to do something, because you might be killed by jetsam (I personally had an app which would cause the device to be rebooted because of memory issues after a while, as I was not releasing stuff).
Be also careful about abandoned memory: memory that you’ve stuffed, for example with data or caches, but that you actually don’t use. It increases your memory footprint and that is bad.
Memory spikes are bad. They can cause your app to crash, but also your code to be purged from memory temporarily. The system needs more memory, so it purges your executable, and then needs to reload it, causing a loss of responsiveness.
To be able to analyze memory, Michael has created his own template with:
* Allocations
* Leaks
* VM tracker
* Activity monitor
Here’s a version I made of juryAllocations which you can install in ~/Library/Application Support/Instruments/Templates
The last tool is here to show you generally how much memory your app is using compared to other apps on the device.
The VMTracker shows you the real memory usage of your app.
The leaks tool is here to help you detect leaks. As everybody said in the audience, the right amount of leaks to have in an app is 0, so you should watch that tool closely to repair anything you might have forgotten.
And finally the first tool on the top of the list, Allocations, is here to help you find out which objects and which memory is allocated. Not all memory is objects, the system also allocates some for foundation and other libraries.
Michael used the mark heap button to have a measurement of memory usgae in between two points: move the head to a plateau in memory usage, then press the button, go to another plateau and mark again: this way you see only which memory was allocated during an increase in memory usage.
Drawing: you are no designer, so you’d better be fast
Problems are usually of two kinds when drawing. And what you’re wanting to achieve is 60 fps.
- bad blending of layers causing a bad performance
- misaligned images causing blurry pictures
Use opaque images as much as you can as it will make the life of the rendering engine easier and much faster.
To learn more about how your app draws to the screen, you should use the Core Animation tool. And once it’s launched, first tick the Color Blended Layers option. Then look at your app: what’s green is fully opaque and only one layer is rendered. What’s red is blended between at least two layers, and the redder the merrier: if it’s more, there is more blending.
Blending is not bad per se, it just depends on where it occurs. A famous example is the fact that often people but a clearColor in the back of a UILabel inside a table cell, thinking that it’s the way to have the selection color shine through, when actually it is useless as the framework records that color for the cell that is selected automagically and makes the label background transparent just when it needs to be.
Don’t forget to switch off that before leaving Instruments though:
Bad alignment of images is another kind of problem which has more to do with the quality of the rendering rather than the speed. Basically, the idea is that you can put images not exactly aligned with pixels, thus creating a bad anti alias where each point of the image has to render over two pixels, instead of one as it should be.
This is generally the consequence of scaling, replacing images by inappropriate retina display images.
You can turn the Color Misaligned Images option on, and it will show you where your images are badly aligned to the pixel, thus in danger of blurring.
Getting together
As usual, an important aspect of these get together events is the occasion to see people you’ve not seen in some time, and to meet new people, and usually from all over Europe, or the world.
I met in person with @cocoanetics Oliver Drobnik, for whom I had bought an iPhone 4s in France in October, and we spent some time trying to figure out if this tech talk would now be regularly scheduled or not, what sessions were most helpful, what kinf of audience was there.
I saw people I know from CocoaHeads Belgium, NSConference or the WWDC, such as Steven Vandeweghe (@bluecrowbar) from Bluecrowbar, Simon Wolf (@sgaw), and people who didn’t attend the tech talk, but were there post tech talk to meet other developers, drink one beer or ten, and know what new or more precise stuff had been discussed in the tech talk, such as Mike Lee’s father who came from Cambridge.
I met quite a few people I didn’t know, both from Apple or not. Sorry I don’t put everybody’s name
I left early (you know, the jetlag and my old age don’t get well together), to go back to my wonderful bedroom. Apparently, beers were drank, tweets were exchanged, but nothing special happened regarding #lickahoktor or bleaching.
Bonus
One thing the evangelism team didn’t talk about a lot before we were there is the fact that there was a Lab. I’m quite disappointed I didn’t know. Only a few of us went to see the people in the Lab, and I didn’t have a list of things to show, ask, review with them as I did during WWWDC.
If you’re lucky to go into another tech talk, think about it, there may be another lab. Be ready! If there’s a lab, you have issues and you don’t go to see them, you’re missing the greatest opportunity to solve your issues.
