🍃このブログは移転しました。
3秒後、自動的に移動します・・・。

モバイル向けにSPAをつくってた話

実は4月の頭にリリースされてて、今さら感のあるつくって"た"話です。
もちろん仕事でなのですが、ココはあくまで個人ブログなので、ある程度ぼやかしつつ書きます。

知ってる人は知ってると思いますが、コレです。

作ったもの

何もしらないとイメージしづらいと思うので、いちおう。

  • モバイルメインのWebサービス
  • ゲームではないが、ゲーム性の強いWebサービス
  • シナリオゲーみたいなやつ
  • 複数のSPAと多数のページから成るそれなりの規模
  • ネイティブでもShell-Appでもなく純ブラウザ向け
  • iOS5.x/Android4.x以上が対応OS
  • Safari/標準ブラウザ/Chrome/各種WebViewが対象ブラウザ

この記事を書こうと思ったわけ

新しいFWやらライブラリやら、流行り廃りが激しい最近ですが、
実績といえばなんのアテにもならないTODOアプリとか、たかだか3,4ルートのSPAだったりで、
実際のサービスでそれなりの規模で動いてるものの情報ってあんまり無いですよね・・?

それがなんだかなーと思ってたので、自分から一つ情報提供してみようかと思い。
右クリックするくらいしかできないと思いますが、なにとぞ。

支える技術

HTML/CSS

いちおうHTML5ですが、Googleさんの巡回範囲外は伝家のdiv工芸です。
div職人をマークアップエンジニアとは言いません。

Sass/Compassを使ってて、OOCSSでもBEMでもSMACCSでもないオレオレな感じになってます。
このへんもいつかまとめたいなー。

JavaScript

jQueryはカスタムビルド、LodashはJST(テンプレ)としても使ってます。
Marionetteはリリース時点で最新!のv2.4.0です。
Create.jsも一応使ってますが、Flashの出番は多くないです。

AltJSではなくて、生JavaScriptです。

裏方

  • 各種Gruntタスク
  • jshint
  • csslint
  • stylestats
  • その他もろもろ

細々書いて捨てた系のNodeのスクリプトたちもいっぱいいました。
運用ツールにnwjsとかjson5とかも使ってたりもしましたね。

Gruntタスクは増えてきた時にちゃんとファイル分割すれば、別になんの問題もないです。

技術選定時の振り返り

Marionette.js

あの頃はReactのRの字も出てない頃で、SPA作るならBackboneかAngularかって頃でした。
Vueはまだ知る人ぞ知る・・って頃です。

Angularは身の回りに大した前例がないのと、Vueは周辺機器が揃ってなかったこともあり、
あっさりBackbone、ソースコメントの日本語化とかやって興味があったMarionetteって感じで選びました。

細かいパフォーマンス的なとこや、いくつか実装に異議ありポイントはもちろんありますが、
それを差し置いても良いものです。
開発後期にメジャーバージョンアップがあって追従するのは大変だったものの、
それでも対応する価値はあったかなーと。

ModelがあってViewがあってRouterがあって、アプリ一式作るのに必要なものが完備されてる安心感採用です。

・・・採用事例とかに載せてくれへんかなw

Require.js

世間のムードは「Require(というかAMD)はオワコン、これからはBrowserify!」って感じですが、私は依然としてRequire派です。

正確には、開発中はAMD、配布時はrjs(でもなんでもいいけど固めたい)派です。

jQuery / Velocity.js

カスタムビルドして不要なAPIを削りまくってます。

実際のところ、class操作とon/off、セレクタ周りもfindくらいしか使ってないです。
車輪の再発明するか最後まで悩んでやらなかったやつ。

jQueryのfadeIn/Outの代役がVelocityです。
CSSのtransitionEndとanimationEndのイベントが挙動不審なのが全部悪いです。

2015年に思うモバイル開発

シェア的なもの

新規のサービスを作るなら、Android2系はさすがに切っていい頃だと思います。
どっかでIE8よりシェア低いみたいなのを見た気がする。

ただ4.4(KitKat)以上のみにするにはまだ早くて、2系からのアップデートで4系になったお上りさんがまだまだ多い印象。
そしてバグるのはだいたいココ(ヽ´ω`)

iOSはさすがで、iOS7以上が圧倒的に多いです。
ってもiPhone4でもiOS7にはなれるのでもうちょい細かく見なきゃなりませぬ。

その他のOSは、依然として息してません!

ヤバいのはメモリより描画

jQueryセレクタの書き方がどうとか、あんなもんは大した問題じゃないです。
(やらかしてるなら問題以前に論外です)
リークしないようにするとか、イベントは貼ったら剥がすとかも、注意すればいいだけです。

  • いかに描画を間引くか
  • いっぺんにまとめて処理しない
  • CompositeLayerを綺麗に敷く
  • 動かす必要の無いときは消す(せめて止める)
  • 無駄なCSSは書かない

こういう描画まわりの方がパフォーマンス改善には効きます。
というか、やんないと動かないです・・。

jsの計算はそこそこ速いのに、ただのfadeInでガタつくのがAndroidです。
jsから取れる値はちゃんとしてるのに、描画が追いつかないのがAndroidです!!
人の目には見えてないのに、そこに要素があると言いはるのがAndroidです!!!

JavaScriptは書けるけどCSSよーわからんみたいな人だと、ちょっと辛い分野なのかも?
position: fixedとかoverflow: scrollとか、やっぱりまだまだ闇です。

こういうのに日々接してると、VirtualDOMとかほんと大丈夫なのかと心配で仕方がないですね

WebViewやらChromeやら

1年前と違うのは、FacebookやらTwitterやらLINEやらの、いわゆるWebViewで表示したい需要が増えたこと。

まぁコレはWebViewかブラウザかを判別するのがすこぶる大変なくらいで、
挙動に関しては特に何も変わりません。

ブラウザかWebViewか、どちらで開かれたのかを判別するには - console.lealog();

Chromeが増えてきて、標準ブラウザのバグ地獄から解放されるーとか思ってる皆さーん。
ダウトです。

SafariChromeで微妙に挙動違うとか、Android標準ブラウザと微妙に挙動が違うとかあります。
単純に敵が増えただけです。

アドレスバーの挙動が違うだけで高さ計算は狂う、ブラウザバックの挙動も違う、リロード周りの挙動も違う!
標準ブラウザのくせにUAではChromeって名乗るやつがいる!

Androidへの気持ち

箇条書きで参ります。

  • Galaxyシリーズの2.x->4.0系がヤバい(4.1以上だとマシ)
  • HTCシリーズはアニメーションgifが動きません
  • SH***シリーズ、シェア多いくせに安定して低スペックが生き残ってる
  • Xperiaシリーズ、基本的には安定してるのにたまに抜けてる
  • Nexusシリーズは新しいのと古いのの差がスゴい
  • Arrowsシリーズは2.x時代からの成長がうかがえます

脳内で擬人化して扱うと、ちょっとだけ心が落ち着きますね。
#fxxk_android_sushiとかないんですかね。

Android端末一覧 - Wikipedia

おわりに

こういう分野で日々疲弊してる仲間がいれば是非ともお近づきになりたいのですが、やはりもう誰もモバイルで頑張ってないんですか・・?
iOS8になってもAndroid5になっても、まだバグっぽい挙動はいっぱいあるのにぜーんぜん情報見つからなくて困ってます!

少なくとも目に見えるエッジな人々はみなPCばっかで、モバイルをそこまで相手にしてない印象があるので・・。(個人の感想です)

これからどうしようかなー。