通知短信+运营短信,5秒速达,支持群发助手一键发送🚀高效触达和通知客户 广告
前文讲述的内容都集中在Java层,下面要按照流程顺序分析JNI层的内容。 1. Surface的无参构造分析 在JNI层,第一个被调用的是Surface的无参构造函数,其代码如下所示: **Surface.java** ~~~ public Surface() { ...... //CompatibleCanvas从Canvas类派生 mCanvas = new CompatibleCanvas(); } ~~~ Canvas是什么?根据SDK文档的介绍可知,画图需要“四大金刚”相互合作,这四大金刚是: - Bitmap:用于存储像素,也就是画布。可把它当做一块数据存储区域。 - Canvas:用于记载画图的动作,比如画一个圆,画一个矩形等。Canvas类提供了这些基本的绘图函数。 - Drawing primitive:绘图基元,例如矩形、圆、弧线、文本、图片等。 - Paint:它用来描述绘画时使用的颜色、风格(如实线、虚线等)等。 在一般情况下,Canvas会封装一块Bitmap,而作图就是基于这块Bitmap的。前面说的画布,其实指的就是Canvas中的这块Bitmap。 这些知识稍了解即可,不必去深究。Surface的无参构造函数没有什么有价值的内容,接着看下面的内容。 2. SurfaceSession的构造 现在要分析的是SurfaceSession,其构造函数如下所示: **SurfaceSession.java** ~~~ public SurfaceSession() { init();//这是一个native函数 } ~~~ init是一个native函数。去看看它的JNI实现,它在android_view_Surface.cpp中,代码如下所示: **android_view_Surface.cpp** ~~~ static void SurfaceSession_init(JNIEnv* env,jobject clazz) { //创建一个SurfaceComposerClient对象 sp<SurfaceComposerClient> client = new SurfaceComposerClient; client->incStrong(clazz); //在Java对象中保存这个client对象的指针,类型为SurfaceComposerClient env->SetIntField(clazz, sso.client, (int)client.get()); } ~~~ 这里先不讨论SurfaceComposerClient的内容,拟继续把乾坤大挪移的流程走完。 3. Surface的有参构造 下一个调用的是Surface的有参构造,其参数中有一个SurfaceSession。先看Java层的代码,如下所示: **Surface.java** ~~~ publicSurface(SurfaceSession s,//传入一个SurfaceSession对象 int pid, String name, int display, int w, int h, int format, int flags) throws OutOfResourcesException { ...... mCanvas = new CompatibleCanvas(); //又一个native函数,注意传递的参数:display以后再说,w,h代表绘图区域的宽高值 init(s,pid,name,display,w,h,format,flags); mName = name; } ~~~ Surface的native init函数的JNI实现,也在android_view_Surface.cpp中,一起来看: **android_view_Surface.cpp** ~~~ static void Surface_init( JNIEnv*env, jobject clazz, jobject session, jint pid, jstring jname, jint dpy, jint w, jint h, jint format, jintflags) { //从SurfaceSession对象中取出之前创建的那个SurfaceComposerClient对象 SurfaceComposerClient* client = (SurfaceComposerClient*)env->GetIntField(session, sso.client); sp<SurfaceControl> surface;//注意它的类型是SurfaceControl if (jname == NULL) { /* 调用SurfaceComposerClient的createSurface函数,返回的surface是一个 SurfaceControl类型。 */ surface = client->createSurface(pid, dpy, w, h, format, flags); } else{ ...... } //把这个surfaceControl对象设置到Java层的Surface对象中,对这个函数就不再分析了 setSurfaceControl(env, clazz, surface); } ~~~ 4. copyFrom的分析 现在要分析的就是copyFrom了。它就是一个native函数。看它的JNI层代码: **android_view_Surface.cpp** ~~~ static void Surface_copyFrom(JNIEnv* env,jobject clazz, jobject other) { //根据JNI函数的规则,clazz是copyFrom的调用对象,而other是copyFrom的参数。 //目标对象此时还没有设置SurfaceControl,而源对象在前面已经创建了SurfaceControl constsp<SurfaceControl>& surface = getSurfaceControl(env, clazz); constsp<SurfaceControl>& rhs = getSurfaceControl(env, other); if (!SurfaceControl::isSameSurface(surface, rhs)) { //把源SurfaceControl对象设置到目标Surface中。 setSurfaceControl(env, clazz, rhs); } } ~~~ 这一步还是比较简单的,下面看第五步writeToParcel函数的调用。 5. writeToParcel的分析 多亏了必杀技aidl工具的帮忙,才挖出这个隐藏的writeToParcel函数调用,下面就来看看它,代码如下所示: **android_view_Surface.cpp** ~~~ static void Surface_writeToParcel(JNIEnv* env,jobject clazz, jobject argParcel, jint flags) { Parcel* parcel = (Parcel*)env->GetIntField(argParcel, no.native_parcel); //clazz就是Surface对象,从这个Surface对象中取出保存的SurfaceControl对象 const sp<SurfaceControl>&control(getSurfaceControl(env, clazz)); /* 把SurfaceControl中的信息写到Parcel包中,然后利用Binder通信传递到对端, 对端通过readFromParcel来处理Parcel包。 */ SurfaceControl::writeSurfaceToParcel(control, parcel); if (flags & PARCELABLE_WRITE_RETURN_VALUE) { //还记得PARCELABLE_WRITE_RETURN_VALUE吗?flags的值就等于它 //所以本地Surface对象的SurfaceControl值被置空了 setSurfaceControl(env, clazz, 0); } } ~~~ 6. readFromParcel的分析 再看作为客户端的ViewRoot所调用的readFromParcel函数。它也是一个native函数,JNI层的代码如下所示: **android_view_Surface.cpp** ~~~ static void Surface_readFromParcel(JNIEnv* env, jobject clazz, jobject argParcel) { Parcel* parcel = (Parcel*)env->GetIntField( argParcel,no.native_parcel); //注意下面定义的变量类型是Surface,而不是SurfaceControl const sp<Surface>&control(getSurface(env, clazz)); //根据服务端传递的Parcel包来构造一个新的surface。 sp<Surface> rhs = new Surface(*parcel); if (!Surface::isSameSurface(control, rhs)) { //把这个新surface赋给ViewRoot中的mSurface对象。 setSurface(env,clazz, rhs); } } ~~~ 7. Surface乾坤大挪移的小结 可能有人会问,乾坤大挪移怎么这么复杂?这期间出现了多少对象?来总结一下,在此期间一共有三个关键对象(注意我们这里只考虑JNI层的Native对象),它们分别是: - SurfaceComposerClient。 - SurfaceControl。 - Surface,这个Surface对象属于Native层,和Java层的Surface相对应。 其中转移到ViewRoot成员变量mSurface中的,就是最后这个Surface对象了。这一路走来,真是异常坎坷。来回顾并概括总结一下这段历程。至于它的作用应该是很清楚了。以后要破解SurfaceFlinger,靠的就是这个精简的流程。 - 创建一个SurfaceComposerClient。 - 调用SurfaceComposerClient的createSurface得到一个SurfaceControl对象。 - 调用SurfaceControl的writeToParcel把一些信息写到Parcel包中。 - 根据Parcel包的信息构造一个Surface对象。这个Surface对象保存到Java层的mSurface对象中。这样,大挪移的结果是ViewRoot得到一个Native的Surface对象。 >[info] **注意**:精简流程后,寥寥数语就可把过程说清楚。以后我们在研究代码时,也可以采取这种方式。 这个Surface对象非常重要,可它到底有什么用呢?这正是下一节要讲的内容。