I have read that OSes like Android and iOS are somehow optimised to improve battery life.
My understanding is that a CPU executes a certain number of operations in a certain time, so I would think that you can speed up applications by reducing number of operations required, but since the CPU will still do x operations in y time, that should not affect power?
Also, if a process occupies more RAM, does it consume more power?
Common CPUs that go into smartphones, laptops and even desktop PCs have a variable clock rate. When the scheduler detects that it has idle time, it can reduce the clock rate, and increase it again if there are more processes competing for CPU time.
CPUs optimized for battery-powered devices tend to be composed of many functional components that each have their own clock (example: ARM Cortex A8). When one component is idle, the operating system can turn it off (or reduce its clock), which saves power. For example, on many multicore CPUs (such as the ones in high-end mobile devices), each core can be turned on or off separately. ARM is particularly good at this game, which is one of the reasons why most smartphones have ARM CPUs.
Varying the clock rate or turning off the clock of electronic components is known as power management. It tends to be a complex part of writing and optimizing an operating system for a battery-powered device, with many dependencies on the exact hardware model.
What goes for the CPU goes for peripherals too. The backlit display is a major consumer of power on a smartphone, for example, followed by the radio. The CPU operating system may play a role in power management of peripherals; secondary chips also runs their own firmware which performs power management as well.
Applications have their part to play in keeping power consumption down: they must allow the operating system to do its thing. The worst thing an application can do is polling — running a loop like while (not_ready()) {}. Even introducing a small delay as in while (not_ready()) {usleep(100);} doesn't help as it doesn't allow enough time for the processor to go into low-power mode, or if it does, each unfruitful wake up means wasted energy. Thus the operating system APIs must be designed so that applications never need to poll, but can instead subscribe to some kind of event mechanism and remain idle until they are notified of a relevant event. Applications in turn need to take advantage of such mechanisms, so the design of the whole software stack has an impact on power consumption.
You can get some information about what's responsible for your PC's power consumption with Intel's Powertop utility. Smartphones typically have a way to see how much power applications have been consuming as well. Accounting for power consumption by application precisely is difficult: if a component wakes up for two applications, the wake-up time may be accounted to one of them somewhat arbitrarily or to neither; peripherals' power consumption are also not always be easily tracked to the application responsible.
A RAM chip doesn't know which of its bits store data of an active process, so it can't be turned off selectively in this manner. A process's power consumption isn't related to the amount of memory that it uses (except inasmuch as the RAM accesses consume power, but re-using the same memory or using different RAM areas makes no difference with respect to power consumption).
In terms of processor power the main thing the OS can do is to provide APIs that discourage applications from polling. (And also eliminate all polling inside the kernel and device drivers if there was any.) Then the processor can be put into a low power sleep state whenever there is nothing to do.
For every device there needs to be a way for the user apps to go to sleep after a request and then get woken up again only when the result is ready.
Obviously tight polling loops are a disaster (because they keep the processor fully awake and executing useless noops and jumps.) But there are more subtle, but nearly as bad cases where the user app is setting timers, waking up on the timer alarm, checking some condition, resetting the timer and going back to sleep.
I know less about this part but I think there may also be creative ways of using DMA (direct memory access) controllers to handle long strings of repeat interrupts without waking the processor core itself.
The OS main role is to provide a runtime environment as independent from the hardware as possible. It knows who is using what hardware, when and how someone is using hardware. This allow the OS to reduce the hardware power consumption when it is not used.
Modern hardwares provide many ways to reduce power consumption, such as
if a process occupies more RAM, does it consume more power?
Not really. Nevertheless, if your system has 1GB of DRAM, but you only uses 512MB, with some memory controllers, it is possible to stop refreshing part of the DRAM, thus reducing power consumption. LPDDR supports Partial Area Self Refresh to do the same while in self-refresh (while the processor is stopped, which is true most of time on mobile devices).
As you may see, there are many ways to reduce power consumption on modern architectures, but it requires the OS to handle it. Some features, such as PASR, are very tricky to use, this requires much work on the OS to adapt memory management, to implement suspend/resume procedures, ...
As you are no doubt aware, the OS maintains a variety of lists. Two of these lists are the ready list and the timer list. The ready list identifies which tasks/threads are ready to run. The timer list identifies the tasks/threads that are in a blocked state with a timeout.
Imagine that the OS has an empty ready list. That is, it has run out of tasks that are ready to run (it is in the idle state). Some processors (such as the x86) have a halt instruction that the OS can invoke to cause the processor to stop until it is awoken by an external interrupt (such as a tick interrupt). During this period of time, it is consuming less power. This technique can be further improved by peeking at the timer list. If you are idle and you know that soonest a task can wake up from a timer tick is 100 ticks away, the tick rate may be temporarily modified to be say 100 times slower. This way, the processor can expend even less energy for a longer period of time because it will not have to service up to 100 tick interrupts.
Once the external interrupt arrives, the tick rate will have to be recalculated. If the external interrupt made a task ready, the tick rate goes back to normal. If not, the number of ticks to sleep must be recalculated along with the new (slowed) tick rate.
Hope this helps.
To add to the other answers:
Your question regards iOS and Android as operating systems but the "Operating System" is only part of them.
Both Android and iOS are frameworks and include many parts that are not considered part of the actual OS but are active in reducing power consumption.
For example, Android by design allows the application developers to save their state when hidden, so processes can be terminated when not actively in use and thus reduce the amount of ready threads and allow for core shutdown and clock rate reductions.
There are features in the "OS" that set adaptive brightness, wi-fi sleep state, cleanup threads, schedule pooling, LED indicators, cellular standby behavior, and other aspects that affect power consumption drastically.
In addition, some mobile platforms have been working hard on optimizing their CPU/GPU usage ratio, since the GPU is more adapted at graphics and it's a relatively new addition to the mobile landscape, more and more graphic related parts of the OS are moving to the GPU, which clears work from the CPU, and allowing for the usage of CPU power optimizations to be used (and in many cases, also speed up the system as a whole).
