最近我读到这篇文章的 管理你的应用程序的内存 的，我强烈建议阅读它，如果你是一个AndroidDev和从来没有。

I recently read this article on Managing Your App's Memory,I strongly suggest to read it if you are an AndroidDev and never did.

有很多很好的做法，有一件事我永远不会发生知道的是onTrimMemory(int级）调用系统中的每个活动的方法/片段，通知上的内存应该或可能被释放的事件。

There are lots of good practice and one thing I never happen to know about is the onTrimMemory(int level) method called by the system on every Activity/Fragment to notify events on which memory should or could be released.

下面是这篇文章报价：

请注意，您的应用程序接收到带有onTrimMemory（）回调   只有TRIM_MEMORY_UI_HIDDEN当你的应用程序的所有UI组件   过程成为对用户隐藏的。这是从不同的   的onStop（）回调，当活动实例变为被称为   隐藏，即使当用户在移动到另一个活动而发生   你的应用程序。所以，尽管你应该实现的onStop（）来释放   活动的资源，例如网络连接或注销   广播接收器，您平时应不释放你的UI资源   直到收到onTrimMemory（TRIM_MEMORY_UI_HIDDEN）。这可确保   如果用户返回的另一项活动中的应用，   你的UI资源仍然可以迅速恢复活动。

Notice that your app receives the onTrimMemory() callback with TRIM_MEMORY_UI_HIDDEN only when all the UI components of your app process become hidden from the user. This is distinct from the onStop() callback, which is called when an Activity instance becomes hidden, which occurs even when the user moves to another activity in your app. So although you should implement onStop() to release activity resources such as a network connection or to unregister broadcast receivers, you usually should not release your UI resources until you receive onTrimMemory(TRIM_MEMORY_UI_HIDDEN). This ensures that if the user navigates back from another activity in your app, your UI resources are still available to resume the activity quickly.

我在实施一个良好的内存管理在我的应用程序，所以我很期待实施onTrimMemory()以正确的方式。

I am really interested in implementing a good memory management in my application so I am looking forward to implement the onTrimMemory() in the right way.

我只有一个关于它的一些问题：

I only have a few question about it:

是onTrimMemory(TRIM_MEMORY_UI_HIDDEN)之后叫的onStop（）？

is onTrimMemory(TRIM_MEMORY_UI_HIDDEN) called right after the onStop()?

什么是释放你的UI资源，在这种情况下意味着什么？只是比如清理位图缓存，或实际删除和销毁的视图树中的每个视图？我通常会破坏在的onDestroy（）或 onDestroyView（）的方法，我现在想知道如果我做的意见是正确的。

what "release your UI resources" means in that context? just for instance clean the Bitmap cache, or actually remove and destroy every View in the View tree? i usually destroy the Views in the onDestroy() or onDestroyView() methods, i am now wondering if i'm doing it right.

有一个双人标准间/记者回调onTrimMemory(TRIM_MEMORY_UI_HIDDEN)?喜欢的的onCreate-的onDestroy 的 ONSTART-的onStop 的 onCreateView-onDestroyView 的。我'问到undestand在那里，我应该如何在活动后恢复UI状态/片段被带到FG后，onTrimMemory(TRIM_MEMORY_UI_HIDDEN)被调用。

is there a Twin/correspondent callback to onTrimMemory(TRIM_MEMORY_UI_HIDDEN)? like onCreate-onDestroy, onStart-onStop, onCreateView-onDestroyView. I'am asking to undestand where and how i should restore the UI state after an Activity/Fragment as been brought in FG after onTrimMemory(TRIM_MEMORY_UI_HIDDEN) has been called.

推荐答案

onTrimMemory与TRIM_MEMORY_UI_HIDDEN水平的onStop之前，实际上是调用。当的onStop被调用，这意味着该活动真正停止和Android操作系统可能会杀了它的时候了，如果需要，所以你不应该指望任何多次调用该活动的回调aftet的是，除了onRestart有时的onDestroy。

onTrimMemory with TRIM_MEMORY_UI_HIDDEN level is actually called before onStop. When onStop is called, it means the activity is really stopping, and the Android OS might kill it right away if it needs to, so you should not expect any more calls to that activity's callbacks aftet that, except for onRestart and sometimes onDestroy.

释放你的UI资源，其实就是这样的事情缓存。您通常不必担心管理观点或UI组件，因为该操作系统已经这样做了，这就是为什么有那些回调创建，启动，暂停，停止和销毁活动。但是，有时为了提高性能，你必须提高内存的使用情况，如缓存使用你的活动的一些数据。这是资源，你应该释放时onTrimMemory叫的类型，所以您的应用程序使用较少的内存，即使它会影响性能。你应该担心内存泄漏虽然。如果你的活动停止后，一定不要保留任何引用他们的意见，因为这样会防止被垃圾回收活动，这将防止被收集的整个环境，而这是很糟糕，主要是如果你想保持你的应用程序运行数小时或数天（当您实现服务等）。

"release your UI resources" is actually about things like caches. You usually don't have to worry about managing views or UI components because the OS already does that, and that's why there are all those callbacks for creating, starting, pausing, stopping and destroying an activity. However, sometimes to improve performance you have to increase memory usage, such as caching some data used by your activities. That's the type of resource you should release when onTrimMemory is called, so your app uses less memory, even if it affects performance. You should worry about memory leaks though. If your activity stops, be sure not to keep any references to its views, because that would keep the activity from being garbage collected, which would keep the whole context from being collected, and that's bad, mostly if you want to keep your app running for hours or days (like when you implement services).

没有，有没有相应回调onTrimMemory。但是，你不应该需要一个。正如我以前说过，如果你把一些资源缓存以提高性能，只是空的，并让它再长出来，如果​​它需要。如果内存级别是很低的，onTrimMemory可能会很快再次呼吁，与相同的内存水平。顺便说一句，请记住，onTrimMemory将被称为几种不同的存储层次，而不仅仅是TRIM_MEMORY_UI_HIDDEN。

No, there's no correspondent callback to onTrimMemory. However, you shouldn't need one. As I said before, if you keep a cache of some resources to improve performance, just empty that, and let it grow again if it needs to. If memory level keeps low, onTrimMemory may be called again soon, with that same memory level. By the way, keep in mind that onTrimMemory will be called with several different memory levels, not just TRIM_MEMORY_UI_HIDDEN.