Android高效計算——RenderScript（一）

高效計算——RenderScript

RenderScript是安卓平臺上很受谷歌推薦的一個高效計算平臺，它可以自動把計算任務分配到各個可用的計算核心上，包括CPU,GPU以及DSP等，提供十分高效的並行計算能力。多是因爲應用開發時的需求不夠，關於RenderScript的相關文章不多，恰好我在工做中應用到此平臺，作了一些筆記，所以決定整理成博文分享給你們。內容主要來源於官方文檔、StackOverflow以及本身的理解，若有錯誤，請你們指正。本篇主要介紹RenderScript的基本概念。

1 RenderScript簡介

RenderScript是安卓提供的一個高效計算平臺。它顯著的特色在於：

1. 可以自動利用各類核心，包括CPU，GPU以及DSP等，來進行並行計算，能大大提升在圖片處理、數學模型等領域提供高效的計算能力；
2. 不須要針對不一樣的核心平臺而編寫不一樣的代碼，由於RenderScript是在設備上進行運行時編譯的。

使用了RenderScript的應用與通常的安卓應用在代碼編寫上與並無太大區別。使用了RenderScript的應用依然像傳統應用同樣運行在VM中，可是你須要給你的應用編寫你所須要的RenderScript代碼，且這部分代碼運行在native層。

RenderScript採用從屬控制架構：底層RenderScript被運行在虛擬機中的上層安卓系統所控制。安卓VM負責全部內存管理並把它分配給RenderScript的內存綁定到RenderScript運行時，因此RenderScript代碼可以訪問這些內存。安卓框架對RenderScript進行異步調用，每一個調用都放在消息隊列中，而且會被儘快處理。

 

RenderScript工做流程須要經歷三層：

1. RenderScript運行時API：提供進行運算的API
2. 反射層：至關於NDK中的JNI膠水代碼，它是一些由安卓編譯工具自動生成的類，對你寫的RenderScript代碼進行包裝，使得安卓層可以和RenderScript進行交互
3. 安卓框架：經過調用反射層來訪問RenderScript運行時

 

RenderScript的主要優勢：

1. 可移植性：對於不一樣架構，不一樣的處理器都不須要考慮代碼的差別化，由於都是運行時在設備上進行編譯的；
2. 高性能：提供充分利用全部核心的無縫的並行化計算
3. 易用性：簡化編碼，不須要像JNI同樣寫膠水代碼

缺點：

1. 開發複雜：須要去學習新的api
2. 調試可見性：由於RenderScript可能運行在除了主cpu以外的處理器上，因此調試困難 

2  使用RenderScript

    使用RenderScript須要對編譯或者開發環境進行必定的配置。

    使用RenderScript主要分爲兩個步驟：編寫.rs文件以及在Android framework中使用RenderScript，下面分別介紹。

2.1 環境配置

• RenderScript的API能夠有兩種來源方式：

對於Android 3.0 （API level 11）及以上的能夠在android.renderscript包中獲取

經過android.support.v8.renderscript包獲取，能夠支持API level 8及以上的平臺，官方強烈建議使用此支持包的方式來獲取API

• 編譯環境要求：

Android SDK Tools revision 須要22.2及以上

Android SDK Build-tools revision 須要18.1.0及以上

• 在project.properties文件中寫入以下屬性：

renderscript.target=18

renderscript.support.mode=true

或者在AS中的build.gradle的defaultConfig中添加

renderscriptTargetApi 18

renderscriptSupportModeEnabled true

注意：target的值應該爲11及以上，但推薦使用18.若是在Manifest中配置的minSDK的值與target的值不相同，那麼在編譯的時候，將使用target的值替代Mainfest中的minSDK值。

 

2.2 編寫RenderScript文件

RenderScript代碼放在.rs或者.rsh文件中，在RenderScript代碼中包含計算邏輯以及聲明全部必須的變量和指針，一般一個.rs文件包含以下幾個部分：

• 編譯聲明：#pragma rs java_package_name(package.name)，好比#pragma rs java_package_name (com.willhua.RenderScript)，用來聲明本rs所在的java包。注意：.rs文件只能在應用程序包中，而不能在library項目中。
• 編譯聲明：#pragma version(1).聲明RenderScript版本，如今都是1
• 主工做函數root().它會被RenderScript層的reForEach函數調用，實現多處理器對root工做的並行處理。Root函數必須返回void以及接受以下參數

1.分配給RenderScript的輸入輸出地址的指針。在Android3.2以及更低版本中，輸入輸出的指針都須要，在Android4.0及之後的版本中，給出其中一個或者兩個均可以

•     2.下面兩個參數是可選的，可是隻要用了其中一個就必須兩個都提供

　　　　　　　　a)   指向用戶數據的指針。該數據會在RenderScript的計算中用到。該數據能夠指向原始類型或者複雜結構類型

　　　　　　　　b)   用戶數據的大小

從官方文檔來看，老版本的文檔中有介紹root，而新版本的則用kernel替代。官方在弱化root函數的概念，而是推薦使用kernel概念。本質上來講，root僅僅是一個寫法形式上特殊的kernel而已。

• 可選init()函數。能夠用來作任何初始化工做，好比初始化變量。它將會在每次RenderScript啓動的時候，在其餘任何代碼以前執行一次
• 一些invokable函數。這些函數都是單線程函數（kernel函數的工做則是並行工做的），你能夠給這些函數傳遞任意數量的參數。這些函數將會在反射層中生成對應的版本，能夠從Android framework中調用。這些函數通常用來作一些初始化工做或者當作計算任務中的一個串行計算單元任務。注意：invokable函數不能是static的。
• 一些計算內核（compute kernel）。計算內核是並行執行的，它將並行處理輸入Allocation中的每個Element。一個簡單的compute kernel以下：

uchar4 __attribute__((kernel)) invert(uchar4 in, uint32_t x, uint32_t y) {
    uchar4 out = in;
    out.r = 255 - in.r;
    out.g = 255 - in.g;
    out.b = 255 - in.b;
    return out;
}

　　　　compute kernel基本與一個C函數同樣，可是有以下特徵：

　　　　　　a)   __attribute__((kernel))標誌。該標誌表示該函數是一個RenderScript kernel函數，而不是一個invokable函數

　　　　　　b)   in參數及其類型。在RenderScript kernel中，這個參數將會基於傳給kernel的輸入Allocation而自動賦值，且默認狀況下，對於Allocation中每個Element都將會執行一遍kernel函數

　　　　　　c)   返回值及其類型。每次kernel函數執行的返回值將會自動寫入到輸出Allocation的正確位置。RenderScript將會對輸入輸出Allocation進行檢查，若是他們與kernel函數聲明不匹配則將拋出異常。

每一個kernel都應該有一個輸入Allocation或者一個輸出Allocation或者兩者都有，但不能有兩個及以上的輸入或者輸出Allocation。若是須要在kernel中訪問多個輸入或者輸出，則須要聲明rs_allocation全局變量來擔任多餘一個的輸入或者輸出角色，而後再kernel函數或者invokable函數中經過rsGetElementAt_type()或者rsSetElementAt_type()來訪問或者設置相應的Allocation，其中type爲對應Allocation的Element類型對應的數據類型，好比uchar4。

在kernel中，能夠經過可選的xyz參數來獲取當前Element在整個Allocation中的座標值，好比上面的invert中就經過xy來獲取了xy座標值。注意xyz的參數名不能設置爲其餘名稱，且類型必須爲uint32_t。

• 任何要在RenderScript中用到的變量，指針以及結構。這些聲明也能夠在.rsh文件中
• 所須要的script變量。就和C中的全局變量同樣，這些全局變量通常用來傳遞參數給計算kernel。
• 一些靜態變量以及函數。靜態的變量與普通全局變量的區別在於：靜態變量不會在映射在反射層，也即沒法從Android framework中調用；靜態函數就是一個標準的C函數，可是不會映射到反射層，也沒法從Android framework中調用，可是能夠在RenderScript中的kernel或者invokable中調用。若是有變量或者函數須要在RenderScript中使用可是不須要在Java中使用，強烈推薦設置爲static的。
• 可選的精度控制配置，主要有三個等級：

a)   #pragma rs_fp_full：默認的等級。表示的徹底遵照IEEE 754-2008 standard的精度要求

b)   #pragma rs_fp_relaxed：不嚴格的IEEE 754-2008 standard的精度要求

c)   #pragma rs_fp_imprecise：比relaxed更低的精度要求

對於大部分應用來講，使用relaxed精度要求均可以知足要求而無任何反作用 

example.rs :

#pragma version(1)
#pragma rs java_package_name(com.willhua.rgbtoyuv)
#pragma rs_fp_relaxed

typedef struct Point_T{
    int x;
    int y;
}Point;

//script variable
uint32_t inW;
uint32_t inH;
uint32_t inCount;
rs_allocation outYUV;
struct Point point;

//root
void root(const uchar4 *in, uint32_t x, uint32_t y){
    struct myStruct my;
    my.x = 0;
    struct myStruct my2 = my;
    int u = my.x;
    uchar R,G,B;
    int Y,U,V;
    R = (*in).r;
    G = (*in).g;
    B = (*in).b;
    Y = ( (  66 * R + 129 * G +  25 * B + 128) >> 8) +  16;
    uint32_t yIndex = y * inW + x;
    Y = ((Y < 0) ? 0 : ((Y > 255) ? 255 : Y));
    rsSetElementAt_uchar(outYUV, ((uchar)Y), yIndex);
    if((x & 1) == 0 && (y & 1) == 0) {
        U = ( ( -38 * R -  74 * G + 112 * B + 128) >> 8) + 128;
        V = ( ( 112 * R -  94 * G -  18 * B + 128) >> 8) + 128;
        uint32_t index = (y >> 1) * inW + x + inCount;
        U = ((U < 0) ? 0 : ((U > 255) ? 255 : U));
        V = ((V < 0) ? 0 : ((V > 255) ? 255 : V));
        rsSetElementAt_uchar(outYUV, ((uchar)U), index + 1);
        rsSetElementAt_uchar(outYUV, ((uchar)V), index );
    }
}

//compute kernel
__attribute__((kernel)) invert(uchar4 in, uint32_t x, uint32_t y) {
    uchar4 out = in;
    out.r = 255 - in.r;
    out.g = 255 - in.g;
    out.b = 255 - in.b;
    return out;
}
//invokable function
void setInPara(uint32_t w, uint32_t h){
    inW = w;
    inH = h;
    inCount = w * h;
}

//init
void init(){
}

View Code

 

2.3 在Android framework層調用RenderScript

雖然各個應用使用RenderScript細節各不相同，但大致有着這樣的模式：

1. 初始化RenderScript context。經過RenderScript.create函數能夠建立相應的context，有了該context才能夠進行RenderScript的其餘動做，並經過該context能夠控制其餘RenderScript對象的生命週期。由於context的建立須要在不一樣的硬件設備上建立資源，因此可能會比較耗時。所以，最好不要讓context的建立在響應速度要求比較高的時間點上。通常來講，一個應用應該只有一個context。
2. 至少須要建立一個Allocation。用的比較多的方法是createTyped(RenderScript, Type) 或createFromBitmap(RenderScript, Bitmap)。
3. 建立須要的scripts。能夠分爲兩種，一種就是經過自定義.rs文件，而後在反射層自動生成的ScriptC子類，名字爲ScriptC_rsfilename；還有一種就是系統定義的一些scripts，好比高斯模糊等，他們都是ScriptIntrinsic的子類。
4. 給Allocation填充數據。使用Allocation的copy系類方法
5. 設置必要的script變量。在ScriptC_rsfilename會給script變量生成相應的set方法，好比int型名爲num的script變量則會在反射層生成set_num(int)方法。
6. 啓動計算。.rs中定義的kernel函數都會在反射層的ScriptC_rsfilename類中生成forEach_kernalname方法。該方法的執行是異步的，且會在RenderScript中按照kernel調用順序來執行。前面提到過，forEach_kernalname方法默認對對應Allocation中全部的Element執行計算，可是能夠在forEach_kernalname參數的最後傳入一個Scrpit.LunchOptions參數來指定Allocation中須要被計算的子集。.rs中定義的invokable函數則會在反射層生成invoke_functionname的方法，也能夠按需調用
7. 從Allocation中獲得數據。經過Allocation的copyTo系類方法，能夠把Allocation中的數據放到Java數據中。這些copyTo方法與forEach方法保持同步，forEach的計算完成以後就會自動啓動copy過程。目前只支持基本類型的copyTo，暫不支持好比自定義的struct等數據。
8. 釋放資源。經過RenderScript.destory方法來釋放相關資源。 

2.4 RenderScript工做流程

最開始就提到，RenderScript是一個主從架構，底層的RenderScript被上層的Android framework所控制。其工做流程也正是如此。從在Android framework建立RenderScript的context開始，而後給RenderScript層分配、綁定相關內存，對script變量進行初始化，而後調用forEach函數通知啓動RenderScript計算。RenderScript將會自動把它的計算任務分配到各個可用的核心上來完成計算任務（如今還只能支持CPU，之後將會支持到GPU以及DSP，且代碼不須要變更）。RenderScript計算完成之後將會自動把計算結果放到相應的Allocation內存，而後在Android framework層再從Allocation中copy出數據，最後Android framework層命令RenderScript釋放資源，流程介紹。下圖展現了RenderScript的工做流程：