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

Java WEB系统微服务化迁移

  1. Docker
  2. 微服务
  3. Spring-Boot

支撑互联网公司运行的庞大后端服务系统经历了原始的BS架构设计、前后端分离、模块化组件、系统分层设计的进化,从计算资源的虚拟化到今天容器技术的应用,互联网一直在朝着资源高效配置、分布式集群服务的方向进发。

Docker作为当下最流行的容器化技术,相比于运行在实体物理机上的虚拟机技术,它具有轻量级资源隔离、快速部署、持续交付、版本控制、 可移植、开放技术等特点。

如果采用虚拟机技术去部署一套系统,需要几个步骤:

1、分配物理资源(CPU\内存\网络)

2、开机启动运行

3、安装系统运行时支撑环境(模版)

4、发布生产系统

5、上线。

采用Docker需要如下几个步骤:

1、拉取Docker Image

2、发布生产系统

3、上线

相比来看可能就会发现,Docker相当于把最繁琐最耗时的工作帮助我们解决了。Docker运行在(特定)操作系统之上,只需要一条命令即刻启动;通过Docker Image将运行时配置、依赖管理、版本管理集成一个Dockerfile描述文件中标准化,快速解决原始虚拟机技术中的1、2、3步骤。如果再搭配Google出品的Kubernetes容器管理工具更加得心应手。

与Docker并行出现一个架构模式-微服务,它并不是一种全新的架构体系,更确切的说是一种架构的思考。在经历了模块化、组件化、服务化之后,系统的架构设计实现复杂、服务调用关联度高等问题困扰着一个系统的稳定性和开发难度。微服务是在原有的服务治理的基础上,将原有系统服务的粒度进行再切分使得服务之间的耦合性降至最低,同时不依赖于过多的外部运行时环境,对外暴露的输入输出可能只是一个JSON、XML数据集,可以实现大规模的快速部署运行。这些特点与Docker的容器化优势不谋而合,这也是当前微服务实践采用比较多的一种方式。

Spring Boot在微服务概念出现之前已经发布了有一段时间,但并没有大行其道,大家对于Java Web的项目更倾向于原有Servlet Container Server的部署模式。随着微服务的出现,Spring Boot再次引起了大家的注意,同时Spring在被收购后也在朝着云服务商的方向上进发,推出了自己的云服务平台。

相比一切全新的服务系统,遗留的Java WEB系统如何进行更好的迁移使用微服务,是需要考虑的一大问题。当前的项目中框架采用了Freemarker+Spring+Hibernate的方式,Spring的配置是原有的XML配置方式,与Spring-Boot推荐的注解配置相比,迁移难度较大。

Spring-Boot使用注解配置剥离了XML的配置方式,使用内嵌式Servlet Container(Jetty\Tomcat\Undertow)来实现服务的HTTP通信、监控、交互。与此相对照,能否维持XML配置不变,仅使用内嵌Servlet Container来提供服务呢?答案是:可以。

采用Tomcat Embed作为默认的Servlet Container,通过Tomcat Bootstrap中Host、Port配置来实现HTTP服务,指定WEB路径的方式来提供Spring XML配置部分和其他WEB资源,这样就基本实现了原有Java WEB系统的服务化迁移。

在迁移测试过程中,也遇到了几个坑。

1、Gradle编译工具对JAR包的支持度不够完善,需要额外的插件来实现Eclipse FatJar的功能。

2、如果自定义Jar合并时,一定要注意Spring Schema文件的合并。在不使用插件的情况下,会导致spring schema XSD文件的丢失。需要在插件支持下通过tramformer来合并。

如果单独使用Maven来打包之需要通过修改POM文件来实现。

相关资料     Docker Spring-Boot Gradle FatJar Plugin Tomcat Embed

Posted on Leave a comment

Android Studio编译NDK工程

由于现在的开发都是基于AS的,但是当前AS对NDK的支持还不是特别完善,再切换ADT略显别扭,简单根据NDK文档写了一个Gradle脚本,来调用NDK ENV来编译。

目前的脚本仅能实现对*.c的编译,对NativeActivity的支持还不是特别完善。

主要分为3个步骤:

1)NDK编译链环境检查

2)编译

3)迁移编译后so文件、清理文件夹

将脚本放入build.gradle的android标记内。

然后将这个任务添加到编译过程中