以太坊钱包 Trust Wallet 项目解读

主要模块

第一个模块是一个浏览器, 具体来说是一个 Web3浏览器, 它支持许多 DApp( 的缩写, 即分布式应用), 支持基于以太坊的货币交易和游戏的 DApps。当然也具备普通浏览器的功能, 访问其它网址, 添加书签, 查看历史记录等等。

第二个模块是钱包模块, 是这个 App最核心的部分, 对Token的交易记录、余额、汇率变化的查看, 也可以进行交易转账(发送和接收)。

第三个模块是设置模块, 包括钱包账户的切换, 安全管理, 当前货币种类, 浏览器设置, 社区分享, 开发者选项等等。

项目架构

Trust的 iOS项目在架构设计和代码风格、包括技术栈都是很不错的。我将会以架构模式和四层式架构来解析此项目。

目录结构。 如上图所示, 主要模块和重要功能组成第一层的节点目录, 如、、Style、等等。又在各个模块中将第二层目录按照功能分为、Views、、、等等。

架构模式。 采用的是MVVM的架构模式, 不过并没有使用动态绑定, 但这并不影响它项目结构清晰的逻辑。相对于MVC的架构模式来说, 就使得的负载变小了, 易于测试性提高了。当然它也具备MVVM架构的优缺点, 这里就不赘述了。 我大概画了一个草图, 如下图:

视图层。 整个项目绝大部分使用纯代码进行View层的编写, 且代码规范性较强, 也没有过多的继承, 所以代码可读性高。布局方式采用方式, 在具体模块中还以为功能模块进行开发, 使View层的代码更加清晰。

业务层。 Trust的主要业务逻辑当然是有来承担的, 另外还配合了(或者说路由)的使用, 在页面之间的跳转逻辑上实现了统一管理。这样就减少了横向依赖, 也让跨层访问的业务更加容易开展。

网络层。 项目中使用Moya进行数据请求, Moya已经做了足够多的工作了, 包括交付给给业务层封装成对象的数据、网络层的各种优化工作等。Trust客户端在区块链中相当于一个轻量节点, 从公链上请求数据的话, 需要依靠某个全节点。就如图中的URL, 就可以理解为Trust客户端取链上数据所借助的全节点。

数据层。 主要的数据持有化方式使用Realm数据库, 这是个轻量级、高性能、高效率、可跨平台的移动数据库。核心数据如钱包账户、交易、Token等都存储于此。另外, 也使用了来保存比较重要且轻量的数据, 如私钥、应用锁设置和密码、最近使用的钱包、的。还有一些数据, 如当前货币种类、启动次数、当前版本启动次数、是否分享、是否评分等等, 都是采用的形式进行数据保存的。

项目流程

从程序启动开始, 作为app间的路由, 判断当前app内是否有钱包账户, 若没有则进入以r为根控制器的页面进行钱包账户创建; 若有最近使用过的钱包账户, 则进入app内部的路由。在这里, 钱包账号创建的页面和钱包使用页面已经划分为两条业务线。其实从业务角度来说, 可以也可以理解为这是Trust内部的两个应用。

进入后, 才真正开始创建、以及各个业务模块的和VC。上图中明确表示了这个过程, 也对主要的业务模块的和其对应的VC进行了说明, 且同颜色的之间是一一对应的。

主体框架的功能划分

本文前面介绍过项目的目录结构了, 但这里所说的框架并不是按照目录结构的角度, 而是延续上面的项目流程的角度。首先, 我将按源码进行原模原样的表述, 然后我将提出对于其功能划分的一些自己的建议。因为我认为某写业务模块的功能是应该出现在另一个业务模块中的。

需要承担的是程序的初始化以及整个应用生命周期的所影响的业务逻辑。

r。 功能是在保护应用的方面, 如应用锁、解锁以及当应用失去焦点后保护应用内部页面不被暴露的功能。

tor。 功能是由 和 的功能组成的。前者是对进行监听的, 并在检测到约定好的URL了进行映射和处理。后者是关于延迟深度链接( Deep )的。

。 和上面的是同一个, 在启动应用时进行初始化, 并将在应用程序生命周期中多次调用，当应用由后台向前台切换时也将调用。用于处理从外部跳转入后, 根据传入的参数要跳转进入指定的页面。

。 应用的核心业务的处理类, 有钱包管理(创建、删除、导入、导出)、助记词转化、签名工作、私钥管理等功能。

在中, r需要跟随应用的生命周期进行功能的调整。tor中的用来处理响应URL 这种由其它 App的跳入, 而用来处理响应 Links这种通用链接的跳入形式。

而在这里只是作为一个初始化的一个参数, 并无实际使用。这也是我个人认为在这个业务模块并不应出现的类, 当然后面我也会细聊我为什么这么说? 我也将会给出我自己的建议。

(或者说路由)在业务上一般可以分为 App间的路由和 App内的路由。而在此项目中, 因为还有, 所以当前的是一个 App间的路由, 而是一个App内的路由。所以在项目中承担了一些应用层的功能。

。 er是统计崩溃的, 用到的一些工具, 如 、等。而是防止文件被备份的。

。 记录应用启动次数、当前版本启动次数、是否分享、是否评分等一些仅保存于本地的应用层统计数据。

。 应用统一的风格, 包括导航栏外观、外观、分割线风格(边距, 颜色)等。这个统一风格是整个应用一致的, 一定要区别于统一管理的字体和颜色的类(如项目中的类和类)。

。 管理远程推送授权和注册相关的业务。

。 在从外部跳入当前 App后, 由的操作调起的, 在的 block中, 由下层的来控制将要跳入的目标页面。但我个人认为, 它并不应该出现在这里, 后面建议中会具体说明原因。

这是 App内的路由, 与具体业务模块有间接联系的路由, 负责创建和管理各个业务模块的和各个业务模块之间的跳转逻辑。

or。 检测当前设备是否是越狱设备, 如果是越狱设备则会提醒用户不安全, 因为这样在 中存储的钱包账户的私钥就可能被盗。毕竟在区块链中, 私钥是你作为钱包主人的唯一证明。

。 通过本地对启动次数的监听, 在指定的启动次数时对用户进行应用分享和评分的提醒。

、。 在中进行监听, 一旦检测到有约定好的URL后, 可以在对应的block中做出想要的映射或者处理。如下图。

、Realm、。 Realm数据库和数据库迁移的处理。这里其实不是特指数据库, 而是指所有与具体业务模块的创建时所使用的公共类。所以这里包括等类。

。 指所管理的具体业务模块的 , 包括、、。

。 创建上述中各个具体业务模块的 所管理的和。

直抒己见

在上面的文章中, 我也说过有一些地方, 我个人认为是可以做一些调整的。当然, 如果你没有我这样的强迫症, 可以略过。先来看一个理念。

在没有使用的项目中, 其启动流程和各个VC之间的创建应该是这样的():

然而在使用了的项目中, 应该是这样的():

当然, 在这个项目中, 项目的架构模式并不完全是第二张图这样。Trust将第二张图中的 细分为了两个, 即应用间和应用内的路由。而在Trust项目中, 图二中的显然只是相当于, 而从外部跳转(包括从其它 App跳转也包括从通用链接跳转)进入当前 App的管理是来处理的。这个理念懂了, 我们进入主题。

第一, 将 App外部跳转的事务交于。 如果按照上面所说的理念, 那么在中, 其实应该把所有与外部跳转的事务交由来做。也就是可以考虑将tor、、这些放到中, 而中只留下与应用的初始化以及整个应用生命周期的所影响的业务逻辑。

第二, 将于具体的业务模块切换的事务交于。 在中有一个, 是用来通过来控制目标页面的跳转的。这些与具体业务模块的跳转逻辑有关的业务就应该交于内部路由来做。中只留下与外部跳转和应用层有关的业务。

如果这样多了的话, 功能划分就有变化了, 如下图, 绿色边框的是新增的功能:

到此为止 Trust 项目以 iOS的角度, 按照架构和主要功能对其源码解析完了。然后, 真正关于区块链的核心功能, 像智能合约这样的, 接下来将会涉及。无论你认为区块链是好是坏, 或者有没有实际的应用和市场的欢迎, 这门技术都带来了无限创新。对于我来说, 怀揣着对技术的热忱, 无论如何也要了解究竟区块链能否改变世界。