android 队列执行动画,Android 重学系列 渲染图层-图元缓冲队列初始化
前言
經(jīng)過上一篇文章，對開機啟動動畫的流程梳理，引出了實際上在開機啟動動畫中，并沒有Activity，而是通過OpenGL es進行渲染，最后通過某種方式，把數(shù)據(jù)交給Android渲染系統(tǒng)。
本文，先來探索在調(diào)用OpenGL es進行渲染的前期準備。
正文
讓我們回憶一下，上一篇開機動畫OpenGL es 使用步驟，大致分為如下幾個：
1.SurfaceComposerClient::getBuiltInDisplay 從SF中查詢可用的物理屏幕
2.SurfaceComposerClient::getDisplayInfo 從SF中獲取屏幕的詳細信息
3.session()->createSurface 通過Client創(chuàng)建繪制平面控制中心
4.t.setLayer(control, 0x40000000) 設置當前l(fā)ayer的層級
5.control->getSurface 獲取真正的繪制平面對象
6.eglGetDisplay 獲取opengl es的默認主屏幕，加載OpenGL es
7.eglInitialize 初始化屏幕對象和著色器緩存
8.eglChooseConfig 自動篩選出最合適的配置
9.eglCreateWindowSurface 從Surface中創(chuàng)建一個opengl es的surface
10.eglCreateContext 創(chuàng)建當前opengl es 的上下文
11.eglQuerySurface 查找當前環(huán)境的寬高屬性
12.eglMakeCurrent 把上下文Context，屏幕display還有渲染面surface,線程關(guān)聯(lián)起來。
13.調(diào)用OpenGL es本身特性，繪制頂點，紋理等。
eglSwapBuffers 交換繪制好的緩沖區(qū)
15.銷毀資源
我們就沿著這個邏輯看看在這個過程中Android的渲染系統(tǒng)在其中擔任了什么角色。
SurfaceComposerClient::getBuiltInDisplay
sp SurfaceComposerClient::getBuiltInDisplay(int32_t id) {
return ComposerService::getComposerService()->getBuiltInDisplay(id);
}
ComposerService本質(zhì)上是ISurfaceComposer 一個BpBinder對象，對應著BnBinder對象是SF，也就到了SF的getBuiltInDisplay。
SF getBuiltInDisplay
sp SurfaceFlinger::getBuiltInDisplay(int32_t id) {
if (uint32_t(id) >= DisplayDevice::NUM_BUILTIN_DISPLAY_TYPES) {
return nullptr;
}
return mBuiltinDisplays[id];
}
還記得我初始化第一篇聊過這個數(shù)據(jù)結(jié)構(gòu)嗎？mBuiltinDisplays 將會持有根據(jù)每一個displayID也同時displayType持有一個BBinder作為核心。然而此時的BBinder只是一個通信基礎，還沒有任何處理命令的邏輯。我們需要看下面那個方法做了什么？
SurfaceComposerClient::getDisplayInfo
status_t SurfaceComposerClient::getDisplayConfigs(
const sp& display, Vector* configs)
{
return ComposerService::getComposerService()->getDisplayConfigs(display, configs);
}
int SurfaceComposerClient::getActiveConfig(const sp& display) {
return ComposerService::getComposerService()->getActiveConfig(display);
}
status_t SurfaceComposerClient::getDisplayInfo(const sp& display,
DisplayInfo* info) {
Vector configs;
status_t result = getDisplayConfigs(display, &configs);
if (result != NO_ERROR) {
return result;
}
int activeId = getActiveConfig(display);
if (activeId < 0) {
ALOGE("No active configuration found");
return NAME_NOT_FOUND;
}
*info = configs[static_cast(activeId)];
return NO_ERROR;
}
該方法通過了兩次Binder通信進行屏幕數(shù)據(jù)的獲取，第一次getDisplayConfigs，如果成功則getDisplayConfigs獲取第二次。
SF getDisplayConfigs
status_t SurfaceFlinger::getDisplayConfigs(const sp& display,
Vector* configs) {
...
int32_t type = NAME_NOT_FOUND;
for (int i=0 ; i<:num_builtin_display_types i>
if (display == mBuiltinDisplays[i]) {
type = i;
break;
}
}
if (type < 0) {
return type;
}
// TODO: Not sure if display density should handled by SF any longer
class Density {
static int getDensityFromProperty(char const* propName) {
char property[PROPERTY_VALUE_MAX];
int density = 0;
if (property_get(propName, property, nullptr) > 0) {
density = atoi(property);
}
return density;
}
public:
static int getEmuDensity() {
return getDensityFromProperty("qemu.sf.lcd_density"); }
static int getBuildDensity() {
return getDensityFromProperty("ro.sf.lcd_density"); }
};
configs->clear();
ConditionalLock _l(mStateLock,
std::this_thread::get_id() != mMainThreadId);
for (const auto& hwConfig : getHwComposer().getConfigs(type)) {
DisplayInfo info = DisplayInfo();
float xdpi = hwConfig->getDpiX();
float ydpi = hwConfig->getDpiY();
//默認主屏幕的獲取DPI的法則
if (type == DisplayDevice::DISPLAY_PRIMARY) {
// The density of the device is provided by a build property
float density = Density::getBuildDensity() / 160.0f;
if (density == 0) {
// the build doesn't provide a density -- this is wrong!
// use xdpi instead
ALOGE("ro.sf.lcd_density must be defined as a build property");
density = xdpi / 160.0f;
}
if (Density::getEmuDensity()) {
xdpi = ydpi = density = Density::getEmuDensity();
density /= 160.0f;
}
info.density = density;
// TODO: this needs to go away (currently needed only by webkit)
sp hw(getDefaultDisplayDeviceLocked());
info.orientation = hw ? hw->getOrientation() : 0;
} else {
...
}
info.w = hwConfig->getWidth();
info.h = hwConfig->getHeight();
info.xdpi = xdpi;
info.ydpi = ydpi;
info.fps = 1e9 / hwConfig->getVsyncPeriod();
info.appVsyncOffset = vsyncPhaseOffsetNs;
info.presentationDeadline = hwConfig->getVsyncPeriod() -
sfVsyncPhaseOffsetNs + 1000000;
info.secure = true;
if (type == DisplayDevice::DISPLAY_PRIMARY &&
mPrimaryDisplayOrientation & DisplayState::eOrientationSwapMask) {
std::swap(info.w, info.h);
}
configs->push_back(info);
}
return NO_ERROR;
}
能看到這里BBinder實際并不是作為通信使用，而是作為對象標示。用來篩選出對應的屏幕的type是什么。
核心是下面這一段，先從HWComposer中獲取該id的屏幕的信息，并且保存在DisplayInfo。我們關(guān)注Density，也就是dpi是怎么計算的。
解釋一下dpi是什么，dpi是對角線每一個英寸下有多少像素。
計算就很簡單就是一個普通勾股定理即可。
其實這個數(shù)值是由ro.sf.lcd_density和qemu.sf.lcd_density屬性決定的。當然如果ro.sf.lcd_density沒有數(shù)值，則density則是由HWC的getConfigs的xdpi/160決定。最后找找qemu.sf.lcd_density，如果有數(shù)值，則xdpi，ydpi全部都是它，但是density則是qemu.sf.lcd_density數(shù)值/160.換句話說，qemu.sf.lcd_density這個LCD全局參數(shù)起了決定性的因素。
當然，沒有設置這兩個屬性，xdpi和ydpi則是默認的從HWC獲取出來的數(shù)據(jù),density 為xdpi/160f。
當然此時還會判斷整個屏幕的橫豎狀態(tài)，最后在做一次寬高的顛倒。
HWComposer getConfigs
std::vector<:shared_ptr hwc2::display::config>>
HWComposer::getConfigs(int32_t displayId) const {
RETURN_IF_INVALID_DISPLAY(displayId, {});
auto& displayData = mDisplayData[displayId];
auto configs = mDisplayData[displayId].hwcDisplay->getConfigs();
if (displayData.configMap.empty()) {
for (size_t i = 0; i < configs.size(); ++i) {
displayData.configMap[i] = configs[i];
}
}
return configs;
}
還記得在SF初始化中，當onHotPlugin進入到HWC之后，先添加到HWCDevice中，之后就會添加到mDisplayData中。其實就是HWC::Display對象。而這個對象在初始化的時候就會讀取對應配置保存起來。
文件：/frameworks/native/services/surfaceflinger/DisplayHardware/HWC2.cpp
void Display::loadConfigs()
{
ALOGV("[%" PRIu64 "] loadConfigs", mId);
std::vector<:config> configIds;
auto intError = mComposer.getDisplayConfigs(mId, &configIds);
auto error = static_cast(intError);
if (error != Error::None) {
return;
}
for (auto configId : configIds) {
loadConfig(configId);
}
}
void Display::loadConfig(hwc2_config_t configId)
{
ALOGV("[%" PRIu64 "] loadConfig(%u)", mId, configId);
auto config = Config::Builder(*this, configId)
.setWidth(getAttribute(configId, Attribute::Width))
.setHeight(getAttribute(configId, Attribute::Height))
.setVsyncPeriod(getAttribute(configId, Attribute::VsyncPeriod))
.setDpiX(getAttribute(configId, Attribute::DpiX))
.setDpiY(getAttribute(configId, Attribute::DpiY))
.build();
mConfigs.emplace(configId, std::move(config));
}
int32_t Display::getAttribute(hwc2_config_t configId, Attribute attribute)
{
int32_t value = 0;
auto intError = mComposer.getDisplayAttribute(mId, configId,
static_cast<:icomposerclient::attribute>(attribute),
&value);
auto error = static_cast(intError);
if (error != Error::None) {
ALOGE("getDisplayAttribute(%" PRIu64 ", %u, %s) failed: %s (%d)", mId,
configId, to_string(attribute).c_str(),
to_string(error).c_str(), intError);
return -1;
}
return value;
}
我們找到對應保存硬件的configId，最后通過getDisplayAttribute查找，每一個屬性是什么。
此時就會到Hal層中讀取屏幕信息。根據(jù)上兩節(jié)的UML圖就能知道本質(zhì)上是通過hw_device_t和硬件進行通信，那么我們就繼續(xù)以msm8960為基準閱讀。
文件：/hardware/qcom/display/msm8960/libhwcomposer/hwc.cpp
int hwc_getDisplayAttributes(struct hwc_composer_device_1* dev, int disp,
uint32_t config, const uint32_t* attributes, int32_t* values) {
hwc_context_t* ctx = (hwc_context_t*)(dev);
//If hotpluggable displays are inactive return error
if(disp == HWC_DISPLAY_EXTERNAL && !ctx->dpyAttr[disp].connected) {
return -1;
}
//From HWComposer
static const uint32_t DISPLAY_ATTRIBUTES[] = {
HWC_DISPLAY_VSYNC_PERIOD,
HWC_DISPLAY_WIDTH,
HWC_DISPLAY_HEIGHT,
HWC_DISPLAY_DPI_X,
HWC_DISPLAY_DPI_Y,
HWC_DISPLAY_NO_ATTRIBUTE,
};
const int NUM_DISPLAY_ATTRIBUTES = (sizeof(DISPLAY_ATTRIBUTES) /
sizeof(DISPLAY_ATTRIBUTES)[0]);
for (size_t i = 0; i < NUM_DISPLAY_ATTRIBUTES - 1; i++) {
switch (attributes[i]) {
case HWC_DISPLAY_VSYNC_PERIOD:
values[i] = ctx->dpyAttr[disp].vsync_period;
break;
case HWC_DISPLAY_WIDTH:
values[i] = ctx->dpyAttr[disp].xres;
ALOGD("%s disp = %d, width = %d",__FUNCTION__, disp,
ctx->dpyAttr[disp].xres);
break;
case HWC_DISPLAY_HEIGHT:
values[i] = ctx->dpyAttr[disp].yres;
ALOGD("%s disp = %d, height = %d",__FUNCTION__, disp,
ctx->dpyAttr[disp].yres);
break;
case HWC_DISPLAY_DPI_X:
values[i] = (int32_t) (ctx->dpyAttr[disp].xdpi*1000.0);
break;
case HWC_DISPLAY_DPI_Y:
values[i] = (int32_t) (ctx->dpyAttr[disp].ydpi*1000.0);
break;
default:
ALOGE("Unknown display attribute %d",
attributes[i]);
return -EINVAL;
}
}
return 0;
}
其實這個時候就是檢測dpyAttr對應id中所有的ydpi，xdpi，xres，xdpi，vsync_period的信息。這個數(shù)組很熟悉，就是onHotPlugin的時候，通過uevent線程的socket回調(diào)上來的信息。
SF getActiveConfig
int SurfaceFlinger::getActiveConfig(const sp& display) {
if (display == nullptr) {
ALOGE("%s : display is nullptr", __func__);
return BAD_VALUE;
}
sp device(getDisplayDevice(display));
if (device != nullptr) {
return device->getActiveConfig();
}
return BAD_VALUE;
}
此時繼續(xù)在用BBinder作為key，找到DisplayDevice，使用DisplayDevice的getActiveConfig。而這個對象是什么？其實就是onHotPlugin的時候，調(diào)用setupNewDisplayDeviceInternal，裝載進來的參數(shù)。
if (state.type < DisplayDevice::DISPLAY_VIRTUAL) {
hw->setActiveConfig(getHwComposer().getActiveConfigIndex(state.type));
}
而這個參數(shù)還是調(diào)用了HWC的getActiveConfigIndex，從Hal中設置了活躍的ConfigId到DisplayDevice中。之后就能拿到這個活躍的ID了。
HWC的getActiveConfigIndex 本質(zhì)上還是調(diào)用了HAL的getActiveConfig方法。而這個方法又是依賴setActiveConfig保存在HWC2On1Adapter::Display中。
什么時候設置呢？還記得我在WMS系列中聊過的RootWindowConatiner的嗎？它會調(diào)用performSurfacePlacement調(diào)用DisplayManagerService的performTraversal，通過SF設置當前活躍屏幕的id。它作為所有窗口的根窗口。同時在Activity onResume刷新界面之時，ViewRootImpl的performTraversals會調(diào)用聊到了WMS的relayout方法，這個方法刷新WMS中某個窗口的界面的時刻將會performSurfacePlacement。
通過這個方法，把WMS，DMS，SF全部串聯(lián)起來。
小結(jié)
思路有點跑遠了，getDisplayInfo實際做的事情拿到當前活躍的屏幕的屏幕信息。
SurfaceComposerClient createSurface
我們來回憶下，這個方法是怎么使用的：
sp control = session()->createSurface(String8("BootAnimation"),
dinfo.w, dinfo.h, PIXEL_FORMAT_RGB_565);
能看到開機動畫設置Surface，設置了Surface的名字，寬高以及Surface的像素格式是RGB-565.
注意，這里是整個SF渲染畫面前期準備最為核心的步驟。
sp SurfaceComposerClient::createSurface(
const String8& name,
uint32_t w,
uint32_t h,
PixelFormat format,
uint32_t flags,
SurfaceControl* parent,
int32_t windowType,
int32_t ownerUid)
{
sp s;
createSurfaceChecked(name, w, h, format, &s, flags, parent, windowType, ownerUid);
return s;
}
status_t SurfaceComposerClient::createSurfaceChecked(
const String8& name,
uint32_t w,
uint32_t h,
PixelFormat format,
sp* outSurface,
uint32_t flags,
SurfaceControl* parent,
int32_t windowType,
int32_t ownerUid)
{
sp sur;
status_t err = mStatus;
if (mStatus == NO_ERROR) {
sp handle;
sp parentHandle;
sp gbp;
if (parent != nullptr) {
parentHandle = parent->getHandle();
}
err = mClient->createSurface(name, w, h, format, flags, parentHandle,
windowType, ownerUid, &handle, &gbp);
ALOGE_IF(err, "SurfaceComposerClient::createSurface error %s", strerror(-err));
if (err == NO_ERROR) {
*outSurface = new SurfaceControl(this, handle, gbp, true /* owned */);
}
}
return err;
}
此時會調(diào)用SF的Client的createSurface創(chuàng)建一個SurfaceControl。能看到傳入了一個十分重要的對象IGraphicBufferProducer，這個對象就是圖元生產(chǎn)者。
Client createSurface
status_t Client::createSurface(
const String8& name,
uint32_t w, uint32_t h, PixelFormat format, uint32_t flags,
const sp& parentHandle, int32_t windowType, int32_t ownerUid,
sp* handle,
sp* gbp)
{
sp parent = nullptr;
if (parentHandle != nullptr) {
auto layerHandle = reinterpret_cast<:handle>(parentHandle.get());
parent = layerHandle->owner.promote();
if (parent == nullptr) {
return NAME_NOT_FOUND;
}
}
if (parent == nullptr) {
bool parentDied;
parent = getParentLayer(&parentDied);
// If we had a parent, but it died, we've lost all
// our capabilities.
if (parentDied) {
return NAME_NOT_FOUND;
}
}
/*
* createSurface must be called from the GL thread so that it can
* have access to the GL context.
*/
class MessageCreateLayer : public MessageBase {
SurfaceFlinger* flinger;
Client* client;
sp* handle;
sp* gbp;
status_t result;
const String8& name;
uint32_t w, h;
PixelFormat format;
uint32_t flags;
sp* parent;
int32_t windowType;
int32_t ownerUid;
public:
MessageCreateLayer(SurfaceFlinger* flinger,
const String8& name, Client* client,
uint32_t w, uint32_t h, PixelFormat format, uint32_t flags,
sp* handle, int32_t windowType, int32_t ownerUid,
sp* gbp,
sp* parent)
: flinger(flinger), client(client),
handle(handle), gbp(gbp), result(NO_ERROR),
name(name), w(w), h(h), format(format), flags(flags),
parent(parent), windowType(windowType), ownerUid(ownerUid) {
}
status_t getResult() const { return result; }
virtual bool handler() {
result = flinger->createLayer(name, client, w, h, format, flags,
windowType, ownerUid, handle, gbp, parent);
return true;
}
};
sp msg = new MessageCreateLayer(mFlinger.get(),
name, this, w, h, format, flags, handle,
windowType, ownerUid, gbp, &parent);
mFlinger->postMessageSync(msg);
return static_cast( msg.get() )->getResult();
}
該方法做了如下事情：
1.首先檢測當前的需要繪制的面Layer是否有父Layer。有則獲取parent的Layer。
2.構(gòu)造一個Handler，等到下一個Loop才進行操作。這個操作就是通過SF調(diào)用createLayer創(chuàng)建一個Layer。注意這里繼續(xù)把Binder接口IGraphicBufferProducer繼續(xù)傳下去。
SF createLayer
status_t SurfaceFlinger::createLayer(
const String8& name,
const sp& client,
uint32_t w, uint32_t h, PixelFormat format, uint32_t flags,
int32_t windowType, int32_t ownerUid, sp* handle,
sp* gbp, sp* parent)
{
if (int32_t(w|h) < 0) {
ALOGE("createLayer() failed, w or h is negative (w=%d, h=%d)",
int(w), int(h));
return BAD_VALUE;
}
status_t result = NO_ERROR;
sp layer;
String8 uniqueName = getUniqueLayerName(name);
switch (flags & ISurfaceComposerClient::eFXSurfaceMask) {
case ISurfaceComposerClient::eFXSurfaceNormal:
result = createBufferLayer(client,
uniqueName, w, h, flags, format,
handle, gbp, &layer);
break;
case ISurfaceComposerClient::eFXSurfaceColor:
result = createColorLayer(client,
uniqueName, w, h, flags,
handle, &layer);
break;
default:
result = BAD_VALUE;
break;
}
if (result != NO_ERROR) {
return result;
}
// window type is WINDOW_TYPE_DONT_SCREENSHOT from SurfaceControl.java
// TODO b/64227542
if (windowType == 441731) {
windowType = 2024; // TYPE_NAVIGATION_BAR_PANEL
layer->setPrimaryDisplayOnly();
}
layer->setInfo(windowType, ownerUid);
result = addClientLayer(client, *handle, *gbp, layer, *parent);
if (result != NO_ERROR) {
return result;
}
...
return result;
}
核心的邏輯分為2步驟：
1.createBufferLayer 創(chuàng)建圖層
2.addClientLayer 把圖層添加到Client
能看到在SF在這個時候會根據(jù)當前傳進來的type創(chuàng)建不同的Layer，分別是：
1.ISurfaceComposerClient::eFXSurfaceNormal 對應BufferLayer
2.ISurfaceComposerClient::eFXSurfaceColor 對應 ColorLayer
eFXSurfaceNormal = 0x00000000,
eFXSurfaceColor = 0x00020000,
eFXSurfaceMask = 0x000F0000,
分別分別是指這2個數(shù)值。在這個時候默認0，創(chuàng)建的是BufferLayer。那么這兩個Layer(圖層)有什么區(qū)別呢？其實ColorLayer一般不會使用，BufferLayer內(nèi)置一套消費者生產(chǎn)者的圖元消費邏輯，能夠持續(xù)不斷的更新圖元。然而ColorLayer中沒有這些邏輯比較小巧，我們可以理解成一個無法變動的圖層。在現(xiàn)在的復雜的UI交互里面，用武之地比較少。
以后遇到再解析ColorLayer，我們需要集中精力給BufferLayer。
createBufferLayer 創(chuàng)建圖層
status_t SurfaceFlinger::createBufferLayer(const sp& client,
const String8& name, uint32_t w, uint32_t h, uint32_t flags, PixelFormat& format,
sp* handle, sp* gbp, sp* outLayer)
{
// initialize the surfaces
switch (format) {
case PIXEL_FORMAT_TRANSPARENT:
case PIXEL_FORMAT_TRANSLUCENT:
format = PIXEL_FORMAT_RGBA_8888;
break;
case PIXEL_FORMAT_OPAQUE:
format = PIXEL_FORMAT_RGBX_8888;
break;
}
sp layer = new BufferLayer(this, client, name, w, h, flags);
status_t err = layer->setBuffers(w, h, format, flags);
if (err == NO_ERROR) {
*handle = layer->getHandle();
*gbp = layer->getProducer();
*outLayer = layer;
}
return err;
}
這里會判斷傳進來的format，如果是需要設定透明色，則強制設置format為RGBA_8888模式。最后生成一個BufferLayer，把BufferLayer中的句柄以及圖元生產(chǎn)者返回客戶端(此時是SurfaceComposerClient中的SurfaceControl)。
Layer的初始化
Layer::Layer(SurfaceFlinger* flinger, const sp& client, const String8& name, uint32_t w,
uint32_t h, uint32_t flags)
: contentDirty(false),
sequence(uint32_t(android_atomic_inc(&sSequence))),
mFlinger(flinger),
mPremultipliedAlpha(true),
mName(name),
mTransactionFlags(0),
mPendingStateMutex(),
mPendingStates(),
mQueuedFrames(0),
mSidebandStreamChanged(false),
mActiveBufferSlot(BufferQueue::INVALID_BUFFER_SLOT),
mCurrentTransform(0),
mOverrideScalingMode(-1),
mCurrentOpacity(true),
mCurrentFrameNumber(0),
mFrameLatencyNeeded(false),
mFiltering(false),
mNeedsFiltering(false),
mProtectedByApp(false),
mClientRef(client),
mPotentialCursor(false),
mQueueItemLock(),
mQueueItemCondition(),
mQueueItems(),
mLastFrameNumberReceived(0),
mAutoRefresh(false),
mFreezeGeometryUpdates(false),
mCurrentChildren(LayerVector::StateSet::Current),
mDrawingChildren(LayerVector::StateSet::Drawing) {
mCurrentCrop.makeInvalid();
uint32_t layerFlags = 0;
if (flags & ISurfaceComposerClient::eHidden) layerFlags |= layer_state_t::eLayerHidden;
if (flags & ISurfaceComposerClient::eOpaque) layerFlags |= layer_state_t::eLayerOpaque;
if (flags & ISurfaceComposerClient::eSecure) layerFlags |= layer_state_t::eLayerSecure;
mName = name;
mTransactionName = String8("TX - ") + mName;
mCurrentState.active.w = w;
mCurrentState.active.h = h;
mCurrentState.flags = layerFlags;
mCurrentState.active.transform.set(0, 0);
mCurrentState.crop.makeInvalid();
mCurrentState.finalCrop.makeInvalid();
mCurrentState.requestedFinalCrop = mCurrentState.finalCrop;
mCurrentState.requestedCrop = mCurrentState.crop;
mCurrentState.z = 0;
mCurrentState.color.a = 1.0f;
mCurrentState.layerStack = 0;
mCurrentState.sequence = 0;
mCurrentState.requested = mCurrentState.active;
mCurrentState.appId = 0;
mCurrentState.type = 0;
// drawing state & current state are identical
mDrawingState = mCurrentState;
const auto& hwc = flinger->getHwComposer();
const auto& activeConfig = hwc.getActiveConfig(HWC_DISPLAY_PRIMARY);
nsecs_t displayPeriod = activeConfig->getVsyncPeriod();
mFrameTracker.setDisplayRefreshPeriod(displayPeriod);
CompositorTiming compositorTiming;
flinger->getCompositorTiming(&compositorTiming);
mFrameEventHistory.initializeCompositorTiming(compositorTiming);
}
只需要知道它持有了HWC，flinger等對象即可。
BufferLayer的初始化
BufferLayer::BufferLayer(SurfaceFlinger* flinger, const sp& client, const String8& name,
uint32_t w, uint32_t h, uint32_t flags)
: Layer(flinger, client, name, w, h, flags),
mConsumer(nullptr),
mTextureName(UINT32_MAX),
mFormat(PIXEL_FORMAT_NONE),
mCurrentScalingMode(NATIVE_WINDOW_SCALING_MODE_FREEZE),
mBufferLatched(false),
mPreviousFrameNumber(0),
mUpdateTexImageFailed(false),
mRefreshPending(false) {
ALOGV("Creating Layer %s", name.string());
mFlinger->getRenderEngine().genTextures(1, &mTextureName);
mTexture.init(Texture::TEXTURE_EXTERNAL, mTextureName);
if (flags & ISurfaceComposerClient::eNonPremultiplied) mPremultipliedAlpha = false;
mCurrentState.requested = mCurrentState.active;
// drawing state & current state are identical
mDrawingState = mCurrentState;
}
這里面做了兩件比較重要的事情：
1.genTextures借助RenderEngine生成名字為mTextureName紋理對象
2.初始化Texture對象，綁定mTextureName。Texture是一個紋理矩陣的輔助類很簡單。
BufferLayer onFirstRef 設置圖元緩沖隊列
僅僅只是有BufferLayer還不夠，需要建立起一套生產(chǎn)者，消費者還需要更多東西。在實例化之后的onFirstRef才是真正的核心。
void BufferLayer::onFirstRef() {
// Creates a custom BufferQueue for SurfaceFlingerConsumer to use
sp producer;
sp consumer;
BufferQueue::createBufferQueue(&producer, &consumer, true);
mProducer = new MonitoredProducer(producer, mFlinger, this);
mConsumer = new BufferLayerConsumer(consumer,
mFlinger->getRenderEngine(), mTextureName, this);
mConsumer->setConsumerUsageBits(getEffectiveUsage(0));
mConsumer->setContentsChangedListener(this);
mConsumer->setName(mName);
if (mFlinger->isLayerTripleBufferingDisabled()) {
mProducer->setMaxDequeuedBufferCount(2);
}
const sp hw(mFlinger->getDefaultDisplayDevice());
updateTransformHint(hw);
}
在Layer中，我們明確能看到消費者和生產(chǎn)者字樣。通過BufferQueue::createBufferQueue 創(chuàng)建核心的生產(chǎn)者和消費者之后最后包裝，暴露外面的對象如下：
1.IGraphicBufferProducer 圖元生產(chǎn)者對應MonitoredProducer
2.IGraphicBufferConsumer 圖元消費者對應BufferLayerConsumer
緊接著有一個核心的邏輯，圖元消費者設置了ContentsChangedListener監(jiān)聽，當需要刷新的時候，將會回調(diào)這個接口讓消費者消費。
BufferQueue::createBufferQueue 創(chuàng)建核心的生產(chǎn)者和消費者
void BufferQueue::createBufferQueue(sp* outProducer,
sp* outConsumer,
bool consumerIsSurfaceFlinger) {
sp core(new BufferQueueCore());
sp producer(new BufferQueueProducer(core, consumerIsSurfaceFlinger));
sp consumer(new BufferQueueConsumer(core));
*outProducer = producer;
*outConsumer = consumer;
}
整個核心有3個對象：
1.BufferQueueCore 緩沖隊列
2.BufferQueueProducer 圖元生產(chǎn)者
3.BufferQueueConsumer 圖元消費者
BufferQueueCore 初始化
BufferQueueCore::BufferQueueCore() :
mMutex(),
mIsAbandoned(false),
mConsumerControlledByApp(false),
mConsumerName(getUniqueName()),
mConsumerListener(),
mConsumerUsageBits(0),
mConsumerIsProtected(false),
mConnectedApi(NO_CONNECTED_API),
mLinkedToDeath(),
mConnectedProducerListener(),
mSlots(),
mQueue(),
mFreeSlots(),
mFreeBuffers(),
mUnusedSlots(),
mActiveBuffers(),
mDequeueCondition(),
mDequeueBufferCannotBlock(false),
mDefaultBufferFormat(PIXEL_FORMAT_RGBA_8888),
mDefaultWidth(1),
mDefaultHeight(1),
mDefaultBufferDataSpace(HAL_DATASPACE_UNKNOWN),
mMaxBufferCount(BufferQueueDefs::NUM_BUFFER_SLOTS),
mMaxAcquiredBufferCount(1),
mMaxDequeuedBufferCount(1),
mBufferHasBeenQueued(false),
mFrameCounter(0),
mTransformHint(0),
mIsAllocating(false),
mIsAllocatingCondition(),
mAllowAllocation(true),
mBufferAge(0),
mGenerationNumber(0),
mAsyncMode(false),
mSharedBufferMode(false),
mAutoRefresh(false),
mSharedBufferSlot(INVALID_BUFFER_SLOT),
mSharedBufferCache(Rect::INVALID_RECT, 0, NATIVE_WINDOW_SCALING_MODE_FREEZE,
HAL_DATASPACE_UNKNOWN),
mLastQueuedSlot(INVALID_BUFFER_SLOT),
mUniqueId(getUniqueId())
{
int numStartingBuffers = getMaxBufferCountLocked();
for (int s = 0; s < numStartingBuffers; s++) {
mFreeSlots.insert(s);
}
for (int s = numStartingBuffers; s < BufferQueueDefs::NUM_BUFFER_SLOTS;
s++) {
mUnusedSlots.push_front(s);
}
}
int BufferQueueCore::getMaxBufferCountLocked() const {
int maxBufferCount = mMaxAcquiredBufferCount + mMaxDequeuedBufferCount +
((mAsyncMode || mDequeueBufferCannotBlock) ? 1 : 0);
// limit maxBufferCount by mMaxBufferCount always
maxBufferCount = std::min(mMaxBufferCount, maxBufferCount);
return maxBufferCount;
}
在Core中初始化了一個很重要Slot數(shù)組。我發(fā)現(xiàn)Android系統(tǒng)很喜歡Slot這種設計，rosalloc也是類似的設計。slot我暫時稱為插槽。
能看到在這個插槽中準備了如下大小的當前Layer最大能申請的圖元數(shù)以及最大入隊圖元數(shù)，此時兩個同步模式的標志位都為false，因此就實際上maxBufferCount為2。mMaxBufferCount為一個編譯常量64。
因此此時會設置大小為2的mFreeSlot，也就是2個大小空閑插槽。同時設置剩下62個為mUnusedSlots，是不使用的插槽。
這個插槽，我們能夠知道實際就是一個緩沖隊列，等待圖元插進來。
BufferQueueProducer 圖元生產(chǎn)者初始化
class BufferQueueProducer : public BnGraphicBufferProducer,
private IBinder::DeathRecipient
這個對象就是上面IGraphicBufferProducer，因此這個對象會在SF的Layer中存在一個，同時會傳遞給客戶端。
BufferQueueProducer::BufferQueueProducer(const sp& core,
bool consumerIsSurfaceFlinger) :
mCore(core),
mSlots(core->mSlots),
mConsumerName(),
mStickyTransform(0),
mConsumerIsSurfaceFlinger(consumerIsSurfaceFlinger),
mLastQueueBufferFence(Fence::NO_FENCE),
mLastQueuedTransform(0),
mCallbackMutex(),
mNextCallbackTicket(0),
mCurrentCallbackTicket(0),
mCallbackCondition(),
mDequeueTimeout(-1) {}
關(guān)鍵是把當前的Slot傳遞進來。
BufferQueueConsumer 圖元消費者初始化
BufferQueueConsumer::BufferQueueConsumer(const sp& core) :
mCore(core),
mSlots(core->mSlots),
mConsumerName() {}
這里也很簡單，持有了Slot緩沖隊列。接下來看看他的包裹類。
BufferLayerConsumer 初始化
BufferLayerConsumer::BufferLayerConsumer(const sp& bq,
RE::RenderEngine& engine, uint32_t tex, Layer* layer)
: ConsumerBase(bq, false),
mCurrentCrop(Rect::EMPTY_RECT),
mCurrentTransform(0),
mCurrentScalingMode(NATIVE_WINDOW_SCALING_MODE_FREEZE),
mCurrentFence(Fence::NO_FENCE),
mCurrentTimestamp(0),
mCurrentDataSpace(ui::Dataspace::UNKNOWN),
mCurrentFrameNumber(0),
mCurrentTransformToDisplayInverse(false),
mCurrentSurfaceDamage(),
mCurrentApi(0),
mDefaultWidth(1),
mDefaultHeight(1),
mFilteringEnabled(true),
mRE(engine),
mTexName(tex),
mLayer(layer),
mCurrentTexture(BufferQueue::INVALID_BUFFER_SLOT) {
memcpy(mCurrentTransformMatrix, mtxIdentity.asArray(), sizeof(mCurrentTransformMatrix));
mConsumer->setConsumerUsageBits(DEFAULT_USAGE_FLAGS);
}
它除了持有一個IGraphicBufferConsumer之外，還初始化了一個類型為mat4的mtxIdentity矩陣。如果熟悉著色器語言就知道這個的含義。它就是一個4*4矩陣。
class BufferLayerConsumer : public ConsumerBase
可以看到他是繼承了ConsumerBase，看看ConsumerBase初始化做了什么。
ConsumerBase 初始化
ConsumerBase::ConsumerBase(const sp& bufferQueue, bool controlledByApp) :
mAbandoned(false),
mConsumer(bufferQueue),
mPrevFinalReleaseFence(Fence::NO_FENCE) {
// Choose a name using the PID and a process-unique ID.
mName = String8::format("unnamed-%d-%d", getpid(), createProcessUniqueId());
wp listener = static_cast(this);
sp proxy = new BufferQueue::ProxyConsumerListener(listener);
status_t err = mConsumer->consumerConnect(proxy, controlledByApp);
if (err != NO_ERROR) {
...
} else {
mConsumer->setConsumerName(mName);
}
}
在ConsumerBase初始化中把當前這個對象轉(zhuǎn)化為ConsumerListener，因為它繼承了ConsumerListener。同時mConsumer就是IGraphicBufferConsumer也就是上面的BufferQueueConsumer對象。把當前對象封裝成IConsumerListener，調(diào)用了consumerConnect注冊監(jiān)聽,把行為鏈接到真正的消費者中。
BufferQueueConsumer consumerConnect
virtual status_t consumerConnect(const sp& consumer,
bool controlledByApp) {
return connect(consumer, controlledByApp);
}
status_t BufferQueueConsumer::connect(
const sp& consumerListener, bool controlledByApp) {
...
Mutex::Autolock lock(mCore->mMutex);
if (mCore->mIsAbandoned) {
...
return NO_INIT;
}
mCore->mConsumerListener = consumerListener;
mCore->mConsumerControlledByApp = controlledByApp;
return NO_ERROR;
}
此時就在BufferQueueCore中設置了消費者監(jiān)聽回調(diào)。
BufferLayerConsumer setContentsChangedListener
接下來BufferLayerConsumer還需要注冊一個新的監(jiān)聽是關(guān)于內(nèi)容發(fā)生了變化也界面需要刷新的監(jiān)聽。
文件：/frameworks/native/services/surfaceflinger/BufferLayerConsumer.cpp
void BufferLayerConsumer::setContentsChangedListener(const wp& listener) {
setFrameAvailableListener(listener);
Mutex::Autolock lock(mMutex);
mContentsChangedListener = listener;
}
此時會調(diào)用ConsumeBase的setFrameAvailableListener
ConsumeBase setFrameAvailableListener
void ConsumerBase::setFrameAvailableListener(
const wp& listener) {
Mutex::Autolock lock(mFrameAvailableMutex);
mFrameAvailableListener = listener;
}
這樣就完成了整個監(jiān)聽的循環(huán)。類的嵌套太多，讓我畫一張UML圖來整理下。
Layer與緩沖隊列的設計.png
總結(jié)一句話就是，因為FrameAvailableListener最終進入到BufferQueueCore中。當生產(chǎn)者生產(chǎn)了一個圖元的時候就會從core中獲取FrameAvailableListener調(diào)用監(jiān)聽，進入到ConsumeBase中，進一步的回調(diào)到BufferLayer中。最后到BufferLayer和SF執(zhí)行后面的繪制步驟。
addClientLayer
status_t SurfaceFlinger::addClientLayer(const sp& client,
const sp& handle,
const sp& gbc,
const sp& lbc,
const sp& parent)
{
{
Mutex::Autolock _l(mStateLock);
...
if (parent == nullptr) {
mCurrentState.layersSortedByZ.add(lbc);
} else {
if (parent->isPendingRemoval()) {
ALOGE("addClientLayer called with a removed parent");
return NAME_NOT_FOUND;
}
parent->addChild(lbc);
}
if (gbc != nullptr) {
mGraphicBufferProducerList.insert(IInterface::asBinder(gbc).get());
...
}
mLayersAdded = true;
mNumLayers++;
}
client->attachLayer(handle, lbc);
return NO_ERROR;
}
如果當前的圖層Layer沒有任何父Layer，則存儲在mCurrentState的layersSortedByZ，也就是Z軸的最末尾，也就是當前渲染圖層的最上層。如果有就綁定給父Layer。
最后生產(chǎn)者隊列需要插入到mGraphicBufferProducerList全局集合中。
最后調(diào)用client的attachLayer把Client的Binder和生產(chǎn)者綁定起來。
Client attachLayer
void Client::attachLayer(const sp& handle, const sp& layer)
{
Mutex::Autolock _l(mLock);
mLayers.add(handle, layer);
}
這樣也同時存儲在Client上。
SurfaceControl 的初始化
經(jīng)過上面的流程，完成了整一套的圖元緩沖隊列的構(gòu)造。現(xiàn)在讓我們回到SurfaceComposerClient中，繼續(xù)SurfaceControl的初始化。
文件：/frameworks/native/libs/gui/SurfaceControl.cpp
SurfaceControl::SurfaceControl(
const sp& client,
const sp& handle,
const sp& gbp,
bool owned)
: mClient(client), mHandle(handle), mGraphicBufferProducer(gbp), mOwned(owned)
{
}
此時SurfaceControl同時持有了Client的Binder，圖元生產(chǎn)者以及SurfaceComposerClient服務。
SurfaceControl 生產(chǎn)Surface
當SurfaceControl有了之后，需要繪制像素，是繪制在SurfaceControl生成的Surface上。
sp SurfaceControl::generateSurfaceLocked() const
{
// This surface is always consumed by SurfaceFlinger, so the
// producerControlledByApp value doesn't matter; using false.
mSurfaceData = new Surface(mGraphicBufferProducer, false);
return mSurfaceData;
}
sp SurfaceControl::getSurface() const
{
Mutex::Autolock _l(mLock);
if (mSurfaceData == 0) {
return generateSurfaceLocked();
}
return mSurfaceData;
}
其實就是把圖元生產(chǎn)者設置到Surface中。
Surface的初始化
Surface才是面向我們客戶端，開發(fā)者的繪制圖層。我們不會直接操作圖元生產(chǎn)者。一切的事情都交給Surface來發(fā)送。這里面包含了很重要的圖元發(fā)送等邏輯。
class Surface
: public ANativeObjectBase
可以看到繼承了一個ANativeObjectBase模版類，這個模版類只是處理引用計數(shù)，不過設計的很精巧，可以學習。
template
typename NATIVE_BASE = android_native_base_t>
class ANativeObjectBase : public NATIVE_TYPE, public REF
{
public:
// Disambiguate between the incStrong in REF and NATIVE_TYPE
void incStrong(const void* id) const {
REF::incStrong(id);
}
void decStrong(const void* id) const {
REF::decStrong(id);
}
protected:
typedef ANativeObjectBase BASE;
ANativeObjectBase() : NATIVE_TYPE(), REF() {
NATIVE_TYPE::common.incRef = incRef;
NATIVE_TYPE::common.decRef = decRef;
}
static inline TYPE* getSelf(NATIVE_TYPE* self) {
return static_cast(self);
}
static inline TYPE const* getSelf(NATIVE_TYPE const* self) {
return static_cast(self);
}
static inline TYPE* getSelf(NATIVE_BASE* base) {
return getSelf(reinterpret_cast(base));
}
static inline TYPE const * getSelf(NATIVE_BASE const* base) {
return getSelf(reinterpret_cast(base));
}
static void incRef(NATIVE_BASE* base) {
ANativeObjectBase* self = getSelf(base);
self->incStrong(self);
}
static void decRef(NATIVE_BASE* base) {
ANativeObjectBase* self = getSelf(base);
self->decStrong(self);
}
};
使用了模版了決定了繼承關(guān)系。換句話說其實相當于一個Hook，在不改變設計結(jié)構(gòu)下，增加了引用的特性。
ANativeWindow 結(jié)構(gòu)體
struct ANativeWindow
{
#ifdef __cplusplus
ANativeWindow()
: flags(0), minSwapInterval(0), maxSwapInterval(0), xdpi(0), ydpi(0)
{
common.magic = ANDROID_NATIVE_WINDOW_MAGIC;
common.version = sizeof(ANativeWindow);
memset(common.reserved, 0, sizeof(common.reserved));
}
/* Implement the methods that sp expects so that it
can be used to automatically refcount ANativeWindow's. */
void incStrong(const void* /*id*/) const {
common.incRef(const_cast(&common));
}
void decStrong(const void* /*id*/) const {
common.decRef(const_cast(&common));
}
#endif
struct android_native_base_t common;
/* flags describing some attributes of this surface or its updater */
const uint32_t flags;
/* min swap interval supported by this updated */
const int minSwapInterval;
/* max swap interval supported by this updated */
const int maxSwapInterval;
/* horizontal and vertical resolution in DPI */
const float xdpi;
const float ydpi;
intptr_t oem[4];
int (*setSwapInterval)(struct ANativeWindow* window,
int interval);
int (*dequeueBuffer_DEPRECATED)(struct ANativeWindow* window,
struct ANativeWindowBuffer** buffer);
int (*lockBuffer_DEPRECATED)(struct ANativeWindow* window,
struct ANativeWindowBuffer* buffer);
int (*queueBuffer_DEPRECATED)(struct ANativeWindow* window,
struct ANativeWindowBuffer* buffer);
int (*query)(const struct ANativeWindow* window,
int what, int* value);
int (*perform)(struct ANativeWindow* window,
int operation, ... );
int (*cancelBuffer_DEPRECATED)(struct ANativeWindow* window,
struct ANativeWindowBuffer* buffer);
int (*dequeueBuffer)(struct ANativeWindow* window,
struct ANativeWindowBuffer** buffer, int* fenceFd);
int (*queueBuffer)(struct ANativeWindow* window,
struct ANativeWindowBuffer* buffer, int fenceFd);
int (*cancelBuffer)(struct ANativeWindow* window,
struct ANativeWindowBuffer* buffer, int fenceFd);
};
實際上，我們就能看到不少線索，別看叫做Window，實際上ANativeWindow不是作為圖元存儲的結(jié)構(gòu)體，能從結(jié)構(gòu)體中的方法指針看得出，實際上ANativeWindow是用來控制ANativeWindowBuffer 像素緩存的。大致上有四個操作，queueBuffer 圖元入隊，dequeueBuffer 圖元出隊，lockBuffer 圖元鎖定，query圖元查找等。當然還有setSwapInterval交換緩沖。
我們再轉(zhuǎn)過頭看看整個Surface的初始化。
Surface::Surface(const sp& bufferProducer, bool controlledByApp)
: mGraphicBufferProducer(bufferProducer),
mCrop(Rect::EMPTY_RECT),
mBufferAge(0),
mGenerationNumber(0),
mSharedBufferMode(false),
mAutoRefresh(false),
mSharedBufferSlot(BufferItem::INVALID_BUFFER_SLOT),
mSharedBufferHasBeenQueued(false),
mQueriedSupportedTimestamps(false),
mFrameTimestampsSupportsPresent(false),
mEnableFrameTimestamps(false),
mFrameEventHistory(std::make_unique()) {
// Initialize the ANativeWindow function pointers.
ANativeWindow::setSwapInterval = hook_setSwapInterval;
ANativeWindow::dequeueBuffer = hook_dequeueBuffer;
ANativeWindow::cancelBuffer = hook_cancelBuffer;
ANativeWindow::queueBuffer = hook_queueBuffer;
ANativeWindow::query = hook_query;
ANativeWindow::perform = hook_perform;
ANativeWindow::dequeueBuffer_DEPRECATED = hook_dequeueBuffer_DEPRECATED;
ANativeWindow::cancelBuffer_DEPRECATED = hook_cancelBuffer_DEPRECATED;
ANativeWindow::lockBuffer_DEPRECATED = hook_lockBuffer_DEPRECATED;
ANativeWindow::queueBuffer_DEPRECATED = hook_queueBuffer_DEPRECATED;
const_cast(ANativeWindow::minSwapInterval) = 0;
const_cast(ANativeWindow::maxSwapInterval) = 1;
mReqWidth = 0;
mReqHeight = 0;
mReqFormat = 0;
mReqUsage = 0;
mTimestamp = NATIVE_WINDOW_TIMESTAMP_AUTO;
mDataSpace = Dataspace::UNKNOWN;
mScalingMode = NATIVE_WINDOW_SCALING_MODE_FREEZE;
mTransform = 0;
mStickyTransform = 0;
mDefaultWidth = 0;
mDefaultHeight = 0;
mUserWidth = 0;
mUserHeight = 0;
mTransformHint = 0;
mConsumerRunningBehind = false;
mConnectedToCpu = false;
mProducerControlledByApp = controlledByApp;
mSwapIntervalZero = false;
}
在Surface初始化的時候，同時為每一個方法指針都賦值了，讓Surface擁有了操作的能力。
總結(jié)
關(guān)于BufferQueue 圖元緩沖隊列的初始化就到這里。在這個初始化流程中，初步的搭建了整個生產(chǎn)者-消費者模型。剩下的步驟就是生產(chǎn)圖元，寫入生產(chǎn)者，生產(chǎn)者把數(shù)據(jù)寫進緩沖隊列，通知消費者進行消費。
后面的步驟，我們慢慢再聊。老規(guī)矩用一幅圖總結(jié)整個流程。
SF的生產(chǎn)者消費者模型.png
總結(jié)一遍流程，本文總結(jié)了開機動畫1-5的步驟。
getBuiltInDisplay 從BuiltInDisplay數(shù)組中獲取當前的屏幕
getDisplayInfo 從SF中獲取活躍的屏幕信息
createSurface 通過SF的Client對象創(chuàng)建了一個圖元生產(chǎn)者，并且賦值給SurfaceControl中。
setLayer 設置layer 圖層在Z軸上的層級
getSurface 通過SurfaceControl生產(chǎn)Surface對象，真正進行交互是Surface對象。
有了這些基礎之后，下一篇文章就來聊聊，Android在OpenGL es上的封裝。
總結(jié)
以上是生活随笔為你收集整理的android 队列执行动画,Android 重学系列 渲染图层-图元缓冲队列初始化的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： WEB安全基础-PHP相关
- 下一篇： 素短语,最左素短语-编译原理