Why Mobile Platforms Diverge: Lessons from Renren’s Cross‑Platform Journey

Introduction

The evolution of mobile operating platforms mirrors the development of mobile terminals, which can be divided into four stages: (1) functional terminals for basic calls and SMS, (2) smart terminals that support third‑party apps and web browsing, (3) internet‑centric platforms where phones become full‑featured platforms (iPhone, Android, Windows Phone 7), and (4) the future IoT‑enabled smart terminal.

Major Mobile Platforms

Six mainstream platforms are discussed:

Symbian : once dominant due to low price, ease of use, and Nokia’s brand, but threatened by Android and iPhone and likely to be replaced.

Android : overtook Symbian as the largest smartphone platform; open‑source nature enables customization but creates fragmentation and compatibility challenges.

iPhone OS : high‑end market leader with polished UI and rich app ecosystem; growth depends on Apple hardware adoption.

Windows Mobile : lagging behind in UI, usability, and app support.

MTK : closed environment targeting low‑end devices; limited third‑party apps.

WP7 : Microsoft‑Nokia collaboration aiming for a three‑way market balance.

Renren’s Early Mobile Effort

In late 2008 Renren (then 校内网) began a JavaME client to bring its SNS services to phones. The team selected a multi‑tab UI to expose core features (news feed, profile, friends, messages). The first version failed due to navigation issues, memory constraints, and lack of a browser‑like back‑stack.

Browser Engine “Across”

To solve navigation problems, Renren built a JavaME‑based browser engine called Across, loosely based on WebKit. The architecture (shown in the original diagram) separated rendering from JavaScript/CSS/plug‑ins. Although functional, the engine consumed 8‑10× memory of the source XHTML and produced a 200 KB package, making it unsuitable for JavaME devices. The project was abandoned after Android 1.5 and iPhone entered the market.

Rethinking Architecture

Renren realized that a unified architecture was needed because its services were heavily web‑based and constantly evolving. Rather than a full browser, the team adopted a tab‑plus‑independent view‑stack model inspired by iPhone and Facebook, where each tab maintains its own navigation stack, allowing seamless back navigation without switching tabs.

Unified UI Design Across Platforms

The tab‑plus‑view‑stack approach was implemented on JavaME, iPhone, and Android clients, providing a consistent navigation experience despite differing programming languages (Java, Objective‑C, C++, C#).

Server‑Side Architecture

Renren’s backend relies on a JavaEE stack:

WEB layer: REST‑style MVC built on a custom framework Rose (based on Spring) that supports controller conventions and REST URLs. The framework is open‑source at http://code.google.com/p/paoding-rose/.

Business layer: SOA framework XOA built on Rose and Netty, exposing resources via URLs such as xoa://blog.xoa.renren.com/photo/{user-id}/{photo-id}. XOA supports remote calls and horizontal scaling.

Data‑access layer: JADE ORM (Java Database Engine) with horizontal sharding, also open‑source.

Persistence layer: MySQL for relational data and a custom key‑value store called Nuclear, which can use MySQL, Memory, Cassandra, TC, or Redis as storage engines.

High‑performance services are built on XOA (using Google SPDY over Netty) and ICE (C++ framework) for latency‑sensitive tasks such as search and friend‑graph calculations. Memcached pools provide distributed caching, and the HTTP layer runs on Resin with load balancing via F5 or Nginx. All web servers are stateless to avoid session replication.

Mobile‑Specific Optimizations

The API layer serves JSON (and optionally Google Protocol Buffers) over HTTP, compresses responses with gzip, and aggregates multiple calls into a single batch to reduce TCP handshakes. Low‑end devices receive lightweight payloads, and server‑side processing handles heavy tasks like image resizing.

Conclusion

Renren’s experience illustrates the rapid shifts in mobile platforms, the trade‑offs between native development and cross‑platform solutions, and the necessity of a scalable, high‑performance backend to support billions of daily requests.