Issott_Common Design Patterns for Symbian OS-The Foundations of Smartphone Software_0470516356 (779879), страница 74
Текст из файла (страница 74)
A plug-inprovider then provides a body class to implement that handle.Variants and Extensions• Rapid Development using Handle–BodyLet’s consider interface design. How often have you sat down andtried to come up with a design for a class’s interface without thinkingabout its implementation? Never? Well, you are in good company.HANDLE–BODY395It turns out that most developers actually consider multiple differentimplementations when designing an interface. This is a good thing.It is even better if you can prototype several implementations.
Youcan use the Handle–Body pattern to ensure that the same interface isprovided by all your prototype implementations and also make surethat the interface is not dependent on an implementation.If you write all of your test code to work through your interfacethis also allows you to use it to test each of the different prototypeimplementations. Using this pattern can also allow you to delay yourimplementation, for example you could provide the interface and aprototype or stub implementation to a customer knowing that thecode they write will work with your implementation when you finishit. In the world of mobile phone operating system development thiscan be a key factor in reducing the time to market of a phone withyour new software in it.References• [Coplien, 1991] discusses Handle–Body in a different context.• Adapter (see page 372) is related to this pattern in that the clientuses an interface that doesn’t directly provide the implementation butinstead forwards calls to another object.
A key distinction betweenthe two is that here the handle and body classes are provided by thesame vendor whilst this is not the case with Adapter .• See also Chapter 3 for some ways to deal with the lifetime of the bodyobject.• This pattern is a specialization of Bridge [Gamma et al., 1994] inwhich there can be whole hierarchies of handle classes joined toanother hierarchy of body classes.• Façade [Gamma et al., 1994] is a similar pattern to this one but differsin that it allows the interface to change between the handle and thebody.Appendix AImpact Analysis of RecurringConsequencesThis appendix analyzes the impact of consequences that recur in thepatterns described in this book. Note that the data given here is onlyintended to allow you to assess the feasibility of design decisions andshould not be taken as accurate figures to be precisely relied upon. Werecommend that you measure directly any facts on which you base thedevelopment of your software.In this discussion, the following factors can make a significant difference to the impact of using a pattern:• which type of CPU is present on the device• which memory model is being used: this is determined by the CPU;1ARMv5 usually implies the moving memory model whilst ARMv6usually implies the multiple memory model• whether code is eXecuted In Place (XIP) or not (non-XIP).At the time of writing, the most common device configuration is anARMv6 core with non-XIP flash.
However, older or midrange devicesmay well use an ARMv5 core with either XIP or non-XIP flash.See also [Sales, 2005] as this provides helpful background material tothe discussion here.Run-time Impact of a New ThreadRAMThe RAM impact of a new thread can change depending on the size ofthe user stack it is given, as well as the size of the heap it is using. Hence1 This may be listed on the device manufacturer’s website, e.g.
for S60 devices:www.forum.nokia.com/devices .398IMPACT ANALYSIS OF RECURRING CONSEQUENCESit is only possible to give an absolute minimum figure for RAM usage. Athread uses RAM for the following things:• supervisor mode call stack – fixed at 4 KB• user mode call stack – absolute minimum of 4 KB if steps are taken toreduce it from the Symbian OS default of 8 KB; some UI vendors raisethe default stack size to 20 KB or more and may prevent it from beingreduced below this value• heap – absolute minimum of 4 KB but can be shared between threadsif required• objects used by the Kernel to track the thread – approximately 1 KB.Hence the absolute minimum RAM used by a new thread is 9 KB if theuser mode stack is reduced to its minimum and the thread shares the heapof an existing thread. However, the default minimum is at least 17 KB.Thread CreationThe time taken to create a thread will vary according to how busy thesystem is, which CPU is present on the device, etc.
However to give yousome idea of the time needed to create a new thread within an existingprocess here are some rough figures measured at the time this was written:• OMAP1623/ARM9/ARMv5 UREL – 600 microseconds• OMAP2420/ARM11/ARMv6 UREL – 300 microsecondsInter-thread Context SwitchingThe time to switch between two threads in the same process variesaccording to how busy the system is, which CPU is present on the device,etc. However to give you some idea of the time taken here are somerough figures measured at the time this was written:• OMAP1623/ARM9/ARMv5 UREL – 2 microseconds• OMAP2420/ARM11/ARMv6 UREL – 2 microsecondsNote that this is effectively the time needed to pass a message betweenthe two threads.Run-time Impact of a New ProcessRAMThe RAM impact of a new process depends on the type of smartphoneyou are targeting since this determines the following key factors:RUN-TIME IMPACT OF A NEW PROCESS399• whether the code executed by the process is run from XIP or non-XIPflash• which memory model is being used.The RAM used by a process also includes the RAM used by at leastone thread since a process cannot exist without a main thread.
Asdiscussed above, a thread uses an absolute minimum of 9 KB. However,this assumed there was another thread to share a heap with. If thereis only a single thread in a process this isn’t possible and the absoluteminimum RAM used by a single thread is 13 KB. The default RAM usagefor a thread isn’t affected by this and so is still at least 17 KB.A process also uses RAM for a number of other factors such as theamount of code loaded into the process, additional kernel objects, pagetables, etc. This all adds up to the following absolute minimum RAMusage shown in Table A.1.Table A.1 RAM Used by a ProcessXIP CodeNon-XIP codeAbsoluteMinimumDefaultMinimumAbsoluteMinimumDefaultMinimumMoving memory model17 KBAt least 21 KB21 KBAt least 25 KBMultiple memory model25 KBAt least 29 KB30 KBAt least 34 KBMemory Model LimitationsAn additional concern when creating a new process is that there is afixed limit on how many processes can be running at the same time.On the moving memory model, the limit is 1000 simultaneously runningprocesses, while on the multiple memory model it is 256.Process CreationThe time taken to create a process varies according to how busy thesystem is, which CPU is present on the device, etc.
However to give yousome idea of the time needed to create a new process, here are somerough figures measured at the time this was written:• OMAP1623/ARM9/ARMv5 UREL – 20,000 microseconds• OMAP2420/ARM11/ARMv6 UREL – 10,000 microsecondsInter-process Context SwitchingThe time to switch between two processes varies according to how busythe system is, which CPU is present on the device, etc.
However to give400IMPACT ANALYSIS OF RECURRING CONSEQUENCESyou some idea of the time taken here are some rough figures measured atthe time this was written:• OMAP1623/ARM9/ARMv5 UREL – 70 microseconds• OMAP2420/ARM11/ARMv6 UREL – 10 microsecondsNote that this also gives a minimum time for a message passed betweenthe two processes.
However, if a large amount of data is transferred (andtherefore copied), the time needed for that could be more significant thanthe time to simply switch contexts.Run-time Impact of Increased Code SizeIncreasing the code size of an executable can impact the following systemcharacteristics:2• The executable takes up additional disk space.• More RAM is needed to load the executable.• Loading the executable takes longer.However, which characteristics are impacted and to what degreevaries according to how the device is configured and what technologiesit uses.