1.性能比肩美拍秒拍的Android视频录制编辑特效解决方案
2.如何在Android上实现FrameBuffer和Overlay的blend
3.opengl和skia哪个快
4.SurfaceTexture详解
5.在android4.0.几的版本上会出现这个问题,在线求解答
6.Android 14 HWUI 源码研究 View Canvas RenderThread ViewRootImpl skia

性能比肩美拍秒拍的Android视频录制编辑特效解决方案

       前言

       在进行Android平台的音视频开发时，Java层API的支持在MediaCodec之前还相对抽象，功能受限。MediaCodec虽在后期推出，但也存在兼容性问题以及各厂商实现不一致的情况。开发者开始转向NDK寻求更丰富的仿应用商店cms源码音视频处理能力，但NDK提供的API并不全面，尤其是音视频处理方面。因此，开发者们考虑使用开源的C/C++框架，如ffmpeg、x、mp3lame、faac等。然而，这些框架在不同平台如ARM和mips的支持上存在局限，且软解软编导致编码速度较慢，无法满足高帧率录制需求。因此，本文旨在提供一个性能更佳、兼容性更强的Android视频录制编辑解决方案。

       NDK可用API介绍

       在NDK中，开发者可以利用一些API进行音视频处理。例如，OpenSL可直接在C++层操作音频设备，进行录音和播放声音；EGL可用于创建OpenGL环境，进行视频图像渲染、图像处理等；OpenGL(ES)提供C++层的OpenGL接口；OpenMAXIL为视频播放提供抽象接口。此外，建筑网站源码还需注意的是，OpenMAXAL虽然提供了抽象接口，但不支持Android平台的摄像头使用，因此需要从Java层获取摄像头数据。

       选择开源框架

       在处理音频编码问题时，考虑到ffmpeg、x、mp3lame和faac等开源框架的性能与兼容性，选择ffmpeg2.7.5版本进行文件解析、图像拉伸、像素格式转换以及大多数解码器，x作为H编码器，并使用最新版本进行优化，faac编码器虽存在速度问题，但通过曲线救国的方式解决了音频编码问题。最后，引入OpenGL2D/3D引擎，如COCOS2D-X，用于视频特效处理，同时简化了COCOS2D-X的回收机制，使其更符合项目需求。

       完整解决方案

       为解决音频编码速度慢的问题，采用ffmpeg直接处理视频编码，而音频数据则写入文件。这样既能灵活配置编码参数，实现快速编码，又能避免磁盘写入速度的瓶颈。同时，php源码建站教程多线程异步写入数据可以满足编码速度与帧率的匹配需求。引入OpenGL2D/3D引擎，如COCOS2D-X，用于添加视频特效，并简化其回收机制，提高性能。

       主副线程模式

       为确保OpenGL操作的线程安全，设计了主副线程模式。主线程负责UI的响应，而副线程则用于执行其他耗时任务，如OpenGL渲染等。通过任务接口实现多任务调度，提高整体性能和稳定性。

       总结与优化

       选择合适的API版本（ffmpeg2.7.5、x最新版本）并开启优化选项（asm，neon等）。采用分步编码策略，视频数据直接调用x编码，音频数据写入文件。引入COCOS2D-X作为特效引擎，简化其回收机制。设计主副线程模式，确保OpenGL操作在单一线程内执行，提高性能稳定性。

       源码与演示

       完整工程源码已发布，支持API及以上版本。操作演示和视频生成位置已提供链接。需要注意的智诚源码平台API调用细节如下：

       1、com.android.video.camera.EFCameraView类中设置当前选用的摄像头分辨率宽度和高度。

       2、jni/WORKER/EFRecordWorker.cpp中的createRecordWorker函数内，配置当前录制视频的各种基本参数。

       3、jni/WORKER/EFRecordWorker.cpp的on_create_worker函数内，设置OpenGL绘制帧率，与视频帧率不同，请根据实际需求设置。

       感谢社区反馈，针对优化建议：

       1、使用更优的AAC开源方案，推荐FDKAAC。

       2、尝试升级OpenGL版本，使用GLES 3.0实现快速获取渲染结果图像。

       在Android上进行音视频处理，结合特定版本的API和开源框架，可以实现更高效、兼容性强的解决方案。随着技术的不断演进，Android平台在音视频处理方面的能力也在不断提升。

如何在Android上实现FrameBuffer和Overlay的blend

       1.SurfaceFlinger是一个服务，主要是负责合成各窗口的Surface，然后通过OpenGLES显示到FrameBuffer上。

       2.DisplayHardware是对显示设备的抽象，包括FrameBuffer和Overlay。加载FrameBuffer和Overlay插件，并初始化OpenGLES:

       view plain

       mNativeWindow = new FramebufferNativeWindow();

       framebuffer_device_t const * fbDev = mNativeWindow->getDevice();

       if (hw_get_module(OVERLAY_HARDWARE_MODULE_ID, &module) == 0) {

        overlay_control_open(module, &mOverlayEngine);

       }

       surface = eglCreateWindowSurface(display, config, mNativeWindow.get(), NULL);

       eglMakeCurrent(display, surface, surface, context);

       3.FramebufferNativeWindow 是framebuffer 的抽象，它负责加载libgralloc，并打开framebuffer设备。FramebufferNativeWindow并不直接使用 framebuffer，而是自己创建了两个Buffer：

       queueBuffer负责显示一个Buffer到屏幕上，它调用fb->post去显示。

       dequeueBuffer获取一个空闲的Buffer，用来在后台绘制。

       è¿™ä¸¤ä¸ªå‡½æ•°ç”±eglSwapBuffers调过来，调到

       view plain

       egl_window_surface_v2_t::swapBuffers：

        nativeWindow->queueBuffer(nativeWindow, buffer);

        nativeWindow->dequeueBuffer(nativeWindow, &buffer);

       4.msm7k/liboverlay是Overlay的实现，与其它平台不同的是，高通平台上的Overlay并不是提供一个framebuffer设备，而通过fb0的ioctl来实现的，ioctl分为两类操作：

       OverlayControlChannel用于设置参数，比如设置Overlay的位置，宽度和高度：

       view plain

       bool OverlayControlChannel::setPosition(int x, int y, uint_t w, uint_t h) {

        ov.dst_rect.x = x;

        ov.dst_rect.y = y;

        ov.dst_rect.w = w;

        ov.dst_rect.h = h;

        ioctl(mFD, MSMFB_OVERLAY_SET, &ov);

       }

       OverlayDataChannel用于显示Overlay，其中最重要的函数就是queueBuffer:

       view plain

       bool OverlayDataChannel::queueBuffer(uint_t offset) {

        mOvData.data.offset = offset;

        ioctl(mFD, MSMFB_OVERLAY_PLAY, odPtr))

       }

       5.msm7k/libgralloc 是显示缓存的抽象，包括framebuffer和普通Surface的Buffer。framebuffer只是/dev/graphic/fb0的包 装，Surface的Buffer则是对/dev/pmem、ashmem和GPU内存(msm_hw3dm)的包装，它的目标主要是方便硬件加速，因为 DMA传输使用物理地址，要求内存在物理地址上连续。

       6.msm7k/libcopybit这是2D加速库，主要负责Surface的拉伸、旋转和合成等操作。它有两种实现方式：

       copybit.cpp: 基于fb0的ioctl(MSMFB_BLIT)的实现。

       copybit_c2d.cpp: 基于kgsl的实现，只是对libC2D2.so的包装，libC2D2.so应该是不开源的。

       7.pmem

       misc/pmem.c: 对物理内存的管理，算法和用户空间的接口。

       board-msm7x.c定义了物理内存的缺省大小：

       view plain

       #define MSM_PMEM_MDP_SIZE 0x1B

       #define MSM_PMEM_ADSP_SIZE 0xB

       #define MSM_PMEM_AUDIO_SIZE 0x5B

       #define MSM_FB_SIZE 0x

       #define MSM_GPU_PHYS_SIZE SZ_2M

       #define PMEM_KERNEL_EBI1_SIZE 0x1C

       msm_msm7x2x_allocate_memory_regions分配几大块内存用于给pmem做二次分配。

       8.KGSL

       Kernel Graphics System Layer (KGSL)，3D图形加速驱动程序，源代码drivers/gpu/msm目录下，它是对GPU的包装，给OpenGLES 2.0提供抽象的接口。

       9.msm_hw3dm

       è¿™ä¸ªæˆ‘在内核中没有找到相关代码。

       .msm_fb

       msm_fb.c: framebuffer, overlay和blit的用户接口。

       mdp_dma.c: 对具体显示设备的包装，提供两种framebuffer更新的方式：

       mdp_refresh_screen： 定时更新。

       mdp_dma_pan_update: 通过pan display主动更新。

       mdp_dma_lcdc.c：针对LCD实现的显示设备，mdp_lcdc_update用更新framebuffer。

opengl和skia哪个快

       从Honeycomb[3.x]版本起，Andorid便支持GPU加速，但目前Android并没有使用Skia GPU进行Webkit渲染。Skia GPU使用OpenGL进行后台加速渲染，未来也许会代替Skia。

       很多人觉得，开源博客源码即使Android成功使用了GPU加速Webkit渲染，在访问浏览如雅虎等一般的网站时，用户也感觉不到太大的差异。因为Webkit的资源大多数消耗在了Javascript脚本和布局定位上。

       我们觉得Webkit使用GPU加速渲染的最大意义无非是HTML5 Canvas[HTML5的动态绘图效果]。Android渲染Canvas动画实在太慢，导致Web开发者根本无法在Android上用Canvas开发网页游戏[要注意的是，目前很多手机和平板的应用程序以HTML5做为界面，并使用Webkit工作，这也是很多应用在Android系统上感觉不流畅的重要因素。

       Android Webkit开发平台[NDK]使用Skia GPU加速测试

       我们对Android系统使用Skia GPU加速的Webkit进行了测试。我们手上已经有Android Webkit NDK的WAC2.0版本，我使用了某个提交版本的Skia源码，并开启Skia GPU加速将其编译进NDK中。

       我并没有使用Canvas加速，因为这还要增加修改GraphicsContextSkia API的工作，所以并未测试Canvas渲染的性能。

       为了使用Skia GPU加速，我做了以下两点：

       1，新增了一个使用GLSurfaceView的eglContext内容。

       2，在WebView.cpp中使用SkGpuCanvas代替SkCanvas。 我在系统版本为2.3.2的Nexus S上测试，并禁用了屏幕合成加速和Webkit后备缓存，结果出乎意料，Skia GPU反而降低了绘图性能，比Skia使用CPU渲染的时候慢了两倍以上。

       当用户滚动雅虎网站页面的时候，每一帧都会使Webkit对页面元素进行重绘。页面元素包括%的文本，%的矩形和%的图像，Skia GPU加速渲染时候反而慢了五倍。

       你看到图表后也许会觉得Skia GPU渲染SVG动画时是要比CPU快那么一丁点了。不过Webkit在渲染SVG动画的时候出了一些问题，它绝大多数时间花在了定位布局SVG元素上，而不是渲染SVG元素。所以我不敢确定Skia使用GPU加速时是不是真的变快了。

       Skia在栅格化文本的时候使用的是CPU而不是GPU，它将文本缓存为材质贴图。因此Skia GPU加速并不会增加滚动文本时的速度。

       我一开始觉得Skia GPU加速会在绘制飞舞的浏览器图标时理应能速度更快了，毕竟那是位图动画，是GPU的强项。结果，Skia GPU渲染慢了倍由于还没有得到详细结果，所以我们需要做进一步的研究，以找到问题的原因。

       当你构建Skia的时候，你会得到一个跑分程序，运行之后，你会看到使用CPU和GPU渲染时的性能差异。下面是一些测试得分中的重点项目。

SurfaceTexture详解

       ä¹‹å‰è®²åˆ°äº† flutter的Texture

        SurfaceTexture 是 Surface 和 OpenGL ES (GLES) 纹理的组合。SurfaceTexture 用于提供输出到 GLES 纹理的 Surface

        SurfaceTexture 包含一个 BufferQueue。当生产方将新的缓冲区排入队列时，onFrameAvailable() 回调会通知应用。然后，应用调用 updateTexImage()，这会释放先前占有的缓冲区，从队列中获取新缓冲区并执行 EGL 调用，从而使 GLES 可将此缓冲区作为外部纹理使用。

        关键方法：

        SurfaceTexture(int texName, boolean singleBufferMode)构造方法

        setOnFrameAvailableListener 设置回调，当生产者准备好新的帧后会调用Listener

        updateTexImage 更新texture到指定的GLESContext

        detachFromGLContext

        attachToGLContext

        解绑/绑定 当前GLContext

        getTransformMatrix 设置重采样纹理矩阵，当渲染的时候会用到这个数据

        release() 完全释放 SufaceTexture的 buffers并且吧Surface状态置为abandoned

        android-8.0.0_r1 源码解析：

        GLConsumer参数解释：

        bq是BufferQueue创建BufferConsumer

        tex 表示要将图像流传输到的OpenGL ES纹理名称。

        texTarget指定了哪个纹理将被绑定

        useFenceSync表示是否需要同步访问缓冲区

        可以从一个OpenGL ES上下文中分离GLConsumer，然后分别使用detachFromContext和attachToContext方法将GLConsumer附加到另一个上下文。

        如果设置tex参数则会通过attachToContext将GLConsumer附加到OpenGL ES context中。

        第一次调用updateTexImage才会绑定，之后所有对updateTexImage的调用必须使用相同的当前OpenGL ES context进行

        acquireBufferLocked创建EglImage并设置到EglSlots中

        updateAndReleaseLocked 更新 EglImage

        createIfNeeded 如果EGLDisplay改变或者crop改变则会创建EglImage

        bindToTextureTarget 将调用glEGLImageTargetTexture2DOES去绑定image到指定的目标纹理

        这里创建EGLImageKHR，EGLImageKHR用于共享EGL资源

        EGL的ShareContext是常见的共享上下文的方式（iOS平台的EAGL叫ShareGroup）。

        当share_context参数传入另一个EGL的context时，这两个EGLContext就可以共享纹理以及VBO等。

        需要注意的是container objects不能被共享，比如：

        Framebuffer objects

        Vertex array objects

        Transform feedback objects

        Program pipeline objects

        参考： /project/deep-android-v1/classes.html

        EGLImageKHR: mon (out/host/linux-x/obj/STATIC_LIBRARIES/libGLcommon_intermediates/libGLcommon.a)

        解决：sudo ln -s /usr/lib/i-linux-gnu/mesa/libGL.so.1 /usr/lib/i-linux-gnu/libGL.so

       . 错误：make: *** [out/host/linux-x/obj/EXECUTABLES/obbtool_intermediates/Main.o] Error 1

        后来发现了，原来是Ubuntu .里的gcc和g++版本太高了，于是执行下面的操作：

        sudo apt-get install gcc-4.4

        sudo apt-get install g++-4.4

        sudo rm -rf /usr/bin/gcc /usr/bin/g++

        sudo ln -s /usr/bin/gcc-4.4 /usr/bin/gcc

        sudo ln -s /usr/bin/g++-4.4 /usr/bin/g++

        把默认的4.6版本换为了4.4，继续编译源码，又出现了另一个错误，大致提示为：

        g++ selected multilib '' not installed

        继续奋战吧，安装相应的工具吧：sudo apt-get install g++-4.4-multilib，现在正在make -j8(开启多线程编译（不推荐），可能有时候会出现问题，最好是直接make)

       2. 解决各种依赖问题

        首先安装一些库

        ?View Code BASH

        1 sudo apt-get install gnupg flex bison gperf libsdl1.2-dev libesd0-dev

        2 sudo apt-get install libwxgtk2.6-dev squashfs-tools build-essential

        3 sudo apt-get install zlib1g-dev pngcrush schedtool ia-libs libncurses5-dev

        这些库可能不全，如果出现问题，再google一下吧

       3. error: “_FORTIFY_SOURCE” redefined [-Werror]

        这个问题，据说与gcc版本有关，4.4版不会出现。

        后来在google code上找到了使用gcc 4.6编译的方法

        修改build/core/combo/HOST_linux-x.mk文件line

        ?View Code BASH

        1 -HOST_GLOBAL_CFLAGS += -D_FORTIFY_SOURCE=0

        2 +HOST_GLOBAL_CFLAGS += -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0

        这是CyanogenMod打上的补丁

       4. No rule to make target ‘out/target/product/generic/obj/lib/libcamera.so’

        修改 /home/Android-2.3.4/frameworks/base/services/camera/libcameraservice/Android.mk，USE_CAMERA_STUB:=false -> true

        ?View Code BASH

        1 LOCAL_PATH:= $(call my-dir)

        2

        3 # Set USE_CAMERA_STUB if you don't want to use the hardware camera.

        4

        5 # force these builds to use camera stub only

        6 ifneq ($(filter sooner generic sim,$(TARGET_DEVICE)),)

        7 USE_CAMERA_STUB:=true

        8 endif

        9

        #########CHANGE THIS LINE############

        USE_CAMERA_STUB:=true

        ifeq ($(USE_CAMERA_STUB),)

        USE_CAMERA_STUB:=false

        endif

Android HWUI 源码研究 View Canvas RenderThread ViewRootImpl skia

       HUWUI是Android系统中负责应用可视化元素绘制的核心组件，其架构主要在C++层实现，从Java层接收View绘制信息，通过唯一的渲染线程使用skia技术完成渲染任务。整体上，从应用程序到UI线程，再到渲染线程，形成了清晰的层级关系。

       HUWUI的构建主要包括三个核心类，它们分别是：RecordingCanvas、Canvas、RenderNode、RenderProxy、RenderThread、CanvasContext、IRenderPipeline。在Java层，主要涉及两类Canvas，RecordingCanvas用于记录绘制指令，Canvas则是直接用于渲染。RecordingCanvas在构造时创建，而Canvas在调用时创建。这两个类在C++层分别对应SkiaRecordingCanvas和SkiaCanvas，后者直接引用SkCanvas。

       在全局循环中，UI线程与渲染线程之间的协同操作至关重要。具体流程包括：新创建Activity后，附着到对应的PhoneWindow，然后调用PhoneWindow的setContentView方法，将View添加到DecorView作为子节点。接着，DecorView与ViewRootImpl对接，完成View的更新与渲染。整个过程包含了measure、layout和draw等复杂子流程。

       渲染线程创建与核心对象紧密关联，主要包括RenderProxy、RenderThread和DrawFrameTask。RenderProxy负责Java层信息的衔接，RenderThread作为进程唯一的渲染线程，持有DrawFrameTask和CanvasContext，完成一帧的绘制任务。指令记录流程的核心在于使用C++层的RecordingCanvas将View属性和绘制信息记录到DisplayList中，进而完成指令的渲染。

       Surface、ANativeWindow、EGLSurface的创建流程在ViewRootImpl的performTraversals函数中初始化。ReliableSurface的封装和EGL与Skia环境的创建主要在RenderThread的requireGlContext函数中实现。从源码分析，这一过程通常在三个地方调用。

       View树与RenderNode树之间的协作关系明确，一个Application进程对应多个Activity，每个Activity与一个PhoneWindow绑定，PhoneWindow持有DecorView，DecorView对应一个ViewRootImpl，而ViewRootImpl与ThreadedRender模块对接。ThreadedRender与C++层的RenderProxy一一对应，RenderProxy持有关键对象，如RenderThread、CanvasContext、DrawFrameTask等。RenderThread是单例模式，进程唯一，负责一帧绘制的逻辑。

       在RenderPipeline模块中，关键操作包括makeCurrent、draw和swapBuffers。Native Canvas在这一过程中扮演了桥梁角色，接收Java API调用，而RecordingCanvas完成Op记录，最终DisplayListData存储这些Op。

       skia的核心资源主要在三个使用场景中发挥作用，具体细节需深入分析，这些资源对于实现高效、稳定的渲染效果至关重要。

安卓系统 android 2.1 android 2.2 android 2.3 有什么区别？

       安卓系统 android 2.1 android 2.2 android 2.3 区别如下：

       1.Android 2.1: 年 月 日，又一个主要版本升级以创纪录的速度放出。这次，大版本升级到了Android 2.1 “Eclair” 。

       Android 2.0.1 SDK 于 年 月 3 日 发布，之后是 年 1 月 日的 2.1 版本。很多用户和围观群众可能会奇怪：“为什么 Android 会用甜点作为它们系统版本的代号？”，这个命名方法开始于 Andoird 1.5 发布的时候。作为每个版本代表的甜点的尺寸越变越大，然后按照字母数序：小蛋糕，甜甜圈还有松饼。之前人们预计 2.2 版本的代号会是“馅饼”，但这个被最终证明是错误的，“FroYo”（冻酸奶）才是Android 2.2这个伴随 Google Nexus One 发布的新版的最新代号。

       2.谷歌于北京时间年5月日晚上:点在旧金山Moscone会展中心举办Google I/O 大会第二天的会议，Google正式发布了代号是“froyo 冻酸奶”的Android手机操作系统2.2版。

       3.北京时间年月7日凌晨，Google正式对外发布了他们的智能手机操作系统Android 2.3，也就被大家所熟知的AndroidGingerbread（姜饼）系统。虽然在版本方面Android2.3相对于前作而言的提升并不算多，但是从功能以及界面的变化上来看还是十分明显的。