This is the third post in the reading notes series for The Programmer’s Apprenticeship: From Good to Great. The author, Jeff Atwood, is one of the founders of Stack Overflow. His articles cover a wide range of topics. He is a seasoned programmer, manager, and entrepreneur. This book discusses man...
This is the second post in the reading notes series for The Programmer’s Apprenticeship: From Good to Great. The author, Jeff Atwood, is one of the founders of Stack Overflow. His articles cover a wide range of topics. He is a seasoned programmer, manager, and entrepreneur. This book discusses ma...
This is the first post in the reading notes series for The Programmer’s Apprenticeship: From Good to Great (a compilation of Jeff Atwood’s posts). The author, Jeff Atwood, is one of the founders of Stack Overflow. His articles cover a wide range of topics. He is a seasoned programmer, manager, an...
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.
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.
In this post, I want to discuss the factors affecting Android fluency from several perspectives:
- Hardware
- System
- Applications
- The Optimization Loop
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’ll discuss a major differentiator between iOS and Android: the StartingWindow (colloquially, the Splash Screen). While both systems have them, their implementations vary wildly. iOS requires a StartingWindow—usually a static image—that displays immediately upon an icon tap with zero delay. Android, being open, allows developers to customize, disable, or even make the StartingWindow transparent.
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 has unknowingly passed, and the blog hasn’t been updated for a long time. One reason is that I increasingly feel my knowledge is shallow, fearing I might mislead everyone with technical articles; another reason is that I’m too lazy. Given these two reasons, I decided that this blog’s updates should no longer be limited to technical articles—some meaningful things, thoughts, etc., will also be updated here. On one hand, this is a record for myself; if it can also bring some help to readers along the way, that would naturally be the best (although there aren’t many readers…)
Since 2017 has just passed, I feel it’s necessary to recommend to everyone the things that I think had excellent experiences in 2017 or were very helpful to my work life—perhaps you’ll need them in 2018. The recommended content includes apps, hardware, books, equipment, etc. It should be noted that these are things that brought me great help in 2017, which might not necessarily suit you. Let’s not say too much, let’s get straight to the content!
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.
One day in March, Google updated its design guidelines with a new component: Bottom Navigation. This release was quite surprising to many, as Bottom Navigation hadn’t been mentioned in previous Material Design iterations. Traditionally, one of the biggest differences between Android and iOS design was the use of bottom bars; while they were essential for iOS, Android apps following MD guidelines generally avoided them.
This is the second article in a series on Android Bottom Navigation, covering style, behavior, and dimensions.
One day in March, Google updated its design guidelines with a new component: Bottom Navigation. This release was quite surprising to many, as Bottom Navigation hadn’t been mentioned in previous Material Design iterations. Traditionally, one of the biggest differences between Android and iOS design was the use of bottom bars; while they were essential for iOS, Android apps following MD guidelines generally avoided them.
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 provided detailed answers. Since Zhihu reach can be limited, I’ve compiled our responses here with his permission as a guide for other developers.
In the previous article, we used the third method to implement DelayLoad. However, the previous article was written relatively simply and only explained how to implement. This article will explain why we need to do this and the principles behind it.
This will involve some relatively important classes in Android, as well as several relatively important functions in Activity lifecycle.
Actually, the principles here are quite simple, but to clarify the implementation process, it’s still a quite interesting thing. It will involve using some tools, adding debug code ourselves, and proceeding step by step. Through this, our understanding of Activity launch will be one layer deeper. I hope that after reading this, everyone will also get some help from it.
In Android development, startup speed is a critical metric, and optimization is a vital process. The core philosophy of startup optimization is “doing less” during launch. Typical practices include:
- Asynchronous Loading
- Delayed Loading (DelayLoad)
- Lazy Loading
Most developers who have worked on startup optimization have likely used these. This article dives deep into a specific implementation of DelayLoad and the underlying principles. While the code itself is simple, the mechanics involve Looper, Handler, MessageQueue, VSYNC, and more. I’ll also share some edge cases and my own reflections.
