Video version
This article has a corresponding video on site B. If you like to watch the video version, you can click here to watch bilibili, or click here to watch YouTube.
Start with memory jitter
Interviewer: You have done performance optimization.
Interviewer: Well, yes, I’ve done a lot of things about lag and power consumption.
Interviewer: Have you learned about the solution to memory jitter?
Interviewer: Memory what?
Interviewer: Memory jitter. Never heard of it?
Interviewer:… No.
Interviewer: Hoo (shaking his head). Young people still need to respect technology and keep learning.
Interviewer: I… HMM…
Hi, I’m Zhu Kai from throwline.
Cool words always catch the eye, like “parent delegate,” like “chain of responsibility,” like — “memory jitter.” Attracting attention means getting more clicks, and clicks are what content creators love, so it’s natural for cool names to be favored by technical articles because you can get more traffic by writing them. Again, there’s nothing wrong with that. But some authors are too paranoid about the pursuit of flow, what things like to blow too much.
Everyone as a reader, when looking at the article to have discrimination, not to be biased by these traffic words, not to be cheated by some traffic traffickers to add to their interview questions to test whether your interviewer has read an article, this is worthless.
Valuable, or not?
Ah ha? The concept of “memory jitter” is worthless?
No, I’m not saying the concept of memory jitter is worthless. Ah forget, I first say what is memory jitter:
In a program, every time an object is created, a block of memory is allocated to it; For each block of memory allocated, the program has less available memory. When a program reaches a critical level of memory usage, the Garbage Collector is called out to free up some of the memory that is no longer being used. The View.ondraw () method in Android is called every time it needs to be redrawn, which means that if you write object creation code in onDraw(), you will frequently create a large number of objects that will only be used once the screen is constantly refreshed. This leads to a rapid increase in memory usage; Then, very quickly, it might trigger a GC collection, where the objects you created are collected by the GC. Too much junk memory gets cleaned up, that’s how Java works, that’s not a problem. The problem is that creating these objects frequently causes memory to keep climbing, rising quickly after being reclaimed, and then being reclaimed again, right? This, over and over, eventually leads to a cycle in which memory is increased and reclaimed repeatedly over a short period of time.
The technical name for this recurring state is Memory Churn, which is translated as Memory Churn in the Android documentation. So memory jitter isn’t really some magical thing where our memory shakes as a whole,
It’s just like having a stir stick gently stirring the edge of memory.
We can also see this phenomenon more visually with Android Studio’s Memory Profiler:
Although memory reclamation is fast and time cost is low, there is a time cost. One or two memory reclaims are not easily detected by users, but multiple memory reclaims occur in a short period of time, which causes a large risk of interface lag. This is why Android’s documentation and Android Studio advise us to avoid creating objects in onDraw().
In the same way, creating objects in large loops, not just onDraw(), can cause memory jitter. However, in practice, the objects created in onDraw() tend to be drawn related objects, and these objects often contain references to the lower level of the system Native objects, which leads to the creation of objects in onDraw() resulting in higher memory reclamation time. To put it bluntly — the interface is more sluggish.
In addition, memory jitter can sometimes turn into an overflow of memory, which is more serious, because the direct result of an overflow of memory is a software crash.
Yes, but the words “memory jitter” are not the key
So, does the concept of “memory jitter” have any value?
Of course it does, because it helps us visualize a phenomenon in a program. Isn’t it? Add, recycle, add, recycle.
So what do I mean by “worthless” at the beginning?
I am not saying that the concept of “memory jitter” is worthless, but that the pursuit of understanding the concept itself is worthless. To be sure, the interviewer’s attempt to use the word “memory jitter” to determine whether the candidate is highly developed is a worthless strategy. Memory optimization is a complex and nuanced topic, and avoiding object creation in onDraw() is just the tip of the iceberg. And even in this tip of the iceberg, the focus is on “avoiding memory growth,” not “avoiding memory thrashing.” Memory jitter is only a superficial phenomenon, and the reason behind it is rarely seen in other contexts than creating objects in onDraw(). So what’s the point of having such context-defining words specifically listed in interview questions?
When we ask “memory jitter”, what should we care about
I’m not saying you shouldn’t ask about memory jitter during an interview, but you should definitely not focus on it. It is not important that you have heard of memory jitter, but that you know the cause and solution of memory jitter.
HMM… If you haven’t heard of memory jitter, how can you know its cause and solution?
He hasn’t. You can tell him! Do you know that Android officially advises us not to create objects in onDraw()? Do you know why? If he immediately answers that this will cause frequent memory reclamation, doesn’t that show that he actually understands the principle? At this time you tell him again, this is called memory jitter, on the line.
And without limiting yourself to just one word, you can also ask: why does creating objects in onDraw() result in memory jitter rather than overflow? This examination of ability is much more important than that of vocabulary. I’m not sure that every interviewer who likes to ask about memory jitter will answer this question, but it’s the best way to test a programmer’s ability.
If you ask about memory jitter in an interview, but after they say they haven’t heard of it, you stop giving them any instructions and just give them a penalty, you’re asking: I have a high-end term. Have you heard of it?
To blow his own horn
When I teach, I always emphasize to my students that they should learn the essence when they learn the technology, because I go too far in some areas and I’m afraid they won’t learn it. Speaking of my class, there are Android advanced advanced serialization knowledge, scan code consulting.
Why do I think my AD is a little tricky? The transition was not graceful, forced turns, strong. Improve it next time improve it next time.
The last
Back to the essence, learning technology to learn the essence, but memory jitter is not the essence of any technology. I’m not talking about memory jitter per se, but I want to make a point:
We learn technology, should learn deep, and should be deep enough, but do not be scared by all kinds of fancy words, also do not run with them, we should have their own knowledge system, have their own growth logic.
I’m a throwline. I don’t compete with you. I just help you grow. We’ll see you next time.
This article is formatted using MDNICE