Shaping up ATOK to fit
to your iPhone/iPad
株式会社ジャストシステム
入江賢治
JustTechTalk#01
入江賢治 is 誰?
• 2003年度入社、12年目
• ATOK for iOS 開発責任者
• 最近携わったATOK関連商品:
– ATOK for Android [Professional] – 開発初期
– ATOK 2014 for Mac
ATOK for iOSのご紹介
• 2014年9月22日発売
• iOS 8から導入されたサードパーティ製キー
ボードとして提供
ATOK for iOSの特徴
• Windows/MacのATOKと同等の高性能変換エンジン
「ATOK EVエンジン」を搭載
– 豊富な語彙から、文脈に応じて最適な変換候補を表示、
長文にも強い
• 使いやすさにこだわったキーボードUI
– 6/6 Plusの大画面で片手操作できる幅寄せUIに一番乗り。
サイズ・位置までカスタマイズ可能。
– iOS標準に近い使用感の中にカーソル移動・まとめて削除
など、入力を支援する機能を盛り込んだ
本日のテーマ
• ATOK for iOS実現に至るまでの軌跡から、下記に
ついてお話します
1. ATOK EVエンジンの実現について
2. ATOK for iOSで苦労した点、得られた知見
キーワードは「シェイプアップ」
ATOK EVエンジンとは
• 元々はATOK for Androidの変換エンジンを新しく
しようという話からスタート
– 携帯電話やゲーム機向けのモバイル機器に特化し
たバージョンの変換エンジンを採用していた
• スマホ・タブレットが高性能化、PCに近いスペック
を備えるようになった
→最新のPC版変換エンジンと統合し、スマホ・タブレット
での進化を加速したい
とはいってもATOKデカイ
• 参考: ATOK 2014 for Windows
– インストール必要容量: 455MB
– インストールファイルの容量: 約350MB
– 辞書などのデータ類: 約180MB
• 候補の生成に使う主なデータだけでも
約111MB
→さすがにそのままスマホに乗せるワケには…
とはいってもATOKデカイ
• 支配的なのはデータサイズ
• 続いてコードサイズ(プログラムサイズ)
• Wi-Fiでアプリをダウンロードできるサイズに
抑えることは必須
– Androidの場合apkで50MBまで
データサイズをシェイプアップ
• 使用データをスマホに合わせて最適化
– 変換精度低下を最低限にとどめつつ、データ容量を
大きく削減できる「美味しい」ところから削減
• 使用データをスマホ専用に圧縮
– ATOK EVエンジン専用の圧縮辞書形式を導入
– 圧縮形式を導入したデータについては50%近くまで圧
縮することができた
コードサイズをシェイプアップ
• 明らかに無駄なコードばかりでザクザク削れ
たわけではなく、地道な削減の積み重ね
• 最終的には、nmコマンドでモジュール内の関
数コードサイズを分析、大きいもので削れそう
なものがないか探す泥臭いことも…
第一部 〜完〜
→などなどの取り組みで
なんとか目標としたサイズに収まりました!
ここから動作調整・速度チューニングを経て…
– 2014年2月7日
ATOK for Android [Professional]
として発売。
そしてATOK for iOSへ…
• 2014年6月3日iOS 8発表。サードパーティ製
キーボードへの対応も発表された。
http://www.apple.com/jp/ios/developer/
そしてATOK for iOSへ…
• 2014年6月3日iOS 8発表。サードパーティ製
キーボードへの対応も発表された。
App Extensions
• ほかのアプリと連携して同時に動作できる特殊なアプ
リ形態
– Share ー Today
– Photo Editing ー Custom Keyboard
– File Provider ー Actions
– Document Provider
• 今まで:他アプリ動作中には、通知処理、音楽再生、
ファイルのダウンロードをバックグラウンドで行うくらい
しかできなかった
App Extensions
• 調査した結果、色々制約はあるも、ついに
IMEとしてiOSにもATOKを提供できそう
• となると
iOSにもやっぱり、最新の変換エンジンを搭載
してご提供したい!
iOSにはiOSのちょうどいいサイズ
• アプリ容量→100MB未満を目標に
– 100MBがWi-Fiなしでインストールできる最大サイズ
→MUST
– App Storeで見て100MBを超えているとずっと入れて
おくアプリとしては重たい印象
• 音楽やムービーはもちろん、ゲームとかゲームとかゲーム
とか最近容量大きいですからね
iOSにはiOSのちょうどいいサイズ
• アプリ容量→100MB未満を目標に
– 100MBがWi-Fiなしでインストールできる最大サイズ
→MUST
– App Storeで見て100MBを超えているとずっと入れて
おくアプリとしては重たい印象
• 音楽やムービーはもちろん、ゲームとかゲームとかゲーム
とか最近容量大きいですからね
• →64bit対応必須でコードサイズを心配したが
32bit+64bitのバイナリでも無事収まった
iOSにはiOSのちょうどいいサイズ
• iOS 8対応デバイスの搭載メモリ
– iPhone 4s/iPod touch(5th) 512MB
– iPhone 5/5c/5s/6 1GB
• メモリ使用量
– もちろん使いすぎてはいけないが、Max数十MBの範
囲なら何とかなるだろう
iOSにはiOSのちょうどいいサイズ
• iOS 8対応デバイスの搭載メモリ
– iPhone 4s/iPod touch(5th) 512MB
– iPhone 5/5c/5s/6 1GB
• メモリ使用量
– もちろん使いすぎてはいけないが、Max数十MBの範
囲なら何とかなるだろう
↓
そう思っていた時期が私にもありました
Retina iPadなど高解像度
デバイスで謎の死が…
• 実機で使い込みをしているとクラッシュすることが
• 開発中ならそんなこともあるよねとクラッシュログを読
むも、スタックトレースなし
なんぞこれ?iOS 8βのバグかな?
↓
甘 か っ た
ここでApp Extension Programming
Guideを確認してみましょう
• https://developer.apple.com/library/ios/documentation/General/Conceptual/ExtensibilityPG/ExtensionCreation.html#//apple_ref/doc/uid/TP40014214-CH5-SW1
ここでApp Extension Programming
Guideを確認してみましょう
• https://developer.apple.com/library/ios/documentation/General/Conceptual/ExtensibilityPG/ExtensionCreation.html#//apple_ref/doc/uid/TP40014214-CH5-SW1
意訳)メモリ使いすぎたら コ ロ ス
え、そんな物騒な…
アプリの動作を守るためとはいえ…
アプリの動作を守るためとはいえ…
アプリの動作を守るためとはいえ…
_人人人人人人人人_
> ATOK 突然の死 <
 ̄Y^Y^Y^Y^Y^Y^Y ̄
※ただしSimulatorでは起きない/実機のみ
メモリはどこへ消えた?
• 測ってみた。
(注: 開発中のある時点のものです)
6 plus上でUI、メモリ食い過ぎィィ!
(当社比)
メモリはどこへ消えた?
• UIおよび描画に関連しそうなオブジェクトが
Allocations上位に続々ランクイン。
– なんとかViewとか
– なんとかPainterとか
– CG(CoreGraphics) raster
dataっていうのも…
– CALayerってキーワードが頻出
CALayerって?
• CA(CoreAnimation)LayerはiOSアプリ画面表示の基本
となるオブジェクト(※ゲームではOpenGL ESなど例外も)
• UIViewも基本、裏にCALayerを持っている
– ボタンなどのコントロールの描画パーツというイメージ
• 表示内容に効果やアニメーションを適用できる
– 移動・拡大縮小・回転させたり透過させたりしつつ、
階層をもって重ね合わせできる
– これらの効果はアニメーションできる
CALayerって?
• 表示内容は通常、描画バッファとして持つ
– 高速なアニメーションを実現するため
– 幅x高さx色深度(RGBAなら4bytes)のメモリ上ビットマップ
画像のイメージ
さっきのグラフと 完 全 に 一 致
モデル 解像度 画素数 比率(概算)
iPhone 6 Plus 1920x1080 2,073,600 3
iPhone 6 1334x750 1,000,500 1.5
iPhone 5s 1136x640 727,040 1
原因はわかった。でもどうすれば?
• 実は、描画バッファを使わずCPU/GPUで画面
に直接描画を行うCALayerもある。
– CALayerのshouldRasterizeプロパティがNO
• 描画バッファを使うかどうかのヒント。NOにしても条件
によって描画バッファが使われてしまう。後述。
これだ!全部これでいこう
直接描画する条件の例
直接描画できる例
• 簡易な図形を描画する
CAShapeLayer
– 直線、直方体、丸など?
– 厳密な条件は未判明
• 右記に該当しないCALayer
– ぶっちゃけ、ただの四角形。
描画バッファを使ってしまう例
• CALayerDelegateでカスタム描
画するCALayer
– paintLayer:inContext:
• ベジェ曲線で複雑な図形を描
画するCAShapeLayer
• 文字(列)表示
• 画像表示
• 影、一部のアニメーション
じゃあ…と、メモリ使わず
GPU酷使してみた結果
• 試しにQWERTYキーボード全体を
CAShapeLayerを使いまくってキートップ以外
CoreAnimationに全部ランタイムに描かせるようにして
みた
– キーが約40個なので
キートップのレイヤー・
CAShapeLayer各40個。
角丸影付きくらいなら
いけるでしょ?
じゃあ…と、メモリ使わず
GPU酷使してみた結果
• メモリ消費量は激減。こうかはばつぐんだ!
• 世界は平和になったかと思われた
• しかし、Retina iPadで画面回転など再描画面積が大き
くなる操作を繰り返すと…
_人人人人人人人人_
> ATOK 突然の死 <
 ̄Y^Y^Y^Y^Y^Y^Y ̄
じゃあ…と、メモリ使わず
GPU酷使してみた結果
• メモリ消費量は激減。こうかはばつぐんだ!
• 世界は平和になったかと思われた
• しかし、Retina iPadで画面回転など再描画面積が大き
くなる操作を繰り返すと…
_人人人人人人人人_
> ATOK 突然の死 <
 ̄Y^Y^Y^Y^Y^Y^Y ̄
再びApp Extension Programming
Guideを確認してみましょう
• https://developer.apple.com/library/ios/documentation/General/Conceptual/ExtensibilityPG/ExtensionCr
eation.html#//apple_ref/doc/uid/TP40014214-CH5-SW1
再びApp Extension Programming
Guideを確認してみましょう
• https://developer.apple.com/library/ios/documentation/General/Conceptual/ExtensibilityPG/ExtensionCr
eation.html#//apple_ref/doc/uid/TP40014214-CH5-SW1
意訳)GPUはみんなのもの
GPU独り占めしても コ ロ ス
メモリもダメ、GPUもダメ
• GPUリソースも制限されてる
• GPUキューに描画命令がある程度溜まってし
まうと死んでしまう
• 先ほどのケースでは画面回転の度にRetina
iPadの高解像度の約半分をリアルタイム描画
する高負荷に耐えきれず死亡
※そんなに複雑な描画でなくてもこの有様
メモリもダメ、GPUもダメ
• この件に関してはキー背景の表示内容を自分で
用意してキー背景が同じすべてのCALayerにセッ
トすることで何とかしました。
↓これを共有→
•
•
•
メモリもダメ、GPUもダメ
• この件に関してはキー背景の表示内容を自分で
用意してキー背景が同じすべてのCALayerにセッ
トすることで何とかしました。
– テクニックの説明
• CALayerのcontentsプロパティに画像を設定することで描画
バッファを外部から与えることができる。
• 同一のオブジェクトを複数のCALayerにセットすることで描画
バッファを一つで済ませられる。
CALayerメモリ消費の傾向と対策
• 描画バッファを使わせない
– 単純な図形はCALayerのプロパティやCAShapeLayer
で描画する。四角形、角丸四角形
(CALayer.cornerRadiusをセット)など。
– 個数の多いものは同じ描画バッファを再利用する。
(CALayer.contentsをセット)
• CAShapeLayerだけで頑張るとGPU使いすぎで死ぬ
• 影付けやとくにアニメーションは瞬間最大風速が
大きいのでなるべく避ける
Appendix: 動作速度についても、少し
• ATOKは大規模なデータを使って変換動作を行う
ため、ストレージ速度に強く依存する
• HDDなど、ストレージが遅い環境も考慮して、
ATOKには以下の2つのモードがある
– データを一度にメモリに読み込んでしまう
– 都度ファイルにアクセスする
Appendix: 動作速度についても、少し
• 検証の結果、iPhone/iPadのフラッシュスト
レージは十分に高速と判明
– フラッシュストレージ直接アクセス+OSキャッシュ
で現実的な性能を引き出せた
↓
何とかセーフ
iOS版開発で得られた知見まとめ
• iOS 8においてApp Extensionは使用メモリに大きな制
約がある。
• コアロジックでメモリを使うExtensionでは、メモリ使用
量の瞬間最大風速に気を遣った設計・実装が必要。
– 高性能な変換エンジンを搭載したIMEを作る際などにはご
注意ください
• あと、新機種実機はなるべく早く手に入れたい。実機
確認大事です。
かくして
• ATOK for iOSを何とかお客様の元に届けるこ
とができました。
• これからも、お客様の声をお聞かせいただき、
iOS上で最高の日本語入力環境を目指してま
いります。
Conclusion
• ATOK EVエンジンを搭載したATOK for iOSは、今
後とも最新ATOKの開発成果を搭載し、進化し続
けます。
• いま、最もシェイプアップが必要なのは
私自身です!
これからもATOK for iOSをよろしくお願いします
ジャストシステムでは
実力あるスマホアプリエンジニアを募集しています
変化を共に創ろう。 次の当たり前を創り出すために。

Shaping up ATOK to fit to your iPhone / iPad