なめらかに動作するUITableViewのつくりかた

矢口裕也です。

Advent Calendar 10日目はiOSのUITableViewの話をします。

ぼやき

iOSアプリを開発していると70%くらいの時間はUITableViewに費やしている気がしてきます。
UITableViewは非常にめんどうなものですが、パフォーマンスがシビアでかつユーザーの快適さに直結するものなので大いに手間をかける価値があります。

この記事ではガクガク処理落ちするUITableViewを例として改善していきながら快適なUITableViewのつくりかたを解説します。

目的

以下のケーススタディでは次の目的でコードを改善していきます

  • なめらかに動くようにする

ここでのポイントは実際速くなくてもユーザが快適に感じればOKである、ということです。処理速度が高速である必要はありません。

戦略

UITableViewでのパフォーマンス問題は次の2点であることが多いです

  • スクロールがガクつく
  • loadMoreで0.5〜数秒固まる

スクロールがガクつく

これはcellForRowAtIndexPath:の実行に時間がかかっていること、または描画自体が重いことのいずれかが原因です。
前者についてはcellForRowAtIndexPath:はメインスレッドで実行されるため、処理に時間がかかるとその間、画面の更新が止まってしまい、スクロールがガクガクしてしまいます。メソッドの実行時間を短くすることで改善することができます。
後者については、画像のリサイズ、角丸など重い描画時加工を行わないこと、ブレンドレイヤーを減らすことで改善できますできます。

loadMoreで0.5〜数秒固まる

これは多くの場合、cellのinsert, delete, reloadで呼ばれるtableView:heightForRowAtIndexPath:の実行に時間がかかっていることが原因です。
tableView:heightForRowAtIndexPath:はメインスレッドで実行されるため、処理に時間がかかるとその間、画面の更新と操作の受付が止まってしまい、ユーザーにフリーズしたような感覚を与えてしまいます。
メソッドの実行時間を短くすることで改善することができます。

用意するもの

  • なるべく遅いiOS端末

速い端末ではチューニングの効果が確認しにくいです。少なくともメインターゲットとしている端末の1世代前のものを用意しましょう。iOS7であればiPhone4あたりがおすすめです。

効果の測定方法

遅い端末でアプリを触って確かめます。
快適っぽく感じたら効果があったと考えてよいでしょう。
逆に遅い端末で効果がよくわからないチューニングは効果がないと考えていいでしょう。数字は参考程度でフィーリングを大切に。

サンプルアプリ

例として何かのコメントを表示するアプリを考えてみます

スクリーンショット

ソースコードはこちらです:
https://github.com/yayugu/UITableViewExamples
slowExampleの方を動かしていただければわかりますが、非常に重く、AppStoreのレビューで「重すぎなので ☆1つ」と書かれそうなクオリティーになっています。これを改善していきます。

通信は必ずasynchronousで行う

当たり前のことかと思われるかもしれませんが、特に不慣れな方が書いたコードで何度か同期通信を行っているコードを見たことがあります。通信は必ず非同期で行うようにしましょう。

JSONの読み込みを非同期に

https://github.com/yayugu/UITableViewExamples/commit/8662980566de2048ce898643741fa203c1cb57ed

ViewControllers/YYTableViewController.m

before

after

画像の読み込みを非同期に

https://github.com/yayugu/UITableViewExamples/commit/c70b863ce864a715a7019da83b226bd7817d2f1c

Views/YYCommentCell.m

画像は別スレッドでリサイズ&角丸化してからメインスレッドに持ってくる

以下のようなUIImageViewはパフォーマンスを低下させてしまう場合があります。

  • 表示するサイズと画像のサイズが一致していない
  • CALayerで角丸にしている
  • 透過を使用している

これらの問題は別スレッドでUIImageを加工することで対応できます。
今回の例では

  • リサイズ
  • 白背景塗りつぶし
  • 角丸
  • 枠線

の処理を行ったUIImageを作成するようにしました

画像加工のコードについては長くなるのでコミットログを参照してください。

https://github.com/yayugu/UITableViewExamples/commit/c92b9b368bd0b817283612d6116e9ab06ed93944

CommentCellのコードは以下のようになり、CALayerのborderWidth, cornerRadiusを指定する箇所が削られます。

cell height計算には専用のLayoutクラスを使用し、UIViewを使用しないようにする

UITableViewCellでは全てのcellの高さは追加時に計算される必要があります。iOS7からはestimateHeight系のプロパティ指定/メソッド定義により正確な高さの計算をスクロール時まで遅延させることができるようになりましたが、いずれにせよcellForRowAtIndexPath:よりも前に高さが決定される必要があります。

サンプルプログラムではcellに値をassignし、UIViewのsystemLayoutSizeFittingSize:を利用してAutoLayoutで計算された高さを取得しています。

これはコードの重複がなく簡潔に書ける方法ですが非常に遅いです。
下のようにlayout専用クラスを作成し高さの計算を自分で記述することで大幅に高速化でき、loadMore時のフリーズがなくなります。

Layouts/YYCommentCellLayout.h

Layouts/YYCommentCellLayout.m

今回やらなかったこと

  • 加工した画像のキャッシュ

viewのなめらかさには直接影響しないため行いませんでしたが、実際のアプリケーションでは行ったほうがよいでしょう。

  • cell height計算を別スレッドで行いキャッシュ

今回は行わなくても十分なパフォーマンスが得られたため行いませんでした。より複雑なlayout, 大量のcellの追加などでcellの追加が重くなる場合には行ったほうがよいでしょう。

まとめ

  • main threadを極力ロックしないようにする
  • heightForRowAtIndexPath, cellForRowAtIndexPathを高速にする
  • blend layerを極力排除する
  • 画像の加工を行わない

めんどうな作業ですが、こういった改善の積み重ねがネイティブでしか実現できない気持ちいいアプリをつくるのです!

明日はkyo_agoさんです。