移动互联网工程--语音读物的设计实现和产品规划

前言:
  算是幸运的事, 在朋友友情赞助下做了个语音读物App, 不仅攒了人品, 也攒到了个人在Android应用的第一桶金. 现在分享下对该语音读物App的一些技术方面的想法和产品实现上的感悟.

产品形态:
  该App的定位是语音读物, 主要面向低年龄学生. 学生可以浏览书架, 选择感兴趣的书籍. 然后点击具体的电子读物进行浏览学习. 步步高点读机在这块领域, 算是鼻祖, 也是该App模仿的对象.
  
  从用户的角度来解读该App, 主要有两块: 书架, 语音书.
  书架的设计大致如下:
  
  语音书的设计如下:
  
  注: 点击具体的文字, 会播放相应的语音, 图片来自网络

技术分析:
  从软件开发的角度去解读, 该APP的难点在于电子书的资源管理上. 一个是书架管理, 用于展示语音书的元信息列表. 另一个是电子书的语音素材管理.
  假设App是单机版, 那采用什么方案来存放语音书籍的元信息?
  这个相对还是简单的, 可由如下两种方式来实现.
  1. 外部导入sqlite的db文件
  2. 自定义xml文件来描述语音书籍列表
  比如如下规则:

<bookshelf>
  <book>
    <name>课本第一册</name>
    <image>default</image>
    <resource>2C8E4202929D8331ED585FCE30669649</resource>
  </book>
  <book>
    <name>课本第二册</name>
    <image>default</image>
    <resource>29E54AFB1494CB28E30B034B5FCBA408</resource>
  </book>
  ...
</bookshelf>

  评注: 实际采用方案二, 把自定义的book_desc.xml文件放到android工程res/xml中去, 然后运行时载入并解读.
  那对语音读物的存储如何来实现?
  对于具体的电子书, 我们把相关的素材(音频/图像)组织并整理汇总到一起. 这样可以为每本电子书打包成zip文件.
  
  具体实施之前, 我们需要做些准备工作:
  首先要做的是对资源进行压缩优化处理, 在保持音质/画质可接收的范围下, 尽量减少素材资源所占的空间比重. 相关的优化策略可以参考: 移动端音频和图形优化处理. 
  其次需要对Android的硬件/常见的存储方式, 需要有一定的理解, 具体可参见该文: 资源类APP的数据存储处理和优化

  每本语音书籍, 包含如下目录结构:
  
  注: images存放图像文件, musics存放语音文件,而book.xml则具体描述每页的图像, 以及每页的关联区域和语音文件的对应关系.

  而具体book.xml的定义, 按如下规则来定义:

<book>
  <meta>
    <name>zp</name>
    <author>zp</author>
    <description>zp</description>
  </meta>
  <ppts>
    <!-- 具体某一页的详细定义 -->	
    <ppt>
      <!-- 图片 -->	
      <image>544F9EFF07DD68D1F143E3E9A995E573.jpg</image>
      <realx>533</realx>
      <realy>640</realy>
      <!-- 语音区域列表 -->
        <soundblocks>
          <!-- 具体的点击区域(tx, tp, bx, by)和相关联的语音music -->	
          <soundblock>
            <topx>120</topx>
            <topy>71</topy>
            <bottomx>345</bottomx>
            <bottomy>117</bottomy>
            <music>C5ECF459D28DF8289E96DB7F1065C281.wav</music>
          </soundblock>
        </soundblocks>
        ...
    </ppt>
    ...
  </ppts>
</book>

  评注: <ppt>标签下为具体某一页的详细定义, 包含背景图片, 以及语音关联区域的坐标范围和响应语音 

辅助软件设计:
  对于该App的设计, 最重要的就是语音书籍的定义以及后端的制作编辑工具.
  具体的设计, 请参见上部分. 而后端的制作编辑工具, 最终的产出就是那个book.xml.
  具体的工作界面如下所示:

对产品的思考:
  好的语音读物App, 应该具备什么?
  1). 好的交互性, 软件体验简单易学, 更适合低年龄儿童
  2). 黏性好, 让学生学得快, 且印象深刻
  这些都是基本的东西, 但真正实现起来却很难.
  当前所做的工作:
  1). 引入左右滑动效果, 手指滑动的交互方式更适合手机端应用
  2). 标识每个语音块区域, 显示小喇叭以表明这是相应的语音区域
  不足的是, 感觉用户体验还是一般. 这个不再是技术的问题, 而是产品形态的问题.
  回过头来看, 步步高点读机. 其核心理念是:实体硬件+软件APP, 硬件嵌入学习软件, 但我感觉本末倒置了, 就应该着重软件App, 而不需要带个几乎没用的外壳(或许中国人的消费习惯是, 只愿花钱买带实体的物品, 还不愿意掏钱买付费软件). 其交互方式, 有动画也适合学生的学习习惯, 但总觉得少点什么.
  要做好一款面向低年龄儿童的语音读物, 其实蛮难的.

后记:
  原本想详细的展开技术细节, 但写着写着就迷失了方向, 想想还是大致点一下. 对产品的思考和把握或许才是技术人员更应该关注的东西, 技术真得不是全部. 当然没有技术是万万不行的, 呵呵.

原文地址:https://www.cnblogs.com/mumuxinfei/p/3810254.html