手记

做了一个PC端图片阅读器,将它命名为「图阅」 | 初尝rust

目录

1 这图片阅读器长啥样?

2 为啥要整这活?

3 怎么开发的?

4 rust用起来感觉怎样啊?

5 软件在哪里下载?(show me the code)


// 它长这样

兴趣使然,做了一个电脑上用的图片阅读器,它长这样:
图库列表

看看漫画

看看照片

// 缘由

其实去年差不多时候也做过一个类似的东西,那时候起名为ComicLibrary,私心里想要一个用户友好的漫画阅读器

漫画有各种排版方式:单页、从左到右、从右到左、长条滚动。

在线阅读要等待加载、本地阅读则windows自带的图片浏览器使用上不太方便。

那便自己做一个。

去年的那个软件是用electron做的。electron内置了chromium内核,对于小型软件来说未免过于庞大,颇有杀鸡用牛刀的意味。

恰巧最近对rust语言颇感兴趣,早就听闻了这门编程语言以其极其陡峭的学习曲线而著名,并且据说学了之后思维都会有所改变。

于是一拍即合:用tauri来写一个图片浏览器吧。

// 开发

# 框架

tauri也是一个帮助开发者开发跨(桌面)平台软件的工具包,跟electron一样。前端也是web,而它的后端是rust。

# UI

不擅长美术的我要写有界面的软件,是离不开前端UI库的。这次用的库是NaiveUI,当初一看到名字就觉得,嗯很对我口味。

# 前端

使用Vue3,颇为亲切。

# 后端

rust是从头学起的。

先是阅读rust文档(的一部分),领会它的精神;

接着上leetcode用rust刷了十几道题,熟悉基本语法;

好嘞,开始写吧。

// rust体验后感,与对其精神的领会

以目前接触到的rust的内容,个人理解其精髓在于变量**“所有权”**这一理念:每一块内存都只能有一位(变量)拥有它的所有权,掌握所有权的那位需要对这块内存负责到底,变量在内存在。

又,所有权是可以转让的。

这特性便造就了move(移动)代替copy(拷贝)成为默认操作 —— 在其他很多语言里,拷贝才是默认的行为,可以理解为“A将一份信息给到B,B拥有了这份信息的复制,但A也仍然持有这份信息”。这很符合直觉。

但人们终究要为这种“符合直觉”的行为付出代价,即当信息的复制代价太高(信息量太大,复制很耗时间和内存)的时候,人们创造了浅复制 —— 信息仍然只有一份,让它静静呆在那里,咱们俩都拿着它的地址就好,这样咱们俩都能去查阅它更改它。

但人们终究又要为这节省代价的“浅复制”付出另外的代价,即竞争。A和B都想去篡改同一份信息的时候,咋整?更甚,其中一人想要删除这份信息,但另一个人不知道这份信息已经被删,这时仍去查阅……铺天盖地的bug就来了。

rust做了一个改变。在最初最初的地方做了一个简单的改变。

rust说,不妨把信息看成是像实物一样的东西,A要把这东西给到B,那A手头就没有这个东西了。

只要将信息看作实物,上述的问题就都不存在了。

永远只有一个人能拥有一份信息的所有权,竞争消失了;

所有权只能转让,拷贝消失了(当然,如果必要,可以显示定义拷贝行为,将一个信息多复制出一份来);

当然,所有权除了转让之外,还可以借用

rust定义了“可变”和“不可变”,也就是更改一份信息的权限。它还保证了在所有借用了同一份信息的人之中,同时最多只能有一位具备更改权限。(只读和可写借用之间也有约束,甚至保障到了只读那位的安全性。宛如读写锁。)

如此设计,让rust安全得一逼。绝大多数安全隐患在编译阶段就能被揪出来(当然这也导致了它的编译器非常严格,但严格归严格,提示却很友好)。

而这一切,都源于在最初做的一个理念的转变。

美妙。

初时写起来确实颇为卡顿,脑里需要时时记得这份信息是所有权在谁那里,要记得这份信息的类型(不像c/c++那样允许隐式类型转换)。

不记得也行,编译器会友善地告诉你你在哪里sb了,甚至会教你怎么改才对。

写多了之后便也写得流畅了(也不是很多)。编程终究是个练习的过程。

// 货在哪

源码和windows可执行文件放在github:

如网络条件不佳可私聊我。


写得挺开心的。

0人推荐
随时随地看视频
慕课网APP