古琴小程序开发记录：识谱页面终于有了第一个雏形

从一个按钮开始#

最近继续折腾我的古琴小程序。

前面更多时间都花在页面结构和整体功能规划上，但一直只有页面，没有真正让我觉得“这个东西已经开始能用了”的功能。

所以这次我决定先把重点放到 识谱页面 上。

我的想法很简单：

用户上传一张古琴琴谱图片，小程序识别图片中的琴谱内容，然后把结果展示出来。

真正做到完整识别当然还有很长一段路，但至少可以先把整个操作流程跑起来。

目前第一版已经有了一个比较完整的雏形。

现在已经能做什么#

目前识谱页面实现的流程是：

选择图片 → 显示图片 → 点击识别 → 显示识别结果

用户可以直接从相册选择图片，也可以调用手机摄像头拍摄。

小程序里我使用的是 wx.chooseMedia：

1
wx.chooseMedia({
2
  count: 1,
3
  mediaType: ['image'],
4
  sourceType: ['album', 'camera'],
5

6
  success: (res) => {
7
    const tempFilePath = res.tempFiles[0].tempFilePath
8

9
    this.setData({
10
      imagePath: tempFilePath,
11
      result: ''
12
    })
13
  }
14
})

选择成功之后，会拿到一个临时图片路径：

1
const tempFilePath = res.tempFiles[0].tempFilePath

然后通过：

1
this.setData({
2
  imagePath: tempFilePath
3
})

把图片路径保存到页面数据中。

这样页面就可以把用户刚刚选择的琴谱显示出来。

虽然只是很基础的一步，但当图片真正出现在页面上的时候，还是挺有“项目终于动起来了”的感觉。

“开始识别”现在还只是一个演示版#

图片上传之后，下一步自然就是点击“开始识别”。

目前我先写了一个简单的加载效果：

1
wx.showLoading({
2
  title: '识别中'
3
})

然后暂时返回一段模拟识别结果。

现在的结果并不是真正通过算法得到的，而是为了先验证整个前端流程：

用户有没有上传图片？

按钮能不能正常点击？

识别的时候有没有加载提示？

识别结束后结果能不能正确显示？

这些功能确认没有问题以后，再把假的识别结果换成真正的后端返回数据。

以前写代码的时候，我经常想一次就把完整功能做完。

但现在慢慢发现，项目开发更适合一步一步来。

如果一开始同时写图片上传、Django 接口、图像处理和识别算法，一旦出错，很难判断到底是哪一层出了问题。

所以目前我的策略是：

先把前端做通，再做后端，最后接算法。

这样每一步都可以单独验证。

下一步：把图片真正传给 Django#

现在的识谱功能还全部发生在小程序前端。

真正完整的流程应该是：

1
微信小程序
2
    ↓
3
用户选择琴谱图片
4
    ↓
5
上传图片
6
    ↓
7
Django 后端接收
8
    ↓
9
识谱算法处理
10
    ↓
11
返回识别结果
12
    ↓
13
小程序展示结果

所以下一步我要做的，就是让小程序真正把图片发送到 Django。

第一版后端接口甚至不用马上做识谱。

可以先做到：

1
收到图片
2
返回文件名
3
返回图片大小
4
返回上传成功

只要这一层能够成功，就意味着：

微信小程序和 Django 后端之间的图片上传链路已经打通。

之后再慢慢把真正的琴谱识别算法接进去。

为什么我想做识谱这个功能#

相比小程序里的文章展示、每日一曲这些功能，我一直觉得“识谱”是整个项目里最有意思的一部分。

因为它不只是把已有内容展示给用户。

而是用户给系统一个输入，系统真正对这个输入进行处理，再返回新的结果。

这种交互会让整个小程序从一个“古琴资料展示工具”，慢慢变成一个真正有功能的应用。

当然，现在距离真正能够识别古琴谱还很远。

图像预处理怎么做？

琴谱符号怎么识别？

复杂版面怎么处理？

识别结果以什么形式展示？

这些问题后面都会慢慢遇到。

写在最后#

现在这个识谱页面还只能算一个很早期的版本。

甚至真正的识谱算法都还没有接进来。

但相比最开始只有一个“识谱”按钮，现在至少已经有了：

图片选择、图片预览、识别交互和结果显示。

从“我想做一个识谱功能”，到屏幕上真的出现一个可以操作的页面，中间其实就是很多这样不起眼的小步骤。

下一步：

让图片真正跑到 Django 后端。

等这一段跑通以后，再继续记录。