Badooでのbadooソーシャル共有画像の生成方法

ソーシャルネットワークは重要なトラフィックのソースです。 ユーザーがコンテンツを共有することは私たちにとって有益であり、ユーザーにこの機会を与えます。共有できるコンテンツにはいくつかの種類があります。

• あなたのプロフィール;
• 他の誰かのプロファイル（所有者が許可した場合）;
• サイトでのユーザーの人気を反映した評価。
• ユーザーの行動または他のユーザーの行動に対して受け取った報酬。

ユーザーにこれをすべて共有させたいと思うために、バッジと呼ばれる特別な画像を生成します。 ユーザーが取得できるバッジの例を次に示します。



バッジの特徴は、ユーザー自身の写真が含まれているため、誰もがユニークな画像を見たり共有したりすることです。 この記事では、このような画像の生成方法、遭遇した問題、およびそれらの解決方法について説明します。

画像生成

ソーシャルネットワークからのユーザーまたはボットのリクエストに応じて、リアルタイムバッジの画像を生成します。 事前に調理することはできません これには、必要なすべてのイメージを完全に生成するために大量のストレージスペースとサーバーリソースが必要になります（ただし、実際に必要になるという事実ではありません）。
生成スキームの基礎として、私たちの写真が機能するものを採用しましたが、わずかに変更しました。 サーバーの観点から見ると、生成は次のとおりです。

1. バッジ生成のためのHTTPリクエストがPhotocacheサーバーに到着します。その目的は、リクエストを受け入れ、レスポンスキャッシュを保存することです
2. それにより、写真自体を保存するサーバーの負荷を軽減します。
3. Photocacheのnginxは、キャッシュ内の画像を探し、もしあれば、クライアントに提供します。 ここでは、バッジの最初の違いが表示されます。 リクエストは比較的少なく、ここでは標準のnginxキャッシュが使用されます。通常の写真を使用する場合のように、自己作成モジュールではありません。
4. キャッシュに何もない場合、リクエストはBphotos-バッジを生成するユーザーの写真が保存されているサーバーにプロキシされます。
5. BphotosのnginxはリクエストをPHPスクリプトに渡します。PHPスクリプトは必要なすべてのリソースをロードし、生成を開始して完成したイメージを提供します。 これが2番目の違いです。nginxは、PHPスクリプトの助けを借りずにカスタムユーザーの写真を提供します。
6. Photocacheは受信したバッジ画像をクライアントに送信し、キャッシュします。

バッジの各タイプには独自のURL形式があり、生成に必要なユーザーの写真やその他のリソース（賞など）の識別子が含まれます。 正しいサーバーへのリクエストの転送に影響するサービスパラメータ。 このバッジが生成される言語とソーシャルネットワークのコード。

Badooは複数の言語にローカライズされたプロジェクトであるため、URLの言語コードは非常に重要です。 通常のクエリでは、現在のユーザーの設定に基づいたローカライズオブジェクトを使用してトークンを取得します。 バッジでは、これは機能しません。 リクエストの約3分の1はソーシャルネットワークのボットから送信されます。ボットは、システムが不正ユーザーとして処理し、IPアドレスによって言語を推測しようとします。 最初はこれについては考えていませんでしたが、私たちのウェブサイトまたはアプリケーションで、ユーザーが1つの言語のテキストを含む画像を見て、Facebookに追加して、英語のテキストを含む画像を見ました。

ソーシャルネットワークには画像サイズの好みが異なるため、ソーシャルネットワークコードが必要です。 たとえば、Facebookには1200x630の写真が必要で、Instagramには640x640の写真が必要です。 誰に対して画像を生成しているのかがわかっている場合、受信者に適応できます。



これに加えて、通常、URLの一部を変更のビットマスクの下に置きます。これは、ジェネレーターの一部の機能を一部の場合にのみ含める必要がある場合に使用されます。 たとえば、AppleがiOSアプリケーションのユーザーの評価で写真を配布しないように要求したときに、このフィールドを使用しました。 次に、レーティングを非表示にするフラグを追加しました。これにより、一方ではAppleと口論することなく、可能な場合は既存のバッジを残すことができました。 このフィールドなしでも実行できますが、バッジの変更されたバージョンごとに新しいURL形式を作成する必要があります。これにより、これらの形式が成長し、時間が経つにつれてサポートが複雑になります。

コードの観点から見ると、画像生成スクリプトは次のようになります。

1. サーバーからのリクエストを受け入れ、URL形式からバッジの必要なタイプを決定し、バッジイメージを作成するジェネレーター自体とジェネレーターのデータソースであるオブジェクトのペアを作成する単一のコントローラーがあります。
2. URLからのパラメーターはソースオブジェクトに渡されます。ソースオブジェクトは、バッジを作成してロードするために必要なリソースを理解します。
3. ソースオブジェクトはジェネレーターオブジェクトに「設定」されます。これにより、ジェネレーターは、既にロードされているリソースからのイメージのアセンブリのみを処理できます。
4. コントローラーは、ジェネレーターオブジェクトの結果を受け取り、目的のヘッダーと共に返します。

原則として、データソースオブジェクトの構造はバッジのタイプによって大きく異なり、ジェネレーターオブジェクトも同様の構造を持っているため、継承元の抽象クラスがあります。 次のようになります。

abstract class AbstractBadgeGenerator { /** *      false    * @return bool|\FastImageEditor */ final public function getImage() { $this->startPinbaTimer('isAvailable'); $is_available = $this->isAvailable(); $this->stopPinbaTimer(); if (!$is_available) { return false; } $this->startPinbaTimer('generate'); $Result = $this->generate(); $this->stopPinbaTimer(); return $Result; } /** *  ,       . *   —   ,    , *            * @return bool */ public function isAvailable() { return true; } /** *      false,      * @return bool|\FastImageEditor */ abstract public function generate(); //    } 

ここで最も重要なことはgetimageメソッドで、これはコントローラーから「ひきつり」ます。 画像オブジェクトを返さない場合、コントローラーは404エラーを返します。アクセシビリティおよび画像アセンブリメソッドの呼び出しはPinba-timersでカバーされており、特定のクラスの名前を名前に置き換えます。これにより、各タイプのバッジの生成に必要な時間に関するデータが得られます。 さらに、タイマーを使用して特定のジェネレータークラスの画像ですべての操作を終了し、コントローラーでソースとジェネレーターの合計動作時間に関する情報を収集し、統計収集システムを使用してデータベースに書き込みます（Habrでは、説明付きのビデオを見つけることができます）

画像を使用する場合、非常に限られた数の操作を使用します：任意の角度での回転、画像のサイズ変更とトリミング、レイヤーのオーバーレイ（透明度を含む）、テキストの追加。 それらを実行するには、 Leptonicaライブラリを使用します。 このライブラリのラッパーは、Anton Dovgalによって作成されました（古いバージョンはgithubにあります ）。 彼女は競合他社よりも速く働いたため、数年前に彼女が選ばれました。 これを実証するために、GD、ImageMagick、およびLeptonicaとの小さなベンチマーク比較を行いました。

ライブラリごとに、サイズが1000x1000の新しいイメージを作成するスクリプトを作成しました。このイメージには、ディスクから読み込まれた別のイメージ（リソースのアナログ）がスーパーインポーズされます。 コードをバッジの生成時に使用されるものに近づけるために、ロードされたイメージにいくつかの操作を追加しました-縮小して回転します。 操作の結果は、JPEG形式でディスクに保存されます。 このようなシナリオにより、バッジを生成するときに使用するほぼすべての操作の速度を推定できます。 記事のコード自体はサイズが大きいため提供しませんが、興味のある方はGitHubにソースコードを投稿します 。

サーバーでこれらのスクリプトを100回連続して実行すると、次の結果が得られました。



テスト結果によると、このシナリオでは、LeptonicaはGDおよびImagemagickのほぼ2倍の速さであり、合計時間はほぼ同じでした。
もちろん、実際のバッジの生成では、このテストよりもはるかに多くの画像操作が使用されるため、Leptonicaがすでに高速で動作していることを期待しないでください。ただし、必要な操作の数を最小限に抑えてください。 これを行うには、リソースの準備段階で最適化を実行し、できるだけ多くのレイヤーを1つのイメージに結合します。

生成結果のテスト

徐々に、バッジが増えていきました。コードまたはリソースを変更した後、すべてのバッジが正しく機能することを確認したかったのです。 このために、機能テストを使用することにしました。ユーザーのスタブ、彼の写真、および賞を作成し、バッジのURLを作成してジェネレーターに渡しました。 主な問題は、結果を正確に確認することでした。 明らかな方法-テストで生成された画像を既存のサンプルと比較する-私たちは本当に好きではありませんでした、なぜなら 彼は、すべての可能なバッジサンプル（番号が50に達する）を変更して手動で組み立てることを要求し、自動化の魅力を奪いました。または、オプションの一部だけを取った場合、すべてのバッジが機能することを保証しませんでした。

いくつかの考えと実験の後、2つの単純化されたタイプのチェックを使用し始めました。

1. 生成結果の基本的な検証：ジェネレーターが期待されるサイズの画像を正確に返し、制御点に複数の色が含まれていることを検証します。
2. いくつかの生成結果の比較：テストでは、ほぼすべてが類似している2つのバッジのURLを生成しますが、1つのパラメーター（言語コード、表示テキスト、賞など）のみが異なり、2つの画像を取得することを期待しています。互いに異なる。 少なくとも1つのコントロールポイントで色の不一致が存在することを違いと定義します。

両方のチェックで、制御点の概念が表示されます。 それは、何らかのルールによって得られた画像内の一連の点を意味します。 具体的には、画像を水平および垂直に10個の等しい部分に分割します。その結果、線の交点で81個のコントロールポイントを取得し、同様のコードを使用してカラーマップを収集します。

 protected function getImageColorsMap($Image, $color_grid_size = self::COLOR_GRID_SIZE) { $image_info = $Image->getInfo(); $dx = ceil($image_info['width'] / $color_grid_size); $dy = ceil($image_info['height'] / $color_grid_size); $colors_map = []; for ($row = 1; $row < $color_grid_size; $row++) { for ($cell = 1; $cell < $color_grid_size; $cell++) { $x = $dx * $cell; $y = $dy * $row; $color = $Image->getOnePixel($x, $y); $colors_map[$color][] = [$x, $y]; } } return $colors_map; } 

2つの画像のすべての点が一致するということは、これらの画像が完全に一致することを意味するものではありませんが、これは注意して、そのような点の数を増やすか、誤検出が頻繁に発生する場合の選択規則を変更する理由です。 実際には、81ポイントで、誤検知に遭遇したことはありません。

もちろん、そのような単純なチェックは、バッジが私たちが期待するものを正確に表示することを保証しません。 しかし、それらはすべてのバッジが機能することをすばやく確認し、本番稼働前にいくつかのバグをキャッチするのに役立ちました。それらの一部は、PHP生成コードではなく、画像を操作するための「システム」ライブラリで許可されていました。

テキスト出力の問題

この記事では画像生成に焦点を当てていますが、解決に最も時間がかかった問題はテキストに関連していました。

テキストによるアルファベットの定義

テキストを異なる言語で表示します。 一部の言語では、キリル文字とラテン文字以外のアルファベットを使用していますが、すべてのフォントがそれらをサポートしているわけではありません。 したがって、適切なフォントを使用するには、出力に必要なアルファベットを理解することが重要です。 事前定義されたトークンを導出する場合、これは非常に簡単です-テキストが書かれている言語を知っています。 ただし、一部の場所ではユーザーテキストを表示し（たとえば、Instagramでプロフィールを「共有」する場合、ユーザー名はバッジに表示されます）、どの言語で書かれているのかわかりません。

この問題は、unicode.orgウェブサイトでグループのシンボルのメンバーシップを直接見つけることができるため、非常に簡単に解決されました 。 私たちがしなければならなかったのは、テーブルをダウンロードして、文字のグループの範囲を単一のテーブルに縮小することだけでした。 このようなテーブルを使用すると、文字列内のすべての文字を確認し、使用されているグループのリストを取得し、これらすべての文字グループをサポートするフォントを選択できます。

覚えておくべき主なこと：サイト上のコードはUCS-4で提供されており、多くのUTF-8ではおなじみのものではありません。

指定された寸法にテキストを合わせる

バッジは異なる言語のテキストを使用し、異なる言語の同じフレーズは長さが異なります（したがって、異なる場所が必要です）。 テキストサイズに合わせるために、フォントサイズの調整とテキストの行への分割という2つのアルゴリズムを使用します。

フォントサイズの調整。 テキストに使用できる特定の「理想的な」フォントサイズと最大幅があります。 テキストがこの幅に収まるかどうかを確認し（たとえば、GDにはimagettfbboxおよびimageftbbox関数があります）、収まる場合は、単にテキストを印刷します。 テキストがより多くのスペースを占有する場合は、フォントサイズを小さくしてチェックを繰り返します。 サイズの選択を実装するコードは次のとおりです。

 $font_size = $initial_font_size; $max_x = 0; while ($font_size > $min_font_size) { $text_size = $Image->getTextBox($font_size, $angle, $font, $text); $max_x = max($text_size[2], $text_size[4]); if ($max_width >= $max_x) { break; } $font_size -= 1; } 

このアルゴリズムは単純さでは優れていますが、表示されるテキストの長さの小さな広がりに対してのみ使用できます。 大きなテキストでは、フォントサイズを大幅に縮小する必要があるため、読みにくくなります。 そのような場合、改行を使用します。

改行は非常に簡単に機能します：表示できる文字数を決定し、その後、最初にテキストを単語に分割し、次に単語を行に収集します。各文字は最大文字数を超えません。 ここでは、文字列の文字数よりも長い可能性のある長い単語があり（その後、フォントサイズの調整を分割結果に適用する必要がある）、一部の言語では標準の区切り文字（たとえば、 日本語 ）を使用しないことに注意する必要があります。

少数の文字だけが1行に収まらない場合、改行はうまく機能しません。 この状況の結果は通常、1つまたは2つの短い単語を含む1つの長い行と1つの短い行です。 この状況を修正するために、テキストを行の長さに沿って互いにできるだけ近くに2つに分割しようとしています。 これを行うために、分割するとき、行の最大長ではなく、テキストの実際の長さの半分に焦点を合わせます。 長い単語が理想的な区切りを壊すという問題を解決するために、テキストの先頭から末尾まで、およびテキストの末尾から先頭までの2つのオプションを作成します。その後、行の長さの差が少ない方を選択します。

 $len = mb_strlen($text); if ($len <= 2 * $this->max_line_size) { $ideal_line_len = ceil($len / 2) - 1; $lexems_list = $this->getTextLexems($text); $direct_order_lines = $this->getDirectOrderLines($lexems_list, $ideal_line_len); $reversed_order_lines = $this->getReversedOrderLines($lexems_list, $ideal_line_len); $delta_direct = $this->getLinesDelta($direct_order_lines); $delta_reversed = $this->getLinesDelta($reversed_order_lines); return ($delta_direct < $delta_reversed) ? $direct_order_lines : $reversed_order_lines; } 

歌詞についての楽しい事実。 私たちの経験では、ギリシャ語とスワヒリ語のトークンが最も多くを要求しました。 ドイツ語のテキストは通常​​短いですが、長い単語が存在するため、行に分割するのは困難です。

右から左へのワードプロセッシング

右から左へのつづり（RTL言語）を使用するテキストは、そのまま表示することはできません-それらは完全に判読できません。 これは、そのような言語には、ストレージ中に使用される論理文字と、表示される視覚文字の2つの順序の文字があるためです。

いわゆるUnicode双方向アルゴリズム（略してBIDI）は、ある注文を別の注文に変換する役割を果たします。 これについては、 ハブ （ BIDI（Unicode双方向アルゴリズム） ）、W3C Webサイト（ ビジュアルとテキストの論理的順序 、 Unicode双方向アルゴリズムの基本 ）、unicode.org（ Unicode双方向アルゴリズム ）で詳細を学ぶことができます。 Unicodeを使用する現代のクライアントには、このアルゴリズムの実装が含まれており、画像にテキストを書き込むときは、これを自分で処理する必要があります。

いくつかのRTL言語がありますが、具体的には、ユーザーが使用するのはアラビア語とヘブライ語の2つだけで、バッジ生成リクエストの総数の1％未満を提供します。

ヘブライ語の問題は非常に迅速に解決されました。PHPには、論理テキストをビジュアルに変換するためのhebrev関数があり、この関数のドキュメントページの最初のコメントは、UTF-8のテキストにそれを使用する方法を示しています：

 $visual_hebrew_text = iconv("ISO-8859-8", "UTF-8", hebrev(iconv("UTF-8", "ISO-8859-8", $logical_hebrew_text))); 

アラビア語では、すべてがより複雑でした。 幸いなことに、リモートのアラビア語翻訳者が以前にこのような問題に遭遇し、Ar-PHPライブラリの作成に参加したことがあります 。 ライブラリには多くの機能が含まれていますが、ここ数年はあまり積極的に開発されていません。 彼女のサイトは定期的に利用できませんが、コードはGitHubのフォークにあります： 1、2、3 。 元のバージョンでは、テキストは次のように変換されます。

 $ArabicGlyphs = new \I18N_Arabic_Glyphs(); $visual_arabic_text = $ArabicGlyphs->utf8Glyphs($logical_arabic_text, $max_characters_count); 

テキストがこの方法で処理される場合、imagettftextのような通常の関数で表示できます。 これがどのように見えるかです：

1. 処理に加えて、RTLテキストを操作する際に覚えておく必要のあるいくつかのニュアンスがあります。
2. グラフィックライブラリの機能を使用してテキストを表示する場合、テキストの左境界線の座標が示されますが、RTLでは原則として、正しいものを知る必要があります。 したがって、結論自体の前に、テキストの幅を事前に計算する必要があります。その後、テキストとテキストの右境界の座標を知ってから、左境界の座標を計算できます。
3. テキストを複数の行に分割して表示する場合、最初に順序を逆にする必要があります。 テキストを左から右に分割し、左のテキストが最初の要素に格納されている文字列の配列を取得します。 RTLテキストの場合、これは最初ではなく最後であり、テキストは下から上に書かれていることがわかりますが、これは間違っています。

おわりに

PHPで画像を操作することは最も人気のあるトピックではなく、インターネット上で新たに発生した問題の解決策を見つけることは困難です。 私の記事のおかげで、これが少し簡単になることを願っています。 私の記事で何かが理解できないと思われ、質問がある場合は、コメント欄で質問してください。答えてみます。

TechBadooの技術ブログでは、さらに多くの記事や資料を見つけることができます。

Viktor Pryazhnikov、機能開発者