目录

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：

https://github.com/BD777/imageview

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

写得挺开心的。