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

EOS的账户授权和多重签名

EOS在它的技术白皮书中介绍了账户、授权、以及多重签名的技术概念,我们也可以从EOS的代码中一窥其中的奥秘,它与BTC、ETH的区块链实现有什么区别或者有更为先进的地方,那就需要先从概念入手细细体会。

钱包

钱包是一个存储账户Key、权限Key的客户端。它支持一个或者多个账户,通过高复杂度的密码来加锁、解锁钱包。EOS的代码中自带了一个轻量级的钱包-keosd。keosd通过调用cleos接口来与区块链建立连接。

在这一点上与BTC、ETH基本一致,由于BTC、ETH并没有多权限、授权的概念,这是EOS钱包中的一大特点,这对于后期的账户找回也会有略许的差别。

账户:

一个账户以人类可读的名字存储在区块链中,它按照权限配置从属于一个个人或者组织。在转账或者推送一笔交易到区块链的时候账户是必须要有的。

BTC简单说账户就是Address,它没有人类可读标记,就是一串Base58编码之后的字符,区分大小写;ETH的账户也是Address的概念,是一串公钥加工后的十六进制串,不区分大小写,但ENS的出现弥补了人类识读的短板,现有的很多钱包也支持ENS对Address的解析;EOS的原生支持,也算是在吸取前人之鉴对账户这一概念的增强。

授权、权限

授权方来决定是否将某个权限来授予某个行为。

每个账户都有两个固定命名的权限。

owner

如其所名,owner拥有整个账户的所有权。只有极少的交易需要这个授权,主要集中在对账户所有权变更的时候。强烈建议!!!将这项权限保存在离线存储中,不与任何人分享。owner权限可以用于恢复可能已被泄漏的其他权限。

active:

它主要用于转账、对块生产者投票、处理其他高级别的账户操作。

除了这两个固定命名的权限外,一个账户可以拥有一些自定义的权限来扩展账户的功能。自定义权限具有非常高的灵活性而且已经被地址化,权限如何被使用被约定,这完全取决于开发者社区如何使用它。

被授予权限的一方会被分配到一个、多个公钥或者一个账户名。

权限与签名

单签名(默认账户配置)

一个账户刚被创建时,有owner、active两个权限,它们都被地址化为一个key字符串,每个key的权重为1,每个权限的开启阈值为1。这项默认的配置就需要一个签名就可以授权来做某些行为。因为每个key的权重>=开启阈值。

@bob 账户授权

Permission Account Weight Threshold
owner 1
EOS5Ez…25Dch 1
active 1
EOS61c…TgmcX 1

上图的@bob账户中,@bob对onwer权限的权重为1,阈值为1,符合权限授予的最小要求就可以发起一笔交易。这笔交易就只需要@bob用它自己的owner key进行签名就可以了,签名之后将交易发给cleos来处理。

多重签名以及自定义权限

下图的例子虚构了一个账户@multisig,它对其他的两个账户@bob、@stacy授予了owner、active权限,同时它对@bob、@stacy、一个公开账户授予了publish权限也赋予了不同的权重。

@multisig 账户授权

Permission Account Weight Threshold
owner 2
@bob 1
@stacy 1
active 1
@bob 1
@stacy 1
publish 2
@bob 2
@stacy 2
EOS7Hnv4i…Sqt 1

在这个例子中,onwer权限的开启阈值为2,在这一权限级别的任何改变都需要权重大于等于2才可以,但@bob、@stacy各自的权重都为1,这就是需要两者共同签名才能获取完整的授权。

当需要active授权来发起一笔交易是,开启阈值被设置为1,@bob、@stacy的权重都为1,它们就可以独立签名完成授权。

还有一个自定义权限叫做publish。假设这个权限是用来发表博文到@multisig账户的博客Dapp的。这项权限的开启阈值为2,@bob、@stacy的权重都为2,一个公开账户的权重为1,根据上文的权重、阈值关系,@bob、@stacy都可以独立签名发表一篇博文,但那个公开账户则需要额外的签名来获取到publish权限,无论它是从@bob还是@stacy。

通过上面的这个例子我们可以看到@bob、@stacy作为一个账户的所有者利用权限的分配实现一个主编、编辑的角色,可能上面的例子并不是一个好的设计,但它充分证明了EOS权限体系的灵活性。同时我们也注意,权限可以授予给一个账户名,也可以是一个公开key,这样也增加了一些灵活性。

 

后记:

EOS的权限系统相比于BTC、ETH的有了很大的进步,也更加贴近了现实记账系统和其他软件系统的架构模型,也正是因为这样,也让EOS对于账户找回成为了可能,这套虽然不算复杂但对于普通用户还是略复杂的权限带来的是机会还是风险,这都要主网上线后去验证。

 

参考:

https://github.com/EOSIO/eos/wiki/Accounts%20%26%20Permissions#putting-it-all-together

Posted on Leave a comment

以太坊矿工奖励之多少

以太坊通过PoW(工作量证明)的共识算法来生产一个新的区块,通过不断的调整区块nonce值来让以太坊网络上的矿工来计算不同的随机数,当计算出的随机数小于maxUint256除以header.Difficulty时就意味着挖矿成功,一个新的区块产生了。

在广播给全网新区块产生的同时,系统会发放一定量的以太币作为挖矿成功的奖励。与比特币挖矿不同的是以太坊协议不仅承认最长链上的区块(1),对于同时产生的非最长链的区块(1·)鼓励子区块(2)来将它索引起来,并将它(1·)称为子区块的叔块,索引了叔块的子区块也会获得一定的奖励,系统最多允许索引两个叔块,叔块与当前区块的高度差最大为6。

所以矿工奖励主要是三个部分:区块奖励、Gas奖励、索引叔块奖励;当然挖出叔块的矿工也会给予奖励。

1、区块奖励,在4370000块硬分叉之前奖励5个以太币,之后奖励3个以太币;

2、Gas奖励,区块内所有交易的Gas费用归矿工所有;

3、索引叔块奖励,每索引一个叔块会奖励区块奖励的1/32;

挖出叔块的奖励=(叔块高度+8-索引叔块的区块高度)*区块奖励/8


挖矿奖励:

区块高度 1-4370000 4370000-~
区块奖励 5 3
Gas奖励 \ \
索引叔块奖励 5/32 3/32
总计(1个叔块) 5+0.15625+块内Gas费 3+0.09375+块内Gas费
总计(2个叔块) 5+0.3125+块内Gas费 3+0.1875+块内Gas费

叔块奖励:

与被索引区块高度差 1-4370000 4370000-~
1 4.375 2.625
2 3.75 2.25
3 3.125 1.875
4 2.5 1.5
5 1.875 1.125
6 1.25 0.75

参考:

https://github.com/ethereum/go-ethereum/blob/master/consensus/ethash/consensus.go

https://github.com/ethereum/go-ethereum/blob/master/core/state_transition.go