こんにちは、Habr。
今日は、クライアントサーバーだけでなく、外の世界とも接続されたアプリケーションをどのように作成したかについて十分に詳しく説明したいと思います。
アプリケーションは、 iPhoneおよびAndroid用に作成されたAlkoscannerです（現在4.0から、デュースのリリースがリリースの準備中です）。 完全に無料。 簡単に言えば、株式のアグリゲーターとアルコール購入の特別オファーです。 現在、モスクワで働いており（大富豪の都市は徐々に追加されます）、2500の店舗がサポートされ、約70,000の特別オファーがデータベースにあります。
最初は、すべてが1つの形式で計画されていたため、アプリケーションはリリースするまでに進化しましたが、これにより特定の問題が発生しました。
それでは、サーバーから始めましょう
1.仕事のスピード
一般的に、非常に重要な要素であり、特に携帯電話に関係があります（特に今すぐ飲みたいときは、誰も回答を待つことはありません）。 当初、すべては問題ありませんでしたが、最初の戦闘基地をロードした後、特にモスクワの半径では、クライアントにとって永遠にかかるデータが非常に多いことが判明しました。 私は結論を書き直さなければなりませんでした。それはサーバー側に大きなブレーキを必要としました。 最適化、最適化、最適化。 専用サーバーでは、すべてがHetznerで非常に迅速かつ適切に機能しましたが、その後Selectelに移行しました...
2.サーバープラットフォーム
ホスティングプロバイダーを選択すると、最初はpingを減らし、2番目にスケーリング（できれば自動）を行うために、サーバーをモスクワに近づけることによって導かれました。 何らかの理由で、Skalaxiは電話に出ず、Selectelを選択しました（ちなみに、他のロシアの雲さえ知らないのですが、教えてもらえますか？）。 しかし、うまくいきませんでした-負荷なしで一定の独立したサーバーがクラッシュしたり、200％のプロセッサの負荷が発生したり、アプリケーションに誰もいない場合など ヘッツナーに戻るよう説得した。
3.まとめ
これまでのところ、すべてがPHP + MySQL（CodeIgniterフレームワークで独自のアドインを使用）で実行されています。 MySQLの一部をRedisに移動する予定です。 アーキテクチャは常に進化しており、リクエストはより高価になっています。
iPhone部分
1.統合YandexMapKit。
gitHubからライブラリをダウンロードします。 私たちは例を立ち上げます-すべてがうまく機能し、多くのことができます。
gitの簡単な説明を使用して、プロジェクトに統合します。 コンパイルして、ハーフキックですべてを獲得しました。 しかし、UCで数週間作業した後、理由もなく、アプリはマップに注釈を追加するとクラッシュし始めました。 バグを見つけるための主要なツールとしてのデバッグは何も提供しませんでした。インターネット上で同様の状況の説明を検索しても成功しませんでした。 彼らはまだGithubの問題に答えています） github.com/yandexmobile/yandexmapkit-ios/issues/95
最終的には、プロジェクトからライブラリ全体を破棄して再インポートすることで、すべてを決定しました。コードを書き直す必要はありませんでした。 すべてが再び時計仕掛けのようになりましたが、1時間も離れて水のように砂になり、沈殿物は残りませんでした。
2.追加のポイントとクラスタリング。
少しグーグルして、そのようなタスクのヒントを見つけられず、大きな希望なしに、UCでクラスタリングを実装する方法を提案するリクエストでGithubの同じ問題にサブスクライブしませんでした。 github.com/yandexmobile/yandexmapkit-ios/issues/109すぐに、すでにYAKを使用していた男の1人が、自分の手でやったと答えました。 そのために、私たちは袖をまくり始めました。 シンプルだが華麗なアルゴリズムをスケッチすると、望みどおりの結果が得られました-ズームにより、追加ポイントが本格的なバルーンに変わり、離れると再び小さな赤いマークに変わりました。
3.ルート建設
そして再び、YAK。 ポイントツーポイントのルートが必要ですか？ Apiはこれを行う方法を知りません。 アプリからYandexNavigatorを実行し、そこで座標を転送すると、車のルートのみが構築されます。 Yandex.Mapsを使用して足を構築したいですか？ Androidを使用してください！ 彼は、iOSキットの方法を知っています-いいえ。
Android
1.サーバーとの通信
大量のデータで、古き良きJSONがブレーキをかけられた老女に変わるとは誰も考えなかったでしょう...
パーサーの最初の実装は、ネイティブAndroid実装であるJSONParserでした。JSONParserは、実際のデータ量がロードされる前であっても、最適な側からではないことを示しました。 しかし、彼らがダウンロードしたとき... 15〜90秒の解析から受信しました。 同時に、JSONParserはメモリをほとんど消費せず、アプリケーションがいっぱいになることもありました。 最初の解決方法は、「大きいヒープ」属性を使用してアプリケーションのヒープを増やすことでした。 しかし、これは速度の問題を解決しませんでした。
androdの達人は実際のパスに送信され、リポジトリhttps://github.com/johnkil/Android-JSONCompareへのリンクを破棄しました。 潜在的な解析速度がグラフとサンプルで表示されましたが、ロックのみで、ハードコアのみです！ 開始するために、彼らはJSON.simpleを採用しました。これはオブジェクト内の実装によると、ネイティブのものとそれほど変わらず、コードを大幅に変更することなくオンザフライで使用できます。 予想どおり、1000以上のレコードが大量に記録された結果、気のめいるような結果が得られたため、JSONParserよりもさらに単純化されました。 その後、GSONが選択されました。GSONは、以前の障害を考慮してすぐに警告したネイティブの実装と非常によく似ていました。 しかし、すべてがそれほど悪くないことが判明しました！ 90秒は最大30秒になりました。しかし、これは誰にも合わなかったため、選択肢は1つだけでした-ジャクソン。 パーサーは、以前のものと比較して独特ですが、試行錯誤によって、私たちはまだそれを自分自身のために働かせました。 そして、彼らは衝撃を受けました。
彼は夢の中で夢を見ることができるよりも自分自身をより良く見せました。 前の30秒は忘却に沈み、3〜5秒浮上しました。
2.ああ、これらのYandex.Maps
GoogleとAppleカードがまだ非常に悲しいロシア向けのアプリケーションであることを考えると、Yandex.mapsに選択肢がありました。 まず、 github.com / yandexmobile / yandexmapkit-androidリポジトリ自体をご覧ください 。 カードの使用は非常に簡単に始まりましたが、「森の奥深くにいるほどキツツキは怒ります」。 最初の停止ポイントは、マップ上のポイントのインストールで、バランと同様にポイントも完全にインストールされていましたが、マップ上に50以上があると、重大なメモリリークが始まり、そのためアプリケーションが体系的にクラッシュし始めました。 最初に、リークがコードのどこかにあることを提案しました。 コードを何度も調べ、フラグの代わりに使用する画像を最適化し、再コーディングして圧縮すると、何も変わっていないことがわかりました...その結果、マップの中心を中心とする特定の半径内に収まるランダムな割合のデータ（3エントリごと）に制限する必要がありました。 しかし、この瞬間までに、私は実際に現場でアプリケーションをテストしたかったのです。サイエンスフィクションは科学とはほど遠いからです。 さらに、2つの明白で非常に顕著なバグが出た瞬間まで、落ち着いています：黒いタイルまたは非常に奇妙な動作をするタイル（ https://github.com/yandexmobile/yandexmapkit-android/issues/105 ）または自発的なクラッシュバランをクリックします （ https://github.com/yandexmobile/yandexmapkit-android/issues/122 ）。 同時に、ユーザーと開発者の両方によって発見され修正されたバグの数を考えると、ライブラリはすでにほぼ1年間更新されていません...一般的に、脳とシャーマニックタンバリンで武装して、このライブラリをクラッシュなしで動作するように強制しました（頻繁）ある時点で、Yandex.Maps用の独自のマップキットを書くことを真剣に考え始めました。
3.ポート2.2+
初期の変換では、Sherlockライブラリを使用することが決定されました。 その最初の使用は、魂に心地よい残渣を残しました。 アプリケーションを4.0から2.2に変換するのに15分かかりましたが、すべての機能はそのままで、スタイル、またはむしろ標準のAndroidスタイルのインデントにはわずかな問題しかありませんでしたが、これは5分、検索で決定されました。
そしてさらに。 手元にあったすべての電話機（2.2、2.3）でのテストでは、何百キロも離れた友人や知人とのテスト、クラッシュ、クラッシュ、クラッシュなどは表示されません...
ここではテストがまだ進行中です。HTCDesireでのクラッシュの理由に関する提案は受け入れられます。
4.アニメーション
システム内のアクションとしてのアニメーションは、実装の観点から見ると非常に単純なプロセスです。 しかし、観察とテストは興味深い画像を示しました。 非同期要求がサーバーに呼び出されると、アニメーションが表示されます。アニメーションは、外観も実装も非常に簡単です。 データは非同期にロードされますが、解析には遅延があり、奇妙な長い時間がかかります。 データを受信したら、すぐにdoInBackgroundに解析し、onPostExecuteでそれらを表示します（必要に応じて）。 単純なアニメーションはUIストリームを大量にロードし、その後アプリケーションをロードするようです。 アニメーションが約3秒（SGS3）でデータ解析を遅くするアニメーションを使用した測定。 異なるデバイスでは、この遅延時間は異なるため、現在は問題が残っています。
データ
この作業はすべて、ストアの割引に関する最新情報をアプリに入力できる場合にのみ意味があります。 さて、少し秘密を教えましょう。いいえ、アプリケーションを使用した多くの人が考えるように、私たちはいくつかの秘密のデータベースにこだわることはありませんでした。 データを直接受け取るストアはありますが、これまでのところ多くはありません。 収集プロセスの開発中に、単一のプロセスが不安定な品質の結果をもたらし、各取引ネットワークを調査する必要があるという結論に達しました。現在、1つのプロセスではなく、実際にはネットワークの数とこれらの手順に応じて20以上の収集手順があります-アプリケーションの重要な部分。 私たちの方法は100％の正確さを与えることはできませんが、私たち自身のテストによれば、80％の正確さを持っています。 アートに反して、警備員との戦いや部屋のコレクターの妨害まで、いまだにさまざまなばかげた問題があります。 ロシア連邦憲法の29（国での権限を強調しています）ですが、一般的に、これらの事件に対処し、必要に応じて、さまざまなトリックを発明します。
コメントの質問や説明に喜んでお答えします。