bitmap size exceeds VM budget 的解决...- HttpClient 课程 (三)

当前位置: 编程技术>移动开发

本页文章导读:

▪bitmap size exceeds VM budget 的解决方法 bitmap size exceeds VM budget 的解决办法转载至： http://developer.aiwgame.com/ 昨天遇到这个问题就是从一个输入流里调用BitmapFactory.decodeStream(this.getContentResolver().openInputStream(uri))得到一个bitmap报的错。.........

▪ HttpClient 课程 (三) HttpClient 教程 (三) HttpClient 教程 (三)第三章 HTTP状态管理原始的HTTP是被设计为无状态的，面向请求/响应的协议，没有特殊规定有状态的，贯穿一些逻辑相关的请求/响应交换的会话。由于HTT.........

▪ 常见存储器概念剖解常见存储器概念辨析常见存储器概念辨析：RAM、SRAM、SDRAM、ROM、EPROM、EEPROM、Flash存储器可以分为很多种类，其中根据掉电数据是否丢失可以分为RAM（随机存取存储器）和ROM（只读存储器）.........

[1]bitmap size exceeds VM budget 的解决方法

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

bitmap size exceeds VM budget 的解决办法

转载至： http://developer.aiwgame.com/

昨天遇到这个问题就是从一个输入流里调用BitmapFactory.decodeStream(this.getContentResolver().openInputStream(uri))得到一个bitmap报的错。第一次调用都没问题，第二次再次调用就会报上面那个内存溢出的问题。而且有的手机报有的手机不报。研究了半天终于解决。首先分析了下原因，应该是图片占用的内存超过了系统虚拟机可分配的最大限制。不同手机可能分配的最大值不一样。后来找到解决办法主要是设置BitmapFactory.Options。

BitmapFactory.Options options=new BitmapFactory.Options();
options.inSampleSize = 8;
Bitmap preview_bitmap=BitmapFactory.decodeStream(is,null,options);

上面写死了，其实可以根据内容来动态设置更好。

//decodes image and scales it to reduce memory consumption
private Bitmap decodeFile(File f){
    try {
        //Decode image size
        BitmapFactory.Options o = new BitmapFactory.Options();
        o.inJustDecodeBounds = true;
        BitmapFactory.decodeStream(new FileInputStream(f),null,o);

        //The new size we want to scale to
        final int REQUIRED_SIZE=70;

        //Find the correct scale value. It should be the power of 2.
        int scale=1;
        while(o.outWidth/scale/2>=REQUIRED_SIZE && o.outHeight/scale/2>=REQUIRED_SIZE)
            scale*=2;

        //Decode with inSampleSize
        BitmapFactory.Options o2 = new BitmapFactory.Options();
        o2.inSampleSize=scale;
        return BitmapFactory.decodeStream(new FileInputStream(f), null, o2);
    } catch (FileNotFoundException e) {}
    return null;
}

这样bitmap size exceeds VM budget的文件就解决了

[2] HttpClient 课程 (三)

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

HttpClient 教程 (三)
HttpClient 教程 (三)

第三章 HTTP状态管理
原始的HTTP是被设计为无状态的，面向请求/响应的协议，没有特殊规定有状态的，贯穿一些逻辑相关的请求/响应交换的会话。由于HTTP协议变得越来越普及和受欢迎，越来越多的从前没有打算使用它的系统也开始为应用程序来使用它，比如作为电子商务应用程序的传输方式。因此，支持状态管理就变得非常必要了。
网景公司，一度成为Web客户端和服务器软件开发者的领导方向，在它们基于专有规范的产品中实现了对HTTP状态管理的支持。之后，网景公司试图通过发布规范草案来规范这种机制。它们的努力通过RFC标准跟踪促成了这些规范定义。然而，在很多应用程序中的状态管理仍然基于网景公司的草案而不兼容官方的规范。很多主要的Web浏览器开发者觉得有必要保留那些极大促进标准片段应用程序的兼容性。
3.1 HTTP cookies

Cookie是HTTP代理和目标服务器可以交流保持会话的状态信息的令牌或短包。网景公司的工程师用它来指“魔法小甜饼”和粘住的名字。
HttpClient使用Cookie接口来代表抽象的cookie令牌。在它的简单形式中HTTP的cookie几乎是名/值对。通常一个HTTP的cookie也包含一些属性，比如版本号，合法的域名，指定cookie应用所在的源服务器URL子集的路径，cookie的最长有效时间。
SetCookie接口代表由源服务器发送给HTTP代理的响应中的头部信息Set-Cookie来维持一个对话状态。SetCookie2接口和指定的Set-Cookie2方法扩展了SetCookie。
SetCookie接口和额外的如获取原始cookie属性的能力，就像它们由源服务器指定的客户端特定功能扩展了Cookie接口。这对生成Cookie头部很重要，因为一些cookie规范需要。Cookie头部应该包含在Set-Cookie或Set-Cookie2头部中指定的特定属性。
3.1.1 Cookie版本

Cookie兼容网景公司的草案标准，但是版本0被认为是不符合官方规范的。符合标准的cookie的期望版本是1。HttpClient可以处理基于不同版本的cookie。
这里有一个重新创建网景公司草案cookie示例：
BasicClientCookie netscapeCookie = new BasicClientCookie("name", "value");
netscapeCookie.setVersion(0);
netscapeCookie.setDomain(".mycompany.com");
netscapeCookie.setPath("/");
这是一个重新创建标准cookie的示例。要注意符合标准的cookie必须保留由源服务器发送的所有属性：
BasicClientCookie stdCookie = new BasicClientCookie("name", "value");
stdCookie.setVersion(1);
stdCookie.setDomain(".mycompany.com");
stdCookie.setPath("/");
stdCookie.setSecure(true);
// 精确设置由服务器发送的属性
stdCookie.setAttribute(ClientCookie.VERSION_ATTR, "1");
stdCookie.setAttribute(ClientCookie.DOMAIN_ATTR, ".mycompany.com");
这是一个重新创建Set-Cookie2兼容cookie的实例。要注意符合标准的cookie必须保留由源服务器发送的所有属性：
BasicClientCookie2 stdCookie = new BasicClientCookie2("name", "value");
stdCookie.setVersion(1);
stdCookie.setDomain(".mycompany.com");
stdCookie.setPorts(new int[] {80,8080});
stdCookie.setPath("/");
stdCookie.setSecure(true);
// 精确设置由服务器发送的属性
stdCookie.setAttribute(ClientCookie.VERSION_ATTR, "1");
stdCookie.setAttribute(ClientCookie.DOMAIN_ATTR, ".mycompany.com");
stdCookie.setAttribute(ClientCookie.PORT_ATTR, "80,8080");
3.2 Cookie规范

CookieSpec接口代表了cookie管理的规范。Cookie管理规范希望如下几点：
解析的Set-Cookie规则还有可选的Set-Cookie2头部信息。
验证解析cookie的规则。
格式化给定主机的Cookie头部信息，原始端口和路径。
HttpClient附带了一些CookieSpec的实现：
网景公司草案：这个规范符合由网景通讯发布的原始草案规范。应当避免，除非有绝对的必要去兼容遗留代码。
RFC 2109：官方HTTP状态管理规范并取代的老版本，被RFC 2965取代。
RFC 2965：官方HTTP状态管理规范。
浏览器兼容性：这个实现努力去密切模仿（mis）通用Web浏览器应用程序的实现。比如微软的Internet Explorer和Mozilla的FireFox浏览器。
最佳匹配：’Meta’（元）cookie规范采用了一些基于又HTTP响应发送的cookie格式的cookie策略。它基本上聚合了以上所有的实现到以一个类中。
强烈建议使用Best Match策略，让HttpClient在运行时基于执行上下文采用一些合适的兼容等级。
3.3 HTTP cookie和状态管理参数

这些是用于定制HTTP状态管理和独立的cookie规范行为的参数。
'http.protocol.cookie-datepatterns'：定义了用于解析非标准的expires属性的合法日期格式。只是对兼容不符合规定的，仍然使用网景公司草案定义的expires而不使用标准的max-age属性服务器需要。这个参数期望得到一个java.util.Collection类型的值。集合元素必须是java.lang.String类型，来兼容java.text.SimpleDateFormat的语法。如果这个参数没有被设置，那么默认的选择就是CookieSpec实现规范的值。要注意这个参数的应用。
'http.protocol.single-cookie-header'：定义了是否cookie应该强制到一个独立的Cookie请求头部信息中。否则，每个cookie就被当作分离的Cookie头部信息来格式化。这个参数期望得到一个java.lang.Boolean类型的值。如果这个参数没有被设置，那么默认的选择就是CookieSpec实现规范的值。要注意这个参数仅仅严格应用于cookie规范（RFC 2109和RFC 2965）。浏览器兼容性和网景公司草案策略将会放置所有的cookie到一个请求头部信息中。
'http.protocol.cookie-policy'：定义了用于HTTP状态管理的cookie规范的名字。这个参数期望得到一个java.lang.String类型的值。如果这个参数没有被设置，那么合法的日期格式就是CookieSpec实现规范的值。
3.4 Cookie规范注册表

HttpClient使用CookieSpecRegistry类维护一个可用的cookie规范注册表。下面的规范对于每个默认都是注册过的：
兼容性：浏览器兼容性（宽松策略）。
网景：网景公司草案。
rfc2109：RFC 2109（过时的严格策略）。
rfc2965：RFC 2965（严格策略的标准符合）。
best-match：最佳匹配meta（元）策略。
3.5 选择cookie策略

Cookie策略可以在HTTP客户端被设置，如果需要，在HTTP请求级重写。
HttpClient httpclient = new DefaultHttpClient();
// 对每个默认的强制严格cookie策略
httpclient.getParams().setParameter(
ClientPNames.COOKIE_POLICY, CookiePolicy.RFC_2965);
HttpGet httpget = new HttpGet("http://www.broken-server.com/");
// 对这个请求覆盖默认策略
httpget.getParams().setParameter(
ClientPNames.COOKIE_POLICY, CookiePolicy.BROWSER_COMPATIBILITY);
3.6 定制cookie策略

为了实现定制cookie策略，我们应该创建CookieSpec接口的定制实现类，创建一个CookieSpecFactory实现来创建和初始化定制实现的实例并和HttpClient注册这个工厂。一旦定制实现被注册了，它可以和标准的cookie实现有相同的活性。
CookieSpecFactory csf = new CookieSpecFactory() {
public CookieSpec newInstance(HttpParams params) {
return new BrowserCompatSpec() {
@Override
public void validate(Cookie cookie, CookieOrigin origin)
throws MalformedCookieException {
// 这相当简单
}
};
}
};
DefaultHttpClient httpclient = new DefaultHttpClient();
httpclient.getCookieSpecs().register("easy", csf);
httpclient.getParams().setParameter(
ClientPNames.COOKIE_POLICY, "easy");
3.7 Cookie持久化

HttpClient可以和任意物理表示的实现了CookieStore接口的持久化cookie存储一起使用。默认的CookieStore实现称为BasicClientCookie，这是凭借java.util.ArrayList的一个简单实现。在BasicClientCookie对象中存储的cookie当容器对象被垃圾回收机制回收时会丢失。如果需要，用户可以提供更复杂的实现。
DefaultHttpClient httpclient = new DefaultHttpClient();
// 创建一个本地的cookie store实例
CookieStore cookieStore = new MyCookieStore();
// 如果需要填充cookie
BasicClientCookie cookie = new BasicClientCookie("name", "value");
cookie.setVersion(0);
cookie.setDomain(".mycompany.com");
cookie.setPath("/");
cookieStore.addCookie(cookie);
// 设置存储
httpclient.setCookieStore(cookieStore);
3.8 HTTP状态管理和执行上下文

在HTTP请求执行的过程中，HttpClient添加了下列和状态管理相关的对象到执行上下文中：
'http.cookiespec-registry'：CookieSpecRegistry实例代表了实际的cookie规范注册表。这个属性的值设置在本地内容中，优先于默认的。
'http.cookie-spec'：CookieSpec实例代表真实的cookie规范。
'http.cookie-origin'：CookieOrigin实例代表了真实的源服务器的详细信息。
'http.cookie-store'：CookieStore实例代表了真实的cookie存储。设置在本地内容中的这个属性的值优先于默认的。
本地的HttpContext对象可以被用来定制HTTP状态管理内容，先于请求执行或在请求执行之后检查它的状态：
HttpClient httpclient = new DefaultHttpClient();
HttpContext localContext = new BasicHttpContext();
HttpGet httpget = new HttpGet("http://localhost:8080/");
HttpResponse response = httpclient.execute(httpget, localContext);
CookieOrigin cookieOrigin = (CookieOrigin) localContext.getAttribute(
ClientContext.COOKIE_ORIGIN);
System.out.println("Cookie origin: " + cookieOrigin);
CookieSpec cookieSpec = (CookieSpec) localContext.getAttribute(
ClientContext.COOKIE_SPEC);
System.out.println("Cookie spec used: " + cookieSpec);
3.9 每个用户/线程的状态管理

我们可以使用独立的本地执行上下文来实现对每个用户（或每个线程）状态的管理。定义在本地内容中的cookie规范注册表和cookie存储将会优先于设置在HTTP客户端级别中默认的那些。
HttpClient httpclient = new DefaultHttpClient();
// 创建cookie store的本地实例
CookieStore cookieStore = new BasicCookieStore();
// 创建本地的HTTP内容
HttpContext localContext = new BasicHttpContext();
// 绑定定制的cookie store到本地内容中
localContext.setAttribute(ClientContext.COOKIE_STORE, cookieStore);
HttpGet httpget = new HttpGet("http://www.google.com/");
// 作为参数传递本地内容
HttpResponse response = httpclient.execute(httpget, localContext)

[3] 常见存储器概念剖解

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

常见存储器概念辨析

常见存储器概念辨析：RAM、SRAM、SDRAM、ROM、EPROM、EEPROM、Flash存储器可以分为很多种类，其中根据掉电数据是否丢失可以分为RAM（随机存取存储器）和ROM（只读存储器），其中RAM的访问速度比较快，但掉电后数据会丢失，而ROM掉电后数据不会丢失。
ROM和RAM指的都是半导体存储器，ROM是Read Only Memory的缩写，RAM是Random Access Memory的缩写。ROM在系统停止供电的时候仍然可以保持数据，而RAM通常都是在掉电之后就丢失数据，典型的RAM就是计算机的内存。

RAM 又可分为SRAM（Static RAM/静态存储器）和DRAM（Dynamic RAM/动态存储器）。SRAM 是利用双稳态触发器来保存信息的，只要不掉电，信息是不会丢失的。DRAM是利用MOS（金属氧化物半导体）电容存储电荷来储存信息，因此必须通过不停的给电容充电来维持信息，所以DRAM 的成本、集成度、功耗等明显优于SRAM。 SRAM速度非常快，是目前读写最快的存储设备了，但是它也非常昂贵，所以只在要求很苛刻的地方使用，譬如CPU的一级缓冲，二级缓冲。DRAM保留数据的时间很短，速度也比SRAM慢，不过它还是比任何的ROM都要快，但从价格上来说DRAM相比SRAM要便宜很多，计算机内存就是DRAM的。

而通常人们所说的SDRAM 是DRAM 的一种，它是同步动态存储器，利用一个单一的系统时钟同步所有的地址数据和控制信号。使用SDRAM不但能提高系统表现，还能简化设计、提供高速的数据传输。在嵌入式系统中经常使用。

ROM也有很多种，PROM是可编程的ROM，PROM和EPROM（可擦除可编程ROM）两者区别是，PROM是一次性的，也就是软件灌入后，就无法修改了，这种是早期的产品，现在已经不可能使用了，而EPROM是通过紫外光的照射擦出原先的程序，是一种通用的存储器。另外一种EEPROM是通过电子擦出，价格很高，写入时间很长，写入很慢。

Flash也是一种非易失性存储器（掉电不会丢失），它擦写方便，访问速度快，已大大取代了传统的EPROM的地位。由于它具有和ROM一样掉电不会丢失的特性，因此很多人称其为Flash ROM。FLASH存储器又称闪存，它结合了ROM和RAM的长处，不仅具备电子可擦出可编程（EEPROM）的性能，还不会断电丢失数据同时可以快速读取数据（NVRAM的优势），U盘和MP3里用的就是这种存储器。在过去的20年里，嵌入式系统一直使用ROM（EPROM）作为它们的存储设备，然而近年来Flash全面代替了ROM（EPROM）在嵌入式系统中的地位，用作存储bootloader以及操作系统或者程序代码或者直接当硬盘使用（U 盘）。

目前Flash主要有两种NOR Flash和NADN Flash。NOR Flash的读取和我们常见的SDRAM的读取是一样，用户可以直接运行装载在NOR FLASH里面的代码，这样可以减少SRAM的容量从而节约了成本。NAND Flash没有采取内存的随机读取技术，它的读取是以一次读取一快的形式来进行的，通常是一次读取512个字节，采用这种技术的Flash比较廉价。用户不能直接运行NAND Flash上的代码，因此好多使用NAND Flash的开发板除了使用NAND Flah以外，还作上了一块小的NOR Flash来运行启动代码。

一般小容量的用NOR Flash，因为其读取速度快，多用来存储操作系统等重要信息，而大容量的用NAND FLASH，最常见的NAND FLASH应用是嵌入式系统采用的DOC（Disk On Chip）和我们通常用的“闪盘”，可以在线擦除。目前市面上的FLASH 主要来自Intel，AMD，Fujitsu和Toshiba，而生产NAND Flash的主要厂家有Samsung和Toshiba。