11

私は iOS 開発に不慣れで、かなり単純な設計上の問題にどのようにアプローチするのが最善かを考えています。それぞれがスケッチしたような構造を持つアイテムのセットを表示したいと考えています。所定のセットで、10 個以下のアイテム。

スケッチ

各アイテムには、サムネイル画像、見出し、宣伝文句、および一連のボタンが含まれます。複雑な問題が 2 つあります。

  1. テキストの量とボタンの数は可変です。
  2. テキストには、いくつかの内部書式 (斜体と太字) が必要です。

私はこれらのアプローチを検討しました：

  1. カスタムのサイズ変更可能な UITableViewCell で、おそらくテキストに OHAttributedLabel のようなものを使用して、テーブル ビューを使用します。可変数のボタンについては、これらをプログラムでレイアウトするか、場合によっては新しいコレクション ビューを使用します (古い iOS では、サード パーティのグリッド ビューを使用する必要があります)。

  2. UIWebView に基づくカスタム セルでテーブル ビューを使用します。

  3. セット全体を 1 つの UIWebView として実行します。

  4. セクションのあるテーブル ビューを使用します。各項目には独自のセクションがあり、ボタンとテキストを行に解析します。

より経験豊富な iOS 開発者がこれにどのようにアプローチするかについての提案をお待ちしております。

編集:私は今、最善の方法は次のようになると考えています:

5) 全体に UICollectionView を使用します。

更新: 最後に、すべてをカスタム テーブル セル (つまり、#1) としてコードに配置しました。これは、回答に示されている理由だけでなく、iOS 開発に不慣れな私が自分のベルトの下に置く必要があったため、良い選択でした。ボタンのコレクションビューも使わなかったのは、パフォーマンスと iOS5 対応の手間が心配だったからです。

デザイン全体にコレクション ビューを使用すること (#5) はエレガントなソリューションだったと思いますが、実際にその道を歩み始めました。ただし、上の単純化された写真には示されていなかったいくつかの複雑さにより、扱いにくくなりました。

2 回目の更新: #1 は行き止まりであることが判明しました。私の最終的な解決策は UIWebView (#3) を使用しました - 回答を参照してください。

4

4 に答える 4

3

これが古いスレッドであることは承知していますが、非常に興味深いと思いました。iPhone 開発者として、このような種類のパフォーマンスの問題に対処するのに十分な時間を費やしているからです。Facebook Engineering による Facebook のサイトで非常に興味深い記事を見つけました。この記事では、UITableView を実装し、動的なサイズ変更の問題を克服し、迅速なコンテンツ管理を行った方法について説明しています。彼らはより深いオブジェクトを使用して事前に計算し、可能な限りすべてを非同期にして事前にキャッシュしたようです。記事へのリンクを提供しますが、まさにこの問題に取り組んでいるセクションをコピーします。お役に立てば幸いです。リンクhttps://www.facebook.com/notes/facebook-engineering/under-the-hood-rebuilding-facebook-for-ios/10151036091753920と、最も関連性の高い抜粋は次のとおりです。

(再)スピードの構築

ネイティブ iOS 上に構築することで得た最大の利点の 1 つは、アプリを高速化できることです。iOS 用の新しい Facebook でニュース フィードをスクロールすると、以前よりもはるかに速く感じられることがわかります。これを達成した 1 つの方法は、特定のタスクを実行する場所のバランスを再調整することです。たとえば、iOS では、メイン スレッドが UI を駆動し、タッチ イベントを処理するため、メイン スレッドで作業を行うほど、アプリの動作が遅くなります。代わりに、計算コストの高いタスクをバックグラウンドで実行するように注意します。これは、すべてのネットワーク アクティビティ、JSON 解析、NSManagedObject の作成、およびディスクへの保存がメイン スレッドに影響を与えないことを意味します。

別の例を挙げると、Core Text を使用して多くの文字列をレイアウトしますが、レイアウトの計算がすぐにボトルネックになる可能性があります。新しい iOS アプリでは、新しいコンテンツをダウンロードするときに、これらすべての文字列のサイズを非同期で計算し、CTFramesetter (作成にはコストがかかる可能性があります) をキャッシュし、後でストーリーを UITableView に表示するときにこれらすべての計算を使用します。

最後に、iOS 用の Facebook を起動するときは、読み込み中のスピナーではなく、ニュース フィードを表示する必要があります。可能な限り最高のエクスペリエンスを提供するために、以前にキャッシュされたコンテンツをすぐに表示するようになりました。しかし、これは新しい問題を引き起こします: ニュース フィードに多くの記事がある場合、UITableView はデリゲート メソッド -tableView:heightForRowAtIndexPath: をニュース フィードの各記事に対して呼び出すことで小さなスパナをスローします。スクロールバーを作るための高さ。これにより、アプリはディスクからすべてのストーリー データをロードし、ストーリー全体のレイアウトを計算してストーリーの高さを返すだけになります。つまり、ストーリーを蓄積するにつれて起動が徐々に遅くなります。

この特定の問題の解決策には、主に 2 つの部分があります。まず、最初の非同期レイアウト計算を行うときに、ストーリーの高さも Core Data に保存します。そうすることで、-tableView:heightForRowAtIndexPath: でのレイアウト計算を完全に回避します。次に、「ストーリー」モデル オブジェクトを分割しました。起動時にディスクからストーリーの高さ (およびその他のいくつかのもの) をフェッチするだけです。その後、残りのストーリー データを取得し、これ以上行う必要があるレイアウト計算はすべて非同期で実行します。

これらすべてが、スクロール中の高いフレーム レートと応答性の高いアプリにつながります。

于 2015-01-25T04:11:23.457 に答える
3

複雑な tableviewcell を実行していて高速スクロールが必要な人に役立つリソースをいくつか見つけました。私はまだそれを開発していますが、これを最初に皆さんに共有したいと思います.

  1. Facebook iOS リリース ノート: 彼らはテクニックについて言及しました: コア テキスト、テーブルの高さの事前/非同期計算、バックグラウンド スレッドで多くのことを行い、レイアウト属性をコア データに保存します。http://www.facebook.com/notes/facebook-engineering/under-the-hood-rebuilding-facebook-for-ios/10151036091753920

  2. 高速スクロールのサンプル: https://github.com/adamalex/fast-scrolling

  3. Apple のサンプル プロジェクト TableViewSuite。4番目の例。 https://developer.apple.com/library/ios/#samplecode/TableViewSuite/Introduction/Intro.html

解決策に非常に近い..はい

于 2013-01-17T16:50:13.720 に答える
2

私はもともと@Daij-Djanの答えを受け入れ（そして実装し）ましたが、今では最良のアプローチは＃3（UIWebView）だと信じています。それはパフォーマンスに帰着します。

UITableViewは、特に高さが変化するセルのコンテキストで、サブビューを備えたカスタムセルで適切に機能するように調整されています。ボタンの列により、スクロールが途切れ途切れになります。AppleがCellsとTableViewPerformanceで提案したように、サブビューがすべて不透明であることを確認しましたが、「コンテンツの中継を避ける」という提案に従う方法はありません。

その動的なセルの高さと属性付きの文字列に追加すると、これらのテーブルのスクロールはかなり不十分になります。次の最適化はdrawRectをオーバーライドすることだと思いますが、その時点でUIWebViewを試すことにしました。

UIWebViewにもパフォーマンスの問題があります。そのスクロールパフォーマンスは、コンテンツが大きくなるにつれてかなり速く低下しますが、コンテンツを非表示にして、ユーザーが必要に応じて「開く」ことができるようにすることで、それを管理できます。

于 2012-12-22T01:49:25.180 に答える
1

No 1 はおそらく最も多くの作業であり、その直後に #2 が続きますが
、ACB が述べたように、これは最も柔軟でもあり、IMO は確実に最高のルックアンドフィールを提供します。

no 3 は動作しますが、スムーズに感じられません / 常に少し「html っぽい」

no 4 は、ハイウェイ トゥ ヘルのように聞こえます (後で変更/維持するための PITA になります)。

于 2012-12-02T00:35:23.167 に答える