Existem celulares minúsculos, telas enormes, notches, barras de status e tablets — e seu layout precisa ficar bom em todos. O segredo não é desenhar em pixels, mas pensar em unidades lógicas, respeitar as áreas seguras e deixar o layout se adaptar sozinho. É um dos primeiros temas em que um júnior tropeça e um dos primeiros que entrevistadores cobram.
Pixel físico vs pixel lógico
Dois celulares podem ter o mesmo tamanho físico mas números de pixels muito diferentes: um tem tela "normal", outro "retina/alta densidade" com o dobro de pixels no mesmo espaço. Se você posicionasse tudo em pixels físicos, o botão de 100px ficaria gigante numa tela e minúsculo na outra.
Por isso as plataformas usam unidades lógicas: dp (density-independent pixels, Android) e pt (points, iOS). Você descreve "quero 16 unidades de espaço" e o sistema multiplica pela densidade da tela para chegar nos pixels físicos reais.
| Densidade | Fator | 16 dp/pt viram |
|---|---|---|
| mdpi / @1x | 1x | 16 px físicos |
| xhdpi / @2x | 2x | 32 px físicos |
| xxhdpi / @3x | 3x | 48 px físicos |
A analogia: dp/pt são como "centímetros" do mundo mobile — uma medida que significa o mesmo tamanho aparente em qualquer tela. Pixels físicos são como contar grãos de areia, que variam de praia para praia.
Por que medir em dp/pt
Medindo em dp, um espaçamento de 8 dp parece igual no celular do estagiário e no topo de linha. O sistema cuida da conversão. É comum em entrevista pedir para explicar a diferença entre px e dp e por que nunca se deve cravar pixels físicos — a resposta esperada é exatamente essa independência de densidade.
A armadilha do hardcode de pixels
// RUIM: assume largura fixa em pixels
imagem.largura = 320 // estoura em tela pequena
// BOM: relativo ao espaço disponível
imagem.largura = "100%" // ou usa constraints/flex
imagem.altura = aspecto(16, 9)Cravar 320 de largura quebra no aparelho de 4 polegadas e desperdiça espaço no tablet. No dia a dia esse bug aparece como texto cortado, botão fora da tela ou layout que "estoura" em certos modelos.
Safe areas: notch, status bar e home indicator
A tela retangular nem toda é utilizável. No topo há a barra de status (relógio, bateria) e o notch/ilha; embaixo, a barra de gestos ou home indicator. A safe area é a região onde seu conteúdo não fica escondido atrás desses elementos.
+---------------------+
| [status bar / notch]| <- nao coloque botoes aqui
| |
| AREA SEGURA |
| (seu conteudo) |
| |
| [home indicator] | <- nem aqui
+---------------------+Ignorar a safe area faz o título sumir atrás do notch ou o botão de ação ficar embaixo da barra de gestos, onde o usuário não consegue tocar direito.
Do celular pequeno ao tablet
Adaptar não é só esticar. Use constraints (iOS Auto Layout), flexbox (React Native) ou widgets flexíveis (Flutter, ConstraintLayout no Android) para que os elementos se reorganizem conforme o espaço. Em tablets, é comum mudar o layout em si: uma lista que vira lista + detalhe lado a lado (master-detail).
- Proporções, não tamanhos fixos: "ocupe metade da largura" em vez de "240 dp".
- Breakpoints: trocar de layout de coluna única para duas colunas acima de certa largura.
- Texto que cresce: respeitar a fonte aumentada pelo usuário (acessibilidade).
Você não desenha para um aparelho; desenha regras de adaptação. Pense em "como isto se comporta quando o espaço encolhe ou dobra", não em "quantos pixels tem aqui".
Conclusão
Medir em dp/pt, respeitar as safe areas e usar constraints/flex em vez de pixels cravados é o tripé do layout responsivo mobile. Quem internaliza a diferença entre pixel físico e lógico evita os bugs visuais mais frequentes e entrega telas que funcionam do menor celular ao maior tablet.
There are tiny phones, huge screens, notches, status bars and tablets — and your layout has to look good on all of them. The secret isn't designing in pixels, but thinking in logical units, respecting safe areas and letting the layout adapt on its own. It is one of the first topics where a junior stumbles and one of the first that interviewers ask about.
Physical pixel vs logical pixel
Two phones can have the same physical size but very different pixel counts: one has a "normal" screen, the other a "retina/high-density" one with twice the pixels in the same space. If you positioned everything in physical pixels, a 100px button would be gigantic on one screen and tiny on the other.
That's why platforms use logical units: dp (density-independent pixels, Android) and pt (points, iOS). You say "I want 16 units of space" and the system multiplies by the screen density to arrive at the actual physical pixels.
| Density | Factor | 16 dp/pt become |
|---|---|---|
| mdpi / @1x | 1x | 16 physical px |
| xhdpi / @2x | 2x | 32 physical px |
| xxhdpi / @3x | 3x | 48 physical px |
The analogy: dp/pt are like the "centimeters" of the mobile world — a measure that means the same apparent size on any screen. Physical pixels are like counting grains of sand, which vary from beach to beach.
Why measure in dp/pt
Measuring in dp, an 8 dp spacing looks the same on the intern's phone and on a flagship. The system handles the conversion. Interviewers often ask you to explain the difference between px and dp and why you should never hardcode physical pixels — the expected answer is exactly this density independence.
The hardcoded pixels trap
// BAD: assumes a fixed width in pixels
image.width = 320 // overflows on small screens
// GOOD: relative to the available space
image.width = "100%" // or use constraints/flex
image.height = aspect(16, 9)Hardcoding a width of 320 breaks on a 4-inch device and wastes space on a tablet. Day to day, this bug shows up as clipped text, a button off the screen or a layout that "overflows" on certain models.
Safe areas: notch, status bar and home indicator
Not all of the rectangular screen is usable. At the top there's the status bar (clock, battery) and the notch/island; at the bottom, the gesture bar or home indicator. The safe area is the region where your content isn't hidden behind these elements.
+---------------------+
| [status bar / notch]| <- don't put buttons here
| |
| SAFE AREA |
| (your content) |
| |
| [home indicator] | <- nor here
+---------------------+Ignoring the safe area makes the title disappear behind the notch or the action button end up under the gesture bar, where the user can't tap it properly.
From small phones to tablets
Adapting isn't just stretching. Use constraints (iOS Auto Layout), flexbox (React Native) or flexible widgets (Flutter, ConstraintLayout on Android) so elements rearrange according to the available space. On tablets, it's common to change the layout itself: a list that becomes list + detail side by side (master-detail).
- Proportions, not fixed sizes: "take up half the width" instead of "240 dp".
- Breakpoints: switch from a single-column layout to two columns above a certain width.
- Text that scales: respect the font size increased by the user (accessibility).
You don't design for a device; you design adaptation rules. Think "how does this behave when the space shrinks or doubles", not "how many pixels are here".
Conclusion
Measuring in dp/pt, respecting safe areas and using constraints/flex instead of hardcoded pixels is the tripod of responsive mobile layout. Whoever internalizes the difference between physical and logical pixels avoids the most frequent visual bugs and delivers screens that work from the smallest phone to the largest tablet.