技术专栏丨Fabric 和 Sawtooth 技术分析(下)

在前一篇文章(Fabric和Sawtooth技术分析(上))中,我们着重跟大家分享了 Fabric 相关的内容,在本篇文章中,我们将围绕着 Sawtooth 进行一些分析和探讨。

Sawtooth 结构及分析
Sawtooth 是 Intel 公司推出的企业级区块链,2018年 Intel 将其贡献给 Hypherlegder 项目。本文中笔者主要从 Sawtooth 的存储结构、数据结构、网络结构方面做简要介绍。

Sawtooth

Sawtooth 的存储结构

Sawtooth 使用名为 Radix Merkle Tree 的存储结构,它融合了 Radix Tree 和 Merkle Hash Tree 的功能,先看看这两种结构:

  • Radix Tree

Radix Tree 概念比较拗口,简单地说就记住在这个树上,任何一个叶子节点的位置和一个 01 串唯一对应,因此我们可以根据一个 01 串组成的地址确定叶节点是谁。

下图是一个 Sawtooth 所使用的 Radix Tree 对应的字符串,由70个16进制字符组成,前6位称为命名空间前缀(Namespace prefix),后边的是该前缀所对应的空间内可分配的地址范围。

我们以 Sawtooth 预定义的一个 Transaction Family-IntegerKey 为例,注意 Sawtooth中 的 Transaction Family 相当于 Fabric 中的 chaincode 或者 Ethereum 中的 Smart Contract 。IntegerKey 的前缀(prefix)计算法方法是:hashlib.sha512(‘intkey’.encode(‘utf-8’)).hexdigest()[0:6],运算结果是 ‘1cf126’。那么,存储该 transaction family 中一个 block 的地址就是:

address = “1cf126” + hashlib.sha512(‘name’.encode(‘utf-8’)).hexdigest()[-64:]

当然,地址的构成也可以更复杂一些,比如,有个自定义 Transaction Family 的前缀是 prefix = “my-transaction-family-namespace-example”。命名空间可以进一步划分为 object-type 和 unique-object-identifier 。其中,object-type = “widget-type”,unique-object-identifier = ”unique-widget-identifier”。那么,对应的字符串就可以计算如下:

hashlib.sha256(“my-transaction-family-namespace-example”.encode(‘utf-8’)).hexdigest()[:6] + hashlib.sha256(“widget-type”.encode(‘utf-8’)).hexdigest()[:4]

+ hashlib.sha256(“unique-widget-identifier”.encode(‘utf-8’)).hexdigest()[:60]

最后得到下面的地址:

‘4ae1df0ad3ac05fdc7342c50d909d2331e296badb661416896f727131207db276a908e’

众所周知,2的10次方是1K,20次方是1M,30次方是1G,40次方是1T,对于一个名字空间,Sawtooth 为其保留64位,从存储空间需求上讲,即使有一些位被用来做子空间划分,应该也够用了。在查找时,完全可以根据 Transaction 的名字找到它的存储位置,所以检索速度也会非常快。

我们可以认为,Sawtooth 就像一个原始的区块链,每向后一层都可以分叉,以树的形式组织数据存储,而不再是以线性的方式来组织数据存储。也可以把原始的比特币区块链理解为只有一个Transaction Family 的 Sawtooth。在完整的分析过 Sawtooth 以后,最应该记住的就是 Sawtooth 的存储结构,它其后的所有设计都是基于这一结构。

  • Merkle Hash Tree

Merkle Hash Tree 的特点是所有节点的值都是哈希值,每个哈希值是根据其子节点的哈希值计算出来的,所以任何一个节点和哈希值出现变化,它的上层节点的哈希值都会跟着变。

Sawtooth 采用 Radix Merkle Tree 结构做数据存储的好处就是给定 Block 名及类别,直接计算哈希值,就找到它的存储位置了。而且存储空间是隔离的,每个 transaction family 的存储空间和其它的都是分开的,互不影响。所以,从存储结构来看,基于 Sawtooth 的区块链天生是多条连的(Forked),很容易去解析它的分叉。

Sawtooth 的数据结构

Fabric 没有去严格定义数据结构,Sawtooth 的数据结构也没有什么值得特别提出的亮点。只要知道 Sawtooth 定义了 Transaction 包括Header 和 Payload 两部分即可,而 Sawtooth 要求不管是一个还是多个 Transaction 必须被封装在 Batch 中才可以提交给 Transactio n的 Processor ,或者说 Transaction Processor 只接受以 Batch 为最小单位的 Transactions 。同样地,Batch 也包括 Header 和 Payload 两部分,其关系如下图所示:

Sawtooth 的网络结构

如下图所示,Sawtooth 的一个节点可能由如下几个部件组成:Validator、Transaction Proc essor、REST API、以及 Client。Validator 是 Sawtooth 的核心部件,主要功能包括接收 Transaction 请求,并将其转发给相应的 Transaction Processor 来处理,根据 Transaction Processor 的处理结果,决定如何生存新的区块,如何给 Client 回显。Validator 还要与其他的 Validator 协同,以保持 Sawtooth 网络的全局状态一致。Transaction Processor 顾名思义就是用来专门处理某一类型 Transaction Family 的 Transactions 的 Processor 。

Client 需要按照 Transaction 和 Batch 规定的数据结构生成请求,REST API 则是标准化的网络传输数据格式。之所以说可能由这几部分组成,是因为对 Sawtooth 来说,只有 Validator 属于其固定结构,比如图中有 Validator1 和 Validator2 ,而 Validator2 就没有连接其他部件,而是只与 Validator1 相连。从构成角度看,一个 Sawtooth 网络可以只由一个 Validator 构成。从网络方面看,其他的 Validator 可以动态加入网络。从部件方面看,Transaction Processor 可以动态注册到 Validator ,然后 Client 提交相应 Transaction 就有对应的 Processor 来进行处理。网络节点和部件可以分别使用不同的端口来区分。这样,Sawtooth 网络就变成完全动态的了,每个组成部分都可以动态插拔。

接下来,我们先看看 Validator 的组成结构,Validator 的软件实现部分称为 Journal,如下图。从功能上看,Journal 包括 Completer、ChainController 和 BlockPublisher 三个主要部分。

当 Batch 被提交给 Validator 后,先被交付到 Completer ,它先检查是否 Batch 的所有依赖项都得到了满足。完整且满足依赖的 Batch 会被提交给 ChainController 。Sawtooth 的这种设计可以支持串行和并行的 Batch,注意这已经不是进程级并行了,而是线程级并行。接下来再看看 ChainController 是干什么的:

ChainController 需要完成4个工作:

  • 1)确定块的头在哪
  • 2)确定当前块在哪-先去 BlockCache 里找,再去 BlockStore 里找。
  • 3)验证块有没有损坏
  • 4)把新块写进区块链

写入新区块链后的发布工作则是由 BlockPublisher 完成。从图中可以看到,ChainController 和 BlockPublisher 本质上都是接口,具体的实现由更下层的共识(Consensus)机制完成,共识机制向上提供 BlockVerifier,ForkResolver 和 BlockPublisher 三个功能。

从整体上看,Validator 的结构比较简单。接下来再看看 Validator 之间是怎么连接起来的。Sawtooth 的 Validator 的网络连接方式如下图,可能会有点乱,同时解释地也不是很清楚,这里笔者的理解是:把它看做一个 Ad Hoc 网络,组网的过程完全就是模拟 Ad Hoc 网络路由节点发现的。开始的时候有初始(生成 Genesis block 的)节点,它可以发出广播包,问谁在它边上,可以按照设定的规则加入网络,如果有人应答就可以加入,然后这些节点继续广播,每个广播包只传播给距离自己1跳的 Validator 节点,这样网络很快就组成了。有新节点想加入也是这样,发广播包,看看自己周围有没有可以直连的节点,退出就无所谓了,反正少一个节点不影响网络。我们知道 Ad Hoc 网络的健壮性和灵活性都是非常高的,所以 Sawtooth 的 Validator 网络中任何节点都是可以动态加入或退出的,只要网络规模足够大,理论上,网络的健壮性是有保障的。

这里有两个关键问题其实没有说清。

  • 1)哪些 Validator 可以加入该网络
  • 2)Validator 接受哪些 client 提交的 Batch

这两个问题就构成了访问控制和隐私保护功能的核心,而 Fabric 花大力气实现的体系结构也正是为了回答这两个问题,稍后会详细说明,核心网络介绍完毕以后,会想到 Client 提交了 Transaction,那Transaction 执行与否?所以,还差一个事件机制来实现消息传递和回显功能。这里的事件机制要确定这么几件事:

  • 1)谁应该被告知事件—(广播?还是根据注册情况组播单播)
  • 2)事件应该包括什么—(消息格式-收据(Transaction Receipt))
  • 3)事件在什么情况下,或什么时候才算有效—(放在 Transaction Receipt Store 中,通知发起 Transaction 的 client 来拿)

下图是 Sawtooth 的事件机制示意图,它把技术实现和组件名称混到一起,看起来也比较乱。大体的意思是左上部是事件子系统用 Zero message queue 的技术实现,其特点是在需要的时候可以随时创建,右上部是写好的类库,注册后,只要满足约束就可以调用它。下部说的是 Transaction Processor 调用具体的 Handler 处理 Transaction 后会告诉 ChainController 的 Scheduler 和 Executor 执行 Transaction 的结果情况,ChainController 除了把新的 block 写到它应该在的地方之外,还会把 Transaction 的 Receipt 放到一个叫 Transaction Receipt Store 的地方,这时候 ChainObserver (Client 注册后产生的一个部件)就会告诉 Client, Transaction 执行完了,来拿收据吧。

下面是一些事件的例子,可以帮助我们理解事件的格式:

 1Example events generated by BlockEventExtractor:
 2Event {
 3  event_type = "sawtooth/block-commit",
 4  attributes = [
 5    Attribute { key = "block_id"value = "abc...123" },
 6    Attribute { key = "block_num"value = "523" },
 7    Attribute { key = "state_root_hash"value = "def...456" },
 8    Attribute { key = "previous_block_id"value = "acf...146" },
 9  ],
10}
11
12
13Example events generated by ReceiptEventExtractor:
14// Example transaction family specific event
15Event {
16  event_type = "xo/create",
17  attributes = [Attribute { key = "game_name"value = "game0" }],
18}
19
20// Example sawtooth/block-commit event
21Event {
22  event_type = "sawtooth/state-delta",
23  attributes = [Attribute { key = "address"value = "abc...def" }],
24  event_data = <bytes>
25}

Sawtooth的访问权限控制

Sawtooth 的权限(Permissions)机制应该参考过 Fabric。主要功能包括网络权限的设置(哪些 Validator 可以加入这个网络),和 Transaction 权限设置(哪些 client 提交的 Batch 可以被 Validator 执行)两种。和 Fabric 一样的是,Sawtooth 也需要配置文件,如果所有功能全部用配置文件完成则称为 Off-Chain transactor  Permission,通常来说小规模网络,极限情况下,只有一个节点的网络完全可以使用 Off-Chain 的方式实现。在 Off-Chain Permission 中,权限是静态设置的。在配置文件 validator.toml 中,直接配置:

[permissions]

ROLE = POLICY_NAME

Policy file:

PERMIT_KEY <key>

DENY_KEY <key>

这里的 ROLE,POLICY_NAME 暂不解释,key 一般是一个公钥,PERMIT_KEY 和 DENY_KEY 就将它理解为一个 bool 值,一个是1,一个是0,含义就是允许不允许。

和 Fabric 不一样的地方是,Sawtooth 还有一种配置方式叫 On-Chain transactor Permission 。就是在区块链上直接设置访问权限,还专门为此设置了一个叫 Identity 的 Transaction Family 。这样 transactor Permission 就有自己的存储空间,其当前值也好,变化也罢,所有节点都可以同步过去,不会存在各个节点配置文件不一样导致系统出错的可能性。

接下来具体看下 Identity。Identity Namespace 以 key-value 对的形式存储 roles,key 是 role name,value 是 policy。所有的 role 都以 transactor 为前缀。比如下面:

transactor.SUB_ROLE = POLICY_NAME

首先,第一个问题是开始谁可以设置访问权限。和 Fabric 例子中类似,机构 R4 通过网络配置文件设置访问权限一样。在 Sawtooth 中,理所当然的应该由创始区块的生成者来设置初始权限。它执行如下命令来设定允许给别人授权的人的公钥:

sawset proposal create sawtooth.identity.allowed_keys=00000

这里的00000是创始区块的生成者自己的公钥,那现在就它自己可以给别人授权。这个类似于 Fabric 里设定,公钥设定以后可以利用 identity-tp 进行授权,也可以继续用 sawset proposal create 命令让其他 Validator 有权做网络或者 Transaction 授权。proposal 这个子命令其实就能猜到 Sawtooth 设计访问权限的时候肯定是参考了 Fabric 的。

具体的 Transaction 授权命令的例子如下:

sawtooth identity policy create policy_1 “PERMIT_KEY *”,这个的意思是创建一个叫 policy_1 的策略,对所有人都是允许的,也就是谁都可以提交 Transaction ,注意这仅仅是个策略,还可以定义其他的策略,相当于 Fabric 里的 Deploy 而不是 Invoke 。可以调用 sawtooth identity policy list,查询当前有哪些策略,比如在执行了刚才的命令后,会得到如下回显:

$ sawtooth identity policy list

policy_1:

Entries:

PERMIT_KEY *

接下来执行如下命令:

$ sawtooth identity role create transactor policy_1

就会把 transactor 的策略设置为 policy_1。换句话说,这时,就真正让 policy_1 生效了,类似于 Fabric 里的 Invoke。然后可以调用sawtooth identity role list,查询当前角色的状态:

$ sawtooth identity role list

transactor: policy_1

上边我们都用 transactor 为例子,其实 role 可以有如下几种:

default、transactor、transactor.transaction_signer、transactor.transaction_signer.{tp_name}、transactor.batch_signer。

意思其实从字面上能看出来,这里 transactor 可以是 organization,一个 transactor.batch_signer 可以是一个 organization 下边的部门,transactor.transaction_signer 可以是该部门的一个用户,如果有好多 tp 的话,该用户可以只具有其中某些 tp 的执行权限。

比如,我们现在自己写了一个新的 tp 叫 supply_chain,新定义了两个用户,一个的公钥是12345,另一个的公钥是23456,我们希望这个 tp 只有这两个新用户可以运行,这时我们就可以执行命令:

sawtooth identity policy create policy_2 “PERMIT_KEY 12345” “PERMIT_KEY 23456”

sawtooth identity role create transactor.transaction_signer.supply_chain policy_2

网络权限设置和 tp 执行权限设置差不多,比如有个 Validator 对外的公钥是00001,然后执行如下命令,它就不能加入网络了:

$sawtooth identity policy create policy_3 “DENY_KEY 00001”

$ sawtooth identity role create network policy_3

$ sawtooth identity role list

network: policy_3

Fabric 和 Sawtooth 的比较

相信看完了 Fabric 和 Sawtooth 的介绍,大家对这两个项目都有了自己的认识。笔者再谈一下个人对这两个项目的理解。

首先,从背景上看,Fabric 是脱胎于 Ethereum 的,或者说能在 Fabric 上看到 Ethereum 的影子,而 Sawtooth 已经看不到 Ethereum 的任何痕迹了。反而,个人觉得 Sawtooth 更加纯粹一点,它就是一个有共同起点的 比特币区块链,只是比特币没有不同 Transaction 的概念,而 Sawtooth 把 Transaction 按照用途分类,且允许用户根据需要自己定义新的 Transaction (这个概念是 Ethereum 提出来的)。

从体系结构角度看,我认为 Sawtooth 明显优于 Fabric 。Fabric 像是针对特定问题的一个专用解决方案,而不像一个通用架构。Sawtooth 可以认为是一个通用架构,然后根据需求变为一个专用解决方案。从访问控制角度看,Fabric 像是根据实际情况建设了一套管网,让涉及隐私的数据只能在其中运行。Sawtooth 则更像是在一套管网上加装了阀门,通过阀门来控制数据的流向。这可能和 IBM 以及Intel 的业务特点和公司文化息息相关。我的印象中,IBM 是一家咨询公司,专门针对企业级用户设计解决方案。Intel 是处理器公司,不管你的业务是什么样的,它提供通用中央处理器,让你能根据自己的需要配置成自己的专用解决方案。

当然,二者也有一些具体的差异:Fabric 中,多个节点收到相同的输入后分别独立执行,以期得到一致的结果。Sawtooth 的 SGX 和基于 SGX 的 PoET 验证的是在一台机器上的执行结果,没有再让每个节点都去执行一遍,而是一个执行完了以后去和别的同步结果。二者的假设不同,效率上也有差别。Fabric 的权限控制依赖形成 channel 这种体系结构,Sawtooth 的权限控制通过 Transaction 本身进行设置。或者说,Fabric 只有特定的人能看,但能看到特定范围内的全部。Sawtooth 所有人都可以看,但 Transaction 的 Permissions 限制了能看什么。Fabric 的 orderer 完成 Transaction 排序,可以实现进程级并行。Sawtooth 的排序是在 batch 里指明依赖关系,通过Completer 排序实现线程级并行。

对 Fabric 来说,要设计它时,大家认可的网络结构就是 Ethereum 了,怎么能稍作修改,实现隐私保护和访问控制是它的设计目标。Sawtooth 没这种包袱,可以重新设计网络。所以,我感觉 Fabric 更像是一个过渡性的产品。从我的角度看,Sawtooth 的结构设计的比较精巧,可扩展性强,这是它比 Fabric 强的地方。但它还可以借鉴 Fabric,增加类似 CA 的机制确保用户可以被识别,也应该增加权限配置的灵活性,比如引入 ABAC,等等。不过,现在这样就已经非常不错了。

推荐阅读:

技术专栏丨Fabric和Sawtooth技术分析(上)

技术专栏丨基于Core ML的通用性机器学习开发框架探索

干货分享丨研发代码质量管理技术最佳实践

技术专栏丨Redis分布式锁的小坑踩一踩

举个例子丨什么是量子计算机?比常规计算机强在哪里?

作者:YK Sugi

译者:赵磊

原文链接:http://t.cn/EZAElk0

本文作者访问了加拿大温哥华的一家名为 D-Wave System 的制造尖端量子计算机的公司,并在那里学习了很多关于量子计算机的知识。

在这篇文章中,作者将通过一个简单地例子让没有物理或计算机科学知识地小伙伴也能搞懂什么是量子计算机,欢迎分享~

1什么是量子计算机

量子计算机是一种使用量子力学原理进行计算的计算机,它能比常规计算机更有效地执行特定类型的计算。

听的是不是有点云里雾里?不是说好了没有物理学或计算机科学知识也能听懂吗?别急,这里将通过一个简单的例子来告诉大家,它到底是什么。

为什么解释什么是量子计算机,首先就需要解释一下常规(非量子)计算机。

2存储信息方式有何不同

一台普通的计算机以 0 和 1 的 序列存储信息,不同类型的信息,如数字、文本和图像都可以使用这种方式表示,这种由 0 和 1 组成的序列中的每个单元都被成为比特位,所以,比特位可以设置为 0 或 1。

量子计算机不使用比特位来存储信息,相反,它使用一种叫量子位的东西,每个量子位不仅可以设置为 1 或 0,还可以设置为 1 和 0。那这到底意味着什么呢?这里用一个简单的例子来解释这个问题:

假设我们在经营一家旅行社,需要把一群人从一个地方搬到另一个地方。

为了简单起见,假设现在只需要移动3个人—— Alice、Becky 和 Chris。我们为此预定了两辆出租车,但想知道谁上了哪辆出租车。另外我们也得到了关于谁和谁是朋友,谁和谁是敌人的信息。

这里我们假设:

  • Alice 和 Becky 是朋友
  • Alice 和 Chris 是敌人
  • Becky和 Chris 是敌人

我们的目标是把这3个人分成两组并实现以下两个目标:

  • 最大限度地增加共享同一辆车的朋友对的数量
  • 最大限度地减少共享同一辆车的敌人对的数量

这是这个问题的基本前提。我们首先考虑如何用常规计算机解决

3用常规计算机去解决问题

要用普通的非量子计算机解决这个问题,首先需要弄清楚如何用比特存储相关信息。

我们把这两个出租车标记为出租车 1 号和出租车 0 号。

然后,可以用3个比特位表示谁进入哪辆车。

例如,我们可以通过将这3位设为0、0 和 1 来表示:

  • Alice 在 0 号出租车
  • Becky 在 0 号出租车
  • Chris 在 1 号出租车

因为每个人有两种选择,所以有 2x2x2 = 8 种方法将这群人分到两辆车上。

这里列出了所有可能的情况:

A | B | C

0 | 0 | 0

0 | 0 | 1

0 | 1 | 0

0 | 1 | 1

1 | 0 | 0

1 | 0 | 1

1 | 1 | 0

1 | 1 | 1

使用3个比特位,就可以表示这些组合中的任何一种。

计算每个配置的得分:

现在,使用常规计算机,我们如何确定哪种配置是最好的方案呢?

为此,我们需要定义如何计算每个配置的得分。这个分数将代表每个解决方案达到我前面提到的两个目标的程度:

  • 最大限度地增加共享同一辆车的朋友对的数量
  • 最大限度地减少共享同一辆车的敌人对的数量

我们简单定义分数如下:

给定配置的分数 = 共享同一辆车的朋友对数 – 共享同一辆车的敌人对数

例如,假设 Alice、Becky 和 Chris 都乘坐出租车1号。用三个比特表示为 111。

在这种情况下,只有一对朋友共用一辆车—— Alice 和 Becky。

但是却有两对敌人共用一辆车——Alice 和 Chris 以及 Becky 和 Chris。

所以,这个配置的总分为 1 – 2 = -1。

解决问题:

有了这些,我们终于可以着手解决这个问题了。

对于一台普通的计算机,要找到最好的配置,需要遍历所有配置,看看哪个达到了最高分。

构建的表格如下:

A | B | C | Score

0 | 0 | 0 | -1

0 | 0 | 1 | 1 <- 最佳解决方案之一

0 | 1 | 0 | -1

0 | 1 | 1 | -1

1 | 0 | 0 | -1

1 | 0 | 1 | -1

1 | 1 | 0 | 1 <- 另一个最佳解决方案

1 | 1 | 1 | -1

这里有两个正确的答案——001 和 110,都达到了 1 分。

这个问题相当简单。但是随着越来越多的人参与到这个问题中来,用一台普通的电脑很快就会变得难以解决。

可以看到如果是3个人,需要遍历8种可能的配置。

如果有4个人呢?我们需要遍历 2x2x2x2 = 16 个配置。

对于n个人,我们需要通过遍历2的n次方个配置来找到最佳解。

所以,如果有100个人,我们需要遍历:

2¹⁰⁰ ~= 10³⁰ 个配置

因此这是常规计算机根本无法解决的问题。

4用量子计算机去解决问题

那么如果我们用量子计算机来解决这个问题呢?

让我们回到把3个人分到两辆出租车的例子。

正如我们前面看到的,这个问题有8种可能的解决方案:

A | B | C

0 | 0 | 0

0 | 0 | 1

0 | 1 | 0

0 | 1 | 1

1 | 0 | 0

1 | 0 | 1

1 | 1 | 0

1 | 1 | 1

用一台普通的计算机,用3个比特位,一次只能表示其中一个解——例如 001。

然而,使用量子计算机,通过3个量子位,我们可以同时表示所有8个解。

关于这个说法的确切含义存在争议,但作者的看法是这样的:

首先,来看这3个量子位中的第一个量子位。当将其设置为 0 和 1 时,就好像创建了两个并行世界。

在其中一个平行世界中,量子位被设置为 0,而在另一个平行世界中为1。

现在,如果再把第二个量子位也设为 0 和 1 呢?就像是创造了4个平行世界。

在第一个平行世界中,两个量子位被设置为 00,第二个平行世界中是 01,第三个平行世界中是 10,第四个平行世界中是 11。

类似的如果将这三个量子位都设置为 0 和 1 ,就会创建8个平行世界——000、001、010、011、100、101、110 和 111。

虽然这是一种奇怪的思考方式,但它是解释量子比特在现实世界中的行为的正确方式之一。

现在,当对这三个量子位进行某种计算时,实际上是在同时对这8个平行世界进行同样的计算。

因此,我们可以同时计算所有解的分数,而不是按顺序遍历所有这些可能的解。

有了这个特殊的例子,理论上量子计算机可以在几毫秒内找到最好的解——001 或 110,正如我们之前看到的:

A | B | C | Score

0 | 0 | 0 | -1

0 | 0 | 1 | 1 <- 最优解之一

0 | 1 | 0 | -1

0 | 1 | 1 | -1

1 | 0 | 0 | -1

1 | 0 | 1 | -1

1 | 1 | 0 | 1 <- 另一个最优解

1 | 1 | 1 | -1

实际上,要解决这个问题只需要让量子计算机去做两件事:

  • 所有可能的解都用量子位表示
  • 将每个可能的解转化成分数的函数。在本例中,这个函数计算共享同一辆车的朋友对和敌人对的数量。

具备了上述两个条件,量子计算机将在几毫秒内给出其中一个最好的解决方案。在本例中,分数为 1 的是 001 或 110。

现在从理论上讲量子计算机每次运行都能找到最好的解。

然而,实际上在运行量子计算机时有可能存在错误。所以,它可能会找到次优解,次次优解,等等。

随着问题变得越来越复杂,这些错误变得越来越突出。

因此,在实践中可能需要在量子计算机上运行相同的操作数十次或数百次。然后从结果中选出最优解。

量子计算机的改进之处:

即使有一些缺陷,但量子计算机也不会遇到常规计算机那样的计算规模问题。

当有3个人需要分到两辆车上时,需要在量子计算机上执行的操作数是1。这是因为量子计算机同时计算所有情况的分数。

当有4个人的时候,操作的次数仍然是 1。

当有100人的时候,操作的次数仍然是 1。仅仅一次操作,量子计算机就能同时计算出2¹⁰⁰ ~ = 10³⁰ 种情况的分数。

而正如之前所说,在实践中最好运行量子计算机几十次或几百次,然后从得到的结果中选出最好的结果。

5总结

D-Wave Systems 最近推出了一个与量子计算机交互的云环境。

如果你是一名开发人员,并且想使用量子计算机,可以尝试这种简单的方法:

  • 名称:Leap
  • 地址:https://cloud.dwavesys.com/leap

可以免费使用它来解决很多问题,并且在注册后还可以看到很多关于量子计算机的相关教程。

备注:在本文中,作者使用术语“常规计算机”来指代非量子计算机。然而,在量子计算行业中,非量子计算机通常被称为经典计算机

想成为数据科学家?这5个基本统计学概念不能不知道!

译者:TalkingData 赵磊

原文作者:George Seif

原文链接:t.cn/EzFQvOi

如果说数据科学是一门艺术,那统计学可谓是这门艺术的敲门砖,从高层次的角度来看,统计是利用数学对数据进行技术分析。一个很基本的数据可视化如条形图,就能解读出一些高级的信息。

而如果通过统计学,我们就能以一种更加以信息驱动和更有针对性的方式来操作数据,所用到的数据的方法,可以帮助我们对数据形成具体的结论,而不是靠拍脑袋的猜测。

通过使用统计学,我们可以更深入细致地去了解数据的构造,并基于该结构,还可以用其他数据科学来获取更多的信息,将结果最大化。本文将和大家分享数据科学家们需要了解的5个基本统计概念,以及如何更有效地运用它们,希望对小伙伴们有所帮助。

//统计特征//

统计特征大概是数据科学家种最常用的统计概念了,它通常是数据科学家们在研究数据集时应用的第一种统计技术,包括偏差、方差、平均值、中位数、百分位数等等。比较容易让人理解以及在代码中去实现,如下图:

一个简单的箱型图

中线是数据的中位数,由于中位数对离群值的鲁棒性更强,因此中位数比平均值用得更多。第一个四分位数本质上是第25百分位数,表示数据中25%的点低于这个值。第三个四分位数是第75百分位数,表示数据中75%的点都低于这个值。最小值和最大值表示数据范围的上、下端。

这个箱型图完美地阐述了我们能用基本统计特征做什么:

  • 当框图很短时,它意味着许多数据点是相似的,因为在小范围内有许多值;
  • 当框图很长时,它意味着许多数据点是完全不同的,因为这些值分布在一个较广的范围内;
  • 如果中值更接近底部,就可以知道大多数数据的值更低;
  • 如果中值更接近顶部,就可以知道大多数数据都有更高的值;
  • 基本上,如果中值线不在方框中间,那么它就表示数据有偏斜;
  • 是否有长尾?这意味着你的数据有很高的标准差和方差,说明这些值是分散的,高度不同。如果在盒子的一边有长尾而在另一边没有,那么数据可能只在一个方向上有很大的变化;

以上这些信息都来自一些简单的、容易计算的统计特征,当需要对数据进行快速而有效的查看时,可以尝试这些方法。

//概率分布//

我们可以将概率定义为某个事件发生的概率百分比。在数据科学中,通常在0到1之间进行量化,0表示确信不会发生,1表示确信它会发生。概率分布是一个函数,表示实验中所有可能值的概率。

详情请看下面的图表:

均匀分布是本文三个分布中最基本的分布,它只有一个只出现在某个范围内的值,而超出这个范围的任何值都是0。通常,它是一种“开关”分布。我们也可以把它看作是一个有两个类别的分类变量:0或其他值。分类变量可能有多个非0的值,但我们仍然可以把它想象成多个均匀分布的分段函数。

正态分布,通常被称为高斯分布,由均值和标准差定义。均值在空间上平移分布,标准差控制分散程度。与其他分布的重要的区别(比如泊松分布)是,其所有方向上的标准差都是一样的。

泊松分布与正态分布相似,但增加了偏斜因子。在偏态值较低的情况下,泊松分布会像正态分布一样向各个方向均匀发散。但当偏度值较大时,我们的数据在不同方向的发散会有所不同;在一个方向,它将非常分散,而在另一个方向,它将高度集中。

虽然有很多的分布可以深入研究,但上述三个分布已经可以为我们带来很多探索的价值,比如:可以用均匀分布快速地查看和解释分类变量。如果看到一个高斯分布,就能知道可以用很多算法去处理它。有了泊松分布,就必须小心谨慎地选择一种对空间发散的变化具有鲁棒性的算法。

// 降维//

降维这个术语很容易理解:我们有一个数据集,希望减少它的维数。在数据科学中,它是特征变量的数量。

请看下面的图表:

降维

立方体代表数据集,它有三个维度,总共有1000个点。虽然1000个点的计算在今天很容易处理,但是,更大范围的点我们仍然会遇到很多问题。若是仅从二维的角度来看数据,例如从立方体的一边可以看到,划分所有的颜色很容易,通过降维,我们可以将三维数据投射到二维平面上。这有效地将我们需要计算的点数减少了100,大大节省了计算量。

特征剪枝是另外一种降维的方法。通过特征剪枝,可以删除对分析不重要的任何特征。例如,在研究数据集之后可能会发现在10个特性中,7个特性与输出强相关,而其他3个特性的相关性很低。那么,这3个低相关特性可能不值得计算,可以根据分析在不影响输出的情况下将它们删除。

当前用于降维的最常见技术是PCA,它本质上是创建了特征的向量表示,显示它们对输出的重要性,比如相关性。PCA可以用于上面讨论的两种降维方式。

过采样和欠采样是用于分类问题的技术。有时分类数据集可能会严重倾斜到一边。例如,类1有2000个样本,但类2只有200个。这将对很多常用于建模并预测的机器学习技术带来影响,但过采样和欠采样可以改变这一点。

示例请看下面的图表:

欠采样与过采样

上图中蓝色类比橙色类拥有更多的样本,在这种情况下,有两个预处理选项可以帮助于机器学习模型的训练。

欠采样意味着将只从多数类中,只使用与少数类样本数相同的数量,并且这个方案应当保证采样后类别的概率分布与之前相同。操作并不复杂,其实只是通过取更少的样本来平衡数据集。

过采样意味着将创建少数类的副本,以便拥有与多数类相同的样本。创建副本时应当保证少数类的分布不变。这个方案只是把我们的数据集变得更均衡,而不是得到更多的数据。

//贝叶斯统计//

如果要充分理解为什么要使用贝叶斯统计,那么首先需要了解频率统计不足之处。频率统计是大多数人听到“概率”这个词时会想到的统计方法。它应用数学来分析某些事件发生的概率,具体来说,我们使用的数据都是先验的。

举例说明:一个骰子掷出6的概率是多少,大多数人会说是1 / 6。确实,如果我们做频率分析,会通过一些数据比如某人掷骰子10000次,然后计算每个数字出现的频率;大概是1 / 6

但如果骰子是经过改造的,落地后总会是6的那面朝上呢?频率分析只考虑了先验的数据,并没有考虑骰子被改造过这个因素。

贝叶斯统计确实考虑到了这个问题,可以用贝叶定理来说明这一点:

方程中的概率P(H)是频率分析;表示根据之前的先验数据,事件发生的概率是多少。方程中的P(E|H)被称为似然,本质上是根据频率分析得到的信息的条件下,我们得到的结论是正确的概率。例如,滚动骰子10000次,而前1000次全部得到6,就可以认定骰子是被改造过的,P(E)是实际结论成立的概率。

如果频率分析得很好,那么就可以得出:对于骰子6的一面朝上的猜测是正确的,即考虑了骰子是被改造的。

从方程的布局可以看出,贝叶斯统计考虑了所有的因素。当觉得之前的数据不能很好地代表未来的数据和结果时,就可以去使用贝叶斯统计。

技术专栏丨基于Core ML的通用性机器学习开发框架探索

Core ML 概览

机器学习不仅是目前最火的技术,同时也是人工智能最核心的内容。机器学习是一种能让计算机无需不断被显示编程,而自我学习的人工智能技术。不通过某个具体的编程算法,而是在大量的数据样本中找到一个合适的模式或者规律,从而让计算机能够不断的自我发展和完善自我的算法。

一般情况下,机器学习模型都是庞大且复杂的,截止到目前,能够直接进行模型训练的方式和架构还暂未出现,当前的方法是将训练好的模型文件应用在移动设备上,使用预制的框架加载与使用模型,或者通过API 的方式联网远程预测等。

相对来说,通过远程预测的方式可以保证安全性,但却严重依赖网络环境,为了避免不确定的网络环境所带来的预测失败或无法预测等异常情况,可以将模型文件直接应用在移动设备上,这样不仅能够保证时效性,也无需再依赖网络环境,这种方法对于推理预测来说有了保证。

自 iOS 11 开始,苹果在 iOS 系统中引入了一种全新的,直接依附于硬件平台的机器学习框架——Core ML,该框架使机器学习模型在 iOS 系统平台下预测推理可以快速并易于实现。借助 Core ML,可以将已训练好的机器学习模型,集成到自己的应用当中,以实现智能化的应用程序,提升用户体验等。

已训练模型 (trained model),指的是对一组训练数据应用了某个机器学习算法后,所生成的一组结果。举个例子,通过移动设备上附带的传感器数据来训练一个能够识别用户行为类型(走、跑、乘车等)的模型,将该模型应用于应用程序中后,该模型可以对用户使用移动设备时所做出的行为进行预测(该模型目前已在 TalkingData SDK 中实现并应用)。

在iOS体系中,Core ML 是领域特定 (domain-specific) 框架和功能的基础所在。Core ML 为 Vision 提供了图像处理的支持,为 Foundation 提供了自然语言处理的支持(例如 NSLinguisticTagger 类),为 GameplayKit 提供了对学习决策树 (learned decision tree) 进行分析的支持。Core ML 本身是基于底层基本类型而建立的,包括 Accelerate、BNNS 以及 Metal Performance Shaders 等。

Core ML 针对设备的性能进行了优化,最大限度地减少了内存占用和功耗。因其在设备上运行有着严格要求,这不仅保护了用户数据隐私,而且当网络连接丢失时,还能够保证应用能正常工作和响应。

Core ML的缺点

Core ML本身是非常优秀的,它使得将机器学习甚至深度学习模型移植到移动设备上变为了可能。但是不得不说的是,Core ML 也有一定的局限性:

  • Core ML 目前仅能进行预测,无法进行模型的训练。训练模型只能在 PC 上或者云上训练,之后再转为 Core ML 支持的格式才可使用;
  • Core ML 目前所支持的深度学习隐藏层运算函数有限;
  • Core ML 目前的方式不利于模型的更新。当模型集成进应用程序后,如果要更新模型或模型发生了异常,只能通过线下更新模型,并且之后还需要重新提交应用,进行审核;
  • Core ML 目前的模型接口函数的调用,缺少统一性的 API 管理,大多数的模型在移植进 iOS 应用程序后,所产生的 API 大同小异,但 Xcode 都会产生一整套重复的接口文件等。

鉴于以上问题,经过调研和不断的试验,最终找到了一个较为合适,但不敢说是完美的方案。

通用性的模型加载预测框架

在 iOS11 中,所有的预训练模型 .model文 件,在 App 中的存在格式都是经过 Xcode 自动转换过的 .mlmodelc 文件,该文件是 Core ML 框架加载和使用的参数文件,本项目也正是借助此特性,在线下载已经训练好的预训练模型,然后使用 Core ML 提供的 API 来进行文件转换,之后进行加载使用。

这样避免了应用程序最初就带有预训练模型,避免了初始应用程序包过大,给用户造成下载应用程序的忧患。根据上述调研结果,设想该框架的整体架构如下:

通过 URL 请求,下载经过压缩的预训练模型,在压缩之前,模型已经是完整的符合 Core ML 要求的 .model 格式。下载完成后,进行文件解压缩,同时使用 Core ML 提供的模型编译 API ,完成对 .model 模型文件的编译,产生 Core ML 直接可以使用的 .mlmodelc文件并存储在本地磁盘,等待随时的加载使用。

当开发者调用该框架启动 API 后,该框架使用 Core ML 提供的模型加载 API 预加载模型到内存,开发者根据自己的需求在适当的时机将符合格式的数据传递给模型预测 API,模型进行预测推理后给出结果,开发者根据结果实现自我业务逻辑等。

工作流程

经过试验后,整理出了一套可以直接在应用程序中使用的开发框架,开发者不需要过多的设定,仅仅需要在应用程序中配置好所需要使用的模型下载地址,之后在合适的时机调用框架的启动接口即可。当一个机器学习任务来临的时候,调用该框架的预测接口,传入数据(例如图像)即可获得预测结果,直接使用。

使用示例

以 MobileNet 图像识别模型为例,使用Swift进行相关代码编写。

  • 在项目中新建一个 plist 文件,假设命名为 MobileNet-Model.plist ,定义 MobileNet 模型基本信息与下载地址,如下图:

  • 初始化框架对象:

  • 启动框架并传入模型定义plist:

  • 传入数据进行预测与结果使用:

示例结果:

总 结

通过该框架,可以减轻开发者繁重的机器学习模型集成压力,开发者只需要关注模型所需数据的格式即可快速开发有关机器学习任务。

目前该框架可用于大多数的图像分类模型,基本用法同上述示例,接下来我们将进一步的扩展和优化该框架,使其能够适应更多的模型,让移动端的机器学习应用开发更加的得心应手。

必须收藏丨万字长文,带你了解跨平台移动应用开发工具

TalkingData 张永超 译

原文链接:
https://instabug.com/blog/cross-platform-development/?utm_source=reddit&utm_medium=social&utm_content=cross_platform_development

在如今的电子世界当中,运行着各类操作系统,如何让应用适配每个操作系统平台,是开发者们一直在思考的问题。因为平台、技术、工具的有多样性,让适配变得无比的困难与繁杂,甚至需要花费大量的时间和资金去进行研究。本文将介绍目前比较流行的可以开发跨平台应用的开发工具,希望能够帮助开发者们实现全平台覆盖。

本文较长,其中大量资源网址值得收藏!

移动应用开发概述

Web应用

Web应用是运行在网页上并存储在远端服务器上的应用,此类应用通过设备上的网页浏览器加载与展示。

即便在某些情况下网页应用运行良好,但仍无法避免会出现一些问题,比如需要连接到网络才能在设备上运行,因为所需的资源并未存储在本地设备上,而是在远端服务器上。另外,此类应用无法在移动商店上直接使用,导致用户很难找到和下载使用。

Hybrid跨平台应用

Hybrid应用又称为混合应用,此类应用基本上使用每个平台的浏览器内置组件进行包装和打包,以达到在每个平台上运行的目的,应用就像该平台上的Native应用一样。混合应用主要使用的语言为HTML5、JavaScript和CSS。

混合跨平台应用解决了Web应用面临的问题,因为混合应用在本地运行时无需网络连接,而且还能在应用商店上发布,可以让用户轻松找到,从而增强应用的可发现性、增加用户量等。

混合跨平台应用开发工具:Apache Cordova、Ionic、Adobe PhoneGap等。

Native应用

原生应用是为了在特定平台或操作系统上工作而开发的应用。

对于iOS来说,开发者使用的是Swift或Objective-C编写iOS应用,而对于Android来说,开发者使用的是Java或Kotlin编写Android应用。从移动开发工具来看,iOS开发者经常使用Apple的Xcode或者第三方的AppCode等工具,而Android开发者经常使用Android Studio作为它们的主力开发IDE。

Native 跨平台应用

原生跨平台工具允许开发者编写一次代码,然后将该代码转换为适配多个操作系统的本地代码,让开发者以最小的成本在不同的平台上发布移动应用。原生跨平台应用是混合应用和本地应用的完美结合,不仅提供了混合应用的代码重用功能,而且性能也与本地应用类似。

原生跨平台应用开发工具:React Native、Xamarin、Titanium等。

跨平台移动应用开发

跨平台移动应用开发是创建可以使用单个代码库,在多个平台上部署或发布的移动应用开发过程,跨平台移动应用开发无需使用每个平台的对应的本地技术去进行多次开发。

跨平台开发有以下优点:

  • 可重用代码:跨平台开发工具允许只编写一次代码,然后将代码导出到需要操作的系统和平台上,无需为每个平台单独编写创建代码;
  • 便利性:跨平台开发工具能够省去学习许多编程语言的麻烦,开发者只需要理解领会一种语言即可;
  • 可维护代码:当需要修改或更新应用时,开发者只需更新一个代码库,就可以将更新同步反映在平台所有的应用上;
  • 成本效率:跨平台开发可以让单个开发团队能够在多个平台上进行工作,且大多数的跨平台开发工具都是免费的。
  • 市场覆盖率:通过多平台发布应用,可以让其增加曝光量,提升用户基数,从而提高投资回报率和经济利益。

虽然跨平台开发工具拥有很多优势,但在某些场景下的缺点也相当明显:

  • 性能:即便一些跨平台开发工具提供了接近本地应用的性能,但仍有不足,如果所开发的应用属于最高优先级,不建议使用跨平台开发工具。
  • 3D和图形:与性能上的缺点类似,跨平台开发工具无法提供最佳图形和最佳的用户体验,且无法访问核心OS库(如图形),如果所开发的应用严重依赖于图形,比如移动游戏类应用就不建议使用跨平台开发工具。
  • 单平台应用:如果所开发的应用尽在单一平台(如iOS或Android)上发布,那么还是应该使用本地开发的应用,在这种场景下,只需要一个团队使用一种技术即可,没有必要去损失性能。
  • 特定与平台的功能:虽然跨平台开发工具提供了不同平台之间共享的许多基本功能,但它们可能缺少Apple、Google和Microsoft的操作系统上提供的某些特定功能。
  • 特定与设备的功能:跨平台开发工具可以让开发者访问的不同功能,如相机或GPS,但如果所开发的应用需要直接访问和处理设备的硬件,本地开发应用是更好的选择。
  • 更新延迟:在一些特定平台发布更新时,可能需要等一段时间才能在所有平台开发工具中反应这些更新。

跨平台开发技术栈

虽然跨平台开发工具可以帮助开发者节省学习不同技术的时间和工作量,但仍然需要熟练掌握每种工具,使用的技术有:

  • React Native:JavaScript(JSX)、ES6、React.JS
  • Xamarin: C#
  • Cordova: HTML、CSS 、JavaScript

常用跨平台开发工具

  • Ionic
    地址:https://ionicframework.com/
  • Adobe PhoneGap
    地址:https://phonegap.com/
  • Titanium
    地址:
    https://www.appcelerator.com/Titanium/
  • Framework7
    地址:http://framework7.io/
  • Apache Weex
    地址:https://weex.apache.org/
  • Flutter
    地址:https://flutter.io/
  • Native Script
    地址:https://www.nativescript.org/
  • Jasonette
    地址:http://jasonette.com/
  • ManifoldJS
    地址:https://github.com/pwa-builder/ManifoldJS

三大主流跨平台开发工具

React Native

React Native是由Facebook基于其React JavaScript库创建的跨平台本地移动应用开发框架。主要使用JavaScript与JSX(JavaScript的扩展),ES6(ECMAScript 6),JavaScript的主要更新(包括许多新功能)和React.JS(用于构建用户界面的JavaScript库)。

React Native允许开发者使用React Native组件构建移动应用,然后再将其编译为本地应用,这些应用几乎与使用本地工具编写的应用完全相同。

React Native的优点

使用React Native进行跨平台移动应用开发的优点包括:

  • 可重用代码:可开发应用并从单个代码库将其导出到多个平台上。
  • 应用商店: 可以在各个平台的应用商店中发布应用。
  • 性能:React Native可将应用编译为本地应用,这与使用本地工具创建的应用几乎完全相同,使其比必须在特定于平台的Web组件中运行代码的混合应用更快。
  • 本地UI组件:React Native允许开发者使用React Native UI组件创建视图,这些组件被编译为特定于平台的UI组件,与使用HTML标记的其他跨平台工具不同。通过现成的组件,可以节省大量的时间。
  • 热重新加载:React Native中提供一项允许更改代码在iOS和Android应用中立即生效的功能,可以进行可视化更改。
  • 测试:调试React Native应用非常容易,因为它发布了本地应用版本,可以使用Expo这样的工具在物理设备上进行测试,无需在Xcode或Android Studio中打开它们。
  • 本地代码:与大多数其他跨平台开发工具不同,React Native允许开发者单独修改已发布的本地应用,它可以选择在React Native代码和本地代码之间进行组合,无论是Swift,Objective-C,或者是Java。如果想使用特定于平台的代码为不同平台实现单独的可视组件,就非常有用。
  • 可靠性:React Native由Facebook创建,许多世界顶级移动应用都在使用React Native,比如Facebook,Instagram,SoundCloud和Skype。
  • 免费:开源。

React Native的缺点

虽然React Native是目前最好的跨平台开发工具之一,但React Native仍然具有一些缺点:

  • 新技术:学习JSX和ECMAScript并不是一件容易的事,可能比其他熟悉的技术(如HTML和CSS)要花费更多时间。
  • 原生UI组件:虽然UI组件是React Native的最大优势之一,但目前只有少数几种现成的可用。
  • 本地代码:在某些情况下,开发者可能需要在移动应用中编写本地或平台特定的代码,特别是如需访问设备硬件(如相机或GPS),会破坏跨平台开发的目的,对小型团队来说React Native的作用不大。
  • 性能:虽然与大多数其他跨平台开发框架相比,React Native在性能方面表现优异,但比起使用特定于平台的工具和语言的本地应用进行开发来说仍有不足。

React Native 开发工具

  • Atom
    地址:https://atom.io/
  • Nuclide
    地址:https://nuclide.io/
  • Visual Studio Code
    地址:https://code.visualstudio.com/
  • React Native Tools
    地址:
    https://marketplace.visualstudio.com/items?itemName=vsmobile.vscode-react-native

React Native 开发组件

  • Redux
    地址:https://redux.js.org/
  • Expo
    地址:https://expo.io/
  • Ignite
    地址:https://infinite.red/ignite
  • Flow
    地址:https://flow.org/
  • ESLint
    地址:https://eslint.org/
  • ReduxSauce
    地址:
    https://github.com/infinitered/reduxsauce

React Native UI组件

  • Snowflake
    地址:
    https://github.com/bartonhammond/snowflake
  • NativeBase
    地址:https://nativebase.io/

React Native 测试工具

  • Enzyme
    地址:
    https://github.com/airbnb/enzyme
  • Reactotron
    地址:https://infinite.red/reactotron
  • Instabug
    地址:
    https://instabug.com/?src=InstabugBlog&mdm=internal&ref=cross_platform_development&term=instabug

Xamarin

Xamarin是一个跨平台的移动应用开发框架,由微软基于Mono(一个免费的开源.NET框架),使用C#创建本地应用。

Xamarin 优点

Xamarin跨平台移动应用开发具有多个优势,包括:

  • 可重用代码:开发应用并从单个代码库将其导出到多个平台上。
  • 应用商店:可以在各个平台的应用商店中发布应用。
  • 完整的开发堆栈:许多开发者认为Xamarin是最完整的跨平台移动应用开发框架。拥有自己的专用堆栈,C#作为编程语言;Visual Studio作为IDE,与Xamarin完全集成;.NET作为开发平台;Xamarin测试云进行测试;以及Xamarin.Insights用于分析。
  • 性能:Xamarin在性能方面也几乎与本地应用相同。 Xamarin比混合应用更快,因为混合应用必须在特定于平台的Web组件中运行代码。
  • 本地UI组件:使用Xamarin Native UI组件创建视图,这些组件通过Xamarin.Forms编译为特定于平台的UI组件,Xamarin.Forms包含面向.NET开发者的完整跨平台UI工具包,或可以通过Native UI开发。
  • 插件和API:Xamarin提供了一组允许访问硬件功能的插件和API。它还支持通过链接本地库进行自定义。 测试:通过在物理设备上安装Xamarin.Forms Live Player应用,开发者可以使用实时预览立即测试和调试应用,并可以实时同步应用与设备。
  • 可靠性:Xamarin于2016年被微软收购,截至目前,已在120多个国家/地区拥有超过140万名开发者。所以它绝对可靠且拥有良好的维护。
  • Xamarin大学:Xamarin提供由Xamarin专家指导的实时、互动的移动开发培训,涵盖10个方面的80多个课程,让开发者可以轻松地学习。
  • 免费:开源。

Xamarin 缺点

虽然Xamarin可以应用许多场景,但它也是有一些缺点的:

  • 应用大小:通常已知Xamarin应用大小比本地应用更大,因此在内存管理方面不是很理想。
  • 更新延迟:Xamarin的更新时间有时会比平台的更新更慢,无论是新功能的迭代还是其他,因此可能会导致应用出现一些问题。
  • 本地代码:当使用Xamarin.iOS或Xamarin.Android开发具有原生外观的移动应用时,将需要一些本地语言的基本知识,如Objective-C、Swift和Java。
  • 图形:虽然Xamarin使用单个代码库为多个平台构建应用,但它主要在平台之间共享代码逻辑,而UI组件又是特定于平台的。这使得Xamarin并不适合严重依赖图形的应用,比如手机游戏。

Xamarin开发工具

  • Visual Studio
    地址:
    https://visualstudio.microsoft.com/vs/mac/
  • XCode
    地址:
    https://developer.apple.com/xcode/

Xamarin 开发组件

  • NuGet
    地址:https://www.nuget.org/
  • Xamarin Inspector
    地址:
    https://docs.microsoft.com/zh-cn/xamarin/tools/inspector/install?tabs=windows
  • Prism
    地址:
    https://github.com/PrismLibrary/Prism
  • MFractor
    地址:https://www.mfractor.com/
  • Resharper
    地址:
    https://www.jetbrains.com/resharper/

Xamarin 测试工具

  • NUnit
    地址:http://nunit.org/
  • xUnit.net
    地址:https://xunit.github.io/
  • Visual Studio Unit Testing Framework
    地址:
    https://docs.microsoft.com/zh-cn/visualstudio/test/writing-unit-tests-for-the-dotnet-framework-with-the-microsoft-unit-test-framework-for-managed-code?view=vs-2015
  • Instabug
    地址:
    https://instabug.com/?src=InstabugBlog&mdm=internal&ref=cross_platform_development&term=instabug

Apache Cordova

Apache Cordova是一个跨平台的移动应用开发框架,用于使用包括HTML,CSS和JavaScript在内的Web技术,构建混合移动应用。

Apache Cordova 优点

使用Apache Cordova进行跨平台移动应用开发的一些优势包括:

  • 可重用代码:可以开发应用并从单个代码库将其导出到多个平台上。
  • 应用商店:可以在各个平台的应用商店中发布应用。
  • 多平台支持:Apache Cordova支持大多数开发者所使用的移动平台和操作系统,包括Android,iOS,Windows 8.1,iPhone 8.1和10,OS X,几乎可以覆盖所有移动用户。
  • 大量插件:Cordova提供各种插件。
  • 所用技术:Cordova不是一种编程语言,因此开发者可以使用已知的Web技术(如HTML,CSS和JavaScript)进行应用开发。还可以使用自身熟悉的工具,包括所使用的编辑器。
  • 免费:开源。

Apache Cordova 缺点

和任何跨平台移动应用开发工具一样,Cordova也缺点,包括:

  • 性能:使用Apache Cordova创建的移动应用,会因性能问题而受到影响,因为它是一种混合的跨平台移动应用开发工具。
  • 开发工具:由于Apache Cordova使用HTML,CSS和JavaScript等Web技术,因此用于Apache Cordova的大多数开发工具都针对Web开发进行了优化,而非移动应用开发。
  • 测试:在Apache Cordova中调试代码会比较繁琐,虽然可以使用开发工具修复任何代码上的bug,但需要使用特定于平台的工具来修复特定平台中发生的问题。
  • 技术:即便开发者可能熟练掌握了HTML,CSS和JavaScript等网络技术,但仍需要具备Web和移动应用的经验才能创建Cordova移动应用。
  • 支持的平台:Cordova多年来已经弃用了许多支持的平台,包括BlackBerry,Firefox OS,Symbian,Ubuntu Touch,webOS,Windows Phone 8.1和Windows Phone 10.虽然Cordova可能很难弃用iOS和Android,但仍然无法保证它继续支持任何其他当前所有平台。
  • 更新延迟:Cordova的更新时间有时会比平台的更新更慢,无论是新功能的迭代还是其他,因此可能会导致应用出现一些问题。
  • 插件:虽然Cordova提供了比其他任何跨平台开发工具中都多的插件,但它仍然无法与本机移动应用开发工具相比。

Apache Cordova 框架

  • Adobe PhoneGap
    地址:https://phonegap.com/
  • Monaca
    地址:https://monaca.io/
  • Onsen UI
    地址:https://onsen.io/
  • Cocoon
    地址:https://cocoon.io/
  • Framework7
    地址:http://framework7.io/
  • Evothings Studio
    地址:https://evothings.com/
  • Mobiscroll
    地址:https://mobiscroll.com/

Apache Cordova IDES

  • Visual Studio
    地址:
    https://visualstudio.microsoft.com/zh-hans/vs/features/cordova/
  • Cordova Tools Visual Studio Extensions
    地址:
    https://marketplace.visualstudio.com/items?itemName=vsmobile.cordova-tools
  • App Builder
    地址:
    https://www.davidesperalta.com/appbuilder
  • NSB/AppStudio
    地址:https://www.nsbasic.com/

Apache Cordova CLIS

  • Cordova CLI
    地址:
    https://github.com/apache/cordova-cli
  • Node.js
    地址:https://nodejs.org/en/
  • NPM
    地址:
    https://www.npmjs.com/package/cordova
  • Cordova Plugman
    地址:
    https://github.com/apache/cordova-plugman
  • Cordova Coho
    地址:
    https://github.com/apache/cordova-coho

Apache Cordova 类库

  • Apache Cordova JS
    地址:
    https://github.com/apache/cordova-js
  • Apache Cordova Lib
    地址:
    https://github.com/apache/cordova-lib
  • Apache Cordova Common
    地址:
    https://github.com/apache/cordova-common
  • Apache Cordova Create
    地址:
    https://github.com/apache/cordova-create
  • Apache Cordova Fetch
    地址:
    https://github.com/apache/cordova-fetch
  • Apache Cordova Serve
    地址:
    https://github.com/apache/cordova-serve

Apache Cordova 测试工具

  • Apache Cordova Plugin Test Framework
    地址:
    https://github.com/apache/cordova-plugin-test-framework
  • Apache Cordova Paramedic
    地址:
    https://github.com/apache/cordova-paramedic
  • Apache Cordova Mobile Spec Suite
    地址:
    https://github.com/apache/cordova-mobile-spec
  • Instabug
    地址:
    https://instabug.com/?src=InstabugBlog&mdm=internal&ref=cross_platform_development&term=instabug

总结

跨平台开发工具在开发周期中可以为开发者节省大量的时间,并可以使用最少的资源在不同的平台上发布应用,最大程度的去覆盖用户。但即便如此,它也无法替代本地开发应用的替代品,鱼和熊掌不可得兼,需要根据自身实际情况与场景去衡量利弊。

如何确定最适合的跨平台开发工具呢?最好的方法就是每个工具都去尝试一遍,如果时间有限,那么对一些顶级跨平台开发工具进行研究就足够了,比如本文例举的这些,希望对您有用。

干货分享丨研发代码质量管理技术最佳实践

如何高质量快速交付研发产品是每一位技术研发永恒追求的目标,如何在快速迭代发布下保障研发产品质量是每一位技术研发要共同思考的问题。

近日,在“安卓巴士全球开发者论坛·北京站”会议上,TalkingData SDK技术研发经理韩广利做了题为《研发代码质量管理最佳实践》的主题分享,将TalkingData SDK完整的质量保障体系的创建过程和最佳实践分享给所有开发者,希望能够对大家有帮助和借鉴。

TalkingData SDK技术研发经理 韩广利

以下是韩广利的分享精粹:

在演讲之初,韩广利首先分析了移动端平台发展趋势,包括以下三个方向:

  • 首先,双卡是移动端平台的主要趋势,今年9月发布的iPhone最新机型已经支持了双卡,这对于市场将起到很大的驱动作用。
  • 其次,由于人工智能的不断演进,两大平台也不断对其进行技术跟进,比如安卓平台的TensorFlow,以及iOS平台的CoreML。
  • 第三,用户隐私政策会越来越严格,不仅用户自身非常重视隐私,国家相关法规也日益完善,移动端平台的行为权限将逐步受到严格约束。

TalkingData基于相关政策为不同平台提供相应的适配和支持,也正因如此,就需要一个良好的代码质量管理体系去保证TalkingData SDK的质量和稳定性。

回顾TalkingData SDK整体架构的演进史,可以简单分为三个阶段:

  • 简单分层:只支持一条业务线;
  • 多服务:满足不同业务线逐渐增加的需求;
  • 微服务&模块化:满足不同开发者打包定制化的需求。

在功能叠加的过程中,需要对代码架构进行调整,那么此时应该思考两个问题:架构调整的原因什么?调整的目标是什么?

带着这两个问题,韩广利从四个部分进行了阐述。

代码分支管理

当代码分支不断增加,现有的人力和技术框架将无法支持功能的快速迭代。即便在某一个分支上解决了bug,但还需根据不同的场景将其添加到不同的分支上,分支的代码就会产生很大的差异,又需要投入更多的精力和时间去解决相关问题。

为此,TalkingData SDK进行了改造,将分支分为:对外发布交付分支、开发测试分支、以及个人创建分支。同时,也对原有的直接拉取分支的原因进行了一些反思:在架构设计之初,代码之间的耦合性较强,同时没有从业务或数据角度去进行独立设计,在打包的参数上没有进行动态配置。

为了改变现状,TalkingData制定了三个目标,一是改变模块之间的通讯方式;二是重新设计代码功能模块;三是约束代码之间的边界,尽量消除耦合性。

解决方案主要采用了微服务的思想——服务之间相互独立,随意调用或组合;对功能模块和数据模块进行了拆分;改变通讯方式做到解耦的效果,又将动态的配置参数分离出来,实现了支持多条业务线,并且可以满足定制化的需求。

在打包上进行了标签化的管理,同时配合标签检查脚本,达到定制化勾选和服务的打包功能。

韩广利表示,在架构重构时,需要进行一些取舍和选择,其核心思想是:架构在于目的而非框架,因为架构最终是要服务于业务的。他还提供了5大原则作为参考:

  • 独立于框架
  • 可测试性
  • 独立于UI
  • 独立于数据库
  • 独立于任何外部代理

而在选择架构时应从易于维护、易于测试、内聚以及最核心的解耦出发,要让模块之间互相独立。

SDK功能打包管理

TalkingData SDK提供不同业务线打包的定制化开发需求。在庞大的体量中,如何保证打包的功能正常、方便测试?为此,在设计目标当中加入了分层的考量,首先是用户输入信息:邮箱、业务线以及所需平台,然后是整个平台的业务处理、输出的用户申请功能包,最后通过邮件发送给申请的开发者。

逻辑流程如下图:

在打包管理中,比较常用的工具有 GitLab、Jenkins、Server。

代码review规则及流程

在代码review中设置人为检查和脚本检查两种机制。

在人为检查中,负责review的人员必须要参与最初的需求和设计的审核,不仅要了解整个功能需求的细节,还需要对功能或测试负责,撰写review checklist,最后要交付review 模板,在出现问题时可以进行问题追踪。

在脚本检查中,需要进行编译和制定代码规范、静态代码检查,以及安全漏洞等方面的工作。

以上两种机制可以让代码review真正起到作用,而避免沦为形式化流程。

TalkingData SDK在代码review时有几种方式:

  • 1对1:改动较小的bug、需求和优化
  • 1对多:改动较大的bug、需求和优化

与其他公司选用技术主管或特定人员作为代码review人员不同的是,TalkingData SDK 的代码review主要由组内成员相互之间进行,这样对于个人的技术和框架理解会有所帮助。

代码review模板主要有三个部分:谁做的review?发现了什么问题?如何解决整个问题?好的代码review模板要做到问题可记录、问题可追踪。

代码质量管理的工具

在代码质量管理的流程中,TalkingData SDK在代码托管上使用了GitLab,在项目管理上使用了JIRA。之所以选择这两个工具是因为两者可以互相打通,方便后续在遇到问题时可以根据记录进行排查。

研发流程如下图:

其中,单元测试在研发中是非常重要的,开发者写完一个功能模块的主流程通常没有问题,可以做到自测;但是分支的一些处理流程,即便交给测试人员也很难测试出来。因此单元测试就显得尤为重要,它可以覆盖很多异常分支,所输入的条件在参数当中可以动态设置。

QA测试流程如下图:

在前期,会由研发和QA整理一些测试用例,分为高中低等不同的级别,研发在提测时会有测试通过率,以保证测试的效率。

另外,TalkingData SDK 在上线后也需要去做一些监测,比如交付质量、对不需要功能做删减、打包的完整性等等。

总体来说,即采用微服务的思想,尽量让功能模块化管理,利用工具管理流程,进行单元测试,同时上线前后都要设置一些检查策略,做到万无一失。

最后,韩广利表示,流程并非形式,需要真正地落地执行,长此以往,就会对效率有很大地提升。

iView 发布 3.1.0 版本,支持TypeScript

作者|Jonathan Saring

译者|无明

来源丨公众号「前端之巅」

TalkingData经授权转载

编辑|覃云

原文丨https://hackernoon.com/21-top-vue-js-ui-libraries-for-your-app-4556e5a9060e

最近,随着“星球大战”(指 GitHub 的 Star 数量大比拼)的爆发,Vue.js 在 GitHub 上的 Star 数超过了 React。虽然 NPM 的下载量仍然落后于 React,但 Vue.js 的受欢迎程度似乎在持续增长。

1、Vuetify

Star 数为 11K,提供了 80 多个 Vue.js 组件,这些组件是根据谷歌 Material Design 指南实现的。Vuetify 支持所有平台上的浏览器,包括 IE11 和 Safari 9+(使用 polyfill),并提供了 8 个 vue-cli 模板。

地址: https://github.com/vuetifyjs/vuetify

2、Quasar

Star 数超过 6K,是构建 Vue.js 响应式网站、PWA、混合移动应用和 Electron 应用的流行框架。Quasar 还支持诸如 HTML/CSS/JS 压缩、缓存清除、摇树优化(tree shaking)、源映射、代码分割和延迟加载、ES6 转码等功能。

地址:https://github.com/quasarframework/quasar

3、Element

Star 数将近 28K,是一款面向 Web 的 Vue.js 2.0 UI 工具包。它拥有一个强大的社区和 350 个贡献者,提供了丰富的可定制组件,以及完整的样式指南和更多的资源。 地址:https://github.com/ElemeFE/element

4、Vue Material

Star 数差不多 6K,是一个实了谷歌 Material Design 的简单库。该库还提供了一个 webpack 样板、用于 Nuxt.js 的 SSR 模板和一个单独的 HTML 文件(通过这个文件开始使用框架)。这里有一些入门的例子https://codesandbox.io/s/github/vuematerial/examples/tree/master/examples/quick-start。

地址: https://github.com/vuematerial/vue-material

5、Keen-UI

Star 数将近 3.5 K,一组 Vue 组件的集合,在设计上受到了谷歌 Material Design 的启发。Keen-UI 并不是一个 CSS 框架,它不包含网格系统、排版样式等。相反,它关注的是基于 Javascript 的交互式组件。

地址:https://github.com/JosephusPaye/Keen-UI

6、Buefy

Star 数 3K 左右,基于 Bulma(https://bulma.io)提供了一组轻量级的 UI 组件。Vue.js 和 Bulma 是这个库唯一的两个内部依赖。它的大小约为 60KB(压缩后的大小,并且包含了 Bulma)。你可以查看实时文档网站(https://buefy.github.io/#/documentation/start)并在 Codepen 上运行代码。

地址: https://github.com/buefy/buefy

7、Bootstrap Vue

Star 数超过 5K,为 Vue.js 提供了 Bootstrap 4 组件和网格系统的实现,并提供了自动 WAI-ARIA 可访问性标记。

地址: https://github.com/bootstrap-vue/bootstrap-vue

8、Muse-UI

Star 数超过 6K,是另一个 Vue 2.0 MD 库,提供了 40 多个 UI 组件和可定制主题。文档主要使用中文撰写,不过大多数组件是自解释的,文档只起到辅助作用。该项目在积极开发和维护当中。 地址:https://github.com/museui/muse-ui

9、AT-UI

Star 数接近 1.5 K,一个模块化的前端 UI 框架,用于开发基于 Vue.js 的 Web 界面,适用于桌面应用程序。它提供了 NPM+Webpack+Babel 的前端开发工作流和独立的 CSS 样式,值得一试。

地址: https://github.com/at-ui/at-ui

10、Vux

Star 数超过 13K,是一个流行的社区库,基于 WeUI 和 Vue 2.0。该库还支持 webpack+vue-loader+vux 的工作流。它的文档也是中文的。

地址: https://github.com/airyland/vux

11、iView

Star 数将近 16K,提供了数十种用 Vue.js 构建的 UI 组件和小部件,并采用了干净而优雅的设计。iView 被广泛采用,社区也在积极维护,并提供了 CLI 工具用于以可视化的方式创建项目。这个也值得一试。

地址: https://github.com/iview/iview

12、Uiv

Star 数“仅”550 左右,用于 Vue 2 的 Bootstrap 3 组件库。所有组件加起来差不多 20KB,唯一的外部依赖是 Vue 和 Bootstrap CSS,支持基于 Webpack 的工作流。 地址:https://github.com/wxsms/uiv

13、Vuikit

Star 数 1K 左右,一个用于网站界面的响应式的 Vue UI 库,设计风格干净而统一。该库作为由 Yarn 工作区管理的“monorepo”而构建,但图标和主题可作为单独的包发布。

地址: https://github.com/vuikit/vuikit

14、Onsen UI+Vue

基于流行的 Onsen-UI 框架,封装了核心 Web 组件并暴露了 Vue 风格的 API。Onsen UI 组件也被设计为能够主动对 prop 做出反应。

地址: https://onsen.io/v2/guide/vue/

15、Semantic UI+Vue

这个项目基本上是 Semantic-UI 框架与 Vue.js 的集成。该库仍在开发当中,提供了一个类似于 Semantic-UI 的 API 以及一组可定制的主题。

地址: https://semantic-ui-vue.github.io/

16、Fish-UI

Star 数“仅”为 500 左右,贡献者也只有 3 个,但 fish-ui 提供了一个基于 Vue 的 Web 工具包,其中包含整洁干净的组件。该库支持 ES2015+Webpack 工作流。它的文档不是很全,但它的设计不容忽视。

地址: https://github.com/myliang/fish-ui

17、Mint UI

Star 数超过 11K,为 Vue.js 提供 UI 元素,提供了用于构建移动应用程序的 CSS 和 JS 组件。当全部导入时,压缩后的代码只有月 30KB(JS+CSS),当然它也支持单个组件的导入。

地址: https://github.com/ElemeFE/mint-ui/

18、Framework7 Vue

这个集成提供了几乎所有的 Framework7 元素和组件,并集成了 Framework7 Router,按照 Vue 的方式来渲染页面。该库正处于积极的开发和维护当中。 地址:https://framework7.io/vue/

19、Cube UI

Star 数超过 3K,是用于 Vue.js 移动应用程序的 UI 组件库。所有组件都经过了单元测试,并且该库还支持按需进行后期编译和组件导入。这个库仍在积极开发中。

地址: https://github.com/didi/cube-ui

20、Vueblu

Star 数约 1.5K,是基于 Vue 2.0 和 Bulma 的 UI 组件库,用于构建中台和后台办公产品。它支持 ES2015 和 NPM+Webpack+Babel 工作流,并提供可自定义主题。

地址: https://github.com/chenz24/vue-blu

21、Ant Design Vue

Star 数约 1.5K,用于开发具有数十个 Ant Design 实现组件的企业级后端产品,并支持基于 Webpack 调试的构建解决方案(支持 ES6)。请注意,它的开发已经停止了一段时间。

地址: https://github.com/okoala/vue-antd

特别推荐

n3-components :

https://github.com/N3-components/N3-components

vuikit:

https://vuikit.js.org/

Kendu UI Vue

https://www.telerik.com/kendo-vue-ui

Office Fabric-Vue

https://github.com/aidewoode/office-ui-fabric-vue

vuestrap

http://kzima.github.io/vuestrap-base-components/#/

vueboot

http://morgul.github.io/vueboot/

framevuerk

http://framevuerk.com/

Vue WeUI

http://aidenzou.github.io/vue-weui/#!/

Vue-MDC

https://github.com/posva/vue-mdc

重磅发布预告

排名11位的iView是由TalkingData数据可视化团队开源的UI组件库,也是一个充满情怀的开源项目。 在过去的一年里,iView共迭代了27个版本,还在近期发布了针对微信小程序开发的UI组件库——《iView Weapp》。 7.28是iView的两周年生日,iView团队也将在这一天举办发布会,正式发布iView 3.0以及5款与iView相关的神秘产品。点击文末阅读原文,就有机会亲临发布会现场。

产品专栏 | 灵动分析2.0开创埋点新时代

2018年8月TalkingData正式发布了移动运营平台5.0私有化部署版本,同时也发布了其中的一款无代码埋点利器——灵动分析2.0。

从连接系统到看数据全流程迅速响应——

5 秒  内连接系统

10秒 内完成一个埋点事件

30秒 拉取配置单上报数据

实时  查看报表数据

在灵动分析2.0时代,TalkingData最大程度的简化操作,降低业务与研发的沟通成本、学习成本,提高运营效率,让业务人员能够聚焦于数据。运营人员既不用读懂复杂的SDK集成文档,也不需要向研发解释埋点的业务逻辑,系统能够自动识别可埋点的元素,且支持事件参数埋点,全流程可视化,开创了国内可视化事件参数埋点的先河。

灵动分析本次迭代带来了7大亮点:

1、扫码进入5秒内连接系统

从扫码到连接系统只需5秒钟快速响应,取代旧版摇一摇,解决多人同时摇动抢占连接系统资源的尴尬,解决摇动多次连接不上或响应慢的烦恼。

2、支持多种模式的移动应用一站式埋点  

无论是混合模式app、原生app还是H5,都支持在PC端完成一站式埋点。

3、3种埋点方式 满足业务小姐姐的分析灵感

支持当前元素、当前位置、同类元素3种埋点方式,业务小姐姐可以根据分析需求选择适合的埋点方式,且从埋点到看数据全流程快速响应:

※ 10秒 内完成一个埋点事件

※ 30秒 拉取配置单上报数据

※ 实时 查看报表数据。

4、灵活添加参数 轻轻一点即可指哪采哪

国内首家独创的可视化事件参数埋点,业内尚未有任何一家具备此能力并与之匹敌。

例如,应用界面上的商品价格、商品类型等特定数据,只需拖动鼠标,系统就会智能识别可圈选元素,轻轻一点即可采集:

  • 一方面满足前端业务人员“指哪采哪”的业务分析需求;
  • 另一方面可以让前端非常动态的处理需求变化,而无需开发人员介入。

解决了前后端沟通成本,而且全流程可视化,业务人员可随时完成对各种数据的监控和追踪需求。

5、易测试 数据追踪无遗漏

可视化的数据点测试。您只需在测试设备中轻点各项元素,即可在实时界面中查看到数据产生,从此让数据验证变得异常简单。

6、零代码 解放IT小哥哥的双手 

灵动分析真正做到“零开发、零代码、云配置”架构,颠覆了传统应用统计使用方式,彻底解放了研发人员,无需再为应付琐碎的数据跟踪需求而苦恼,真正把研发时间都用到做好产品上。

7、免更新 自动识别埋点元素

灵动分析可以免去应用更新的种种麻烦,自动识别埋点元素。业务人员只需圈圈点点界面元素来追加数据点,实时生效,无需应用升级


灵动分析+个别事件代码埋点组合出击

综上所述,如果灵动分析已经帮助您解决了80%的埋点需求,那么这里仍建议您采用灵动分析+个别事件代码埋点的方式组合出击,毕竟不是所有用户的交互行为都适用于灵动分析。例如,用户上滑屏幕时内容瀑布流的底部载入新的内容,这种交互用户可以一直进行下去,但没有一个明确的监测点位置,在可视化事件监测设置的界面上找不到这类交互,但这种情况用代码埋点就很容易解决。

因此,采用灵动+代码埋点结合的方式,既能快速满足日常基础数据的收集需求,又能针对个别事件进行多维的数据采集与挖掘,达到整体兼顾数据收集的效率、平衡开发资源、提升运营效率的目标。

TalkingData高铎:数据智能驱动数字经济

8月16日,由IDG主办的以“新时代·数字经济”为主题的“iWorld数字世界博览会”在成都拉开帷幕。TalkingData 副总裁高铎先生在此次峰会上发表了《数据智能驱动数字经济》主题演讲,并与现场嘉宾们分享了最新的行业观点。

TalkingData 副总裁高铎‍

三年前高铎先生提出过一个观点,大家都在讲大数据,但是由于数据的不完备性,大部分企业使用的都是“小数据”;去年在成都的大数据会议上,提出了三个数据孤岛群概念,就是运营商、政府和头部互联网企业(如BAT)的三大数据孤岛群各自难以打通。通过TalkingData几年来在大数据领域的实践,我们认为,大数据开始从概念走向具体应用,同样的在数据治理和数据应用层面,如果能解决好这几个问题,“开放”、“连接”、“智能”和“安全”,那么数据智能将会强烈推动数字经济的发展。

‍建立开放数据的前提认知到数据割裂性‍

  • 第一, 移动应用层数据的割裂性,我们每个人都拥有一台智能手机,手机上少则装了十几款APP,多则上百款,每个APP的数据是割裂的,因为它属于不同的企业。
  • 第二, 跨屏数据的割裂性,我们每个人有4个屏幕,电视、电脑、手机以及车机屏幕,它们相互间是割裂的,它们属于不同的系统,甚至不同的产业。
  • 第三, 场景数据的割裂性,我们在商场里面,在会场,在不同的消费场景里面,都在贡献自己的数据,但它隶属于不同的消费场景。

总之,我们每个人,每时每刻都在生产数据,但是由于数据生产出去之后,分属于不同的企业,不同的机构,不同的场景。它很难关联,很难整合起来给我们提供更好的服务,这就是我们倡议要建立一个开放数据环境的前提。

如何开放数据?数字化、数据在线、数据实时与安全的标准开放协议

放数据,需理解四个概念:

  • 第一, 业务真正是数字化的。原因很简单,如果不是数字化的就没有了大数据的来源。
  • 第二, 业务数据是在线的。数据只有在线,对业务的了解才能全面深刻及时。
  • 第三, 数据是实时更新的,我们想做决策的时候,需要数字化的业务是可以实时回传到调度中心,运营中心以或者控制中心,以进行快速决策。
  • 第四, 开放数据必须建立并遵循安全标准的开放协议。

如何连接数据?ID稳定性、数据可连接、安全机制

大多企业都有这样一个观点:“我有数据,这是我的资产”,但都有一个特点,就是都不愿意拿出去用,却觉得拥有无限财富。真的如此吗?其实并不是,没有应用场景的数据就是一堆字节和服务器,只是公司的成本罢了。但是,如果放出去又觉得不值得、价值低估了、安全有风险了等等。所以我们提一个概念叫数据连接。一旦能建立连接,就可以做联合建模、做深度数据挖掘,实现业务闭环,又避免了企业的各种担忧和敝帚自珍。

数据连接要求:

  • 首先,拥有稳定加密的ID。
  • 第二,数据是可连接的。
  • 第三,健全的安全机制,要保证所有设备信息的安全使用,保证企业业务数据的安全使用。

如何打造 数据智能?数据模型、数据产品、数据场景、数据闭环反馈

在保证数据安全开放和可连接的基础上,我们才能谈数据智能。比如客户要对业务流程进行优化,可以推出针对性的数据模型进行决策;客户有新客获取及老客回流等业务需求,可以推出以目标群体数据画像为主的产品帮助客户营销;在特殊的应用场景中,如风控领域,可以帮助客户更好的区分坏人,更好的对好人的授信额度进行细化。

这里,有一个非常关键的点,我们要认识到,数据的使用是一个闭环,数据应用的过程是螺旋上升的过程。当认识到这一点,在利用数据解决问题的时候,我们才会有耐心,才真正愿意在算法模型上做投入,而不是抱着数据是万能的心思幻想着使用一下就可以毕其功于一役。

‍数据安全贯穿数据生命周期‍

随着大数据的发展,一方面我们享受到了带来种种好处,另一方面也让普通用户有很多质疑,大数据真的安全吗?对我们的隐私做到足够好的保护了吗?

所以我们使用大数据的时候必须要具备安全意识和并落到具体应用的每个环节。

在数据收集端,要收集合规合法的数据;在数据传输端,要做到多层加密;在数据加工端,有相应的脱敏加工机制,和分权加工机制与管理机制;在应用端,也要有相应的安全技术处理,做到各个角度都是不可逆的,不可溯源的,但又是能对业务起到良性帮助的。

‍未来的数字经济图景‍

总结一下,提到未来的数字经济,我们认为,:

首先数据应该是实时在线的,且能够做批量规模化处理,同时在不同的数据源之间有开放安全的标准协议;其次,连接层面有稳定的ID和安全机制,在AI算法上,有能解决具体业务问题的产品或者模型;

  • 再次,应用场景是闭环、且螺旋上升的;
  • 第一, 安全机制贯穿始终,如何强调都不为过。
  • 这是我们从数据和技术层面理解的未来数字经济图景。

产品专栏丨移动运营平台5.0全新改版发布

近日,TalkingData正式发布移动运营平台5.0,本文将从产品的角度回顾和分享TalkingData移动运营平台从2.0到5.0的经验和思考。

一、移动运营领域的经验推动改版

  • 超过6年以上移动端企业级应用的经验
  • 服务用户平均日活>100万的企业级应用
  • 服务金融机构头部用户>60%的企业级应用

TalkingData从2012年就开始尝试大型机构的移动端运营,如今已经保持了行业相对领先的优势,俗话说得好,春江水暖鸭先知,移动运营平台在头部市场这么多年的经验可以帮助我们更好地理解企业需求以及洞察需求的变化。

移动运营的三个阶段:

  • Facts:获取更多更细颗粒度的数据
  • Indication:更快的获取到Facts中间的风险和机会
  • Take Action:尽快地消化数据、规避风险或者抓住商机形成业务结果

在移动运营2.0时代,我们帮助企业获取更多的行为数据补充业务结果,用来解决数据的几个问题:一是时效问题,二是传统企业只能看到结果看不到过程的问题。

在移动运营3.0时代,TalkingData推出“3A3R”理论,帮助企业更好地规整展现数据,简单来说就是:如何看报表。

在移动运营4.0时代,企业的需求逐步从Facts向Indication转型。数据越来越多,颗粒度越来越小,而挖掘机会和规避风险的成本越来越高,于是TalkingData提出无代码埋点帮助业务更快的获取所需数据,推出自定义报表让业务人员按需配置及呈现。

而移动运营5.0时代,是Insight To Action时代。企业越来越关心如何消费数据和ROI,而不是将分析结果看过且过。TalkingData多年来的行业积累、埋点策略和指标体系也逐渐凸显出价值。

因此推动了移动运营平台5.0的全新改版——从统计分析到分析运营的升级!

二、TalkingData移动运营平台5.0做了什么

前文叙述了移动运营的3个阶段:Facts、Indication、Action。接下来,回到运营的本质看移动运营平台5.0都有哪些改进和升级。

移动运营平台5.0的设计框架UIMA:

  • User:强大的人群定义和画像能力
  • Identification:移动运营的场景核心是主路径的定义和识别
  • Marketing:碎片化的交互模式,需要可碎片化的场景触发式营销
  • Analytics:更灵活的采集,更有价值的模板,更方便的ROI归因
  • User: 强大的人群定义和画像能力

首先,来谈下对于用户的定义。移动统计分析平台5.0提供了对于用户的两种定义和选择。传统金融行业的实际业务场景是强账户的登录和交易,因此强账户的业务形态是多平台客户的对应问题。对于电商和零售行业而言,可能存在着多人同时使用一个账号的情况,例如一个家庭只有一个电商类应用的账号,通过账户很难定位用户偏好,因此通过区分行为发生的设备可以更好地定义用户属性和行为特征。

此外,传统的人群分群方式是定义用户属性,但在移动的应用场景中还要关注用户的行为。例如分析信用卡用户可以根据用户的持卡等级以及用户浏览过的分期产品,去定义不同的目标人群,并运用平台的场景触达的能力,编排目标人群的营销策略(Marketing部分会进行详细介绍)。

  • Identification:移动运营的场景核心是主路径的定义和识别

移动运营5.0平台提供了基于用户POI的分析,通过同比和环比的快速切换,即可看到用户分布变化。另外,对于新零售和传统金融机构网点转型的需求,结合TalkingData庞大的移动设备覆盖量,后续将提供更多基于“地图”的分析模块。

至于场景洞察漏斗的分析,将分为两个场景的定义方式:一是主动的场景转化漏斗,二是智能路径。由于现在的应用交互大多仍是界面式交互:一个点击一个页面,因此天然会形成一个路径(游戏除外)。有些产品会设计一些路径,但其实用户可能并没有按照我们的设计去产生行为。

高级转化漏斗可以帮助运营人员观察所涉及的路径的转化情况:有多少用户走了这些路径、转化率情况等。移动运营5.0平台提供了页面和事件混排的转化漏斗,可以一个事件一个页面的去设计漏斗,并且支持漏损人群的下钻,详细分析漏损人群的特征。

如果用户没有走设计好的路径,我们就需要去设计智能路径。设置好页面或者事件的起始点,系统会计算所有用户走过的全路径,并且通过人数、转化率、步骤数量,提示运营人员应该如何优化页面逻辑和页面话术引导。

  • Marketing:碎片化的交互模式,需要可碎片化的场景触发式营销

当完成了对目标用户的定义和对于场景的分析洞察后,会发现很多风险和机会,而移动运营的环境决定了用户在平台上的时间是碎片化的,这是常规触达和运营抓不住的机会。此时可以依靠可视化营销任务编排的能力去实现场景触发式营销,抓住每一次与用户的最好的沟通机会。并且系统会自动记录每一次触达后用户的反馈和对指标的贡献,自然形成数据闭环和业务闭环来优化策略,亦或是为下一次大型营销活动提供基础参照。

  • Analytics:更灵活的采集,更有价值的模板,更方便的ROI归因

基础分析模块,基于多年的企业服务经验及用户分析,移动运营平台将曾经260多个指标精简到了58个,这些核心指标是业务和运营人员经常查看或已经进入业务KPI范畴的。而剩下的指标分析千变万化,因此提供了自定义报表的功能以便业务人员自行梳理业务分析逻辑;此外,还提供TalkingData多年行业服务所积累下来的分析模板,助力业务分析,并将分析逻辑和结果更快的分享到团队内部进行反馈。

在私有化版本的移动运营平台5.0中,同样新增了小程序的分析模块。在社交时代背景下,app的分享目前是受到限制的,但我们可以很容易分享一个小程序或H5。并且,小程序、H5和app之间可以相互调用的趋势已经十分明显。这样,就可以通过分享一个小程序来吸引用户下载一个更稳定和丰富功能的app。

最后,在技术人员不断的技术攻关下,移动运营平台5.0完成了也许是史上最强的无代码埋点。运营人员既不用读懂复杂的SDK集成文档,也不用去理解某个元素是否可以埋点。系统能够自动识别可埋点的元素,并且可视化埋点支持参数的上报,帮助获取“订单金额”、“产品分类”、“产品名称”、“ 交易类型”、“ 交易方式”等等一系列的相关事件的采集。平台还提供“当前元素”、“当前位置”和“同类元素”的采集逻辑,降低了手工埋点的重复性工作。另外,无论是app、h5还是混合模式,都支持在PC端完成一站式埋点,设置足够丰富的参数和埋点逻辑。

三、移动运营平台未来会做什么

看到这里,您可能会问TalkingData移动运营平台未来的发展方向在哪里。我们依然从移动运营的3个阶段来看:

  • Facts: TalkingData本质是大数据公司,我们将逐步输入TalkingData移动端行为数据的绝对优势,帮助企业还原用户画像、洞察潜在价值用户。
  • Indication:挖掘机会和规避风险是有成本的,通过同行业跨企业的经验积累,逐步形成基于模型和规则的预测预警体系。
  • Take action:更多的触达平台和能力对接。