【问题标题】:Android Handlers and AsynctaskAndroid 处理程序和 Asynctask
【发布时间】:2015-09-19 09:34:17
【问题描述】:

我的 android 应用程序完成了我的任务。现在,我有点困惑。我的问题是: 我有一个主类(在这种情况下是一个片段),它的作用(除其他外)是它获取给定人名的图像的 url,然后从该 url 下载图像。以下是我计划进行的方式:

我将这两个异步任务放在单独的类中,因为将来其他类也需要它们。我不确定我做了什么,我不想要任何内存泄漏,所以应用程序不会崩溃。如果有人可以看看并建议我,我真的很感激。

Main Class() {
static MyHandler myhandler;
...
... 
....

static class MyHandler extends Handler {
....
.....
.......
  public void HandleMessage()
 {
 .....
 .......
  if(message == "OK")
    {
     download();
    }
  else if(message = "BMP")
    {
      // I am done
     ....
     ......
    } 
  }
 }


 image_url_fetch(myhandler).execute;

 public void download()
 {
  image_download(myhandler).execute;
 }

 }


 class image_url_fetch exteds Asynctask 
{

 MyHandler myhandler;

 image_url_fetch(MyHandler myhandler)
 {
  this.myhandler = myhandler;
 }
  ...
  ....
  onPostExecute()
 {
myhandler.sendmessage("OK");
 }

}  

class image_download extends Asynctask  
{

 MyHandler myhandler;

 image_download(MyHandler myhandler)
 {
  this.myhandler = myhandler;
 }
  ...
  ....
  onPostExecute() 
 {
  handler.sendMessage(BMP)
    // i have to find a way to send the Bitmap to Main Class
 }

 } 

【问题讨论】:

    标签: android memory memory-leaks android-asynctask handler


    【解决方案1】:

    最好在同一个 AsyncTask 中同时使用 fetching Image Url 和 Downloading Image 而不是两个

    代码看起来有点简化和更快。

    如果您不需要 AsyncTask 来获取 Url ...因为检索一系列字符不会花费足够的时间。下载图片前使用逻辑在image_download AsyncTask中获取Url。

    P.S : 为了更好的可读性和标准,使用以大写字母开头的类名并避免在类名中使用特殊符号..example

    ImageDownloader.java 在不描述的情况下阅读和理解上下文会很棒

    【讨论】:

    • 谢谢。但是我有需要分别使用这两个类的实例。所以我让他们保持独立。您能指出可能发生内存泄漏的位置吗?假设主类被破坏了,这里发生内存泄漏的机会有多大。我不擅长弄清楚这一点。
    • 它不是关于内存泄漏..它关于内存优化,实例增加内存利用率....如果您需要单独获取图像的 url,最好将逻辑包装在没有 Asyncask 的方法中并调用下载AsyncTask中的那个方法
    • 好的,谢谢。如果我的 MainClass 被破坏了,那么其他可能已经实例化并在后台工作的类是否会获得 GC(我认为外部类没有对 MainClass 的引用(我可能错了)?
    • instances 的作用域可以阻止。当你销毁 MainClass 时,类范围内的实例会被销毁,在你的 Language GC 中也会释放它们的内存
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2011-11-02
    • 2014-09-08
    • 1970-01-01
    • 2017-06-08
    • 2021-07-06
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多