Besides the CPU, many users consider RAM size when buying a phone. Different RAM configurations come with different prices—but how much RAM do you actually need? How does Android manage its memory? Average users are often confused: How much RAM does this app use? How much does the system use? How does RAM affect my experience? And how much RAM should my next phone have?
A common question on Zhihu is: “Does the Android system not release memory?”. It’s not that the user doesn’t know the system releases memory, but rather they want to understand the mechanics to optimize their experience. In this article, I’ll address these user concerns. More technical details will be covered in later articles.
Version note — reviewed October 13, 2026: This article was written in 2018. Device examples, app experiences, and vendor opinions describe that period; the old hardware rankings and buying advice are outdated. Technical corrections and updates identify their Android versions. These are not new measurements of the named products.
I’ve long wanted to write about Android system fluency because it’s the most direct aspect of the user experience. The long-standing criticism that Android “gets laggier over time” still casts a shadow over the platform, and it’s a primary reason many users default to iPhone.
Because Google keeps Android open, different manufacturers produce devices with vastly different hardware, and app quality varies wildly. Consequently, fluency is affected by countless factors. It’s rarely just “the system isn’t optimized.” Often, two devices with the same OS but different SOCs offer completely different experiences.
I want to talk through some of the reasons Android can feel slow, so that the next time it happens, we don’t immediately blame the system. Perhaps uninstalling one app will turn out to be enough. Here are the areas I want to cover:
- Hardware
- System
- Applications
- The Optimization Loop
Ready? Let’s get started, and please join the discussion.
It’s often said that the overall iOS experience is superior to Android. This is partly due to third-party software quality (iOS versions are often more polished) and partly due to Apple’s tight control over its ecosystem. To get on the App Store, you must pass rigorous reviews.
Today we look at the system-provided transition before app content is ready: Android’s StartingWindow and iOS’s Launch Screen. Neither is the same as an advertising Activity or business home screen rendered by the app.
I originally wrote that iOS required a single image. I was wrong about that. Xcode 6 release notes document XIB/Storyboard launch screens from iOS 8. They provide early feedback, not a guaranteed zero-delay timestamp. Older Android theme paths allowed customization, disabled previews, and translucent windows; behavior depends on the OS version.
This article records the essential knowledge for Android performance optimization (mainly including outstanding articles, WeChat accounts, blogs, and technical teams), covering all aspects of performance optimization. This post will be continuously updated; personal recommendations are welcome.
2017 slipped by before I knew it, and I haven’t updated the blog in ages. Partly, the more I learn, the less I feel I know, and I worry about misleading readers with a technical post. Partly, I’m just lazy. So I’ve decided this blog doesn’t have to be all technical articles. I’ll also write about things that matter to me and thoughts I want to keep. It’s a record for myself; if someone else finds it useful, even better. (Not that there are many readers…)
With 2017 just behind us, I wanted to share the things I enjoyed using or found helpful at work and at home. Maybe some will be useful to you in 2018. There are apps, hardware, books, and exercise equipment here. These are my picks; what worked for me may not work for you. Right, on to the list.
2017 has passed before we knew it. The blog hasn’t been updated for a while - one reason is that I increasingly realize how shallow my knowledge is and fear that writing about technical topics might mislead readers, and another reason is simply that I’ve been too lazy. Given these two reasons, I’ve decided that blog updates no longer need to be limited to technical articles - things I find meaningful, thoughts, and reflections will also be shared here. On one hand, it serves as my own record, and if it happens to help readers along the way, that would be even better (though there aren’t many readers anyway…).
Since 2017 has just passed, I feel it’s necessary to recommend to everyone the things that I found to be great experiences or very helpful for work and life in 2017 - perhaps you’ll need them in 2018. The recommendations include Apps, hardware, books, equipment, etc. It should be noted that these are things that brought me great help in 2017 - what works for me may not work for you. Without further ado, let’s get into it!
In the blink of an eye, it’s 2017. I’ve been working for nearly four years. I went to school in Weihai in 2009, started my internship in Shanghai in 2012, stayed in Shanghai after graduating in 2013, joined Meizu in Zhuhai in 2014, and have been here ever since.
I’ve been writing on this blog since graduation—writing, deleting, and rewriting—recording my journey from App development to System App development, and finally to System Framework development. Looking back after a few years is a great way to appreciate how far I’ve come.
This post records my thoughts on my blog, my job, my work habits, and my expectations for 2017. It’s a mix of confusion and ambition.
We are already 30% through 2017. I hope it’s not too late to share this.
In March 2016, Google added Bottom Navigation to its design guidelines. This release was quite surprising to many, as Bottom Navigation hadn’t been mentioned in previous Material Design iterations. Bottom tab bars were common in iOS apps, while older Android guidance discouraged them. These were design recommendations, not platform limitations or a requirement for every iOS app.
This is the second article in a series on Android Bottom Navigation, covering style, behavior, and dimensions.
In March 2016, Google added Bottom Navigation to its design guidelines. This release was quite surprising to many, as Bottom Navigation hadn’t been mentioned in previous Material Design iterations. Bottom tab bars were common in iOS apps, while older Android guidance discouraged them. These were design recommendations, not platform limitations or a requirement for every iOS app.
This is the first article in a series on Android Bottom Navigation, covering its usage and historical evolution.
Someone recently asked on Zhihu: “How to calculate APK startup time?”
“How can I use Python or direct ADB commands to calculate APK startup time? I want to measure the time from clicking the icon to the APK being fully started. For example, in a game, this would be from the icon tap to entering the login screen. Existing methods like
adb shell am start -WprovideThisTimeandTotalTime, but I’m unsure of the difference and they don’t seem to match visual reality.”
My colleague Guo Qifa and I answered different parts of the question. With his permission, I put our answers together here: partly so I could find them again, and partly to make them easier for other developers to find outside Zhihu.