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

图片缩放和旋转

Android图片缩放总结及比较
 原文链接：http://www.linuxidc.com/Linux/2011-08/40109.htm

 

 

使用Matrix类对图片进行 等比例缩放和旋转：

// 加载需要操作的图片
		Bitmap bitmapOrg = BitmapFactory.decodeResource(getResources(),
				R.drawable.default_screen);
		// 获取这个图片的宽和高
		int width = bitmapOrg.getWidth();
		int height = bitmapOrg.getHeight();

		// 定义预转换成的图片的宽和高
		int newWidth = 162;
		int newHight = 170;

		// 计算缩放率，新尺寸除原尺寸
//		float scaleWidth = (float) newWidth / width;
//		float scaleHeight = (float) newHight / height;
		float scaleWidth = 0.3f;
		float scaleHeight = 0.3f;
		// 创建操作图片用的matrix对象
		Matrix matrix = new Matrix();
		// 缩放图片动作
		matrix.postScale(scaleWidth, scaleHeight);
		//旋转图片动作
		matrix.postRotate(90);

		// 创建新的图片
		Bitmap resizedBitmap = Bitmap.createBitmap(bitmapOrg, 0, 0, width,
				height, matrix, true);
		// 将上面创建的Bitmap转换成Drawable对象，使得其可以使用在imageView，imageButton上。
		BitmapDrawable bitmapDrawable = new BitmapDrawable(resizedBitmap);
		ImageView imageView = (ImageView)findViewById(R.id.imageView1);
		imageView.setImageBitmap(resizedBitmap);

 

    

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

总结一下对buffer的学习体会

很多人讲lockcanvas，没有讲清楚到底是怎么回事。

 

问题1：lockcanvas出来的canvas到底是什么东西？ 里面的位图到底是什么？

问题2：整个android系统到底有多少个Buffer？android的多个进程又是通过什么方式来共享buffer的。

 

先讲一个静态基本概念：

ISurfaceTexture 是一个很关键的概念，建立了客户端Buffer与服务端的连接通道。

在ISurfaceTexture.h文件中可以看到另外一个本地接口BnSurfaceTexture，这个是作为服务器端的接口而存在的。

 

最重要的是如下几个接口。

 

    virtual status_t requestBuffer(int slot, sp<GraphicBuffer>* buf) = 0;

  virtual status_t dequeueBuffer(int *slot, uint32_t w, uint32_t h,
            uint32_t format, uint32_t usage) = 0;

   virtual status_t queueBuffer(int slot, int64_t timestamp,
            uint32_t* outWidth, uint32_t* outHeight, uint32_t* outTransform) = 0;
    virtual void cancelBuffer(int slot) = 0;

 这个四个接口android的帧缓冲的管理方式的关键所在。

Surface_lockCanvas 是个很关键的方法。在android_view_Surface.cpp中：

 按照本人的分析风格，只看关键部分。其余全删除。

static jobject Surface_lockCanvas(JNIEnv* env, jobject clazz, jobject dirtyRect)
{
    status_t err = surface->lock(&info, &dirtyRegion);
    SkCanvas* nativeCanvas = (SkCanvas*)env->GetIntField(canvas, no.native_canvas);
    SkBitmap bitmap;
     bitmap.setPixels(info.bits);
    nativeCanvas->setBitmapDevice(bitmap);  return canvas;}

非常简单的几句代码，就得到了一个canvas。canvas中的bitmap是从info得到的Pixels。

   所以看到这里。就必须去看这一句。

 

    status_t err = surface->lock(&info, &dirtyRegion);

在目录 frameworks/base/libs/gui/Surface.cpp中，有这么几行：

   

 按照本人的分析风格，只看关键部分。其余全删除。

status_t Surface::lock(SurfaceInfo* other, Region* inOutDirtyRegion) {
    status_t err = SurfaceTextureClient::lock(&outBuffer, inOutDirtyBounds);
}

 这几行代码再简单不过了，只是继续lock而已，一次转发。

 

在目录 frameworks/base/libs/gui/SurfaceTextureClient.cpp中，有这么几行

 按照本人的分析风格，只看关键部分。其余全删除。这段代码重要的不是lockBuffer，lockBuffer的附加效果才是最重要的，也就是dequeueBuffer。

 

status_t SurfaceTextureClient::lock(
        ANativeWindow_Buffer* outBuffer, ARect* inOutDirtyBounds)
{
        int err = SurfaceTextureClient::connect(NATIVE_WINDOW_API_CPU);
        ANativeWindowBuffer* out;
    status_t err = dequeueBuffer(&out);
        sp<GraphicBuffer> backBuffer(GraphicBuffer::getSelf(out));
        err = lockBuffer(backBuffer.get());                      

const sp<GraphicBuffer>& frontBuffer(mPostedBuffer);
             copyBlt(backBuffer, frontBuffer, copyback);
            void* vaddr;
            status_t res = backBuffer->lock(
                    GRALLOC_USAGE_SW_READ_OFTEN | GRALLOC_USAGE_SW_WRITE_OFTEN,
                    newDirtyRegion.bounds(), &vaddr);
            mLockedBuffer = backBuffer;
            outBuffer->width  = backBuffer->width;
            outBuffer->height = backBuffer->height;
            outBuffer->stride = backBuffer->stride;
            outBuffer->format = backBuffer->format;
            outBuffer->bits   = vaddr;
        }
    }
    return err;
}

 上面代码中的lockBuffer一看就猜个大概就是锁住一个临界区域。

int SurfaceTextureClient::lockBuffer(android_native_buffer_t* buffer) {
    LOGV("SurfaceTextureClient::lockBuffer");
    Mutex::Autolock lock(mMutex);
    return OK;
}

 

文件在frameworks/base/include/gui/ISurfaceTexture.h，有几个成员函数：

   virtual status_t requestBuffer(int slot, sp<GraphicBuffer>* buf) = 0;

  virtual status_t dequeueBuffer(int *slot, uint32_t w, uint32_t h,
            uint32_t format, uint32_t usage) = 0;

   virtual status_t queueBuffer(int slot, int64_t timestamp,
            uint32_t* outWidth, uint32_t* outHeight, uint32_t* outTransform) = 0;
    virtual void cancelBuffer(int slot) = 0;

    这仅仅是一些客户端的接口，最终通过

 

class BnSurfaceTexture : public BnInterface<ISurfaceTexture>
{
public:
    virtual status_t    onTransact( uint32_t code,
                                    const Parcel& data,
                                    Parcel* reply,
                                    uint32_t flags = 0);
};

 

的子类 SurfaceTexture，文件在 目录 frameworks/base/libs/gui/SurfaceTexture.cpp

和frameworks/base/include/gui/SurfaceTexture.h

   

    

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

《Maven 实战》读书笔记（五） Maven的生命周期 和插件
1.  Maven的生命周期

Maven的生命周期其实是指它对所有的构建过程进行了反复的推敲、反思，之后总结了一套高度抽象过程。这个过程是高度完善的、容易扩展的。基本上包含了项目的清理、初始化、编译、测试、打包、集成测试、验证、部署、、站点生成等步骤，几乎所有的项目生命周期也就这样。Maven项目周期是一个抽象的概念，这个概念性的东西意味着它并不做任何实质性的事情，也就是说：它就像接口，只定义规范，具体细节它不管。具体的实现细节则交给了Maven的各个丰富的插件。Maven的插件机制有可能是跟Eclipse学的，基于一个内核core，定义一堆流程性的东西，让插件去实现这些规范。其他组织也可以根据这套规范插入自己的东西，形成有特色化的、自定制的Maven。

Maven有三套相互独立的生命周期，分别是：clean、default、site。clean主要是清理项目、default是Maven最核心的的构建项目、site是生成项目站点。每一个大的生命周期又分为很多个阶段。后面的阶段依赖于前面的阶段，这点有点像Ant的构建依赖。生命周期本身相互独立，用户可以仅仅调用生命周期的某一个阶段，也就是说用户调用了default周期的任何阶段，并不会触发clean周期以及site周期的任何事情。

2.  Maven生命周期阶段详解

3大生命周期蕴含着小小的阶段，我们按顺序看一下

clean周期：

pre-clean：准备清理

clean：真正的清理工作

post-clean：执行清理后的一些后续工作

default周期：

validate：验证

initialize：初始化配置

generate-sources：生成源代码编译目录

process-sources：处理项目主资源文件，复制资源文件到outputclasspath

generate-resources：生成资源目录

process-resources：处理资源文件

complie：编译源代码

process-classes：处理编译后文件

generate-test-sources：生成测试目录

process-test-sources：处理项目测试资源文件，复制测试资源文件到outputclasspath

generate-test-resources：生成测试资源文件

process-test-resources：处理测试资源文件

test-compile：编译测试代码

process-test-classes:处理测试代码

test：单元测试运行测试代码

prepare-package：打包前的准备

package：将编译好的代码打包成为jar或者war或者ear等等

pre-integration-test：准备整体测试

integration-test：整体测试

post-integration-test：为整体测试收尾

verify：验证

install：安装到本地Maven库

deploy：将最终包部署到远程Maven仓库

site周期：

pre-site：准备生成站点

site：生成站点及文档

post-site：站点收尾

site-deploy：将生成的站点发布到服务器上

比如说在命令行执行了

mvn clean  

就是执行到clean周期的clean阶段。也就是说实际执行了pre-clean阶段与clean阶段。

mvn deploy  

就是执行了整个default生命周期

mvn clean deploy site-deploy  

这个就是执行了clean周期的前两个阶段、default周期的所有阶段、site周期的所有阶段。

3.  Maven的插件机制

之前我们就说了Maven的生命周期仅仅是个抽象的标准，不干实事的，真正干事的人藏在了幕后，就是Maven插件。插件本身为了能够代码复用，往往一个插件实现了很多功能，这个如果我们做过Eclipse插件开发的人也许更清楚，比如一个Eclipse的SVN插件，即实现了可以查看远程SVN资源库的信息，也可以下载远程代码，还可以上传代码。这实际上是3个功能，而由一个jar实现。在Maven中，管这个叫做“目标”。比如maven-dependency-plugin基于项目依赖实现了很多事情，分析依赖、列出依赖树、分析依赖来源等等。每个功能对应着一个插件的目标，插件的目标越多，插件的功能越多。比如

mvn dependency:analyze  

就是使用maven-dependency-plugin插件的analyze目标，分析项目的依赖。

    [WARNING] Unused declared dependencies found:  
    [WARNING]    org.springframework:spring-core:jar:2.5.6:compile  
    [WARNING]    org.springframework:spring-beans:jar:2.5.6:compile  

Maven的生命周期与Maven插件是项目绑定的，Maven默认地将一些默认插件的目标与Maven的生命周期维系在了一起，比如default的compile这个阶段就是和maven-compiler-plugin这个插件的compile目标维系着不可分割的关系。前者是领导，复杂发号施令，指定规则，后者是小兵，专门根据任务干活儿的人。为了不让用户不用任何配置就能进行一般程度的项目构建，Maven默认给自己生命周期的核心阶段绑定了自己的插件。

clean如下：

生命周期阶段


插件目标

pre-clean

clean

maven-clean-plugin:clean

post-clean

site如下：

生命周期阶段

插件目标

pre-site

site

maven-site-plugin:site

post-site

site-deploy

maven-site-plugin:deploy

最麻烦的就是最核心的default

生命周期阶段


插件目标

process-resources

maven-resources-plugin:resources

compile

maven-compiler-pugin:compile

process-test-resources

maven-resources-plugin:testResources

test-compile

maven-compiler-plugin:testCompile

test

maven-surefire-plugin:testCompile

package

maven-jar-plugin:jar

install

maven-install-plugin:install

deploy

maven-deploy-plugin:deploy

其他没绑定插件的就是说没有什么实际行为。

在我们自己的项目中绑定插件，比如在pom.xml内容添加如下内容

    <build>  
        <resources>  
            <resource>  
                <directory>src/main/resource</directory>  
            </resource>  
        </resources>  
        <plugins>  
            <plugin>  
                <groupId>org.apache.maven.plugins</groupId>  
                <artifactId>maven-source-plugin</artifactId>  
                <version>2.1.1</version>  
                <executions>  
                    <execution>  
                        <id>buildSource</id>  
                        <phase>verify</phase>  
                        <goals>  
                            <goal>jar-no-fork</goal>  
                        </goals>  
                        <inherited>false</inherited>  
                        <configuration>  
                        </configuration>  
                    </execution>  
                </executions>  
            </plugin>  
        </plugins>  
    </build>  

之后执行命令

mvn verify 

看到输出文件夹就包含了我们的源代码source的jar。这个打包源代码的“目标”被绑定到了default周期的verify执行。还有一点就是有些插件一旦写上了pom.xml会有默认的绑定周期，比如就拿以上插件说事，如果将<phase>verify</phase>去掉，执行

mvn package

源代码依然输出，其实它默认适合default周期的package阶段绑定的。Goals代表该插件的某些目标（功能）。

插件还能进行全局性质的参数配置，参数是什么就不用多说了吧，大家接触linux的都知道吧。Configuration就是配置参数的。

    <plugin>  
        <groupId>org.apache.maven.plugins</groupId>  
        <artifactId>maven-compiler-plugin</artifactId>  
        <version>2.1</version>  
        <configuration>  
            <target>1.5</target>  
        </configuration>  
    </plugin> 

4.  Maven插件的详细信息

如果想获取插件的详细信息，一种途径就是通过在线官网查询（google一下就知道了），一种就是利用它的另一个插件，maven-help-plugin。比如在命令行输入如下

    mvn help:describe -D plugin=org.apache.maven.plugins:maven-compiler-plugin:2.1   

效果如下，显示了一些插件的信息

    Name: Maven Compiler Plugin  
    Description: The Compiler Plugin is used to compile the sources of your  
      project.  
    Group Id: org.apache.maven.plugins  
    Artifact Id: maven-compiler-plugin  
    Version: 2.1  
    Goal Prefix: compiler  
      
    This plugin has 3 goals:  
      
    compiler:compile  
      Description: Compiles application sources  
      
    compiler:help  
      Description: Display help information on maven-compiler-plugin.  
        Call  
          mvn compiler:help -Ddetail=true -Dgoal=<goal-name>  
        to display parameter details.  
      
    compiler:testCompile  
      Description: Compiles application test sources.  
      
    For more information, run 'mvn help:describe [...] -Ddetail'  

需要注意的就是Goal Prefix: compiler这里，是代表该插件的目标前缀写法，我称之为目标简写，也就是说你可以简写为

mvn compiler:compile 

就可以使用maven的maven-compiler-plugin插件完成编译项目的功能了。其实使用 “插件:目标”的方式是适合该功能不方便与Maven生命周期绑定的情况下。

5.  总结

这次主要概括了Maven的生命周期以及它的插件机制和插件的使用。生命周期是Maven核心的东西，插件也是Maven核心的东西，所以还是有必要看看的。下次我们单独来看看之前没提到的解析机制，包括Maven仓库的依赖解析和Maven插件的解析机制。