虽然如此说，但似乎并没有什么好的办法：Android设备是嵌入式设备。现代的手持设备，与其说是电话，更像一台拿在手中的电脑。但是，即使是“最快”的手持设备，其性能也赶不上一台普通的台式电脑。

这就是为什么我们在书写Android应用程序的时候要格外关注效率。这些设备并没有那么快，并且受电池电量的制约。这意味着，设备没有更多的能力，我们必须把程序写的尽量有效。

本章讨论了很多能让开发者使他们的程序运行更有效的方法，遵照这些方法，你可以使你的程序发挥最大的效力。

简介

对于占用资源的系统，有两条基本原则：

• 不要做不必要的事
• 不要分配不必要的内存

所有下面的内容都遵照这两个原则。

有些人可能马上会跳出来，把本节的大部分内容归于“草率的优化”（xing:参见[The Root of All Evil ]），不可否认微优化（micro-optimization。xing:代码优化，相对于结构优化）的确会带来很多问题，诸如无法使用更有效的数据结构和算法。但是在手持设备上，你别无选择。假如你认为Android虚拟机的性能与台式机相当，你的程序很有可能一开始就占用了系统的全部内存（xing:内存很小），这会让你的程序慢得像蜗牛一样，更遑论做其他的操作了。

Android的成功依赖于你的程序提供的用户体验。而这种用户体验，部分依赖于你的程序是响应快速而灵活的，还是响应缓慢而僵化的。因为所有的程序都运行在同一个设备之上，都在一起，这就如果在同一条路上行驶的汽车。而这篇文档就相当于你在取得驾照之前必须要学习的交通规则。如果大家都按照这些规则去做，驾驶就会很顺畅，但是如果你不这样做，你可能会车毁人亡。这就是为什么这些原则十分重要。

当我们开门见山、直击主题之前，还必须要提醒大家一点：不管VM是否支持实时（JIT）编译器（xing:它允许实时地将Java解释型程序自动编译成本机机器语言，以使程序执行的速度更快。有些JVM包含JIT编译器。），下面提到的这些原则都是成立的。假如我们有目标完全相同的两个方法，在解释执行时foo()比bar()快，那么编译之后，foo()依然会比bar()快。所以不要寄希望于编译器可以拯救你的程序。

避免建立对象

世界上没有免费的对象。虽然GC为每个线程都建立了临时对象池，可以使创建对象的代价变得小一些，但是分配内存永远都比不分配内存的代价大。

如果你在用户界面循环中分配对象内存，就会引发周期性的垃圾回收，用户就会觉得界面像打嗝一样一顿一顿的。

所以，除非必要，应尽量避免尽力对象的实例。下面的例子将帮助你理解这条原则：

• 当你从用户输入的数据中截取一段字符串时，尽量使用substring函数取得原始数据的一个子串，而不是为子串另外建立一份拷贝。这样你就有一个新的String对象，它与原始数据共享一个char数组。
• 如果你有一个函数返回一个String对象，而你确切的知道这个字符串会被附加到一个StringBuffer，那么，请改变这个函数的参数和实现方式，直接把结果附加到StringBuffer中，而不要再建立一个短命的临时对象。

一个更极端的例子是，把多维数组分成多个一维数组。

• int数组比Integer数组好，这也概括了一个基本事实，两个平行的int数组比(int,int)对象数组性能要好很多 。同理，这试用于所有基本类型的组合。
• 如果你想用一种容器存储(Foo,Bar)元组，尝试使用两个单独的Foo[]数组和Bar[]数组，一定比(Foo,Bar)数组效率更高。（也有例外的情况，就是当你建立一个API，让别人调用它的时候。这时候你要注重对API借口的设计而牺牲一点儿速度。当然在API的内部，你仍要尽可能的提高代码的效率）

总体来说，就是避免创建短命的临时对象。减少对象的创建就能减少垃圾收集，进而减少对用户体验的影响。

使用本地方法

当你在处理字串的时候，不要吝惜使用String.indexOf(), String.lastIndexOf()等特殊实现的方法（specialty methods）。这些方法都是使用C/C++实现的，比起Java循环快10到100倍。

使用实类比接口好

假设你有一个HashMap对象，你可以将它声明为HashMap或者Map:

Map myMap1 = new HashMap();
HashMap myMap2 = new HashMap();

哪个更好呢？

按照传统的观点Map会更好些，因为这样你可以改变他的具体实现类，只要这个类继承自Map接口。传统的观点对于传统的程序是正确的，但是它并不适合嵌入式系统。调用一个接口的引用会比调用实体类的引用多花费一倍的时间。

如果HashMap完全适合你的程序，那么使用Map就没有什么价值。如果有些地方你不能确定，先避免使用Map，剩下的交给IDE提供的重构功能好了。(当然公共API是一个例外：一个好的API常常会牺牲一些性能）

用静态方法比虚方法好

如果你不需要访问一个对象的成员变量，那么请把方法声明成static。虚方法执行的更快，因为它可以被直接调用而不需要一个虚函数表。另外你也可以通过声明体现出这个函数的调用不会改变对象的状态。

不用getter和setter

在很多本地语言如C++中，都会使用getter（比如：i = getCount()）来避免直接访问成员变量（i = mCount）。在C++中这是一个非常好的习惯，因为编译器能够内联访问，如果你需要约束或调试变量，你可以在任何时候添加代码。

在Android上，这就不是个好主意了。虚方法的开销比直接访问成员变量大得多。在通用的接口定义中，可以依照OO的方式定义getters和setters，但是在一般的类中，你应该直接访问变量。

将成员变量缓存到本地

访问成员变量比访问本地变量慢得多，下面一段代码：

for (int i = 0; i < this.mCount; i++)
dumpItem(this.mItems[i]);

再好改成这样：

 int count = this.mCount;
Item[] items = this.mItems;
for (int i = 0; i < count; i++)
dumpItems(items[i]);

（使用"this"是为了表明这些是成员变量）

另一个相似的原则是：永远不要在for的第二个条件中调用任何方法。如下面方法所示，在每次循环的时候都会调用getCount()方法，这样做比你在一个int先把结果保存起来开销大很多。

for (int i = 0; i < this.getCount(); i++)
dumpItems(this.getItem(i));

同样如果你要多次访问一个变量，也最好先为它建立一个本地变量，例如：

   protected void drawHorizontalScrollBar(Canvas canvas, int width, int height) {
if (isHorizontalScrollBarEnabled()) {
int size = mScrollBar.getSize(false);
if (size <= 0) {
size = mScrollBarSize;
}
mScrollBar.setBounds(0, height - size, width, height);
mScrollBar.setParams(
computeHorizontalScrollRange(),
computeHorizontalScrollOffset(),
computeHorizontalScrollExtent(), false);
mScrollBar.draw(canvas);
}
}

这里有4次访问成员变量mScrollBar，如果将它缓存到本地，4次成员变量访问就会变成4次效率更高的栈变量访问。

另外就是方法的参数与本地变量的效率相同。

使用常量

让我们来看看这两段在类前面的声明：

static int intVal = 42;
static String strVal = "Hello, world!";

必以其会生成一个叫做<clinit>的初始化类的方法，当类第一次被使用的时候这个方法会被执行。方法会将42赋给intVal，然后把一个指向类中常量表的引用赋给strVal。当以后要用到这些值的时候，会在成员变量表中查找到他们。下面我们做些改进，使用“final"关键字：

static final int intVal = 42;
static final String strVal = "Hello, world!";

现在，类不再需要<clinit>方法，因为在成员变量初始化的时候，会将常量直接保存到类文件中。用到intVal的代码被直接替换成42，而使用strVal的会指向一个字符串常量，而不是使用成员变量。

将一个方法或类声明为"final"不会带来性能的提升，但是会帮助编译器优化代码。举例说，如果编译器知道一个"getter"方法不会被重载，那么编译器会对其采用内联调用。

你也可以将本地变量声明为"final"，同样，这也不会带来性能的提升。使用"final"只能使本地变量看起来更清晰些（但是也有些时候这是必须的，比如在使用匿名内部类的时候）（xing:原文是 or you have to, e.g. for use in an anonymous inner class）

谨慎使用foreach

foreach可以用在实现了Iterable接口的集合类型上。foreach会给这些对象分配一个iterator，然后调用 hasNext()和next()方法。你最好使用foreach处理ArrayList对象，但是对其他集合对象，foreach相当于使用 iterator。

下面展示了foreach一种可接受的用法：

public class Foo {
int mSplat;
static Foo mArray[] = new Foo[27];
public static void zero() {
int sum = 0;
for (int i = 0; i < mArray.length; i++) {
sum += mArray[i].mSplat;
}
}
public static void one() {
int sum = 0;
Foo[] localArray = mArray;
int len = localArray.length;
for (int i = 0; i < len; i++) {
sum += localArray[i].mSplat;
}
}
public static void two() {
int sum = 0;
for (Foo a: mArray) {
sum += a.mSplat;
}
}
}

在zero()中，每次循环都会访问两次静态成员变量，取得一次数组的长度。 retrieves the static field twice and gets the array length once for every iteration through the loop.

在one()中，将所有成员变量存储到本地变量。 pulls everything out into local variables, avoiding the lookups.

two()使用了在java1.5中引入的foreach语法。编译器会将对数组的引用和数组的长度保存到本地变量中，这对访问数组元素非常好。但是编译器还会在每次循环中产生一个额外的对本地变量的存储操作（对变量a的存取）这样会比one()多出4个字节，速度要稍微慢一些。

综上所述：foreach语法在运用于array时性能很好，但是运用于其他集合对象时要小心，因为它会产生额外的对象。

避免使用枚举

枚举变量非常方便，但不幸的是它会牺牲执行的速度和并大幅增加文件体积。例如：

public class Foo {
public enum Shrubbery { GROUND, CRAWLING, HANGING }
}

会产生一个900字节的.class文件(Foo$Shubbery.class)。在它被首次调用时，这个类会调用初始化方法来准备每个枚举变量。每个枚举项都会被声明成一个静态变量，并被赋值。然后将这些静态变量放在一个名为"$VALUES"的静态数组变量中。而这么一大堆代码，仅仅是为了使用三个整数。

这样:

Shrubbery shrub = Shrubbery.GROUND;会引起一个对静态变量的引用，如果这个静态变量是final int，那么编译器会直接内联这个常数。

一方面说，使用枚举变量可以让你的API更出色，并能提供编译时的检查。所以在通常的时候你毫无疑问应该为公共API选择枚举变量。但是当性能方面有所限制的时候，你就应该避免这种做法了。

有些情况下，使用ordinal()方法获取枚举变量的整数值会更好一些，举例来说，将：

for (int n = 0; n < list.size(); n++) {
if (list.items[n].e == MyEnum.VAL_X)
// do stuff 1
else if (list.items[n].e == MyEnum.VAL_Y)
// do stuff 2
}

替换为:

  int valX = MyEnum.VAL_X.ordinal();
int valY = MyEnum.VAL_Y.ordinal();
int count = list.size();
MyItem items = list.items();
for (int  n = 0; n < count; n++)
{
int  valItem = items[n].e.ordinal();
if (valItem == valX)
// do stuff 1
else if (valItem == valY)
// do stuff 2
}

会使性能得到一些改善，但这并不是最终的解决之道。

将与内部类一同使用的变量声明在包范围内

请看下面的类定义：

public class Foo {
private int mValue;
public void run() {
Inner in = new Inner();
mValue = 27;
in.stuff();
}
private void doStuff(int value) {
System.out.println("Value is " + value);
}
private class Inner {
void stuff() {
Foo.this.doStuff(Foo.this.mValue);
}
}
}

这其中的关键是，我们定义了一个内部类(Foo$Inner)，它需要访问外部类的私有域变量和函数。这是合法的，并且会打印出我们希望的结果"Value is 27"。

问题是在技术上来讲（在幕后）Foo$Inner是一个完全独立的类，它要直接访问Foo的私有成员是非法的。要跨越这个鸿沟，编译器需要生成一组方法：

/*package*/ static int Foo.access$100(Foo foo) {
return foo.mValue;
}
/*package*/ static void Foo.access$200(Foo foo, int value) {
foo.doStuff(value);
}

内部类在每次访问"mValue"和"doStuff"方法时，都会调用这些静态方法。就是说，上面的代码说明了一个问题，你是在通过接口方法访问这些成员变量和函数而不是直接调用它们。在前面我们已经说过，使用接口方法（getter、setter）比直接访问速度要慢。所以这个例子就是在特定语法下面产生的一个“隐性的”性能障碍。

通过将内部类访问的变量和函数声明由私有范围改为包范围，我们可以避免这个问题。这样做可以让代码运行更快，并且避免产生额外的静态方法。（遗憾的是，这些域和方法可以被同一个包内的其他类直接访问，这与经典的OO原则相违背。因此当你设计公共API的时候应该谨慎使用这条优化原则）

避免使用浮点数

在奔腾CPU出现之前，游戏设计者做得最多的就是整数运算。随着奔腾的到来，浮点运算处理器成为了CPU内置的特性，浮点和整数配合使用，能够让你的游戏运行得更顺畅。通常在桌面电脑上，你可以随意的使用浮点运算。

但是非常遗憾，嵌入式处理器通常没有支持浮点运算的硬件，所有对"float"和"double"的运算都是通过软件实现的。一些基本的浮点运算，甚至需要毫秒级的时间才能完成。

甚至是整数，一些芯片有对乘法的硬件支持而缺少对除法的支持。这种情况下，整数的除法和取模运算也是有软件来完成的。所以当你在使用哈希表或者做大量数学运算时一定要小心谨慎。

首先要说明在B中直接使用finish()，接下来手机显示的还是主窗口A，所以一起来看看Android开发网是如何实现的吧.

1. Dalvik VM的本地方法

android.os.Process.killProcess(android.os.Process.myPid())    //获取PID，目前获取自己的也只有该API，否则从/proc中自己的枚举其他进程吧，不过要说明的是，结束其他进程不一定有权限，不然就乱套了。
System.exit(0);   //常规java、c#的标准退出法，返回值为0代表正常退出

2. 任务管理器方法

首先要说明该方法运行在Android 1.5 API Level为3以上才可以，同时需要权限android.permission.RESTART_PACKAGES，我们直接结束自己的package即可，直接使用ActivityManager类的restartPackage方法即可，参数为package name，该类通过getSystemService(Context.ACTIVITY_SERVICE)来实例化ActivityManager对象，这种方法系统提供的，但需要显示声明权限，所以使用中需要综合考虑。

3. 根据Activity的声明周期

我们知道Android的窗口类提供了历史栈，我们可以通过stack的原理来巧妙的实现，这里我们在A窗口打开B窗口时在Intent中直接加入标志Intent.FLAG_ACTIVITY_CLEAR_TOP，这样开启B时将会清除该进程空间的所有Activity。

在A窗口中使用下面的代码调用B窗口

Intent intent = new Intent();
intent.setClass(Android123.this, CWJ.class);
intent.setFlags(Intent.FLAG_ACTIVITY_CLEAR_TOP);  //注意本行的FLAG设置
startActivity(intent);

接下来在B窗口中需要退出时直接使用finish方法即可全部退出。

转自：http://www.android123.com.cn/androidkaifa/519.html

解决办法：

右击该文件 --> BuildPath --> Include

正常实心J时，该选项为 Exclude

The following example shows ActionScript code that is equivalent to the MXML code in the previous example:
private function run():void {
 ro = new RemoteObject();
 var cs:ChannelSet = new ChannelSet();
 cs.addChannel(new AMFChannel("myAmf",
 "http://servname:2000/eqa/messagebroker/amf"));
 ro.destination = "Dest";
 ro.channelSet = cs;
}

Important: When you create a channel on the client, you must still include a channel definition that specifies an endpoint class in the services-config.xml file. Otherwise, the message broker cannot pass a Flex client request to an endpoint.

Assigning channels and endpoints to a destination
1,If most of the destinations across all services use the same channels, you can define application-level default channels in the services-config.xml file, as the following example shows.
Note: Using application-level default channels is a best practice whenever possible.
<services-config ...>
...
<default-channels>
<channel ref="my-http"/>
<channel ref="my-amf"/>
</default-channels>
...
In this case, all destinations that do not define channels use a default channel. Destinations can override the
default channel setting by specifying their own channels, and services can also override it by specifying their own
default channels.
2,If most of the destinations in a service use the same channels, you can define service-level default channels, as
the following example shows:
<service ...>
...
<default-channels>
<channel ref="my-http"/>
<channel ref="my-amf"/>
</default-channels>
...
In this case, all destinations in the service that do not explicitly specify their own channels use the default
channel.
3,The destination definition can reference a channel inline, as the following example shows:
<destination id="sampleVerbose">
<channels>
<channel ref="my-secure-amf"/>
</channels>
...
</destination>

How to choosing a channel?
1, Non-polling AMF and HTTP channels
You can use AMF and HTTP channels without polling for remote procedure call (RPC) services, such as remoting service calls, proxied HTTP service calls and web service requests. These scenarios do not require the client to poll for messages or the server to push messages to the client.
2, Piggybacking on AMF and HTTP channels
The piggybacking feature enables the transport of queued messages along with responses to any messages the client sends to the server over the channel. Piggybacking provides lightweight pseudo polling, where rather than the client channel polling the server on a fixed or adaptive interval, when the client sends a non-command message to the server (using a Producer or RemoteObject object), the server sends any pending data for client messaging or data management subscriptions along with the response to the client message.
Piggybacking can also be used on a channel that has polling enabled but on a wide interval like 5 seconds or 10 seconds or more, in which case the application appears more responsive if the client is sending messages to the server. In this mode, the client sends a poll request along with any messages it sends to the server between its regularly scheduled poll requests. The channel piggybacks a poll request along with the message being sent, and the server piggybacks any pending messages for the client along with the acknowledge response to the client message.
3, Polling AMF and HTTP channels
AMF and HTTP channels support simple polling mechanisms that clients can use to request messages from the server at set intervals. A polling AMF or HTTP channel is useful when other options such as long polling or streaming channels are not acceptable and also as a fallback channel when a first choice, such as a streaming channel, is unavailable at run time.
4, Long polling AMF and HTTP channels
You can use AMF and HTTP channels in long polling mode to get pushed messages to the client when the other more efficient and real-time mechanisms are not suitable. This mechanism uses the normal application server HTTP request processing logic and works with typical J2EE deployment architectures.
You can establish long polling for any channel that uses a non-streaming AMF or HTTP endpoint by setting the polling-enabled ,  polling-interval-millis ,  wait-interval-millis , and  client-wait-interval-
millis  properties in a channel definition.
5, Streaming channels
For streaming, you can use streaming AMF or HTTP channels. Streaming AMF and HTTP channels work with streaming AMF or HTTP endpoints.

Long polling AMF and HTTP channels
In the default configuration for a polling AMF or HTTP channel, the endpoint does not wait for messages on the server. When the poll request is received, it checks whether any messages are queued for the polling client and if so, those messages are delivered in the response to the HTTP request. You configure long polling in the same way as polling, but you also must set the  wait-interval-millis ,  max-waiting-poll-requests , and client-wait-interval-millis  properties.
在一个polling AMF或HTTP channel默认配置下，服务端endpoint不会等待消息，当轮询请求被收到时，它检查任何消息是否排队等待轮询的客户端，如果是，这些消息被交付给HTTP请求的响应。
To achieve long polling, you set the following properties in the  properties  section of a channel definition in the services-config.xml file:
polling-enabled
polling-interval-millis
wait-interval-millis 
max-waiting-poll-requests .
client-wait-interval-millis

下面分别讲一下前面提到的几种模式：
1)无轮询AMF、HTTP通道
你可以使用这些通道无轮询的方式来提供RPC 服务，比如远程服务调用、代理HTTP服务调用以及Web service请求。这些方案不要求客户端轮询信息或者服务端将消息“推”给客户端。
<!-- Simple AMF -->
<channel-definition id="samples-amf"
 type="mx.messaging.channels.AMFChannel">
<endpoint url="http://{server.name}:8400/myapp/messagebroker/amf"
 type="flex.messaging.endpoints.AmfEndpoint"/>
</channel-definition>

<!-- Simple secure AMF -->
<channel-definition id="my-secure-amf" class="mx.messaging.channels.SecureAMFChannel">
 <endpoint url="https://{server.name}:9100/dev/messagebroker/amfsecure" class="flex.messaging.endpoints.SecureAMFEndpoint"/>
</channel-definition>

<!-- Simple HTTP -->
<channel-definition id="my-http"
class="mx.messaging.channels.HTTPChannel">
 <endpoint url="http://{server.name}:8400/dev/messagebroker/http" class="flex.messaging.endpoints.HTTPEndpoint"/>
</channel-definition>

<!-- Simple secure HTTP -->
<channel-definition id="my-secure-http" class="mx.messaging.channels.SecureHTTPChannel">
 <endpoint url="https://{server.name}:9100/dev/messagebroker/httpsecure" class="flex.messaging.endpoints.SecureHTTPEndpoint"/>
</channel-definition>

2)搭载式AMF、HTTP通道
搭载式确保独立于客户端发送信息到服务端或者服务端响应消息到客户端的数据传输。搭载式提供了轻量级的假轮询：一种比固定或者适当时间间隔轮询服务端更好的方式，s特别是当客户端发送一个非命令消息到服务器（使用一个生产者或RemoteObject对象）时，服务器发送任何未确定的数据到客户端或数据管理订阅随着客户端的信息响应。
也可以在一个需要确保轮询，但是间隔却比较长，例如5秒或者10秒甚至更多的通道中使用，在这种情况下，应用程序似乎更加敏感。这种模式下，客户端的轮询请求独立于任何其他消息发送给服务端

3)轮询AMF、HTTP通道
AMF、HTTP通道提供了简单的轮询机制，客户端可以用这个机制定期发送请求消息到服务端。当长期轮询或者流通道不能使用时，或者作为一个流通道的备用通道时候，轮询AMF、HTTP通道是适用的。
<!-- AMF with polling -->
<channel-definition id="samples-polling-amf" type="mx.messaging.channels.AMFChannel">
 <endpoint url="http://{server.name}:8700/dev/messagebroker/amfpolling"   type="flex.messaging.endpoints.AMFEndpoint"/>
 <properties>
  <polling-enabled>true</polling-enabled>
  <polling-interval-seconds>8</polling-interval-seconds>
 </properties>
</channel-definition>

<!-- HTTP with polling -->
<channel-definition id="samples-polling-http" type="mx.messaging.channels.HTTPChannel">
<endpoint url="http://{server.name}:8700/dev/messagebroker/httppolling"
 type="flex.messaging.endpoints.HTTPEndpoint"/>
  <properties>
 <polling-enabled>true</polling-enabled>
 <polling-interval-seconds>8</polling-interval-seconds>
  </properties>
</channel-definition>
 注意：这种模式中你也可以使用secure通道。

4)  长轮询AMF、HTTP通道
当其他更加有效率的实时机制不合适的时候，你可以使用AMF和HTTP通道的长期轮询模式来“推”消息到客户端。 This mechanism uses the normal application server HTTP request processing logic and works with typical J2EE deployment architectures.这一机制的使用标准应用服务器的HTTP请求处理逻辑，并与典型的J2EE架构协同工作。
You can establish long polling for any channel that uses a non-streaming AMF or HTTP endpoint by setting the polling-enabled , polling-interval-millis , wait-interval-millis , and client-wait-interval-millis properties in a channel definition; for more information, see Simple channels and endpoints .您可以为任何通道建立长期轮询来使用相应端点，需要设置一下参数：polling-enabled、polling-interval-millis、wait-interval-millis、client-w ait-interval-mills。有关wait-interval-millis的更多内容请参考Blazeds文档。
<!-- Long polling AMF -->
<channel-definition id="my-amf-longpoll" class="mx.messaging.channels.AMFChannel">
<endpoint url="http://servername:8700/contextroot/messagebroker/myamflongpoll"
 class="flex.messaging.endpoints.AMFEndpoint"/>
  <properties>
 <polling-enabled>true</polling-enabled>
 <polling-interval-seconds>0</polling-interval-seconds>
 <wait-interval-millis>60000</wait-interval-millis>
 <client-wait-interval-millis>3000</client-wait-interval-millis>
 <max-waiting-poll-requests>100</max-waiting-poll-requests>
  </properties>
</channel-definition>

关于 Non-polling,Polling,Long polling和steaming的一些解释
http://www.qgy18.com/2008/08/webim-design-transport/
http://newteevee.com/2009/10/04/adobe-to-finally-support-http-streaming/

1.短轮询(polling)：核心思想是客户端定时去服务器取消息。为了实现即时效果，轮询的间隔必须设计得足够短，另外为了操作的流畅，需要使用Ajax来发送请求。本人的QGYWebIM就是采用的此方案。这种方案的优点是：后端程序编写比较容易，发送完响应信息马上断开连接，不会占用太多服务器资源。缺点是一般情况下，频繁的请求中有大半是无用，这些冗余请求无形中浪费了带宽和服务器资源。我们可以通过判断用户的活跃程度来决策请求服务器的间隔，我在51的一个帖子提到过这种方法，但是间隔一旦长了，消息的传送就有延时，违背了即时聊天的初衷了。

2.长轮询(long-polling)：基本原理是客户端向服务器发送请求，服务器接到请求后hold住连接，直到有新消息才返回响应信息并关闭连接，连接被断开期间用户的新信息会被服务器缓存起来。客户端处理完响应信息后再向服务器发送新的请求。这种做法的优势是如果用户一直没新消息，客户端不会频繁的轮询去服务器取消息，节省了流量，但是服务器维持长连接是很消耗资源的。具体实现起来，前端这边基本不需要什么改动，依然是用Ajax轮询取信息，后端需要在没有新消息时处理一下。

3.长连接(streaming)：其实很早以前就有人使用这种技术来实现聊天室的通讯，HTTP1.1开始支持。以前在页面中嵌入一个iframe，iframe里放一个使用长连接页面，服务器有新消息就会及时的在iframe里反映出来，再依靠客户端的脚本解析出来就OK了。这样做一个比较严重的问题是：使用 iframe请求长连接时，无论是IE还是firefox都会认为页面没有加载完而显示进度条，很难看。不过这个问题是可以解决的。firefox支持了Streaming Ajax，在readyState为3的时候就能接受数据，所以问题不大；IE则只能在readyState为4，即连接断开时才能得到返回值。但是伟大的Google工程师使用了一个hack成功的解决了这个问题：使用一个被称为“htmlfile”的ActiveX，把iframe放在这个ActiveX里就OK了。

无疑，使用长连接对于用户来说是最好的方案，用户体验最好（消息能及时的到达）、占用用户带宽最少（不会发送无用的请求），但是会增加服务器的开销；长轮询是折中方案，Facebook IM 就是采用这种方案，不过做了一点改动：客户端发起的每个连接服务器都hold10S，这10S中新消息会源源不断的返回给客户端，10s后连接关闭，客户端发起下一个连接。这样做是因为Facebook的用户会不断的打开、关闭新页面，如果每个页面都建立一个永久的长连接，会阻塞浏览器其他请求，服务器也会吃不消的；短轮询因为实现起来简单，适用于小型应用。

There is a browser-specific limit to the number of connections allowed per session. In Firefox, the limit is eight connections per session. In Internet Explorer, the limit is two connections allowed per session. Therefore, BlazeDS must limit the number of streaming connections per session on the server to stay below this limit.

Channel and endpoint recommendations

1. AMFChannel/Endpoint configured for long polling (no fallback needed)
Benifits:
Valid HTTP request/response pattern over standard ports that nothing in the network path will have trouble with.
Disadvantages:
When many messages are being pushed to the client, this configuration has the overhead of a poll round trip for every pushed message or small batch of messages queued between polls. Most applications are not pushing data so frequently for this to be a problem.
The Servlet API uses blocking IO, so you must define an upper bound for the number of long poll requests parked on the server at any single instant. If your number of clients exceeds this limit, the excess clients devolve to simple polling on the default 3- second interval with no server wait.
For example, if you server request handler thread pool has a size of 500, you could set the upper bound for waited polls to 250, 300, or 400 depending on the relative amount of non-poll requests you expect to service concurrently.

2. StreamingAMFChannel/Endpoint (in a channel set followed by the polling AMFChannel for fallback)
Benifits:
No polling overhead associated with pushing messages to the client.
Uses standard HTTP ports so firewalls do not interfere and all requests/responses are HTTP so packet inspecting proxies won’t drop the packets.
Disadvantages:
Holding onto the open request on the server and writing an infinite response is not typical HTTP behavior. HTTP proxies that buffer responses before forwarding them can effectively consume the stream. Assign the channel’s ‘connect-timeout-seconds’ property a value of 2 or 3 to detect this and trigger fallback to the next channel in your channel set.
No support for HTTP 1.0 client. If the client is 1.0, the open request is faulted and the client falls back to the next channel in its channel set.
The Servlet API uses blocking IO so as with long polling above, you must set a configured upper bound on the number of streaming connections you allow. Clients that exceed this limit are not able to open a streaming connection and will fall back to the next channel in their channel set.

3. AMFChannel/Endpoint with simple polling and piggybacking enabled (no fallback needed)
Benifits:
Valid HTTP request/response pattern over standard ports that nothing in the network path will have trouble with.
User experience feels more real-time than with simple polling on an interval.
Does not have thread resource constraints like long polling and streaming due to the blocking IO of the Servlet API.
Disadvantages:
Less real-time behavior than long polling or streaming. Requires client interaction with the
server to receive pushed data faster than the channel's configured polling interval.

Messages
All messages have client-side (ActionScript) implementations and server-side (Java) implementations because the messages are serialized and deserialized on both the client and the server.

Endpoint
 It is important that the channel and the endpoint use the same message format.

MessageBroker
The MessageBroker is responsible for routing messages to services and is at the core of BlazeDS on the server. After an endpoint initially processes the request, it extracts the message from the request and passes it to the MessageBroker. The MessageBroker inspects the message's destination and passes the message to its intended service. If the destination is protected by a security constraint, the MessageBroker runs the authentication and authorization checks before passing the message along

Services and destinations
Services and destinations are the next links in the message processing chain in the BlazeDS server. The system includes four services and their corresponding destinationsBlazeDS:
•     RemotingService and RemotingDestination
•     HTPProxyService and HTTPProxyDestination
•     MessageService and MessageDestination
Services are the targets of messages from client-side Flex components. Think of destinations as instances of a service configured in a certain way. For example, a RemoteObject component is used on the Flex client to communicate with the RemotingService. In the RemoteObject component, you must specify a destination  id  property that refers to a remoting destination with certain properties, such as the class you want to invoke methods on. The mapping between client-side Flex components and BlazeDS services is as follows:
•     HTTPService and WebService communicate with HTTPProxyService/HTTPProxyDestination         (RPC services)
•     RemoteObject communicates with RemotingService/RemotingDestination    (RPC services)
•     Producer and Consumer communicate with MessageService/MessageDestination   (Message services)

Adapters and assemblers
Although the BlazeDS server comes with a rich set of adapters and assemblers to communicate with different systems, custom adapters and assemblers can be plugged into the BlazeDS server. Similarly, you do not have to create all destinations in configuration files, but instead you can create them dynamically at server startup or when the server is running.

Configuration tokens
The configuration files sometimes contain special  {server.name}  and  {server.port}  tokens. These tokens are replaced with server name and port values based on the URL from which the SWF file is served when it is accessed through a web browser from a web server. Similarly, a special  {context.root}  token is replaced with the actual context root of a web application.
Note: If you use server tokens in a configuration file for an Adobe AIR application and you compile using that file, the application will not be able to connect to the server. You can avoid this issue by configuring channels in ActionScript rather than in a configuration file.

How you define JVM options depends on the application server you use. For example, in Apache Tomcat, you can define an environment variable JAVA_OPTS that contains tokens and their values, as this code snippet shows:
JAVA_OPTS=-Dmessaging.channel=my-amf -Dmy.token=myValue

 
How to create a Flash Builder project?
Use this procedure to create a Flex Builder project to edit one of the samples shipped with the Test Drive application.
The procedure for creating and configuring a new project is almost the same as the following procedure.
1     Start Flex Builder.
2     Select File > New > Flex Project.
3     Enter a project name. You are editing an existing application, so use the exact name of the sample folder:
testdrive-chat.
Note: If you are creating an empty project, you can name it anything that you want.
4     If you unzipped flex-src.zip in the samples directory, deselect the Use Default Location option, and specify the directory as C:\blazeds\tomcat\webapps\samples\testdrive-chat, or wherever you unzipped the file on your computer.
Note: By default, Flex Builder creates the project directory based on the project name and operating system. For example, if you are using the plug-in configuration of Flex Builder on Microsoft Windows, the default project directory is C:\Documents and Settings\USER_NAME\workspace\PROJECT_NAME.
5     Select the application type as Web application (runs in Flash Player) to configure the application to run in the browser as a Flash Player pplication.
If you are creating an AIR application, select Desktop Application (Runs In Adobe AIR). However, make sure that you do not have any server tokens in URLs in the configuration files. In the web application that ships with BlazeDS, server tokens are used in the channel endpoint URLs in the WEB-INF/flex/services-config.xml file, as the following example shows:
<endpoint
url="https://{server.name}:{server.port}/{context.root}/messagebroker/streamingamf"
      class="flex.messaging.endpoints.StreamingAMFEndpoint"/>
You would change that line to the following:
<endpoint url="http://your_server_name:8400/samples/messagebroker/streamingamf"
      class="flex.messaging.endpoints.StreamingAMFEndpoint"/>
6     Select J2EE as the Application server type.
7     Select Use Remote Object Access.
8     Select LiveCycle Data Services.
9     If the option is available, deselect Create Combined Java/Flex Project With WTP.
10  Click Next.
11  Deselect Use Default Location For Local LiveCycle Data Services Server.
12  Set the root folder, root URL, and context root of your web application.
The root folder specifies the top-level directory of the web application (the directory that contains the WEB-INF directory). The root URL specifies the URL of the web application, and the context root specifies the root of the web application.
13  Make sure that your BlazeDS server is running, and click Validate Configuration to ensure that your project is valid.
14  Verify that the Compile The Application Locally In Flex Builder option is selected.
15  Clear the Output Folder field to set the directory of the compiled SWF file to the main project directory.
By default, Flex Builder writes the compiled SWF file to the bin-debug directory under the main project directory. To use a different output directory, specify it in the Output Folder field.
16  Click Next.
17  Set the name of the main application file to Chat.mxml, and click Finish.

 Client-side logging
For client-side logging, you directly write messages to the log file, or configure the application to write messages generated by Flex to the log file. Flash Debug Player has two primary methods of writing messages to a log file:
?     The global  trace()  method. The global trace() method prints a String to the log file. Messages can contain checkpoint information to signal that your application reached a specific line of code, or the value of a variable.
?     Logging API. The logging API, implemented by the TraceTarget class, provides a layer of functionality on top of the  trace()  method. For example, you can use the logging API to log debug, error, and warning messages generated by Flex while applications execute.
Flash Debug Player sends logging information to the flashlog.txt file. The operating system determines the location of this file, as the following table shows:
Use settings in the mm.cfg text file to configure Flash Debug Player for logging. If this file does not exist, you can create it when you first configure Flash Debug Player. The location of this file depends on your operating system.
The following table shows where to create the mm.cfg file for several operating systems:
The mm.cfg file contains many settings that you can use to control logging. The following sample mm.cfg file enables error reporting and trace logging:
ErrorReportingEnable=1
TraceOutputFileEnable=1
After you enable reporting and logging, call the  trace()  method to write a String to the flashlog.txt file, as the
following example shows:
trace("Got to checkpoint 1.");
Insert the following MXML line to enable the logging of all Flex-generated debug messages to flashlog.txt:
<mx:TraceTarget loglevel="2"/>

Server-side logging
You configure server-side logging in the logging section of the services configuration file, services-config.xml. By default, output is sent to System.out.
You set the logging level to one of the following available levels:
?     All
?     Debug
?     Info
?     Warn
?     Error
?     None
You typically set the server-side logging level to  Debug  to log all debug messages, and also all info, warning, and error messages. The following example shows a logging configuration that uses the  Debug  logging level:
<logging>
<!-- You may also use flex.messaging.log.ServletLogTarget. -->
<target class="flex.messaging.log.ConsoleTarget" level="Debug">
<properties>
<prefix>[Flex]</prefix>
<includeDate>false</includeDate>
<includeTime>false</includeTime>
<includeLevel>false</includeLevel>
<includeCategory>false</includeCategory>
</properties>
<filters>
<pattern>Endpoint</pattern>
<!--<pattern>Service.*</pattern>-->
<!--<pattern>Message.*</pattern>-->
</filters>
</target>
</logging>

You use two parameters in a channel definition to enable message processing metrics:
     <record-message-times> 
     <record-message-sizes> 
Set these parameters to  true  or  false ; the default value is  false . You can set the parameters to different values to capture only one type of metric. For example, the following channel definition specifies to capture message timing
information, but not message sizing information:
<channel-definition id="my-streaming-amf"
class="mx.messaging.channels.StreamingAMFChannel">
<endpoint
url="http://{server.name}:{server.port}/{context.root}/messagebroker/streamingamf"
class="flex.messaging.endpoints.StreamingAMFEndpoint"/>
 <properties>
  <record-message-times>true</record-message-times>
  <record-message-sizes>false</record-message-sizes>
 </properties>
</channel-definition>

What's Producer?

The BlazeDS core features include the RPC services and the Messaging Service.
You can access data through client-side RPC components that include HTTP GET or POST (HTTP services), SOAP (web services), or Java objects (remote object services).
BlazeDS lets you use RemoteObject components to access remote Java objects without configuring them as SOAP-compliant web services.

Client applications that send messages are called message producers. You define a producer in a Flex application by using the Producer component. Client applications that receive messages are called message consumers. You define a consumer in a Flex application by using the Consumer component. A Consumer component subscribes to a server-side destination and receives messages that a Producer component sends to that destination. For more information on messaging, see Using the Messaging Service.

BlazeDS uses a message-based framework to send data back and forth between the client and server. BlazeDS uses two primary exchange patterns between server and client. In the first pattern, the request-response pattern, the second pattern is the publish-subscribe pattern where the server routes published messages to the set of clients that have subscribed to receive them.

To send messages across the network, the client uses channels. A channel encapsulates message formats, network protocols, and network behaviors to decouple them from services, destinations, and application code. A channel formats and translates messages into a network-specific form and delivers them to an endpoint on the server. 

Channels communicate with Java-based endpoints on the server. An endpoint unmarshals messages in a protocol-specific manner and then passes the messages in generic Java form to the message broker. The message broker determines where to send messages, and routes them to the appropriate service destination.
BlazeDS includes several types of channels, including standard and secure Action Message Format (AMF) channels and HTTP (AMFX) channels. AMF and HTTP channels support non-polling request-response patterns and client polling patterns to simulate real-time messaging. The streaming AMF and HTTP channels provide true data streaming for real-time messaging. 

 Configure an existing J2EE web application to support BlazeDS by performing the following steps: 
 1, Add the BlazeDS JAR files and dependent JAR files to the WEB-INF/lib directory. 
2, Edit the BlazeDS configuration files in the WEB-INF/flex directory. 
3, Define MessageBrokerServlet and a session listener in WEB-INF/web.xml.

　　老实说，在这之前，我很少听说过WAS，也未接触过AIX，但是我作为救火队员，作为新任的项目技术负责人，没有权利说不，只能挑起这根大梁，现在想来有些后怕，但那时可能是“勇者无惧，不知者无畏”，就这样硬着头皮上吧。

　　第一步，找来一台PC机，直接在先用用Windows版本的WAS，花了三个小时，完全是凭着相关的经验，终于把WAS装上了。更大的问题也随之而来，在我们的项目中，第三方的Jar包完全处在失控的状态下，变成了一个超过100M的“大个子”，版本复杂，文件重复，冗余严重，开发人员不管三七二十一的一骨脑往里面加，什么JSF，MyFaces，Hibernate，JDOM，AXIS，POI，IText，Log4J，Apache Common Lib，Quartz，XMLBeans，似乎是只要是开源的，不要钱的就加吧。这样的做法，最直接的结果就是导致我第一次要WAS发布我们项目时，搞了一天部署上去后无法正常启动，寻求多方帮助，也无法解决问题，最终我不得不统统将所有的包全部删除，然后找到能在此WAS版本上所使用的包，然后才加入到lib目录中，而且每加入一个新的框架就做一个版本的备份，做好充分回退的准备。又整整搞了我一天，终于第一次把这个项目Run起来了，当然，这其中充满了曲折，比如不能使用MyFaces的上传文件和树形组件等，真是“痛并快乐着”，因为我喜欢挑战这样的问题，挑战自己。

　　解决了紧急问题后，我想都没想，就直接跑去书店立马买了两本WAS的书，大家清楚WAS的书籍是非常少的，而且质量也并不高，没办法，我得接受现实。花了一周时间把红宝书中最重要（我所意想的最重要）的章节过了一遍，然后开始研究WAS的Cluster，因为客户的生产环境是集群环境，这一过程更是痛苦，一连三天，我都在公司干到凌晨才回家，最终也没有搞定，原因是因为没有IBM Http Server的安装源，导致我无法通过IHS来做负载均衡。那时候，网络上也查不到什么资料，现在想来要是有http://www.webspherechina.net这样的网站就好了，只需要用搜索功能一搜就立马可以解决了。最终，我在经历了五天的痛苦煎熬后找到了答案，同时，也发现了当时惟一一个非官方的网站（http://www.wsuc.tw ，现在这个网站在经历一次数据丢失事故后，基本上没有什么资料了）。

　　紧接着，又是熟悉AIX环境（幸好有Linux基础和AIX的SMIT很好用），经历WAS数据源配置，程序和WAS调优等问题的困扰和解开的过程，每一步都充满辛酸，但解决后会得到真正的快乐。

　　经历了那个冬天的甜酸苦辣，在接下来的另一个采用WAS平台的中型项目中，我成功的完成了架构师的角色，将SSO，多数据源，多周边系统集成等问题可以较完善（还不敢说完美）的解决。也因为此，我成了公司最熟悉WAS的人，我的工作得到大家的认可和尊重，包括在以后的工作中，都没有因为WAS的问题而太多的困扰到我。

　　时间过得真快，一晃到了2008年，也不知道是什么时候，我无意中发现了我们的webspherechina.net论坛，发现这个网站的资料慢慢的多起来，人气渐渐的旺起来。又一个偶然的机会，我通过SNS认识了艾依然，成为了webspherechina.net论坛的版主。在这过程中，我也看到论坛中的朋友们因为WAS的各种问题而困扰，而郁闷，我尽我自己的一份力帮这些朋友们解决问题，让他们快乐起来。因为我曾经也痛苦过，郁闷过，没休息好过，所以我知道朋友们的感受，期望能尽早帮大家解脱出来。

　　后来，我成了论坛的超版，我在论坛的努力也得到了大家的认可，当上了2008年10月的优秀版主，这让我很兴奋，但更让我感动的是，在当前全球性financial crisis的笼罩下，特别是在目前所做的这个电信项目进入快失败的边缘时刻（当然不是WAS引起的，正尽一切努力挽回），加之工作环境中上网不便，使得我无暇更多的参与到论坛中来，但论坛和QQ群里的朋友们依然或默默的支持，或真诚的关心，或给我力量，或一次次告诉我：办法总比问题多。

　　这个“冬天”，其实并不那么冷！

一、关于各工具的使用，我简单的整理总结了一下，列表如下：
ga(IBM Pattern Modeling and Analysis Tool for Java Garbage Collector)  
 分析WAS产生的GC Log的工具
 
jca(IBM Thread and Monitor Dump Analyzer for Java)
 分析WAS OOM时产生的(文件名以javacore开头，后缀名为.txt
  例：javacore.20080731.200248.2324.txt)

ha(IBM HeapAnalyzer)
 分析WAS产生的Java Heap Dump的文件(文件后缀名为.phd)


二、关于在Windows上生成WebSphere的java heap dump 和 java core dump的操作，可以参考我的另一篇文章：
《[转载]如何在Windows 平台获得WASv5.x/6.x的 Java HeapDump和JavaCore 诊断文件? 》

三、相关参考资料：
以下内容来自于WebSphere 的Info Center： 

以手动方式生成堆转储

很不错的文章，不敢独享，特转载来分享给大家
原文出处：http://www.itpub.net/731657.html

具体步骤如下：
1、 设置Windows的环境变量，使WAS JVM在产生javacore的同时产生HeapDump文件（缺省只会产生 javacore)。点击windows桌面－>鼠标右键－属性－进入系统属性对话框－进入高级页面－点击环境变量－在系统变量中－分别加入以下变量名和变量值
变量名 变量值
IBM_HEAPDUMP true
IBM_HEAP_DUMP true
IBM_HEAPDUMPDIR c:\

2、 注销当前用户，重新登录

3、 可以通过手工或windows 服务的方式启动WAS，如果使用手工方式，如下：
===For WAS5.x====
cd c:\WebSphere\AppServer\bin
startServer.bat server1
===For WAS6.x====
cd c:\WebSphere\AppServer\profiles\default\bin
startServer.bat server1

4、 WAS启动正常后，在C:\WebSphere\AppServer\bin或C:\WebSphere\AppServer\profiles\default\bin目录中通过以下命令让JVM产生JavaCore和HeapDump文件
键入wsadmin.bat命令，进入wsadmin管理命令行，键入如下代码：
set jvm [$AdminControl completeObjectName type=JVM,process=server1,*]

$AdminControl invoke $jvm dumpThreads

javacore.TIMESTAMP.NUMBER.txt  文件会自动在C:\WebSphere\AppServer或C:\WebSphere\AppServer\default\或您指定的目录中产生。

$AdminControl invoke $jvm generateHeapDump
生成文件类型名为.phd的文件，这个文件就是完整的堆的dump(此命令为我添加的，这个更有用)

补充：
IBM_HEAPDUMP_OUTOFMEMORY true
IBM_JAVADUMP_OUTOFMEMORY true
WAS在以上两项环境变量的设置下，一旦JVM出现内存申请失败抛出Out of Memory错误时，JVM将会自动产生JavaCore和HeapDump。

在生产环境下，谨慎使用此两项环境变量的设置，以防把文件系统撑爆。

Service serviceModel = new ObjectServiceFactory().create(YourService.class);
YourService service = (YourService)
    new XFireProxyFactory().create(serviceModel, "http://your/remote/url");

Service serviceModel = new AnnotationServiceFactory().create(YourService.class);
YourService client = (YourService)
    new XFireProxyFactory().create(serviceModel, "http://your/remote/url");

Service serviceModel =
  new AnnotationServiceFactory(
   new Jsr181WebAnnotations(),
   XFireFactory.newInstance().getXFire().getTransportManager(),
   new AegisBindingProvider(new JaxbTypeRegistry())).create(YourService.class);

package test;

import java.net.MalformedURLException;
import java.net.URL;

import org.codehaus.xfire.client.Client;

public class DynamicClientTest {
    public static void main(String[] args) throws MalformedURLException,
            Exception {
        Client client = new Client(new URL(
                "http://localhost:8080/xfiretest/services/TestService?wsdl"));
        Object[] results = client
                .invoke("sayHello", new Object[] { "Firends" });
        System.out.println(results[0]);

    }
}

<?xml version="1.0"?>
<project name="wsgen" default="wsgen" basedir=".">
    <path id="classpathId">
        <fileset dir="./WebRoot/WEB-INF/lib">
            <include name="*.jar" />
        </fileset>
    </path>
    <taskdef classpathref="classpathId" name="wsgen" classname="org.codehaus.xfire.gen.WsGenTask">
    </taskdef>
    <target name="wsgen" description="generate client">
        <wsgen outputDirectory="./src/" wsdl="abc.wsdl" binding="xmlbeans" package="com.abc.p" overwrite="true" />
    </target>
</project>

AbcServiceClient client = new AbcServiceClient();
String url = "http://localhost:8080/xfireTest/services/TestService";
String result = client.getAbcPort(url).sayHello("Robin");

gpath=xfire-all-1.2-SNAPSHOT.jar:ant-1.6.5.jar:jaxb-api-2.0EA3.jar:stax-api-1.0.1.jar:jdom-1.0.jar:jaxb-impl-2.0EA3.jar\
:jaxb-xjc-2.0-ea3.jar:wstx-asl-2.9.3.jar:commons-logging-1.0.4.jar:activation-1.1.jar:wsdl4j-1.5.2.jar:XmlSchema-1.0.3.jar:xfire-jsr181-api-1.0-M1.jar;

java -cp $gpath org.codehaus.xfire.gen.WsGen -wsdl http://localhost:8080/xfire/services/Bookservice?wsdl -o . -p pl.tomeks.client -overwrite true

其结果与ANT生成的一样。


四，参考资源：
1，XFire 1.2.6手册(http://xfire.codehaus.org/User%27s+Guide)
2，http://xfire.codehaus.org/Client+API
3，http://xfire.codehaus.org/Dynamic+Client