Mobile Development 22 min read

Redesign of 58 APP Android Home Page: Architecture, Componentization, and Performance Optimizations

This article details the redesign of the 58 APP Android home page (version 9.0), covering overall UI and data module architecture, component design inspired by fragments, handling of search bar animations, fling behavior, performance optimizations, and lessons learned from the development process.

58 Tech
58 Tech
58 Tech
Redesign of 58 APP Android Home Page: Architecture, Componentization, and Performance Optimizations

In the later stage of the internet era, user growth slows down and extracting value from traffic becomes critical. 58APP, after years of accumulation, found that a single‑dimension experience could no longer meet rising user expectations, prompting the product and design teams to launch a Home‑page 9.0 redesign with the strategic goal of “knowing what you need and giving you what you want”.

Overall Design

We analyzed the old home page and split it into UI and data modules. The UI module still uses AppBarLayout+ViewPager but adds a framework to support dynamic templates. The data module builds on the previous version and adds pre‑loading capabilities.

1.1 UI Module

The 58APP home page aggregates entry points for various business modules, core services, and personalized recommendations, making it a complex screen. To achieve maintainability and low coupling, we componentized the UI logic, separating component boundaries and responsibilities.

1.2 Component Design

Inspired by Android’s Fragment design, each component contains a data bean, a view, and binding logic. The component is defined as a container without enforcing a specific architectural pattern (MVC/MVP/MVVM), allowing teams to choose the most suitable one.

1.3 Data Module

The home page consumes four interfaces: configuration, content, feed, and notification data. After redesign the data module provides:

Built‑in caching : unified local cache with whitelist strategy to avoid waste and improve cache effectiveness.

Pre‑loading : data is parsed and stored in memory before the UI appears, dramatically reducing white‑page time.

Fault tolerance : field‑level error handling prevents a single malformed field from crashing the whole page.

Interface integration : a unified Observable ‑based API with priority‑based thread‑pool requests ensures consistent, accurate data delivery.

2. Difficult Problems and Solutions

2.1 Search Bar Animation

When the list scrolls to the icon area, the sticky search bar slides in/out. Challenges include synchronizing list scroll offset, locating the icon region, adapting to notch screens, and keeping the inner and sticky search bars in sync.

We obtain the list’s offset via AppBarLayout ’s offset listener and propagate it to the search bar. Android view coordinates ( left, top, right, bottom or x, y, translationX, translationY ) are used to drive the animation.

int left = getLeft();
int top = getTop();
int right = getRight();
int bottom = getBottom();

For notch adaptation we add the status‑bar height to the sticky bar’s height:

@Override
protected void onFinishInflate() {
super.onFinishInflate();
int statusBarHeight = StatusBarUtil.getStatusBarHeight(getContext());
setPadding(0, statusBarHeight, 0, 0);
stickSearchHeight = HolderUtils.getSearchHeight(getContext()) + statusBarHeight;
}

2.2 Tribe Entry Animation

Two effects are shown: a marquee‑style text scroll and a bubble animation for avatars. The bubble effect is implemented with a quadratic Bézier evaluator and an AnimatorUpdateListener that updates the view’s x and y coordinates.

private class BezierEvaluator implements TypeEvaluator
{
private PointF controlPoint;
public BezierEvaluator(PointF pointF) { this.controlPoint = pointF; }
@Override
public PointF evaluate(float fraction, PointF startValue, PointF endValue) {
float oneMinusT = 1.0f - fraction;
PointF point = new PointF();
point.x = oneMinusT * oneMinusT * (startValue.x) + 2 * oneMinusT * fraction * (controlPoint.x) + fraction * fraction * (endValue.x);
point.y = oneMinusT * oneMinusT * (startValue.y) + 2 * oneMinusT * fraction * (controlPoint.y) + fraction * fraction * (endValue.y);
return point;
}
}
private class BezierListener implements ValueAnimator.AnimatorUpdateListener {
private View target;
public void setTarget(View target) { this.target = target; }
@Override
public void onAnimationUpdate(ValueAnimator animation) {
if (target == null) return;
PointF pointF = (PointF) animation.getAnimatedValue();
target.setX(pointF.x);
target.setY(pointF.y);
}
}

2.3 AppBarLayout & RecyclerView Fling Connection

The old version stopped abruptly when the AppBarLayout reached its bottom. By analyzing the source we discovered that the fling is handled by AppBarLayout.Behavior using an OverScroller , and the fling does not propagate to the nested RecyclerView .

case MotionEvent.ACTION_UP:
if (mVelocityTracker != null) {
mVelocityTracker.addMovement(ev);
mVelocityTracker.computeCurrentVelocity(1000);
float yvel = mVelocityTracker.getYVelocity(mActivePointerId);
fling(parent, child, -getScrollRangeForDragFling(child), 0, yvel);
}

We modified the fling logic to use Integer.MIN_VALUE for upward flings, extending the fling distance, and then manually triggered scrolling on the target RecyclerView via scrollToPositionWithOffset .

int fixedMin = velocityY < 0 ? Integer.MIN_VALUE : minOffset;
mScroller.fling(0, getTopAndBottomOffset(), 0, Math.round(velocityY), 0, 0, fixedMin, maxOffset);

3. Performance Optimization

To keep up with rapid product iteration, core pages remain native for superior performance. We focused on FPS during fast scrolling, image caching, and data‑point logging.

3.1 FPS Improvement on Low‑End Devices

By reducing CPU load and optimizing algorithms, the new home page maintains >40 FPS on low‑end phones, compared with <20 FPS on the old version.

3.2 Image Cache Optimization

Using Fresco’s pause‑while‑scrolling feature, image loading is deferred during fast scrolls, dramatically improving FPS on low‑spec devices.

3.3 Data Cache Optimization

Event‑tracking data is pre‑computed and cached, allowing the scroll listener to read from memory instead of performing heavy calculations for each of the hundreds of points generated per swipe.

4. Takeaways

The redesign yielded both technical and methodological insights. Technically, componentization, unified data handling, and performance tuning proved effective. Methodologically, the iterative exploration process reinforced the importance of continuous learning and adaptation in fast‑moving product environments.

From an operational perspective, the new home page achieved the “knowing what you need, giving you what you want” goal, helping users find services faster and reinforcing the mission of simplifying life.

Author Bio

Kong Xiaojun, Liu Yuanliang, Zhang Zhixin, Zeng Peng – Android engineers in the Front‑End Technology Department.

Recommended Reading

How to Use App Factory for Innovative Apps

58 City AI Algorithm Competition Open Registration

Dynamic Framework Practice and Thoughts on 58App Android

PerformanceuiAndroidcomponentizationHomePageAppBarLayout
58 Tech
Written by

58 Tech

Official tech channel of 58, a platform for tech innovation, sharing, and communication.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.