:szatkus to zależy. Teraz wiele rozwiązań idzie w stronę paralelizacji i nie inaczej jest w przypadku telefonów ( choć ja mam skrzywienie w stronę grafiki, więc mój punkt widzenia może być trochę przekrzywiony
). Zresztą nawet Android wykonuje sporo wielowątkowo ( zwróć choćby uwagę na render threads, których ilość odpowiada ilości rdzeni - 1 ). Problemem jest skostniała architektura obecnych systemów i fakt, że aby rzeczywiście móc wyciągnąć jak najwięcej z paralelizacji, to trzeba pójść w DoD. Wielowątkowość często nie jest implementowana, bo architektura nie jest na to przygotowana i np. co z tego, że można zadania sparalelizować, jeśli jedno musiałoby czekać na inne. Całe szczęście zmienia się to drastycznie i teraz myśli sie coraz częściej w kategorii małych niezależnych zadań, które operują na wąskim fragmencie pamięci i nie wymagają synchronizacji z innymi zadaniami. Umiejętność wykorzystania "data locality", niezaśmiecania cachu rdzeni to sporo pracy. Również idąc np. w grafikę, do tej pory na mobilnych urządzeniach rządził GLES, który był z punktu widzenia klienta jednowątkowy ( driver już niekoniecznie, ale deweloper nie miał nad tym kontroli ), teraz jest Vulkan, a jeszcze wcześniej w iOS - Metal i tu paralelizacja pokazuje pazur. Problemem jest niestety wiedza programistów. Wiele lat szliśmy w stronę OOP, by teraz powiedzieć, że OOP właśnie jest przeszkodą dla zwiększenia wydajności ( nic tak nie trashuje cachu CPU jak "najlepsze nawyki OOP"
). Systemy, które rozbijają wszystko co robią na małe zadania, które są przewidywalne, co do czasu jaki zajmie ich wykonanie są doskonale skalowalne i dla nich im więcej rdzeni tym lepiej ( choć eksperymentalnie przy silniku 3D wydajność przy wykorzystaniu więcej niż 4 wątków nie wzrasta już tak bardzo ). Android niestety musiałby zostać napisany od podstaw, a tak się nie stanie.