OK, I'm a bit late to this thread but I'll try an introduce some analysis. I'd be interested in hearing from someone who knows more about this stuff.
Apple wants all developers to use the Cocoa Touch API - but why is this? Most people (Daniel Dilger) will say "because it ensure a consistent, accessible and beautiful user interface", but a quick look at the architecture of the operating system sheds a little more light.
Implicitly, sitting above the top layer is your Objective-C code. Apple don't actually reveal very much about how their App compiler / packager actually works - but running the top command via OpenSSH reveals some things I found interesting. When you scroll through a list of options, say in the settings application, the application's CPU usage shoots up - as does the usage of SpringBoard (the home-screen). This strongly suggests to me that the actual API "Cocoa Touch" is either embedded in the Springboard application or a significant part of user interface work (i.e. compositing / producing the bitmap that's fed to the screen) is done inside SpringBoard.
This top output - for example - was while scrubbing through the list of top stories in the Guardian.
Playing a file in the iPod application:
Playing a video in the iPod:
So we've got one application that takes care of the media. With the on-screen controls, SpringBoard's CPU usage shoots up to around 18%, suggesting that it is heavily involved in compositing.
As for core-services: other than search they seem to be buried inside the Core OS and therefore can't be displayed by top (I don't think...).
So what this means is that Apple's software platform is centralized - only one instance of the services which power the audio, video and visual interfaces are active at one time and all applications must use them. This makes sense - it saves memory because each application doesn't have to load up mediaserve - and means that the operating system kernel doesn't have to decide which applications get access to the screen or video hardware - because all requests (even OpenGL seems to be rendered, passed into SpringBoard and then passed back out) go through these special applications. As a result Apple has, by accident or design, precluded the development of software libraries that access the hardware directly - despite the fact that on a mobile device these facilities need to exist - and that is probably what the FTC must decide is anti-competitive. This means that Apple can, quite legitimately, claim that Flash would eat up the CPU, simply because it can't draw directly to the screen and must go through these servers. This is not a problem on desktop computers, simply because there's so much more power.
No matter what the FTC's decision might be there's no getting round it for Adobe - an alternative intermediary software layer that runs on the iPhone will be forced to duplicate what's already running - at least in the mid-term future. However, Apple could probably make dispensations to permit 'more' direct access to the hardware (this might well end up being important to Adobe - its' very likely that it uses a common rendering engine across all platforms to ensure consistent results), or returning screen co-ordinates to an optional flash 'server' that runs outside normal applications.
Apple wants all developers to use the Cocoa Touch API - but why is this? Most people (Daniel Dilger) will say "because it ensure a consistent, accessible and beautiful user interface", but a quick look at the architecture of the operating system sheds a little more light.
Implicitly, sitting above the top layer is your Objective-C code. Apple don't actually reveal very much about how their App compiler / packager actually works - but running the top command via OpenSSH reveals some things I found interesting. When you scroll through a list of options, say in the settings application, the application's CPU usage shoots up - as does the usage of SpringBoard (the home-screen). This strongly suggests to me that the actual API "Cocoa Touch" is either embedded in the Springboard application or a significant part of user interface work (i.e. compositing / producing the bitmap that's fed to the screen) is done inside SpringBoard.
This top output - for example - was while scrubbing through the list of top stories in the Guardian.
Code:
Processes: 36 total, 1 running, 35 sleeping... 200 threads 15:23:27
Load Avg: 0.21, 0.64, 0.75 CPU usage: 62.50% user, 24.26% sys, 13.24% idle
SharedLibs: num = 0, resident = 0 code, 0 data, 0 linkedit.
MemRegions: num = 5059, resident = 110M + 0 private, 39M shared.
PhysMem: 42M wired, 41M active, 28M inactive, 240M used, 13M free.
VM: 1977M + 0 28329(0) pageins, 50(0) pageouts
PID COMMAND %CPU TIME #TH #PRTS #MREGS RPRVT RSHRD RSIZE VSIZE
29 SpringBoar 44.2% 7:35.41 15 459 901 12068K- 7196K+ 22M- 160M-
755 Guardian 19.4% 0:15.73 6 119 343 4776K 6188K 11M- 106M-
805 top 5.9% 0:00.86 1 22 50 628K 1440K 1152K 15M
699 sshd 0.5% 0:03.78 1 15 36 316K 1212K 1296K 14M
117 MobilePhon 0.5% 0:06.58 6 153 286 4532K 4628K 8100K 117M
33 CommCenter 0.5% 0:20.35 10 225 97 1084K 2428K 2100K 51M
..
Playing a file in the iPod application:
Code:
Processes: 30 total, 1 running, 29 sleeping... 151 threads 15:38:51
Load Avg: 0.68, 0.28, 0.18 CPU usage: 12.15% user, 6.54% sys, 81.31% idle
SharedLibs: num = 0, resident = 0 code, 0 data, 0 linkedit.
MemRegions: num = 2902, resident = 50M + 0 private, 36M shared.
PhysMem: 46M wired, 39M active, 18M inactive, 152M used, 101M free.
VM: 1157M + 0 12829(0) pageins, 0(0) pageouts
PID COMMAND %CPU TIME #TH #PRTS #MREGS RPRVT RSHRD RSIZE VSIZE
37 mediaserve 8.3% 0:02.31 26 288+ 222 9336K+ 1212K 5300K+ 46M+
146 top 5.5% 0:33.16 1 24 50 596K 1468K 1120K 15M
137 MobileMusi 0.9% 0:13.41 8 151 245 6996K 6772K 11M 109M
18 SpringBoar 0.9% 0:15.45 16 420 624 11424K 7096K 19M 152M
...
Playing a video in the iPod:
Code:
Processes: 28 total, 1 running, 27 sleeping... 150 threads 15:39:49
Load Avg: 0.91, 0.39, 0.23 CPU usage: 25.00% user, 13.89% sys, 61.11% idle
SharedLibs: num = 0, resident = 0 code, 0 data, 0 linkedit.
MemRegions: num = 2863, resident = 51M + 0 private, 45M shared.
PhysMem: 55M wired, 40M active, 18M inactive, 165M used, 88M free.
VM: 1099M + 0 13267(0) pageins, 0(0) pageouts
PID COMMAND %CPU TIME #TH #PRTS #MREGS RPRVT RSHRD RSIZE VSIZE
37 mediaserve 24.8% 0:10.66 28 317 239 11228K 5064K 10M+ 54M
146 top 5.5% 0:36.55 1 22 50 604K 1468K 1128K 15M
18 SpringBoar 4.6% 0:18.44 15 422 664 11828K 12M 20M 157M
38 locationd 0.9% 0:00.66 8 106 88 2116K 2352K 4068K 50M
21 SCHelper 0.9% 0:00.59 4 52+ 61 368K+ 1204K 612K+ 21M+
15 configd 0.9% 0:05.59 16 317 131 1108K 2344K 2820K 43M
...
So we've got one application that takes care of the media. With the on-screen controls, SpringBoard's CPU usage shoots up to around 18%, suggesting that it is heavily involved in compositing.
As for core-services: other than search they seem to be buried inside the Core OS and therefore can't be displayed by top (I don't think...).
So what this means is that Apple's software platform is centralized - only one instance of the services which power the audio, video and visual interfaces are active at one time and all applications must use them. This makes sense - it saves memory because each application doesn't have to load up mediaserve - and means that the operating system kernel doesn't have to decide which applications get access to the screen or video hardware - because all requests (even OpenGL seems to be rendered, passed into SpringBoard and then passed back out) go through these special applications. As a result Apple has, by accident or design, precluded the development of software libraries that access the hardware directly - despite the fact that on a mobile device these facilities need to exist - and that is probably what the FTC must decide is anti-competitive. This means that Apple can, quite legitimately, claim that Flash would eat up the CPU, simply because it can't draw directly to the screen and must go through these servers. This is not a problem on desktop computers, simply because there's so much more power.
No matter what the FTC's decision might be there's no getting round it for Adobe - an alternative intermediary software layer that runs on the iPhone will be forced to duplicate what's already running - at least in the mid-term future. However, Apple could probably make dispensations to permit 'more' direct access to the hardware (this might well end up being important to Adobe - its' very likely that it uses a common rendering engine across all platforms to ensure consistent results), or returning screen co-ordinates to an optional flash 'server' that runs outside normal applications.
