Posted on Leave a comment

SVG Path命令属性

Android从5.0开始支持SVG矢量图,通过Vector Asset工具将SVG文件转换VectorDrawable定义的XML文件中,在运行时inflate这个xml文件来绘制图层,这对于减小APK资源文件体积和避免混乱的分辨率支持上都有很好的效果,同时Android通过Support支持库的形式给予了低版本的支持。

Android上对SVG的支持是受限制的,仅支持SVG tiny1.2版本的属性和标签,而且不支持text标签。

path标签是SVG中最常用的标签,这其中最重要的属性就是d(command)属性,它标明这个路径的绘制起点、终点、中间路径关键点、两点之间是否为直线、弧线、贝塞尔曲线等等。

d(command)属性主要分几类:

起点

M、m来表示,如M150,0

表示从path的起点, 从x-150,y=0的坐标起点开始绘制

终点

Z、z来表示,无参数

表示path的终点,链接到path的起点,闭合path,然后结束绘制

直线

假设当前点坐标为(10,10)

L、l表示直线线段,如L100,100,表示从(10,10)开始,绘制一条到(100,100)的直线线段

H、h表示水平线段,如H100,表示从(10,10)开始,绘制一条到(100,10)的水平线段,等同于L100,10

V、v表示垂直线段,如V150,表示从(10,10)开始,绘制一条到(10,150)的垂直线段,等同于L10,150

三次贝塞尔曲线

假设当前点坐标为(100,200)

C、c表示三次贝塞尔曲线,如C100,100 250,100 250,200,表示起点坐标为(100,200),控制点1坐标为(100,100),控制点2坐标为(250,100),终点坐标为(250,200),绘制这一条三次贝塞尔曲线线段。

S、s也表示贝塞尔曲线,只是它比较特殊,它的控制点1来自于上一条C、c、S、s曲线的控制点2坐标与上一条C、c、S、s曲线终点坐标连线上的对称点,

就如上面的例子,S曲线的控制点1坐标就为(250,300),这样的曲线在连贯性上是平滑曲线,所以也称为是平滑三次贝塞尔曲线;

如果上一条线段不是C、c、S、s三次贝塞尔曲线,那么默认它的控制点1坐标与起点坐标一致;

如S400,300 400,200,假设沿着上一条S贝塞尔曲线继续绘制,则起点坐标为(250,200),控制点1坐标为(250,300),控制点2坐标为(400,300),终点坐标为(400,200)。

二次贝塞尔曲线

假设当前点坐标为(200,300)

Q、q表示二次贝塞尔曲线,如Q400,50 600,300,表示起点坐标为(200,300),控制点坐标为(400,50),终点坐标为(600,300),然后绘制一条二次贝塞尔曲线线段。

T、t也表示二次贝塞尔曲线,如同S、s平滑三次贝塞尔曲线一样,它“借用”了上一次二次贝塞尔曲线的控制点,取上次曲线控制点与上次曲线的终点坐标连线上对称点为新的控制点;

如果上一条线段不是Q、q、T、t二次贝塞尔曲线线段,那么默认它的控制点坐标与起点坐标一致。

如T1000,300,假设沿着上一条Q二次贝塞尔曲线继续绘制,则起点坐标为(600,300),控制点为(800,550),终点坐标为(1000,300)。

椭圆曲线

假设当前点坐标为(50,-25)

A、a表示椭圆曲线,如a25,25 -30 0,1 50,-25 l 50,-25,表示椭圆半径rx=25,ry=25,x轴方向上的旋转角度-30。

 

参考资料:

https://svgwg.org/svg2-draft/paths.html

https://developer.mozilla.org/en-US/docs/Web/SVG

Posted on Leave a comment

Chromium Android工程迁移编译过程

本文从Chromium编译的中间产物入手深入分析、学习Chromium Android版本的工程化定制流程。初始工作依赖于Chromium的ninja、GYP构建系统,在构建完成后基于编译中间产物,迁入Android Studio作为新的构建工程,测试编译发布的过程。

注:这种编译过程除了资源文件外其他编译中间产物,都不可修改,不具备大规模定制化的可能性,仅作为熟悉编译过程和代码结构的学习、测试使用。

前提

Chromium代码结构、Android开发、Android Studio使用

编译Chromium

编译步骤可以参考Chromium团队的文章,可以选择编译目标为chrome_public_apk、content_shell_apk,本文以chrome_public_apk为例。

编译结果APK

在以chrome_public_apk为编译目标后,在经历一段时间后编译完成,在out/***文件夹内就包含了所有的编译结果和编译中间产物,其中apk在apks文件夹内,可以拉取安装一下,除了包名外其他功能与Chrome基本一致,本文的迁移目标就是在Android Studio工程下同样可以编译出这个APK,再探讨后续的源码迁移和定制工作。

工作目录

在out/***文件夹下,我们主要涉及到的文件分为三类:so、jar、resource,各自又来自不同的Chromium模块。

apks—编译目标文件目录

gen—编译过程中间产物,基本不涉及

lib.java—jar文件的主要来源,将不同模块的java文件编译后汇集在这个目录

locale—国际化的资源文件

resource-zips—资源文件的主要来源,也是Android Studio module化的主要依据

lib.unstripped—so文件目录

建立Android Studio工程

由于Chromium原有模块是基于命名空间来管理的,而且Android的R资源文件定义方式与此关联,所以需要通过Android Application、Library module的方式进行区分,同时还需要将Android Support这一类第三方库通过Gradle依赖的方式进行关联,而不是JAR+资源文件的方式。

所以基于Chromium的模块划分方式分为如下几个子module:

app—org.chromium.chrome,主App Application

ui—org.chromium.ui,Android Library

base—org.chromium.base,Android Library

components—com.chromium.components,Android Library

content—org.chromium.content,Android Library

media—org.chromium.media,Android Library

autofill—org.chromium.components.autofill,Android Library

web_contents_delegate_android—org.chromium.components.web_contents_delegate_android,Android Library

third_party—com.chromium.third_party,Android Library

tools—org.chromium.tools,Android Library

url—org.chromium.url,Android Library

builder—org.chromium.build,Android Library

net—org.chromium.net,Android Library

mojo—org.chromium.mojo,Android Library

device—org.chromium.device,Android Library

gpu—org.chromium.gpu,Android Library

printing—org.chromium.printing,Android Library

services—org.chromium.services,Android Library

skia—org.chromium.skia,Android Library

迁移编译后so

lib.unstripped目录下的所有so文件,迁入主工程的jniLibs文件中,并在CMake文件中配置引入,切记。

add_library(xxx SHARED IMPORTED)
set_target_properties(xxx PROPERTIES IMPORTED_LOCATION src/main/jniLibs/${ANDROID_ABI}/libxxx.so)

迁移编译后Jar

lib.java目录下按照已经建立好的Android Library工程分别放入libs目录下,注意仅放入非interface.jar的文件,否则可能导致duplicate class问题,同时注意JAR文件重名问题,建议以多多级目录重命名的方式导入。

迁移编译后Resource

gen/chrome/android/chrome_public_apk目录下的AndroidManifest.xml 拷贝到主工程中

resource_zips目录下也同样按照Android Library工程分别解压放入res目录下,尤其注意覆盖问题,因为同一模块下可能有同名的资源文件。android_deps、gvr目录下的资源文件不引入,后续将通过Gradle依赖方式引入。

除此之外还需要将额外的资源文件引入主工程assets目录中,并且禁用压缩。文件如下:chrome_100_percent.pak

icudtl.dat

resources.pak

snapshot_blob.bin

locales目录(包含目录这一级)

修正工程参数+Gradle

上述步骤做完以后工程不能如期运行,还需要调整几个地方,因为有些java文件是在编译过程中生成的:

gen/chrome/android/chrome_public_apk__build_config_java下的buildConfig.java

此文件主要定义启动参数等信息,这个文件主要参考信息,由于Gradle编译的过程中最终会覆盖这个文件,所以里面的所有参数需要通过Gradle配置进行定义。

gen/chrome/android/chrome_public_apk__native_libraries_java下的NativeLibraries.java

此文件主要定义了需要引入哪些so文件、版本号等信息。

运行编译

这一系列的步骤,可以通过一步步的运行报错进行修正,最后得到正确运行的编译包。最后还是那句话,这只是探索定制化过程的一小小步,Chromium项目庞大,需要长久的深入。

如果只是想体验一下迁移后的结果工程,文末附Github工程

Posted on Leave a comment

Zircon内核与LK内核的关系

LK(Little Kernel)是一个为嵌入式应用设计的微系统内核,它为FreeRTOS、ThreadX这样的商业项目提供了一个不错的选择。这些系统仅提供有限的内存、有限的外设和任务集;Zircon运行在那些拥有快速处理器、不定大小内存、能够挂载任意外设的现代手机、PC等末端计算设备上。

Zircon内部构建在LK层之上;Zircon有进程的概念,LK则没有;Zircon的进程构建在LK的线程、内存结构之上。

更多的不同点:

Zircon有一类用户模式的支持,LK没有;

Zircon是一个对象句柄系统,LK没有这个概念;

Zircon有能力安全模型,在LK里所有代码都是被信任的。

随着时间的推移,为了满足新的需求、更好的适应上层系统,低层次的结构也可能会改变。

原文链接:

https://fuchsia.googlesource.com/zircon/+/HEAD/docs/zx_and_lk.md

延伸:

LK:

https://github.com/littlekernel/lk/wiki/Introduction

LK内核正在被使用的场景:Android的bootloader和Trusted Execution Environment