当前位置: 编程技术>移动开发
本页文章导读:
▪进一步优化Bit地图 Cache策略 进一步优化Bitmap Cache策略上一篇文章中(http://blog.csdn.net/a345017062/article/details/8753649)提到了两种bitmap cache,这篇文章讲一下具体如何确定具体的Bitmap Cache策略。
一、为了更快的理解我们的.........
▪ maven灵活解决环境有关问题 maven灵活解决环境问题maven构建之灵活不必细说,这里举个实际遇到的场景,并给出我如何解决。由于服务器紧张,我的hudson服务器和nexus服务器是部署在同一台的,而这台服务器的外网是映.........
▪ 判断受权是否过期 判断授权是否过期1 self.expireTime = [theExpiredTime intValue]+ [[NSDate date] timeIntervalSince1970];
2
- (BOOL)isAuthorizeExpired
{
if ([[NSDate date] timeIntervalSince1970] > expireTime)
{
//删除操作
.........
[1]进一步优化Bit地图 Cache策略
来源: 互联网 发布时间: 2014-02-18
进一步优化Bitmap Cache策略
上一篇文章中(http://blog.csdn.net/a345017062/article/details/8753649)提到了两种bitmap cache,这篇文章讲一下具体如何确定具体的Bitmap Cache策略。
一、为了更快的理解我们的策略,需要先说一下不同版本的Android系统中,对Bitmap的处理有何不同。
1、Android 2.2 (API level 8),以及更低的版本中,一旦GC开始运行,App的线程就会停止工作,因此会造成App性能的下降。从Android 2.3 (API level 9)开始,添加了concurrent GC,这意味着图片一旦没有引用,就可以很快地被回收。
2、在Android 2.3.3 (API level 10),以及更低的版本中,Bitmap的像素数据被存放在native memory中,而Bitmap对象在Dalvik heap中。所以,Bitmap像素数据的如何回收是未知的,可能会造成内存泄漏,从而导致crash。而到了Android 3.0 (API Level 11),以及更高的版本中,像素数据和Bitmap对象一样被存放在了Dalvik heap中。
接下来,说一下如何针对不同版本的Android系统优化Bitmap的内存管理。
在Android 2.3.3 (API level 10),以及更低的版本中,推荐使用Bitmap.recycle方法加快Bitmap内存的回收。
从Android 3.0 (API Level 11)开始,引入了BitmapFactory.Options.inBitmap,这果这个字段被设置了,则解码时会把重用这个字段所引用的那张Bitmap,避免重新分配内存。但使用这个字段时有一些需要注意的地方:
1、重用的Bitmap和即将被解码的Bitmap必须是相同的尺寸,且是JPEG或者PNG格式的。
2、 BitmapFactory.Options.inPreferredConfig字段设置无效,因为会被重用的Bitmap的configuration所覆盖。
3、一定要使用解码方法返回的Bitmap,因为重用可能会失败。
另外,在Android 3.0 (API Level 11),及以上的版本中,当Bitmap被从LruCache中挤出时,我们可以把这个Bitmap的soft reference存起来当作以后解码时的inBitmap来使用。
本文翻译自:http://developer.android.com/training/displaying-bitmaps/manage-memory.html
上一篇文章中(http://blog.csdn.net/a345017062/article/details/8753649)提到了两种bitmap cache,这篇文章讲一下具体如何确定具体的Bitmap Cache策略。
一、为了更快的理解我们的策略,需要先说一下不同版本的Android系统中,对Bitmap的处理有何不同。
1、Android 2.2 (API level 8),以及更低的版本中,一旦GC开始运行,App的线程就会停止工作,因此会造成App性能的下降。从Android 2.3 (API level 9)开始,添加了concurrent GC,这意味着图片一旦没有引用,就可以很快地被回收。
2、在Android 2.3.3 (API level 10),以及更低的版本中,Bitmap的像素数据被存放在native memory中,而Bitmap对象在Dalvik heap中。所以,Bitmap像素数据的如何回收是未知的,可能会造成内存泄漏,从而导致crash。而到了Android 3.0 (API Level 11),以及更高的版本中,像素数据和Bitmap对象一样被存放在了Dalvik heap中。
接下来,说一下如何针对不同版本的Android系统优化Bitmap的内存管理。
在Android 2.3.3 (API level 10),以及更低的版本中,推荐使用Bitmap.recycle方法加快Bitmap内存的回收。
从Android 3.0 (API Level 11)开始,引入了BitmapFactory.Options.inBitmap,这果这个字段被设置了,则解码时会把重用这个字段所引用的那张Bitmap,避免重新分配内存。但使用这个字段时有一些需要注意的地方:
1、重用的Bitmap和即将被解码的Bitmap必须是相同的尺寸,且是JPEG或者PNG格式的。
2、 BitmapFactory.Options.inPreferredConfig字段设置无效,因为会被重用的Bitmap的configuration所覆盖。
3、一定要使用解码方法返回的Bitmap,因为重用可能会失败。
另外,在Android 3.0 (API Level 11),及以上的版本中,当Bitmap被从LruCache中挤出时,我们可以把这个Bitmap的soft reference存起来当作以后解码时的inBitmap来使用。
本文翻译自:http://developer.android.com/training/displaying-bitmaps/manage-memory.html
[2] maven灵活解决环境有关问题
来源: 互联网 发布时间: 2014-02-18
maven灵活解决环境问题
用profile做了2个配置,一个内网一个外网,默认开启内网。
在外办公使用
这样在外办公时再也不用担心持续集成失败的问题了。
maven构建之灵活不必细说,这里举个实际遇到的场景,并给出我如何解决。
由于服务器紧张,我的hudson服务器和nexus服务器是部署在同一台的,
而这台服务器的外网是映射出去的公网地址。
也就是说本机通过外网地址是无法访问本机的。
代码是托管在Github的,每次push代码到Github,hudson就会做检查,如果发现更新就会做持续集成。
在公司内网地址没问题,但是在外办公或者家里,我项目写的就是外网地址,然后更新提交push。
hudson检查,把代码拉在本地就是公网地址了,然后一集成就出错。因为我构建部署的地址是外网。
那么该如何解决这个纠结的问题呢,maven已经帮你想到了。
请看配置文件:
<profiles> <profile> <id>inner</id> <properties> <distribution.repository>192.168.125.51</distribution.repository> </properties> <activation> <activeByDefault>true</activeByDefault> </activation> </profile> <profile> <id>outer</id> <properties> <distribution.repository>113.128.126.149</distribution.repository> </properties> </profile> </profiles> <distributionManagement> <repository> <id>account</id> <name>account Releases Repository</name> <url>http://${distribution.repository}:8080/nexus/content/repositories/account/</url> </repository> <snapshotRepository> <id>account-snapshots</id> <name>account Snapshot Repository</name> <url>http://${distribution.repository}:8080/nexus/content/repositories/account-snapshots/</url> </snapshotRepository> </distributionManagement>
用profile做了2个配置,一个内网一个外网,默认开启内网。
这样我在公司运行时直接使用,
mvn clean deploy
在外办公使用
mvn clean deploy -Pouter
而hudson执行的命令时
mvn clean deploy
这样在外办公时再也不用担心持续集成失败的问题了。
[3] 判断受权是否过期
来源: 互联网 发布时间: 2014-02-18
判断授权是否过期
1 self.expireTime = [theExpiredTime intValue]+ [[NSDate date] timeIntervalSince1970];
2
- (BOOL)isAuthorizeExpired
{
if ([[NSDate date] timeIntervalSince1970] > expireTime)
{
//删除操作
return YES;
}
return NO;
}
最新技术文章: