来源: 互联网  发布时间: 2014-02-18

TabActivity 无法bindService 解决方法(转)
如果使用TabActivity来进行开发，并且程序需要针对TabActivity中TabHost中的每一个Activity单独绑定一个Service，通常做法是在对应Tab页的Activity的onCreate()方法中进行bind service 操作，但是通过实践表明这个方法是无法达到绑定效果，Google Android Issue中有这个缺陷，缺陷详细信息在这里(Google Android Issue 2483)



解决方法：

Using getApplicationContext().bindService instead of just bindService on your activity solves the problem as it is using the higher level application context.



即在TabActivy的TabHost中的Activity如果需要bindService的话，需要先调用getApplicationContext()获取其所属的Activity的上下文环境才能正常bindService，也就是在onCreate()方法中使用this.getApplicationContext().bindService([args…])就可以了,否则bindService将永远失败返回false，remote service 返回也为null。

    

    来源: 互联网  发布时间: 2014-02-18

功能点Url集合
1.如何理解JVM相关参数设置
http://wenku.baidu.com/view/3863bf649b6648d7c1c746b1.html

    

    来源: 互联网  发布时间: 2014-02-18

【转】有关Http Header中Keep-Alive的说明
Keep-alive是指在同一个连接中发出和接收多次HTTP请求。优点是：

使用较少的CPU和内存
开启HTTP 管道
减少网络拥堵
在接下来的请求中，减少传输时间。
错误可以被报告但是不关闭TCP连接。
在RFC 2617第47页里，一个用户客户端对任何服务器或代理不能维持2个以上的连接。代理可以维持2xN个连接。

IE6和7使用 2个长连接，IE8使用6个，都是在60秒之后超时。 Firefox的长连接都是在300秒超时，同时使用的连接可以自定义（按每主机或总计），Opera与Firefox类似。




HTTP Keep-Alive
Keep-Alive功能使客户端到服务器端的连接持续有效，当出现对服务器的后继请求时，Keep-Alive功能避免了建立或者重新建立连接。市场上的大部分Web服务器，包括iPlanet、IIS和Apache，都支持HTTP Keep-Alive。对于提供静态内容的网站来说，这个功能通常很有用。但是，对于负担较重的网站来说，这里存在另外一个问题：虽然为客户保留打开的连接有一定的好处，但它同样影响了性能，因为在处理暂停期间，本来可以释放的资源仍旧被占用。当Web服务器和应用服务器在同一台机器上运行时，Keep- Alive功能对资源利用的影响尤其突出。

为什么有些apache服务器，负载很高，把Keep-Alive关掉负载就减轻了呢？
apache 有两种工作模式，prefork和worker。apache 1.x只有，prefork。
prefork比较典型，就是个进程池，每次创建一批进程,还有apache是基于select实现的。在用户不是太多的时候，长连接还是很有用的，可以节约分组，提升响应速度，但是一旦超出某个平衡点，由于为了保持很多长连接，创建了太多的进程，导致系统不堪重负，内存不够了，开始换入换出，cpu也被很多进程吃光了,load上去了。这种情况下，对apache来说，每次请求重新建立连接要比保持这么多长连接和进程更划算。

KeepAliveTime 值控制 TCP/IP 尝试验证空闲连接是否完好的频率。如果这段时间内没有活动，则会发送保持活动信号。如果网络工作正常，而且接收方是活动的，它就会响应。如果需要对丢失接收方敏感，换句话说，需要更快地发现丢失了接收方，请考虑减小这个值。如果长期不活动的空闲连接出现次数较多，而丢失接收方的情况出现较少，您可能会要提高该值以减少开销。缺省情况下，如果空闲连接 7200000 毫秒（2 小时）内没有活动，Windows 就发送保持活动的消息。通常，1800000 毫秒是首选值，从而一半的已关闭连接会在 30 分钟内被检测到。 KeepAliveInterval 值定义了如果未从接收方收到保持活动消息的响应，TCP/IP 重复发送保持活动信号的频率。当连续发送保持活动信号、但未收到响应的次数超出 TcpMaxDataRetransmissions 的值时，会放弃该连接。如果期望较长的响应时间，您可能需要提高该值以减少开销。如果需要减少花在验证接收方是否已丢失上的时间，请考虑减小该值或 TcpMaxDataRetransmissions 值。缺省情况下，在未收到响应而重新发送保持活动的消息之前，Windows 会等待 1000 毫秒（1 秒）。 KeepAliveTime 根据你的需要设置就行，比如10分钟，注意要转换成MS。 XXX代表这个间隔值得大小。




Apache的KeepAlive的设置。

KeepAlive在Apache Core中的设置说明：
Keep-Alive扩展自HTTP/1.0和HTTP/1.1的持久链接特性。提供了长效的HTTP会话，用以在同一个TCP连接中进行多次请求。在某些情况下，这样的方式会对包含大量图片的HTML文档造成的延时起到50%的加速作用。在Apache1.2版本以后，您可以设置 KeepAlive On 以启用持久链接。
对于HTTP/1.0的客户端来说，仅当客户端指定使用的时候才会使用持久链接连接。此外，仅当能够预先知道传输的内容长度时，才会与HTTP /1.0的客户端建立持久链接连接。这意味着那些长度不定的内容，诸如CGI输出、SSI页面、以及服务器端生成的目录列表等内容一般来说将无法使用与 HTTP/1.0客户端建立的持久链接连接。而对于HTTP/1.1的客户端来说，如果没有进行特殊指定，持久将是默认的连接方式。如果客户端进行了请求，将使用分块编码以解决在持久链接里发送未知长度内容的问题。

另一个相关的是KeepAliveTimeout在Apache Core中的设置说明：
Apache在关闭持久连接前等待下一个请求的秒数。一旦收到一个请求，超时值将会被设置为Timeout指令指定的秒数。
对于高负荷服务器来说，KeepAliveTimeout值较大会导致一些性能方面的问题：超时值越大，与空闲客户端保持连接的进程就越多。

最后还有一个相关的是MaxKeepAliveRequests在Core中的说明：
MaxKeepAliveRequests指令限制了当启用KeepAlive时，每个连接允许的请求数量。如果将此值设为"0"，将不限制请求的数目。我们建议最好将此值设为一个比较大的值，以确保最优的服务器性能。

通过Apache的设置说明，我们已经能明白KeepAlive的原理。在对于一个包含许多图片的网页来说，客户端会在瞬间发出多个HTTP请求，此时多次建立TCP连接会大大降低响应速度。此时通过持续连接，可以允许用户在一个TCP连接中发出多个HTTP请求，减少TCP连接建立次数，提高响应速度。我们可以通过access_log统计出连续HTTP请求出现的次数、间隔时间、访问量，以确定 MaxKeepAliveRequests 和 KeepAliveTimeout 的值。 KeepAliveTimeout 太小发挥不了持续连接的作用；太大了，持续连接迟迟不断， 浪费TCP连接数不说，更糟糕的是系统中的 httpd 进程数目会因此不断增加，使得系统负载升高，甚至会导致服务器失去响应。

但是当你的服务器只是在处理动态网页请求时，由于用户很少会瞬间请求多个动态网页 （一般都是打开页面之后阅读好半天才点下一页），此时打开KeepAlive无异于浪费TCP连接数。

哪么什么决定着我们是不是要开启KeepAlive的因素就很简单的确定出来了，就是说在用户一个页面请求中是否会向服务器发出多个HTTP的请求。
转自http://blog.sina.com.cn/gogogo45