编写高效友好的多线程J2ME联网应用

初次编写J2ME的联网应用程序的时候往往会写出这样的代码：
public void commandAction(Command c, Displayable s) {
    if (c == mExitCommand)
      notifyDestroyed();
    else if (c == mConnectCommand)
      connect();
}
 
  private void connect() {
    String url = getAppProperty("NetworkThreading.URL");
   
    try {
     
      HttpConnection hc = (HttpConnection)Connector.open(url);
      InputStream in = hc.openInputStream();
     
      int contentLength = (int)hc.getLength();
      if (contentLength == -1) contentLength = 255;
      byte[] raw = new byte[contentLength];
........
.......
}
当你运行这样的程序的时候会出现什么问题呢？wtk会提示你联网工作可能会堵塞用户输入，让你到另外一个线程去进行联网操作。OK，那么我们按照他的要求新建一个线程来进行联网，比如这样写：
public void commandAction(Command c, Displayable s) {
  if (c == mExitCommand)
    notifyDestroyed();
  else if (c == mConnectCommand) {
    Thread t = new Thread() {
      public void run() {
        connect();
      }
    };
    t.start();
  }
}
这样联网就可以通过了，那么为什么会这样呢？明白事物背后的原理显得非常的重要，下面我做一下介绍，当程序运行的时候，Application Management Software(应用管理软件)首先初始化一个MIDlet,然后调用他的startApp()方法使得MIDlet进入active状态，这条程序分支就是主线程，他执行其他的方法后都会返回到这个分支上来继续执行。然后联网是个可能堵塞的操作，意味着他可能长时间都不返回。我曾经写的联网程序在手机上运行，的确比较耗费时间。如果他不返回，那么就不能进行后面的操作，用户也不能输入。这样看上去手机就像死了一样，这显然不够友好。看看下面的原理图吧：

当我们在应用程序中新建一个线程来处理联网或者浏览大量RMS数据的时候就不一样了。这时候启动线程后主线程会立刻返回，不会堵塞。

仔细想想这样同样有不好的地方，尽管他可以正常工作，但是每次用户按下按钮的时候都会有新的线程产生，这样显然不够高效。幸好java中提供了wait()和notify()/notifyAll()来协调这样的问题，我们启动线程后让他进入等待的状态，当用户按下按钮的时候才让他继续运行。代码类似这样：
public synchronized void run() {
  while (mTrucking) {
    try { wait(); }
    catch (InterruptedException ie) {}
    if (mTrucking) connect();
  }
}

public synchronized void go() {
  notify();
}

这样效率比较高了！当用户进行联网操作的时候我们应该做一个提示界面，比如一个动画告诉用户正在进行联网操作。这样比较友好。那么当用户选择联网动作的时候，我们让我提前做好的欢迎界面显示在屏幕上，联网结束后再把返回的结果显示出来。这样就是一个出色的联网应用程序了。下面的这个代码可以在屏幕上描绘一个动画的效果，当然你也可以修改一下做成自己喜欢的样子。
import java.util.*;

import javax.microedition.lcdui.*;

public class WaitCanvas
    extends Canvas {