iPhone アプリでApache Thriftの展開を行った、または見た人はいますか?
HTTP と比較して、iPhone 向けの大容量で低遅延のネットワーク サービスの合理的なソリューションであるかどうか疑問に思っています。
私が見つけた注目すべき点の 1 つは、iPhone での Thrift の実行に関するバグ レポートで、修正されたようです。しかし、それは必ずしも取引が成立したことを示しているわけではありません。
3639 次
5 に答える
4
ちょうど私の2セント..
この質問に対する受け入れられた答えは、テクノロジーを使用しないという意見であり、可能かどうかの答えではありません。
Thrift は、Protobuf や Capt'n'Proto のようなインターフェイス定義言語、IDL です。それらは、プラットフォームに依存しないクライアント/サーバー/サーバー プロトコルの定義を許可します。JSON と Plist は、同じレベルの型適合性を提供しません。
以前、iOS、Android、Windows、およびサーバー チームで Google Protobuf v2.5 を使用して 10Ms MAU の iOS チームを率いた経験から、IDL がモバイルで優れていることを証明できます。Apple はそれらを iWork コンテンツの同期に使用します。
私の現在のチームは iOS および Android クライアントに Thrift を使用しており、ほとんどが Scala バックエンドです。Protobufよりもずっと好きです。
HTTPS と WebSocket を介して Thrift ペイロードを送信します。(Thrift で) ワイヤ通信プロトコル (つまり、フレーム構造) を定義すると、API を非常に簡単に進化させることができます。
ただし、特に iOS では、実装上の問題がいくつかあります。現在のバージョンのライブラリはパッケージ化が不十分であり、Objective-C フレームワーク (iOS 8 以降用など) を作成したい場合は、v0.9.2 をそのまま使用することはできません。これは、ライブラリ ヘッダーに (#import "TProtocol.h"の代わりに#import <Thrift/TProtocol.h>) ローカル インポートが含まれており、アンブレラ ヘッダーがないためです。さらに悪いことに、Objective-C コンパイラは、Thrift ライブラリからのローカル インポートも含めて、非常に厄介な Objective-C クラスを生成します。
これらの問題のいくつかはかなり厄介です。IDL を使用することは非常に優れたエンジニアリング上の決定ですが、独自のライブラリを作成するためのリソースが豊富でない限り、多くの iOS チームが Thrift を使用していないことがわかります。
于 2015-03-02T13:35:33.073 に答える
4
Thrift と HTTP は相互に排他的ではありません。実際、thrift には、使用する HTTP トランスポートの実装が同梱されています。また、非常に高速でありながら、多くのマーシャリング/アンマーシャリング定型文を回避するサーバー/クライアント コードを自動生成するための非常に優れた方法でもあります。その内部表現は基本的にバイナリ JSON であるため、RESTful Web サービスと非常によく似ています (コーディングが簡単で、はるかに高速であることを除けば)。
それで...元の質問に答えられる人はいますか？そうでない場合は、thrift に含まれている Cocoa サポートを試して、iPhone でどのように動作するかを確認します。
于 2010-08-25T02:41:28.793 に答える
2
私はいつも、サーバー コードとクライアント コードの両方を構築する共通のインターフェイス定義を使用するフレームワークが嫌いでした。実際には、サーバー API の変更は、それと通信しているクライアントのバージョンで非常に柔軟でなければなりません。
HTTP を介した JSON または PLIST 通信を非常に簡単にする便利なライブラリがあり、何十年にもわたって HTTP プロトコルとその適切な使用方法をデバッグおよび理解しています。私はあなたの危険でそれを無視します。
于 2009-12-11T21:20:09.397 に答える
2
数百万人のユーザーを持つ大規模な iPhone アプリに、thrift の目的の c バインディングを使用しました。言及されたポスターの 1 つとして、両方の長所を活かす Http を使用できます。ただし、thrift 用の非同期 HTTP クライアントはありません。ノンブロッキング I/O 呼び出しを可能にするために、イベント ベースのラッパーを構築する必要がありました。基盤となるレイヤーは依然として一度に 1 つの呼び出しを発行しますが、これは私たちに大きな打撃を与えました。なぜなら、1 つのサーバー呼び出しには長い時間がかかりますが、それは UI フローをブロックせず、もう 1 つの非常に高速なサーバー呼び出しは UI フローをブロックするからです。下位層が低速コマンドでビジー状態の場合、高速コマンドは待機する必要があります。iPhoneで使用できるasyc httpをc ++で構築しようとしていますが、準備が整っていません。
于 2011-05-10T16:19:49.323 に答える
1
外部 API としての倹約は意味がありません。ロックンロールの内部で使用します。
于 2010-04-02T05:01:57.527 に答える