androidとiOSの画面サイズのフラグメンテーションについて
少し前は、androidは画面サイズのフラグメンテーションが激しいから開発者の負担が大きいというのが共通認識だった。
そのころのiOSはといえば、画面のdpは 320x480 の1パターンだけだったので、nibファイルで画面を定義する場合にも直接座標指定で作成していた。
しかし、4年前の2012年にiPhone5が登場し、2014年にiPhone6, plusが登場、2015年にはiPad Proが出てきてiPadさえもフラグメンテーションしてしまった。
2016年現在では、androidの画面dpは 360x640 に統一され1パターンとなったが、逆にiOSは4パターンのdpが混在するに至っている。
dp:320x480 3.5インチretina
dp:320x568 4インチretina
dp:375x667 4.7インチretina
dp:414x736 5.5インチretina
だが、iOSで開発者の負担が増えたかというとさほど増えたとは言えない。
なぜなら、AutoLayout SizeClassという強力なレイアウト機能がStoryboard(nib)に追加されたからだ。
縦持ち横持ちなどの場合の画面レイアウトを考慮しなければならないアプリの場合などでは負担が減ったと言えるかもしれないぐらいだ。
ただ、iOS開発者の中にはXcodeやnibを嫌いコマンドラインでビルドし、コードで座標指定をして画面を定義するのを好む連中が多くいた。私には理解できないし生産性において疑問なのだが。
そういう連中にはフラグメンテーション時代のiOSを生き抜いていくことは難しいであろう。
それにしても、androidは少なくとも日本国内ではFullHD画面が標準になっているがiOSはあの大きくて持ちづらいiPhone6plus以外はFullHDではない。(iPhone6でようやく720p画質だ。)
androidとiOSはお互いに優れているところを相互に取り入れている。
androidがLolipopになってようやくアルファ版を脱してiOS並みにまともに使えるレベルのOSになった今、iOSの混乱ぶりが増していくような気配がするのだ。
2023年12月 | ||||||
日 | 月 | 火 | 水 | 木 | 金 | 土 |
  |   |   |   |   | 1 | 2 |
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
31 |   |   |   |   |   |   |
iOS
web
?スA?スv?ス?ス?スフ抵ソス?ス??
?スu?ス?ス?スb?スN?ス`?スF?ス[?ス?ス?ス^?ステ搾ソス?スZ?スp
?スV?ス?ス?ス?ス?スミ会ソス
?スT?スE?ス?ス謨ァ?ス?ス
?ス?ス?ス{?スフなりた?ス?ス