px: esensya, pisikal na pixel sa mobile development

Ano ang px?

px (pixel, picture element) — pinakamaliit na addressable na elemento ng raster image o display. Ang bawat pixel ay nag-iimbak ng impormasyon ng kulay sa RGB model (pula, berde, asul) na may lalim ng kulay mula 8 hanggang 10 bit bawat channel. Ang mga modernong display ng mobile device ay naglalaman ng milyun-milyong pixel: iPhone 15 Pro — 3 milyon, iPad Pro 12.9" — 5.6 milyong pixel.

Ang pisikal na sukat ng pixel ay nakadepende sa density ng display (PPI). Sa isang device na may 326 PPI (iPhone 11) ang isang pixel ay may sukat na humigit-kumulang 0.078 mm. Sa display na may 460 PPI (iPhone 15 Pro) — 0.055 mm. Kung mas maliit ang pisikal na sukat ng pixel, mas mataas ang talas ng imahe. Ang density ng pixel ay direktang nakakaapekto sa rendering performance: mas maraming pixel = mas maraming trabaho para sa GPU.

Ayon sa datos ng Apple, ang resolution ng display ng iPhone 15 Pro ay 1179 × 2556 px sa density na 460 PPI. Para sa paghahambing, ang iPhone SE (3rd gen) — 750 × 1334 px sa 326 PPI. Ang pagkakaiba sa kabuuang bilang ng pixel ay halos 3 beses, na nagpapaliwanag ng mas mataas na kinakailangan sa GPU sa mga modelong Pro.

Resolution ng screen sa pixel

Resolution ng screen — bilang ng pisikal na pixel pahalang at patayo. Isinusulat sa format na lapad × taas, halimbawa 1179 × 2556 px. Ang resolution ay isang pangunahing katangian ng display na hindi mababago nang programmatically — ito ay nakapirmi sa antas ng hardware at matrix.

Ang resolution sa pixel ay hindi dapat ikalito sa lohikal na sukat ng screen (sa pt para sa iOS o dp para sa Android). Halimbawa, ang iPhone 14 ay may lohikal na sukat na 390 × 844 pt, ngunit pisikal na resolution na 1170 × 2532 px — eksaktong 3 beses na mas malaki, dahil ang scale factor ay 3.

PPI at density ng pixel

PPI (pixels per inch) — bilang ng pixel bawat pulgada ng display. Kinakalkula gamit ang formula: PPI = √(lapad² + taas²) / diagonal. Kung mas mataas ang PPI, mas pino ang indibidwal na pixel at mas makinis ang imahe. Itinuturing ng Apple na Retina display ang screen na may PPI na higit sa 300 sa tipikal na distansya ng pagtingin.

Ang iba't ibang kategorya ng device ay may iba't ibang density: Apple Watch — 326 PPI, iPhone — 326–460 PPI, iPad — 264 PPI, MacBook Pro — 254–264 PPI. Ang mga Android device ay nag-uuri ng density sa pamamagitan ng Density Buckets: mdpi (160 dpi), hdpi (240), xhdpi (320), xxhdpi (480), xxxhdpi (640). Ang mga bucket na ito ay tumutukoy kung aling resource (imahe, dimens) ang ilo-load para sa device.

Epekto ng PPI sa development: kung mas mataas ang density, mas maraming memory ang kinakailangan para mag-imbak ng texture at imahe. Ang isang pixel sa display na may 500 PPI ay nangangailangan ng 2.5 beses na mas maraming memory ng GPU kaysa sa display na may 320 PPI sa parehong lohikal na sukat ng elemento. Ang pag-optimize ng assets para sa mga partikular na density bucket ay karaniwang kasanayan sa Android development.

px vs lohikal na yunit: pt, dp, sp

Ang pisikal na pixel (px) ay naiiba sa lohikal na yunit (pt, dp, sp) dahil ang mga ito ay nakatali sa hardware resolution at hindi nags-scale. Ang lohikal na yunit, sa kabaligtaran, ay nag-aabstrak ng developer mula sa partikular na display, na nagpapahintulot sa parehong halaga na 100 pt na maipakita na may parehong pisikal na sukat sa iba't ibang device.

Mga formula ng conversion: para sa iOS — px = pt × scale (kung saan scale = 1, 2, o 3). Para sa Android — px = dp × (dpi / 160). Ang direktang paggamit ng px sa code ay nangangahulugan na ang interface ay magmumukhang iba sa mga device na may iba't ibang density: sa screen na may mataas na PPI ang elemento ay magiging masyadong maliit, at sa mababang PPI — masyadong malaki.

Bakit hindi ginagamit ang px sa code

Ang paggamit ng px sa source code ng isang mobile application — antipattern na humahantong sa maling pagpapakita ng interface sa mga device na may iba't ibang density ng pixel. Ipinagbabawal o hindi inirerekomenda ng mga modernong framework (UIKit, SwiftUI, Jetpack Compose, XML Layouts) ang pagtukoy ng sukat sa pixel.

• iOS UIKit — lahat ng frame, bounds at constraint constants ay itinakda sa pt. Lumilitaw lamang ang pixel sa yugto ng rasterization sa pamamagitan ng UIGraphicsImageRenderer
• SwiftUI — walang API para sa pagtatakda ng sukat sa px. Lahat ng halaga ay pt sa pamamagitan ng Font, frame, padding
• Android XML — kung tutukuyin mo ang px sa dimens.xml, magpapakita ang Android Studio ng lint warning: "Use \`sp\` instead of \`px\` for text sizes"
• Jetpack Compose — TextUnit para sa teksto, Dp para sa elemento. Hindi pinapayagan ng compiler ang paghahalo ng mga uri

Ang tanging lehitimong paggamit ng px sa code — pagtatrabaho sa mga raster: pag-load ng Bitmap, paggawa ng Canvas para sa rendering ng imahe, pagtatrabaho sa Metal o OpenGL. Sa mga kasong ito, ang px — pisikal na pixel ng target na buffer at dapat isaalang-alang para sa tamang rendering. Sa lahat ng iba pang kaso, ginagamit ang mga lohikal na yunit.

Pixel sa mga imahe at assets

Ang mga imahe at icon ay naka-imbak sa pixel, ngunit para sa bawat uri ng screen ay iba't ibang bersyon ang ibinibigay. Ginagamit ng iOS ang mga suffix na @1x, @2x, @3x sa Assets.xcassets. Ginagamit ng Android ang mga folder na drawable-mdpi (1×), drawable-hdpi (1.5×), drawable-xhdpi (2×), drawable-xxhdpi (3×), drawable-xxxhdpi (4×). Awtomatikong pinipili ng system ang tamang file batay sa density ng screen.

Panuntunan sa pagbibigay ng assets: gumawa ng imahe sa vector format (PDF, SVG) at i-export sa raster copy ng mga kinakailangang sukat. Ang vector assets ay nags-scale nang walang pagkawala ng kalidad at kumukuha ng mas kaunting espasyo sa repository. Sa Android, ang vector resources ay maaaring gamitin nang direkta sa pamamagitan ng VectorDrawable, na nag-aalis ng pangangailangan para sa maraming raster copy.