Agile Cat — in the cloud

新聞を読まない若者たちと、スマホに触らない老人たち:それを示す1枚のチャート

Posted in Entertainment, Mobile, Research by Agile Cat on December 19, 2014

Young People Don’t Care About Newspapers, Old People Don’t Care About Smartphones
http://wp.me/pwo1E-86p
Dave Smith – Dec. 3, 2014
http://www.businessinsider.com/media-sources-every-age-group-cant-live-without-2014-12

_ Business Insider

Kicking off Business Insider’s Ignition event on Tuesday, Business Insider CEO Henry Blodget detailed where digital business is headed. And of all the interesting visuals from that presentation, this chart, based on Ofcom data charted by BI Intelligence, stood out. It shows a major shift in the types of media most important to various generations.

この火曜日に開催された、Business Insider の IGNITION イベントのキックオフで、当社の CEO である Henry Blodget は、デジタル・ビジネスの方向性について、詳しく解説していた。彼のプレゼンテーションでは、さまざまなデータがビジュアライズされていたが、その中でも Ofcom のデータを BI Intelligence がチャート化したものが際立っていた。それは、さまざまな世代において、最も重要とされるメディアが、大きくシフトしている状況を示したものである。

_  space

BI Intelligence

People between the ages of 16 and 24, for example, would not blink an eye if newspapers and magazines went extinct; smartphones are the "must-have" device of the younger generation. The breakdown among all adults shows a much stronger craving for TV over smartphones and computers, and the older generations (those over 75) don’t care much about computers and have absolutely no problem living without smartphones.

例をあげると、16歳〜24歳の人々は、新聞や雑誌が絶滅しても、瞬きすらしないだろう。それらの若い世代にとっては、スマホが必須のデバイスとなる。すべての成人に関するデータを平均してみると、スマホやコンピューターよりも、TV に対する要求が強いという結果が示されている。そして、古い世代(75歳以上)は、コンピュータに対する関心は薄く、さらに言えば、スマホのない生活も、まったく問題ないという結果になっている。

ーーーーー

若年層と老年層で、こんなにも利用するメディアが異なるのですね。 そして、驚くのが、すべての世代における新聞/雑誌への依存度の低さです。 アメリカでは新聞とテレビの間に慣れ合いがないため、日本よりも既存メディアが元気なようにみえますが、それでも先行きは明るくないようです。 同じような調査を、日本で行ったら、どんな結果になるのでしょう? 

ーーーーー

<関連>

ダーク・ソーシャルが支配するオンライン共有の世界
Facebook と Google によりソーシャル・ログインの 80% が占有されている
Twitter と MIT の コラボ が、膨大なソーシャル・ストリームを分析していく
2014年の Android と iOS:出荷数と売上額を1枚のチャートで!
Facebook と Youtube が モバイル・トラフィックの 40% を占める 米国

2014年の Android と iOS:出荷数と売上額を1枚のチャートで!

Posted in Mobile, Post-PC, Research by Agile Cat on December 16, 2014

The Smartphone Market 2014
http://wp.me/pwo1E-863
Niall McCarthy, December 2nd, 2014
http://www.statista.com/chart/3014/smartphone-market-share-forecast/

_ Statista

Android devices are still the driving force across the global smartphone market, according to the International Data Corporation.

International Data Corporation(IDC)によると、グローバルにおけるスマホ市場を牽引する原動力は、依然として Android デバイスが握っていることになる。

This chart shows a forecast of the worldwide smartphone market share in 2014.

このチャートは、2014年におけるグローバル・スマホ市場の、シェアに関する予測を示している。

Total smartphone shipments are set to reach 1.3 billion units this year with Android accounting for over 80 percent compared to just under 14 percent for iOS. From a revenue perspective, Apple’s premium smartphones control 30 percent of global revenue while Android’s more layered approach will afford it just under 67 percent.

今年のスマホの、全体としての出荷台数は 13億台に達するが、そのうちの 80% 以上を Android が占め、iOS は 14% を切るレベルに留まる。また、収益の観点から見ると、Apple のプレミアムなスマホ群が、グローバル売上の 30% をコントロールする一方で、Android は階層的なアプローチにより、67% を下回るところに達している。

ーーーーー

今年の1月にポストした、「 世界のスマホ:総数の 70% 以上を Android が占有 」という抄訳には、Android の出荷数について、2013年 Q3 が 72%で、2012年 Q3 が 55% と記されています。 また、iOS は 2013年 Q3 が 18%で、2012年 Q3 が 19% となっています。そして、この 2014年は、インドなどに代表される途上国に、たくさんの Android スマホが浸透していったことで、このような比率が予測されるのでしょう。 あれだけ売れた、iPhone 6 の数字を加えても、このような結果にしてしまう、Android の伸びには驚きを超えて呆れている、というのが正直な感想です。

ーーーーー

<関連>

Facebook と Youtube が モバイル・トラフィックの 40% を占める 米国
iPhone 6 の浸透により、iPad へのニーズが殺されていく
急降下する Samsung のシェア:最新のスマホ勢力図を1枚のチャートで!
iOS と Android:これまでの出荷台数の推移を、1枚のチャートで!
Facebook と Google によりソーシャル・ログインの 80% が占有されている

Facebook と Youtube が モバイル・トラフィックの 40% を占める 米国:それを示す1枚のチャート

Posted in Mobile, Research by Agile Cat on December 12, 2014

Facebook And YouTube Account For Almost 40% Of All Mobile Internet Traffic
http://wp.me/pwo1E-85R
Dave Smith – Dec. 9, 2014
http://www.businessinsider.com/facebook-and-youtube-account-for-almost-40-of-all-mobile-internet-traffic-2014-12

_ Business Insider

At Business Insider’s IGNITION event last week, Business Insider CEO Henry Blodget detailed the future of the digital landscape, pointing out some important trends. For example, more than a quarter of all internet traffic now comes from smartphones and tablets — and two big internet properties are responsible for a huge amount of that traffic.

先週に Business Insider が主催した IGNITION というイベントで、当社の CEO である Henry Blodget は、いくつかの重要なトレンドを指摘しながら、デジタルの世界の未来について詳しく説明した。たとえば、すべてのインターネット・トラフィックの 1/4 以上が、スマホとタブレットから発生している。また、2つの大きなインターネット・プロパティが、その膨大なトラフィックの要因となっている。

_  space

BI Intelligence

Based on data from a Sandvine report charted for us by BI Intelligence, Facebook and YouTube accounted for nearly 40% of all mobile web traffic in North America in September. Facebook accounted for 19% of that aggregate mobile traffic, YouTube was close behind with 18%, and the third largest share belonged to “general web traffic” through web browsers, at 11%. As BI Intelligence’s Mark Hoelzel points out, ads make up a big percentage of Facebook’s and YouTube’s mobile traffic, since autoplay video ads increase the mobile data demands on those social networks.

BI Intelligence がチャートにした、Sandvine レポートのデータをベースにすると、この 9月における北米の全モバイル Web トラフィックの約40%を、Facebook と Youtube が占めることになる。集計されたモバイル・トラフィックのうち、Facebook が占める割合は 19% であり、Youtube の 18% が僅差で続いている。そして、3番手は、Web ブラウザを介した、「一般的な Web トラフィック」の 11% となる。BI Intelligence の Mark  Hoelzel が指摘するように、Facebook と Youtube のモバイル・トラフィックにおいては、広告が大きな割合を占めている。なぜなら、自動的に再生されるビデオ広告が、これらのソーシャル・ネットワーク上のモバイル・データ量を、増加させているからである。

ーーーーー

アメリカ市場に限定した調査の結果ですが、まず、目を引くのが、Netflix に対する Youtube の圧倒的な強さです。 モバイルでは、こんな比率になる、、、というのが、正直な感想です。 また、今月は、モバイル・トラフィックを低減するための、Facebook の取り組みについて紹介してきましたが、それでも、これだけの帯域を消費しているのですね。 2年ほど前に、「Facebook が1位で、Google Maps が2位 : モバイル・アプリ 2012 ランキング」という抄訳をポストしましたが、こちらは、各モバイル・サービスにおける滞在時間を比較したものです。 今日のポストと比較すると、それぞれのサービスの性質が見えてきて、とても面白いです。

ーーーーー

<関連>

Facebook アプリ:Push + Delta + Thrift で モバイル帯域を 40% も削減!
Facebook が語るモバイル・チューニングの極意:これで途上国のインターネットも OK!
日本と世界のインターネット・トラフィック – 2014年/11月(アメリカ編)
急降下する Samsung のシェア:最新のスマホ勢力図を1枚のチャートで!
iOS と Android:これまでの出荷台数の推移を、1枚のチャートで!

Facebook アプリ:Push + Delta + Thrift で モバイル帯域を 40% も削減!

Posted in .Selected, DevOps, Facebook, Mobile, Network, Post-PC by Agile Cat on December 11, 2014

Facebook Mobile Drops Pull For Push-based Snapshot + Delta Model
http://wp.me/pwo1E-85F
Monday, October 20, 2014
http://highscalability.com/blog/2014/10/20/facebook-mobile-drops-pull-for-push-based-snapshot-delta-mod.html

We’ve learned mobile is different. In If You’re Programming A Cell Phone Like A Server You’re Doing It Wrong we learned programming for a mobile platform is its own specialty. In How Facebook Makes Mobile Work At Scale For All Phones, On All Screens, On All Networks we learned bandwidth on mobile networks is a precious resource.

私たちは、モバイルが別の世界のものであることを学んできた。If You’re Programming A Cell Phone Like A Server You’re Doing It Wrong では、モバイル・プラットフォームのためのプログラミングが、独特のものであることを知った。そして、How Facebook Makes Mobile Work At Scale For All Phones, On All Screens, On All Networks では、モバイル・ネットワークの帯域幅が、きわめて貴重なリソースであることを学習した。

Given all that, how do you design a protocol to sync state (think messages, comments, etc.) between mobile nodes and the global state holding servers located in a datacenter?

それら、すべてのことを考慮して、ステート(メッセージやコメントなど)をシンクさせるためのプロトコルを、どのようにデザインすべきなのだろうか? ここでは、複数のモバイル・ノードと、データセンターのサーバーに置かれたグローバル・ステートの、同期について考えていく。

Facebook recently wrote about their new solution to this problem in Building Mobile-First Infrastructure for Messenger. They were able to reduce bandwidth usage by 40% and reduced by 20% the terror of hitting send on a phone.

最近のことだが、Facebook の Building Mobile-First Infrastructure for Messenger というポストにおいて、この問題に関する彼らの新しいソリューションが紹介されている。それによると、帯域幅の使用率が 40% まで、そして、スマホでの送受信を阻害する要因が 20% まで、削減できたという。

That’s a big win…that came from a protocol change.

それは、素晴らしい成功体験であり、また、プロトコルの変更にもたらされたものである。

<関連> Facebook が語るモバイル・チューニングの極意

Facebook Messanger went from a traditional notification triggered full state pull:

The original protocol for getting data down to Messenger apps was pull-based. When receiving a message, the app first received a lightweight push notification indicating new data was available. This triggered the app to send the server a complicated HTTPS query and receive a very large JSON response with the updated conversation view.

Messenger がデータをダウンロードする際の、オリジナルのプロトコルは Pull ベースのものであった。 このアプリはメッセージを受信するとき、新しいデータがあることを示す、ライトウェイトなプッシュ通知を最初に受信する。それは、アプリに対するトリガーであり、その結果として、サーバーへ向けて複雑な HTTPS クエリーを送信し、また、アップデートされた会話を取り込んだ、きわめて大規模な JSON レスポンスを受信することになる。

To a more sophisticated push-based snapshot + delta model:

Instead of this model, we decided to move to a push-based snapshot + delta model. In this model, the client retrieves an initial snapshot of their messages (typically the only HTTPS pull ever made) and then subscribes to delta updates, which are immediately pushed to the app through MQTT (a low-power, low-bandwidth protocol) as messages are received. When the client is pushed an update, it simply applies them to its local copy of the snapshot. As a result, without ever making an HTTPS request, the app can quickly display an up-to-date view.

私たちは、前述のモデルに代えて、Push ベースの SnapShot + Delta モデルに移行することを決めた。 この新しいモデルでは、クライアントは自身のメッセージに関する、イニシャルの SnapShot を取得する(一般的には、これまでの HTTPS Pull のみとなる)。 続いて、Delta アップデートが読み込まれるが、それはメッセージを受信した直後に、MQTT(リソースと帯域において負荷の少ないプロトコル)を介してアプリに Push されるものである。また、クライアントからアップデートが Push されるときには、ローカルに保持される SnapShot に、その内容がコピーされる。その結果として、これまでのような HTTPS リクエストを必要とすることなく、アプリはアップデートされたビューを表示できるようになる。

We further optimized this flow by moving away from JSON encoding for the messages and delta updates. JSON is great if you need a flexible, human-readable format for transferring data without a lot of developer overhead. However, JSON is not very efficient on the wire. Compression helps some, but it doesn’t entirely compensate for the inherent inefficiencies of JSON’s wire format. We evaluated several possibilities for replacing JSON and ultimately decided to use Thrift. Switching to Thrift from JSON allowed us to reduce our payload size on the wire by roughly 50%.

さらに、私たちは、メッセージと Delta アップデートから、JSON エンコーディングを切り離すことで、このフローを最適化した。もし、開発者のオーバーヘッドを最低限に抑えたかたちで、ヒューマン・リーダブルで柔軟なデータ転送を実現するなら、JSON は素晴らしいソリューションとなる。しかし、JSON における送受信の形式は、きわめて効率が悪い。 圧縮により、いくつかの問題は解決するが、JSON の固有の非効率性を、完全に補完することは不可能だ。私たちは、JSON を置き換えるための、いくつかの可能性について評価し、最終的には Thrift を使用することにした。JSON から Thrift へ移行することで、転送における実質的なサイズを、およそ 50% に低減できた。

On the server side Facebook also innovated:

Iris is a totally ordered queue of messaging updates (new messages, state change for messages read, etc.) with separate pointers into the queue indicating the last update sent to your Messenger app and the traditional storage tier. When successfully sending a message to disk or to your phone, the corresponding pointer is advanced. When your phone is offline, or there is a disk outage, the pointer stays in place while new messages can still be enqueued and other pointers advanced. As a result, long disk write latencies don’t hinder Messenger’s real-time communication, and we can keep Messenger and the traditional storage tier in sync at independent rates. Effectively, this queue allows a tiered storage model based on recency.

Iris は、メッセージングのアップデート(新しいメッセージやメッセージ・リードによるステートの変化など)で用いる順列キューのことであり、Massenger アプリに送信された最新のアップデートと、伝統的なストレージ階層において、別々のポインタを持つことが可能になっている。ディスクおよびスマホへのメッセージ送信が成功すると、それに対応するポインタが前進する。もし、スマホがオフラインであったり、ディスクに障害が発生した場合には、対象となるポインタを所定の位置に留めながら、新しいメッセージをキューに保持し、他のポインタを前進させることができる。その結果として、ディスクへの書き込みなどの、大きなレイテンシが発生しても、Messenger のリアルタイム通信を妨げることはない。 そして、Messenger のレベルと伝統的なストレージ階層を、それぞれの頻度で同期させることも可能だ。このキューの効率性により、新しい階層型ストレージ·モデルが実現する。

Delta based syncing strategies are very common in Network Management systems where devices keep a north bound management system in sync by sending deltas. The problem with a delta based approach is it’s easy for clients to get out of sync. What if changes happen at a rate faster than than deltas can be moved through the system? Or queues get full? Or the network drops updates? The client will get out of sync and it won’t even know it. Sequence numbers can be used to trigger a full sync pull if there’s an out of sync situation.

Delta ベースの同期ストラテジーは、ネットワーク・マネージメント・システムにおいて、きわめて一般的なものである。 そこでは、デバイスが Delta を送信することで、上位階層のマネージメント・システムとの同期を維持する。 Delta ベースのアプローチにおける問題点は、その同期のメカニズムから、クライアントが容易に逸脱してしまうことである。 何らかの変更が Delta よりも速く、対象となるシステムを介して移動することが、実際に起こり得るだろうか? また、キューが溢れると、どうなるだろうか? さらに言えば、ネットワーク上でアップデートが失われたら、何が起こるだろうか? いずれにせよ、クライアントは同期から逸脱し、起こっていることを知ることもできない。そのような場合には、シーケンス・ナンバーを用いる。 それにより、完全な同期を引き起こし、同期から逸脱している状況を解消できる。

It’s also good to see Facebook got rid of JSON. The amount of energy and bandwidth wasted on moving and parsing fat JSON packets is almost criminal.

Facebook が JSON から離れることは、別の観点でも歓迎すべきことだ。このような巨大なシステムが、重たい JSON パケットを解析して転送するために、膨大なエネルギーと帯域幅を消費することは、きわめて罪作りなことでもあるのだ。

ーーーーー

先日にポストした「Facebook が語るモバイル・チューニングの極意」に続いて、今回も Todd Hoff さんの記事を紹介することができました。途上国におけるモバイル通信の状況を前提とした、ストレスを最小限に抑えた環境を提供したいという、Facebook の一貫したストラテジーが見えてきますね。 ただ、これは、途上国だけの問題ではなく、たとえば日本においても、モバイル・トラフィックの大幅な削減という、大きなメリットをもたらすはずです。 そして、私たちが使用している大半のサービスは、① モバイル・デバイス、② モバイル・インターネット環境、③ バックエンド・テクノロジー、④ データセンター・インフラのバランスの上に成り立っているわけですが、とりわけ途上国においては、① と ② のケアが不可欠なのでしょう。

ーーーーー

<関連>

iOS から Android へ : Facebook は優先順位を切り替えるのか?
Facebook が キャリアの協会に参加 : 狙いは Internet.org だ!
Mark Zuckerberg と Internet.org : コネクティビティが社会経済をバランスさせる
Facebook とモバイルの巨人たちが、Internet.org を立ち上げた!
Facebook に続け : 10億に挑む Android と iOS

iOS から Android へ : Facebook は優先順位を切り替えるのか?

Posted in .Selected, Apple, Facebook, Google, Mobile, Post-PC by Agile Cat on December 9, 2014

Facebook Is Seeing More And More App Developers Go Android-First
http://wp.me/pwo1E-85q
Jim Edwards – Nov. 5, 2014
http://www.businessinsider.com/facebook-sees-android-first-app-developer-trend-2014-10?&platform=bi-androidapp

_ Business Insider

Facebook is seeing a trend in Europe of app developers going "Android-first."

Facebook は、ヨーロッパにおけるアプリ開発者の、Android-First へと移りゆく動向を注視している。

That’s significant because for years, Apple’s iOS operating system for iPhone and iPad has been the preferred first stop for any company launching an app. If an app succeeds on iOS, then only later will a company think about making a version for Android. Often months or years later, and sometimes never.

それが、大きな意味を持つのは、この数年にわたり iPhone と iPad で走る Apple の iOS が、あらたなアプリを立ち上げる、あらゆる企業が最初に取り組むプラットフォームとして、不動の地位を維持し続けてきたからである。そして、対象となるアプリ が iOS 上で成功した後にのみ、デベロッパーたちは Android バージョンを考えるというのが常である。多くの場合、それらのアプリの iOS 版と Android 版には、数ヶ月から数年の時間差があり、時には iOS のみというケースもあった。

Stephan Ridgway
Flickr, CC

That’s why Android apps tend to look and feel a bit second-rate compared to the same apps on iPhone — they often are just that. The iOS/Android split is weird because globally 80% of users are on the Android system, yet iOS and its roughly 10% of users are the top priority for developers.

そこに、Android アプリののルック&フィールが、同じアプリの iPhone の二番煎じになりやすい理由があるのだ。そして、実際に、そのようなケースが多々ある。グローバル・ユーザーの 80% が Android システムを利用している一方で、およそ 10% という iOS のシェアが、開発者にとってトップ・プライオリティになっている。 それなのに、iOS と Android のアプリを切り分けるのは、ちょっと奇妙な選択となる。

So it would be dramatic for companies to reverse that trend.

つまり、トレンドが逆転するという、ドラマティックな展開もあり得るのだ。

Yet that is what Facebook is seeing among some companies in Europe, according to Facebook’s Europe, Middle East, and Africa platform director, Julien Codorniou. Developers are beginning to sense that because more people are Android users than Apple users, they’re losing money by working on the smaller iOS platform first, he told Business Insider UK.

しかし、Facebook はヨーロッパにおいて、いくつかの企業の動きを見続けていると、同社の Europe, Middle East, and Africa Platform Director である Julien Codorniou は Business Insider UK に述べている。そして、デベロッパーたちは気付き始めているのだ。Apple ユーザーよりも Android ユーザーの方が多数を占め、また、最初に規模の小さい iOS プラットフォームに対応することで、ビジネス・チャンスを失っていることに。

Historically, Apple has been the preferred platform. Apple’s higher-income users are often more lucrative targets for app advertisers and in-app payments and shopping. It’s also simpler for developers to use, Apple has only one version of iOS running at any one time (the newest one) and the vast majority of Apple users keep their devices updated to the newest version. Android, by contrast, is "fragmented" into several different versions across hundreds of different phones — and all those versions are a headache for developers who must make a separate app tailored for each one.

歴史的にみて、Apple は好ましいプラットフォームだと捉えられている。 Apple のユーザーは高所得者に偏っているため、広告/アプリ/ショッピングを展開する際に、ビジネスのターゲットに成りやすいのである。その一方で、デベロッパーにとっても、取り組みやすい環境となっている。つまり Apple は、常に最新の iOS バージョンのみをプッシュし、大半の Apple ユーザーは最新バージョンにアップデートされたデバイスを手にしている。それとは対照的に、Android は各種のスマホ上の、各種のバージョンとして「断片化」されている。 そして、それらのバージョンごとの、個別アプリを開発する必要性が、デベロッパーにとって頭痛の種となる。

Julien Cordoniou: "People look at the numbers. They want downloads, installs. They know that the monetization is catching up on Android."

But Codorniou told us Facebook has a team of evangelists encouraging Android developers to use Facebook as a way to build and promote their apps: "As of today, I have four guys from my team in Paris talking to Android developers about the greatness of Parse, Facebook login, app links, app events. It’s a very important bet for us."

しかし、Codorniou が言うには、デベロッパーたちが自身のアプリを構築し、プロモートするための手段として Facebook を活用するよう、Android の開発環境を支援するためのエバンジェリスト・チームがあるようだ。そして、 「現時点において、4人で構成されるチームが Paris にある。そして、Parse/Facebook LogIn/App Link/App Event の素晴らしさを、Android デベロッパーたちに説明している。 それは、私たちにとって、きわめて重要な賭けである」と、私たちに語ってくれた。

Wait, Android developers? Android-first, really?

なぜ、Android デベロッパーなのか? ほんとうに、Android-First を考えているのだろうか?

"People look at the numbers," he says. "They want downloads, installs. They know that the monetization is catching up on Android. Of course iOS is the better platform when it comes to monetization, but it’s easier to update your app on Android. There are many people on an Android phone. … The world you described [in which Apple is dominant] was true a year ago, but I see that things are changing."

彼は、「 開発者たちは、数字に注目している。彼らは、数多くのダウンロードとインストールを望んでいる。そして、Android におけるマネタイズが、iOS を捕まえかけていることを知っている。もちろん、マネタイズに関しては、iOS の方が優れたプラットフォームであるが、Android アプリのアップデートも簡単になっているのだ。周知のとおり、Android フォンには、膨大なユーザー数がある。あなた方が、Apple が支配する世界と説明してきたことは、1年前には本当だったが、物事が変化していることを、私は目にしている」と述べている。

"The vision we have with Parse and with the platform in general is to accelerate the time to market. It should not take you six months to develop from iOS to Android."

そして、「Parse と汎用プラットフォームを活用する、私たちのビジョンにより、出荷までの時間が大幅に短縮される。 iOS から Android に切り替わったとしても、その開発のために、6ヶ月も要することなど、あり得ないはずだ」と、彼は続ける。

"There is a pattern coming from Eastern Europe. The Russian developers develop on Android first because of a big audience, and it maybe being easier to develop. They liked the fact that they could submit a new version of the app every day. [With Apple, you have to get each new version of the app approved before it hits the App Store. There is no version-approval system for Android.] This is a trend that I see and I think it is going to accelerate."

最後に、「 Eastern Europe で生まれた、開発のパターンがある。それは、Russian のデベロッパーたちの進め方であり、多数のユーザーがいる Android の優先順位を上げるが、おそらく容易な開発を実現している。彼らは、新しいバージョンのアプリを、毎日のようにサブミットできる状況を好んでいる。Apple の場合には、App Store に出す前に、それぞれのバージョンについて承認を得なければならない。 しかし、Android では、バージョンに関する承認の仕組みは存在しない。そこに、Android が加速している要因があると、私は見ている」と、彼は述べていた。

Do you work at an app developer that switched to go Android first? Contact Business Insider UK at jedwards@businessinsider.com to tell us your story.

ーーーーー

途上国マーケットを支援するための Internet.org を作り、貧しい人々のためにインターネット環境を整備しようとしている Facebook にとって、Android ファーストへの転換は、きわめて整合性の高い戦略となるはずです。 とは言え、Apple 自体に対してはまだしも、iOS エコシステムを構成するデベロッパーには、気遣うことになりそうですね。 また、Facebook の収益の 66% が、モバイル広告からもたらされていることを考えれば、いずれは Android ファーストになっていくのでしょう。 問題は、そのタイミングですが、いつ頃なのでしょうか? とても気になりますね。

ーーーーー

<関連>

Facebook が語るモバイル・チューニングの極意:途上国のインターネットも OK!
Facebook がビッグ・ウェーブに乗った:すでに収益の 66% はモバイルから!
FB+WhatsApp+Instagram のユーザー数は、世界の 1/3 に相当する 22億人だ!
Facebook の Graph API がアップデートされ、AD API も強化されたようだ!
Instagram が史上最大のマイグレ:200億枚のイメージを AWS から FB へ!
Facebook が買収し続けている特許の内容が、とても興味深い
Youtube と Facebook がモバイル・トラフィックの 1/3 を占有している

2014年:iOS/Android/iPad/Chromebook ごった煮 Post-PC マトメ

Posted in .Chronicle, Mobile, Post-PC by Agile Cat on December 7, 2014

アジアのマーケットを中心に、世界が回り始めた 2014年・・・
http://wp.me/pwo1E-854

今年も、いろいろと有りました! このマトメの導入部として、2013年11月29日付で Business Insider がポストした、「世界のスマホ 2013:総数の 70% 以上を Android が占有」という記事を用意しましたので、よろしければ、ご参照ください。それは、グローバルにおけるスマートフォンのインストール・ベース推定値を、オペレーティング・システムごとに算出したものであり、ちょうど1年前の時点で、15 億台のスマートフォンがグローバルで使用されていると述べています。つまり、ここが、2014年のスタート地点なのです。

  • Android のシェアが最大であり、昨年同期の 55% から、今年は 72% にまで成長している。グローバル市場における毎四半期のデータによると、Android のシェアは 80% に達しており、また、アクティブなスマートフォンの比率も上昇しているようだ。
  • インストール・ベースの二番手は iOS であり、昨年の 19% から、今年の 18% へと、その比率を下げている。
  • それに続くのが。BlackBerry OS であるが、その比率は 4% であり、昨年の 9% から大きく下げている。また、Windows Phone は、直近の四半期比較において、2.6% から 2.9% へと、若干の伸びを示している。

そして、アメリカにおいては Apple デバイスの優位性が示されているが、グローバル・マーケットになると、Android が圧倒的に強いと述べています。 その理由は、安価なデバイスが求められる China や India といった途上国市場で、Android が大きな支持を得ているからだと結論づけていますが、この傾向は 2014年を通じて変わることなく、ずっと保たれていたように思えます。

ーーーーー

01/03: iPad Pro というプロダクトは、Tablet/Laptop ハイブリッドになるのか?
01/07:
Apple App Store の年商が、ついに1兆円に到達した!
01/09:
Chromebooks:大半の Microsoft パートナーが参加する事態に!
01/10:
iPad Pro 13-inch の 勝手コンセプト・ビデオ:Youtube で ど〜ぞ!
01/10: iPad に 最強のカレンダー・アプリが登場:もちろん Google とも連携!
01/19: Apple の 2013 Q4:どれだけの iPhone を売ったのか?
01/21:
Apple の iOS in Car:画面イメージがリークされた!
02/07:
iPhone 6 を予測する、美しいデザイン・コンセプト写真を ど~ぞ!
02/07:
いまの iPhone を、1991年に戻って製造すると 3.5 億円になる!
02/07:
Android と OSS:Google の良心と公平性は、どこにあるのか?
02/10:
いまも Microsoft は、シッカリと Android で稼ぎ続けている
02/11:
iPad のシェアは、いつまでトップを維持できるのか?
02/13:
Nokia X という Android フォンのウワサ:ベトナムでは価格まで公表
02/14: Microsoft の大転換:Office for iPad が、Windows 8 版に先行するのか?
02/14: Nokia の Android フォン:生産ラインが止まらないが、事件? 予定調和?
02/14: iPhone と Android Phone の平均価格が2倍以上に開いた
02/20:
中国の 4G ユーザーは、今年中に 5000万人に届くのだろうか?
02/21:
iOS 8 のマルチ・タスクは こうなる! Youtube で、コンセプト・デモを
02/26: Mobile Security の調査:エンタープライズ と Android と フリー・アプリ
02/28: iOS in the Car:ついに Ferrari/Mercedes/Volvo への搭載が始まる!
03/18: Android Wear を Google が正式にアナウンス:Youtube で詳細を
03/27:
2015年の Android は、Windows の4倍の勢力に成長する:Gartner
03/27:
Office For iPad がリリース:Word/Excel/PowerPoint の DL は ココ!
03/31: iPhone 6 の写真がリークされた:Foxconn からのダイレクト版らしい!

 

04/04: Apple が アメリカ市場で Android のシェアを削っている
04/17:
新しい 4.7 インチの iPhone が、どれほどデカくなるのか
04/23:
iPad の成長が止まってしまった:それを示す1枚のチャート
05/02:
Apple の 投資筋が iPhone 6 を熱望する理由
05/05:
Gmail for iPhone が、かなり高速化されたようだ : さっそく DL しよう!
05/10: iOS 7.1 の DL が始まった:CarPlay/Siri/iTunes 関連などがテンコ盛!
05/11: Apple と iPhone の問題:富裕層マーケットの飽和と成長の鈍化
05/13:
iOS 8 + iPad は、スクリーン分割のマルチタスクになるのか?
05/15:
Gmail for Android のダウンロード数が、ついに 10億に達した!
05/15:
Xiaomi の Mi Pad がスゴイ! Retina + Tegra K1 で $240 だ!
05/27:
Apple は 5.5-inch の iPhone を作っているのか? 台湾からの情報を整理
05/28: iOS は 53% で Android は 166%:アプリ売上の成長率
05/30:
さぁ WWDC 2014 だ! iOS 8 だ!
05/31:
Nexus 6 は Google I/O に登場するのか? 予測される 5つの特徴!
06/02:
Samsung が Tizen スマホを WWDC に合わせて発表!
06/02:
WWDC における Tim Cook の Android 批判:誰にとってイタイ話なの?
06/06: Android KitKat のシェア: 北米では 37% まで伸びているらしい
06/21:
Nexus 9 は登場するのか? HTC の Volantis 8.9-inch が浮上してきた!
06/26: 2014年は合わせて5億台:Android One が狙う中国とインドの市場

 

07/01: Android L の狙いは バッテリー : KitKat に対して 36% 増の実行時間!
07/08: どうやら、Apple が eBay で在庫整理らしい : iPhone 6 の発売が近い?
07/08: アメリカの iOS は Android を寄せ付けない
07/09:
やっぱり、日本人は iPhone が大好きなんだ
07/13:
一眼レフを捨て iPhone に持ち替えた、アート・フォトグラファーの話し
07/15: Apple が iPhone を 死ぬほど大切にする理由
07/16:
IBM と Apple が協業をアナウンス:iPhone と iPad でエンタープライズ!
07/18: 米教育関係者:Chromebook のおかげで、全生徒にコンピューティング!
07/21: iPhone 6 のイニシャル・オーダーは、前例のない 7000〜8000万台 規模?
07/22: 中国のインターネット・ユーザー:6.3 億人に到達! Mobile が PC を逆転
07/28: iPhone の 価格は正しいの? 途上国で Android に負け続けて良いの?
07/28: Facebook Page for iPhone という、Apple にとって悩ましき存在とは?
08/04: スマホ 下克上 _1 : 中国では Xiaomi が Samsung を追い抜く
08/05:
スマホ 下克上 _2 : インドでは Micromax が Samsung を追い抜く
08/05: Android が iOS を、ついに Web トラフィックで逆転
08/12:
Acer Chromebook 13 と Tegra K1 のデュオが繰り出すハード・パンチ!
08/15: スマホの価格帯を High/Mid/Low に分けると、Apple の特殊性が見える
08/20:
iPhone 6 のデビュー予測: その週末の売上は、5年連続で記録を更新する
08/21:
ヘルスケア企業の事例:従業員たちが Chromebooks を好んで使う理由
08/22: China Telecom が目論む、世界最強の iPhone 6 とは?
08/22:
iPhone 5S は $79 で 5C は $1 だ: Walmart の在庫一斉処分!
08/27:
Android L の L は、Lemon Meringue Pie の LMP の L なのだ!
09/01: iOS 8 が実現するアプリ連携は、まるでマジックのようだ : Tester は語る
09/04: Evernote 6 for Android により、モバイル・アプリの基準が変わる
09/05:
HP の Chromebook は、Bay Trail と Nvidia K1 の二本立てになるのか?
09/08: さぁ 来い iPhone 6! Amazon Fire Phone は 99セントで対抗だ!
09/09:
iPhone 6/A8 Processor/Apple Pay/Apple Watch 速報
09/09:
あれっ? iPhone 6 の説明が 8分で終わりって記録ですよね?
09/11:
iPhone 6 が 中国マーケットで異常事態:ウラ市場では $5,000 ?
09/12:
最新の Evernote for Android が、最高にイケている!
09/14:
Google が、Android One を搭載する $100 スマホを発表した!
09/16:
iPhone 6 と Apple は、北京政府に ひじ鉄を食らってしまったのか?
09/22: iPhone 6 狂騒曲:こんなビジネスは、誰のためにもならない
09/22:
iPhone 6 と Apple : 今年もリリース時の記録は更新したが違和感が


10/06: Samsung の Q3 収益が 60% に減少:スマホ・ビジネスの利益率が低下!
10/07: 2015年 デバイス市場:中国の $1.8B に対して、インドは $4.8B の成長!
10/14:
Lollipop さんに負けた、Android L な人たちのオーディション風景
10/15:
iOS 8 のインストール率が 50% に届いていない:iOS 7 と比較!
10/16:
iPad オーナーの 約半数が、2年以上も昔のモデルを使っている
10/21:
Chromebook の販売数が急上昇:Q2 と Q3 を比較すると 67% の上昇
10/27: Android の MAU が 11.5 億に近づいている:マネタイズの視点で分析する
10/28:
Xiaomi が北京を脱出:インターナショナル・ユーザーのデータは 海外DC!
11/03:
Samsung と Apple がシェアを落とす、2014 Q3 の スマホ 攻防戦
11/12:
iOS と Android:これまでの出荷台数の推移
11/24:
急降下する Samsung のシェア:最新のスマホ勢力図
11/28:
iPhone 6 の浸透により、iPad へのニーズが殺されていく

ーーーーー

昨年末でも、強さが指摘されていた Android ですが、今年は Xiaomi や Micromax などが台頭してきたことで、低価格スマホからのプレッシャーが、さらに強まったように思えます。 この、Cloud News Asia のポストによると、来年の Samsung は、価格レンジを 30% も引き下げてくるようです。 そして、Apple は、どうするのでしょうか? 2015年も、モバイルをめぐる動きは激しそうですね!

ーーーーー

<関連>

2014年:クラウドの一年を 振り返る、チャート の マトメ
2014年:Agile Cat 日曜版の マトメ

ーーーーー

2013年 : OpenStack の マトメ
2013年 : Post-PC と 地殻変動 の マトメ
2013年 : Asia の 炸裂するパワーの マトメ
2013年 : 世界の データセンターの マトメ
2013年 : Open Compute Project の マトメ
2013年 : 日曜版 の マトメ

 

Xiaomi が北京から脱出:インターナショナル・ユーザーのデータは 海外 DC へ!

Posted in .Selected, Asia, Data Center Trends, Mobile, Post-PC by Agile Cat on December 5, 2014

Xiaomi Moves Overseas Mobile Phone Data Away From Chinese Servers
http://wp.me/pwo1E-84C

October 28, 2014 
http://www.chinatechnews.com/2014/10/28/21076-xiaomi-moves-overseas-mobile-phone-data-away-from-chinese-servers

_ China Tech News

Hugo Barra, global vice president of Xiaomi, recently issued a statement that claims Xiaomi is moving its international user data from servers in Beijing to U.S. and Singapore.

Xiaomi の Global VP dearu Huge Barra が、同社のインターナショナル・ユーザー・データを、Beijing のサーバーから U.S. および Singapore に移行しているという、ステートメントを発表した。

This is reportedly a response to previous incidents which exposed that Xiaomi smartphones automatically returned global user data to Beijing servers. Chinese telecommunications regulations require Chinese companies to store domestic data on local Chinese servers.

それは、Beijin のサーバーへ向けて、自動的に Xiaomi スマホから送信されていた、グローバル・ユーザー・データの漏洩という、最近の出来事への対応だと伝えられている。China における電気通信法では、同国内のユーザー・データに関しては、China のローカル・サーバーにストアすべきと規制されている。

Is this move by Barra enough to quell security and privacy concerns that a Chinese mobile phone company may be in cahoots with the Chinese government for harvesting global user data?

この Barra のアクションにより、グローバルにおけるユーザー・データを刈り取るために、China の政府とスマホ・メーカーが共謀しているという、セキュリティとプライバシーの懸念は、鎮静化されるのだろうか?

According to Barra the international user data migration aims to improve experience of users all over the world, cut down latency and reduce failure rates. At the same time, it will help the company maintain high privacy standards and comply with local data protection regulations.

Barra の説明によると、今回のインターナショナル・ユーザー·データの移行は、グローバルにおけるユーザー・エクスペリエンスの向上および、レイテンシの低減、障害の回避を目指すものとなる。しかし、それと同時に、高度なプライバシー基準の維持と、それぞれの国々におけるデータ保護規制の遵守にも寄与するはずだ。

Based on Xiaomi’s plans, the company will first migrate their global e-commerce platforms and user data for all international users from Beijing data centers to Amazon AWS data centers in California, U.S. and Singapore, which is expected to be completed at the end of October 2014. It will benefit users in all international markets, including Hong Kong, India, Indonesia, Malaysia, Philippines, Singapore, and Taiwan.

Xiaomi は、今回の計画に基づき、グローバルなコマース・プラットフォームとインターナショナル・ユーザー・データから、全面的な移行を開始する。それは、Beijing のデータセンターから、California, U.S. と Singapore の Amazon AWS データセンターへ向けたものであり、2014年10月末までに完了すると予測されている。 その結果として、Hong Kong/India/Indonesia/Malaysia/Philippines/Singapore/Taiwan などを含む、すべてのインターナショナル・マーケットのユーザーにメリットがもたらされる。

For the second step, Xiaomi will migrate their MIUI services and corresponding data for all international users from Beijing data centers to Amazon AWS data centers in Oregon, U.S. and Singapore, realizing the migration of Mi account, cloud messaging and Mi cloud services. The migration is expected to be completed at the end of 2014.

次のステップで Xiaomi は、すべてのインターナショナル・ユーザーのための、MIUI サービス(カスタム ROM?)と、それに対応するデータを、Beijing のデータセンターから、Oregon, U.S. と Singapore の Amazon AWS データセンターへ移行する。それにより、Mi Account/Cloud Messaging/Mi Cloud Service の移行が達成される。それらは、2014年末までに完了するという。

Finally, Xiaomi plans to improve user experience in emerging markets such as India and Brazil in 2015. Due to the lack of Amazon AWS services in those markets, Xiaomi will cooperate with local data center providers.

最後になるが、Xiaomi が意図しているのは、2015年に急成長が期待される India や Barazil での、ユーザー・エクスペリエンスの向上である。 ただし、それらの国々では、Amazon AWS のデータセンターが欠落しているため、Xiaomi 自身がローカルのデータセンター・プロバイダと協調していくことになるだろう。

ーーーーー

とても興味深い展開ですね。これまで、すべてを呑み込んできた中国市場から、今度は外へと飛び出す企業が出てきたわけです。 この背景には、いわゆるバック・ドア問題が有ったわけですが、Xiaomi としては潔白を証明したいのでしょうし、北京政府としても同社のグローバル化を妨げることが、中国のためにならないと判断しているのでしょう。 GOOD ですね!

ーーーーー

<関連>

中国の Xiaomi App Store が、10億ダウンロード を 1年で達成
Xiaomi の Mi Pad がスゴイ! Retina + Tegra K1 で $240 だ!
スマホ 下克上 _1 : 中国では Xiaomi が Samsung を追い抜く
Apple と China Telecom :中国人ユーザーのデータは、中国本土の DC へ
Apple と China Mobile が合意 : 7億人の中国市場に iPhone がリーチする!

Facebook が語るモバイル・チューニングの極意:これで途上国のインターネットも OK!

Posted in .Selected, DevOps, Facebook, Mobile, Network, Post-PC, Strategy by Agile Cat on December 2, 2014

How Facebook Makes Mobile Work at Scale for All Phones, on All Screens, on All Networks
http://wp.me/pwo1E-84k
September 22, 2014 – ImageTodd Hoff
http://highscalability.com/blog/2014/9/22/how-facebook-makes-mobile-work-at-scale-for-all-phones-on-al.html

When you find your mobile application that ran fine in the US is slow in other countries, how do you fix it? That’s a problem Facebook talks about in a couple of enlightening videos from the @scale conference. Since mobile is eating the world, this is the sort of thing you need to consider with your own apps.

アメリカ国内では快適に走るモバイル・アプリが、その他の国では遅くなると分かったとき、どのように修正すればよいのだろう?それは、@scale conference における何本かのビデオで、Facebook が指摘している問題である。そして、この世界をモバイルが呑み込んで以来、あらゆるアプリにおいて考察すべき、ある種の問題でもある。

<関連> Facebook アプリ:Push + Delta + Thrift でモバイル帯域を 40% も削減!

In the US we may complain about our mobile networks, but that’s more #firstworldproblems talk than reality. Mobile networks in other countries can be much slower and cost a lot more. This is the conclusion from Chris Marra, Project Manager at Facebook, in a really interesting talk titled Developing Android Apps for Emerging Market.

アメリカにおいても、私たちはモバイル・ネットワークに文句を言うだろうが、Twitter の #firstworldproblems で語られていることが真実だ。その他の国々におけるモバイル・ネットワークは、はるかに遅いものであり、また、より多くの費用がかかる。以下に示すのは、Developing Android Apps for Emerging Market という興味深いタイトルの講演の中で、Facebook の Project Manager である Chris Marra が結論づけたものである。

Facebook found in the US there’s 70.6% 3G penetration with 280ms average latency. In India there’s 6.9% 3G penetration with 500ms latency. In Brazil there’s 38.6% 3G penetration with more than 850ms average latency.

Facebook が調べた結果によると、アメリカにおける 3G の浸透率は 70.6% であり、レイテンシは 280ms である。それがインドとなると、3G の普及率は 6.9% であり、レイテンシ は 500ms になる。そしてブラジルの場合は、38.6% と 850ms だ。

Chris also talked about Facebook’s comprehensive research on who uses Facebook and what kind of phones they use. In summary they found not everyone is on a fast phone, not everyone has a large screen, and not everyone is on a fast network.

さらに Chris は、Facebook のユーザーである人々および、そこで用いられるスマホに関して、同社が実施している包括的な調査についても話してくれた。要約すると、誰もが高性能のスマホを使い、大きなスクリーンを持ち、高速のネットワークを使用できると思ったら、それは大きな間違いということだ。

It turns out the typical phone used by Facebook users is from circa 2011, dual core, with less than 1GB of RAM. By designing for a high end phone Facebook found all their low end users, which is the typical user, had poor user experiences.

その結果として、Facebook ユーザーが使用する典型的なスマホは、2011年頃のモデルから始まり、Dual-Core の CPIU を搭載し、RAM は 1GB 以下ということが分かってきた。 ハイエンド・スマホに合わせてデザインしてきた Facebook は、ローエンドのデバイスを持つユーザーが大半であり、そのすべてがプアなユーザー・エクスペリエンスを持つことを理解した。

For the slow phone problem Facebook created a separate application that used lighter weight animations and other strategies to work on lower end phones. For the small screen problem Facebook designers made sure applications were functional at different screen sizes.

Facebook は性能の低いスマホのために、軽いアニメーションなどの戦略を適用するために、使別のアプリを作成した。また、同社のデザイナーたちは、小さなスクリーンという問題に対処するために、異なる画面サイズであっても、機能的にアプリが振る舞えるようにしていった。

Facebook has moved to a product organization. A single vertical group is responsible for producing a particular product rather than having, for example, an Android team try to create all Android products. There’s also a horizontally focussed Android team trying to figure out best practices for Android, delving deep into the details of what makes a platform tick.

つまり、Facebook 自身が、プロダクトを構築するための組織に転身しているのだ。例を挙げるなら、すべての Android プロダクツを、そのためのチームが開発するのではなく、特定のプロダクトを構築するために、垂直方向へと問題を掘り下げていくグループに責任が振り分けられている。ただし、プラットフォームに適合するものを詳細まで踏み込み、Android のためにベスト・プラクティスを把握していく、水平方向に焦点を当てた Androidチームも存在する。

Each team is responsible for the end-to-end performance and reliability for their product. There are also core teams looking at and analyzing general performance problems and helping where needed to improve performance.

そして、個々のチームが自身のプロダクトに関して、その性能と信頼性を隅から隅まで担当することになる。さらに、コアとなるチームが、全体的なパフォーマンスの問題を分析し、それを向上させるために必要な支援を行う。

Both core teams and product teams are needed. The core team is really good at instrumentation and identifying problems and working with product teams to fix them. For mobile it’s important that each team owns their full product end-to-end. Owning core engagement metrics, core reliability, and core performance metrics including daily usage, cold start times, and reliability, while also knowing how to fix problems.

コアとプロダクトの、双方のチームが必要とされている。コア・チームは、適切に測定を行い、問題を特定し、それらを修正するために、プロダクト・チームと協調していく。モバイル開発において重要な事は、それぞれのチームが自身のプロダクトについて、隅から隅まで責任を負うことである。また、コアとしての共有メトリクス/信頼性/性能の指標を確立し、そこにアプリを立ち上げたときや、連続して使用したときの、信頼性を加える一方で、問題の解決方式を認識していく。

To solve the slow network problem there’s a whole other talk. This time the talk is given by Andrew Rogers, Engineering Manager at Facebook, and it’s titled Tuning Facebook for Constrained Networks. Andrew talks about three methods to help deal with network problems: Image Download Sizes, Network Quality Detection, Prefetching Content.

低速のネットワークに関連する問題を解決するという、包括的なテーマがある。今回は、Facebook の Engineering Manager である Andrew Rogers の、Tuning Facebook for Constrained Networks というタイトルが付けられたトークを紹介したい。Andrew の話は、ネットワークに関連する問題を解決する、Image Download Sizes/Network Quality Detection/Prefetching Content という、3つの方法論に集約される。

Overall, please note the immense effort that is required to operate at Facebook scale. Not only do you have different phones like Android and iOS, you have different segments within each type of phone you must code and design for. This is crazy hard to do.

総論として、Facebook のスケールで運用するには、膨大な労力が要求される点に注意してくほしい。そこには、Android と iOS といったモバイルの種別だけではなく、それぞれのデバイスごとのセグメントがあり、それに対してコーディングしていく必要があるのだ。それを実践していくことは、まさしくクレイジーである。

Reducing Image Sizes -  WebP saved over 30% JPEG, 80% over PNG

  • Image data dominates the number bytes that are downloaded from Facebook applications. Accounts for 85% of total data download in Facebook for Android and 65% in Messenger.
  • イメージ・データは、Facebook アプリにダウンロードされる、バイトの大半を占める。 Android 用の Facebook においては、全ダウンロード・データの 85% を占め、Messenger では 65% を占めている。
  • Reducing image sizes would reduce the amount of data downloaded and result in quicker downloads, especially on high latency networks (which we learned were typical).
  • イメージ・サイズを削減すれば、ダウンロードされるデータの量が低減され、より迅速なダウンロードが達成されるだろう。それは、高レイテンシのネットワークにおいて、特に有効な手段となる(そこから、私たちは学んだ)。
  • Request an appropriate image size for the viewport
  • 表示環境にあわせた、適切なサイズのイメージを要求する。
  • Resize on the server. Don’t send a large image to the client and then have the client scale the image down to a smaller size. This wastes a lot of bandwidth and takes a lot of time.
  • サーバー上で、イメージのサイズを変更する。クライアントへ向けて大きなイメージを送信し、クライアント側でイメージを小さくするという手法を取ってはならない。 そのような方式だと、大量の帯域幅を無駄にし、長時間を要することになる。
  • Send a thumbnail (for profile pictures) and a small preview image (this is seen in the newsfeed), and then a full image (seen in photo stories) when a user asks to zoom in it. A low-res phone may never need a full image. Most of the time a thumbnail and a small preview is all you need.
  • サムネイル(画像のサムネイル)と、小さなプレビュー・イメージ(例 NewsFeed)を送信し、ユーザーが拡大を要求したときに、フル・イメージを送信する(例 Photo Story)。低解像度のスマホの場合は、フル・イメージが不要かもしれない。また、大半のケースにおいて、サムネイルとプレビューで、すべての要求に応えられる。
  • Significant savings. Scaling a 960 pixel image that is 79KB is size to 240 pixels wide yields a 86% size reduction, to 480 pixels is a 58% size reduction, to 720 pixels is at 23% size reduction.
  • データ転送量を、大幅に削減できる。たとえば、960 pixel スケールのイメージは 79KB であるが、240 pixel なら 86%、480 pixel なら 58%、720 pixel なら 23% の削減が達成される。
  • With screen sizes becoming larger scaling images isn’t as effective as it used to be. Still worth doing, but the payoff isn’t as much.
  • スクリーン・サイズより大きなイメージを、効果的に利用できるケースはほとんど無い。何らかの価値があるかもしれないが、その代償は大きい。
  • Change the image format
  • イメージ・フォーマットの刷新
  • 90% of images sent to Facebook and Messenger for Android use the WebP format.
  • Android 用の Facebook および Messenger では、90% のイメージで WebP フォーマットが用いられている。
  • WebP format released by Google in 2010.
  • WebP フォーマットとは、Google が 2010年にリリースしたものである。
  • WebP saves 7% download size over JPEG for equivalent quality.
  • WebP は、同品質の JPEG に対して、7% のサイズ圧縮を実現にする。
  • WebP saved over 30% download size over JPEG by tuning quality and compression parameters with no noticeable quality differences. A big savings.
  • WebP は、画質チューニングと圧縮パラメータにより、JPEG に対して 30% のデータ削減を可能にするが、視覚的な劣化は生じない。 それにより、ダウンロード・サイズを大幅に削減できる。
  • WebP also supports transparency and animation, which is useful for their Stickers product.
  • さらに WebP は、透過性とアニメーションをサポートするため、Sticker などのプロダクトに適している。
  • WebP saves 80% over PNG.
  • WebP は PNG の 80% に、データ量を低減する。
  • For older versions of Android the images are transported using WebP but transcoded on the client to JPEG for rendering on the device.
  • Android の古いバージョン用のイメージは、WebP を使って転送されるが、レンダリングのためにクライアント上で JPEG に変換される。

Network Quality Detection – Adjust Behavior to Network Quality

  • On the same network technology 2G, 3G, LTE, WiFi, connections speeds in the US were 2-3x faster than in India and Brazil.
  • 2G, 3G, LTE, WiFi といった、それぞれのネットワーク・テクノロジーにおいて、India や Brazil に対して U.S. は、2倍〜3倍の接続速度を有する。
  • LTE is often faster than WiFi, so you can’t just base the connection speed on technology.
  • 大半のケースにおいて、LTE は WiFi より高速であるため、テクノロジーの接続速度を論拠にはできない。
  • Built into the client the ability to:
  • Measure throughput on all large network transfers
  • 以下の機能を、クライアント内に作り込む:
  • 大規模ネットワークを通過する際のスループットを測定する。
  • Facebook servers provide a Round Trip Time (RTT) estimate in the HTTP header in every response
  • Facebook のサーバーは、すべてのレスポンスにおける HTTP ヘッダー内で、Round Trip Time (RTT) 推定値を提供している。
  • The client maintains a moving average of throughput and RTT times to determine network quality.
  • そのため、クライアントは、ネットワーク品質を判断するために、変動するスループットと RTT 時間の、平均値を保持できる。
  • Connections are bucketized into the following groups: Poor is < 150kbps. Moderate is 150-600kbps. Good is 600-2000kbps. Excellent is > 2000kbps.
  • 接続スピードは、以下のグループに分類される:Poor 150kbps 以下:Moderate 150〜600kbps:Good 600〜2000kbps:Excellent 2000kbps 以上。
  • Feature developers can adjust their behavior depending on the connection quality.
  • それらの接続品質に応じて、それぞれの機能の振る舞いを適正化していく。
  • Some possible responses based on quality:
  • その通信品質に基づき、いくつかの対策がある:
  • Increase/decrease compression.
  • Issue more/fewer parallel network requests. Don’t saturate the network.
  • 圧縮比の増減。
  • 並列ネットワーク・リクエストの増減。それにより、ネットワークをサチらせない。
  • Disable/enable auto-play video. Don’t cause more traffic on slow networks.
  • ビデオ自動再生の ON/OFF。 低速ネットワークでは、大量のトラフィックを要求しないようにする。
  • Pre-fetch more content.
  • より多くのコンテントを、プリ・フェッチする。
  • A tool developed at Facebook called Air Traffic Control supports the simulation of different traffic profiles. Each profile can be configured: bandwidth, packet loss, packet loss-correlation, delay, delay correlation, delay jitter. Extremely helpful in finding unexpected behaviour on slow networks.
  • Facebook では、内製のツールである Air Traffic Control により、各種のトラフィック・プロファイルのシミュレーションを行なっている。それそれのプロファイルは、帯域幅/パケット損失/パケット損失相関/遅延/遅延相関/遅延ジッタなどで構成されている。低速のネットワーク上で、予期できない動作などを見つけるのに、きわめて便利である。
  • There are buckets for videos, but not sure what they are.
  • ビデオ・トラフィックに関しては、その内容が不明である。

Prefetching Content

  • Issuing network requests for content ahead of when the content is actually needed on the device.
  • 実際にデバイスでコンテントが必要になる前に、ネットワーク・リクエストを発行する。
  • Prefetching is especially important on networks with high latency. Waiting to issue a download request for an image the user will be looking at a blank screen.
  • プリ・フェッチングは、とりわけ高レイテンシのネットワークで重要となる。イメージをダウンロードするリクエスト発行を待っているのでは、ユーザーにブランクの画面を見せることになる。
  • Issue network requests for feeds early in the app startup process so the data will be present when the feed is displayed to the user.  The download can occur in parallel with other initialization tasks.
  • アプリ起動プロセスで、フィードの先頭へのネットワーク・リクエストが発行されていれば、ユーザーに対して表示するときに、すでにフィードの準備が整うことになる。このダウンロードは、他のイニシャル・タスクと並行して、引き起こすことが可能である。
  • Keep a priority queue of network requests. Don’t block foreground network requests on background network requests or the user won’t see the data they are currently interested in.
  • ネットワーク・リクエストの、プライオリティ・キューを維持する。バックグラウンドのネットワーク・リクエストにより、フォアグラウンドのネットワーク・リクエストをブロックしてはならない。また、ユーザーが興味を持っているデータを、見せないような状況も避けるべきだ。
  • Monitor for overfetching and excess consumption of device resources. Over fetching could fill up the disk or waste a lot of money on the user’s data plan.
  • 過剰なフェッチングとデバイス·リソース消費をモニタリングする。フェッチングが行き過ぎると、全体的なディスク容量が不足し、また、データ・プランによっては、ユーザーのコストを増大させる。

Miscellaneous

  • Client uploading to servers. The idea is to send fewer bytes over the wire from the client to the server, which means resizing images on the client side before they are sent to the server. If an upload fails retry quickly. It’s usually just a problem in the pipe.
  • クライアントからサーバーへのアップロードに関しても、サーバーに送信する前にクライアント側でイメージをリサイズし、データ転送量を低減すべきである。アップロードに失敗した場合は、速やかに再試実行する。 一般的に、この問題はパイプ内のもとと認識すべきだ。
  • There are 20 different APKs (Android application package) for the Facebook app, cut by API level, screen size, and processor architecture.
  • Facebook アプリ用として、20種類の APK(Android Application Package)が存在する。 具体的に言うと、API レベルや、スクリーン・サイズ、プロセッサ・アーキテクチャなどにより分類されている。

Related Articles

Update: Instagram Improved Their App’s Performance. Here’s How.

ーーーーー

この長い記事を訳しながら、似ているなぁと思い始めてきたのが、Google の Street View 撮影部隊の話です。 どちらも、データセンターに積み上げたコンピューティング・パワーや、優秀な頭脳から生み出されるアルゴリズムでは解決の出来ない、労力と根気の世界の話です。 とは言え、このような労働集約型の作業に、膨大なリソースを投じるには、その正当性を裏付けるだけのストラテジーが必要です。 言い換えれば、途上国のマーケットに賭ける、Facebook の強い思いが生み出した唯一無二の方法論が、そこにあるはずなのです。 そして、そのノウハウを、こうして開示してくれる Facebook と、分かり易く整理してくれた Todd Hoff さんに感謝です。すばらしい!

ーーーーー

<関連>

FB+WhatsApp+Instagram のユーザー数は、世界の 1/3 に相当する 22億人だ!
Facebook の Graph API がアップデートされ、AD API も強化されたようだ!
Instagram が史上最大のマイグレ:200億枚のイメージを AWS から FB へ!
Facebook が買収し続けている特許の内容が、とても興味深い
Youtube と Facebook がモバイル・トラフィックの 1/3 を占有している

%d bloggers like this: