记一次【PPT制作、PPT在线编辑预览】功能开发过程

背景
       早上，正愉快写着helloWord(Java)。老大对我来了句，搞个【 根据用户输入的markdow文本内容，将数据插入到PPT模板中，生成新的PPT文件。并且要可以在线预览以及编辑】
       。(ps：就是直接照着人家的功能抄一个出来，参考网址：https://www.*******.vip)。并且跟我说Apache的Apache POI包是支持生成PPT的。
      

       请看下图

       1.用户先按照固定的markdow文本格式输入内容
       

    2.根据用户输入的内容，转换成思维导图的形式展示。
      其中，第一层的【中国传统文化艺术之美】是封面的内容，第二层是目录页的内容。第三层是章节页的内容，
     第四层是内容页的内容。
    

 

  3.选择对应的模板,生成PPT文件
     

 

开始干活

•  需求分析

      接到任务后，第一时间就对功能做了简单的分析，发现参考对象的模板很多是地方是固定的。请看下图。
      

       1.封面页、结束页是固定的。直接占位符替换即可。
       2.章节页、内容页里面的内容可以直接占位符替换，但是章节页、内容页数 需要提前计算好。比如3个章节就需要三个章节页。
       2.目录页 的内容是动态的、目录页也是动态的。

      自己目前想到的有以下三种方式：
      1.在每个PPT模板预先设置好样式，然后取模板的配置(背景颜色、文本框位置等)，所有的PPT内容全部由自己代码编写。注意，是从封面页、目录页、章节页页、内容页的样式都得自己写。
      优点：灵活度高
      缺点：全部自己手写，且涉及到调整样式，工作量大、所需的时间较长（后端就我自己）
　  2.在每个PPT模板上面、预先设置好占位符，然后把用户的数据直接通过占位符替换，把数据填充进去。
      优点：不需要关心样式，直接填充数据即可，简单快捷。
      缺点：灵活度低，部分内容是动态的。
　 3.将上面两张方式结合，大部分使用占位符替换数据，剩余的小部分通过代码动态插入。
     　　     

• 技术选型

　1.Apache的Apache POI库。
    它可以用来操作 PPT 文件。Apache POI 支持两种格式的 PPT 文件：HSLF（用于旧版 .ppt 文件）和 XSLF（用于新版 .pptx 文件）。对于操作 PPT 文件，特别是 .pptx 格式的文件，Apache POI 提        供 了相应的 jar 包，其中包括：

• poi：Apache POI 的核心库 1
• poi-ooxml：用于操作 OOXML 格式的文件，例如 .pptx 1
• poi-scratchpad：用于操作旧版 PPT 文件的库

    优点:

1. 开源和免费：Apache POI 是一个开源项目，可以免费使用，对商业和非商业项目都非常友好 。
2. 丰富的 API：提供了丰富的 API 支持，可以读写和操作多种 Office 文件格式，包括 PPT、Excel、Word 等 。
3. 跨平台：由于是 Java 编写的，可以在任何支持 Java 的平台上运行。
4. 社区支持：作为 Apache 基金会项目，拥有活跃的社区和持续的更新支持。
5. 底层控制：用户可以对文档进行底层控制，比如对 PPT 的每个幻灯片、每个单元格进行操作 。

    缺点:

1. 学习曲线：由于 API 丰富，对于初学者来说可能有一定的学习曲线 。
2. 性能问题：在处理大型文件或进行复杂操作时，性能可能不如一些专门的库 。
3. 内存消耗：在读写大量数据时，可能会出现内存溢出的问题，特别是当数据量很大时 。
4. 更新和维护：虽然 Apache POI 持续更新，但相比一些更现代的库，其更新速度可能较慢。
5. 复杂性：对于一些简单的任务，使用 Apache POI 可能过于复杂，需要编写更多的代码。
   
   
   

    2.Aspose的Aspose.Slides库

    Aspose.Slides 是 Aspose 提供的一个强大的库，用于在 Java 和 .NET 应用程序中创建、编辑和转换 PowerPoint 演示文稿。

   优点:

1. 多平台支持：Aspose.Slides 支持多种编程语言，包括 Java 和 .NET，可以在多个平台和技术栈上使用 。
2. 功能丰富：提供了广泛的 API，可以进行幻灯片创建、修改、格式化以及集成多媒体元素等操作 。
3. 高代码和低代码API：Aspose.Slides 提供了高代码和低代码 API，以及无代码应用程序，以适应不同开发需求 。
4. 详细的文档和示例：Aspose 提供了详细的文档、示例代码和技术支持，帮助开发人员快速集成和使用 API 。
5. 无需安装 Microsoft Office：与 Apache POI 不同，Aspose.Slides 不需要在系统上安装 Microsoft Office，可以独立运行 。

   缺点:

1. 商业软件：Aspose.Slides 是商业软件，可能需要购买许可证，这可能是一些用户的入门障碍 。
2. 成本问题：对于小型项目或个人开发者，Aspose.Slides 的许可费用可能相对较高 。（嗯，不知道有没有魔法可以解除。。。）
3. 学习曲线：尽管 Aspose.Slides 提供了丰富的功能，但对于一些开发者来说，学习和掌握这些功能可能需要一定的时间。
   

• 动手开干

      一开始看到Aspose.Slides需要收费、果断选择了Apache POI(能省则省 ps:bai piao)
      说干就干。当即开始研究起了Apache POI的使用，先把包集成到springboot项目后，开始熟悉API的使用，包括获取PPT文件，获取ppt文件某个幻灯片的文本、自己生成幻灯片、导出文件等等。以         下是集成的pom.xml

    <dependency>
        <groupId>org.apache.poi</groupId>
        <artifactId>poi</artifactId>
        <version>5.2.2</version>
    </dependency>
    <dependency>
       <groupId>org.apache.poi</groupId>
       <artifactId>poi-ooxml</artifactId>
       <version>5.2.2</version>
    </dependency>

      然后各种踩坑就开始了。
     1.获取ppt文件某个幻灯片的所有文本内容的时候(ps:占位符替换的前提是先获取到替换符)，一开始复制了网上的demo代码运行，但是发现不太符合，因为网上案例的PPT文件样式简单，但是我的            PPT文件样式复杂多变。当我想着如何改代码的时候，灵光一闪，好家伙，这不是有GPT吗，我还废这个劲干嘛，GPT 启动！！！！！让GPT作为辅助，描述需求让它帮忙写代码，刷刷刷的几下，崭新的代码跃入眼帘、我直接就是一个copy，心里美滋滋。结果一看。
        
        what？代码报错了？原来是GPT的代码里面。有部分办法是不存在的、还有部分的属性也是不存在的。立马纠正了GPT。又是刷刷刷一顿输出。我直接黏贴。心想：直接拿下。
        当我复制黏贴后，
        
      之前报错的地方不报错了，其他地方又报错了。接下来就是与GPT的来回拉扯。花了整整一下午的时候，最后可算是把幻灯片的文本内容都打印了出来。但是人麻了已经。
      后面换了一张模板，发现又获取不到了。查了下资料， Apache POI 对样式复杂的PPT的支持不是很友好。折腾了一天。果断放弃，选择对Aspose.Slides进行尝试。
      以下是集成Aspose.Slides的pom.xml
　　ps：我是把包下载后放到项目里面的，所以引入方式略微不同

<dependency>
            <groupId>aspose.slides</groupId>
            <artifactId>slides</artifactId>
            <version>19.3</version>
            <scope>system</scope>
            <systemPath>${project.basedir}/lib/aspose.slides-19.3.jar</systemPath>
</dependency>

    aspose.slides对于复杂PPT文件的支持果然比较友好，哐哐哐一顿输出，利用递归的方式，把所有的文本内容都拿到了，可算是把占位符替换内容搞定了。
    2.由于ppt文件的目录页里面的内容是动态的，意味着我不能用占位符的方式去处理。看下图。
   

一开始我的思路就不对了，我想着复制模板上面原有的样式，有多少个标题我就复制多少个，后面折腾了一下午，发现这种方式麻烦，换个其他样式又不行了。
后面换了下思路，目录页的内容自己写，成功解决问题。
3.markdow文本内容的封装问题。
  一开始，老大的意思是说，我这边直接接受markdow文本的内容，然后我自己封装成对象插入到模板里面去，结果就是，我单单封装成对象就花费了一天时候，期间同样使用GPT写代码(踩了上面同样的坑)。
 由于涉及到树形结构的层级补全，还有内容缺失的补全，还有对markdow文本内容格式的判断等等。发现由我这边直接处理markdow文本的内容太难处理了。后续老老实实让前端先展示成思维导图，
 后再把数据给我。

后续的整体思路就是：
获取前端传过来的markdown文本对象(已经封装好的)、选中的模板Id--------》填充模板的封面页--------》动态生成目录页以及动态生成目录页的内容----------》动态生成章节页、目录页
--------------》填充结束页。

至此，功能的初级版本就完成了。后续我还做了一些优化，在模板上面增加了许多配置，后续需要的话，再把代码贴上。
还有ppt文件的在线预览以及编辑的实现，有空再单独讲。

总结
   其实，我最主要是想对这个过程做一个复盘以及反思。
   整个的功能实现，我发现了自己在这个过程中存在着很多问题。上面看似有点逻辑的实现过程，还是我在写这篇文章的时候，自己做了下整理的。
   1.需求分析的时候，我没有先把需求整理清楚，ppt的生成、ppt的预览编辑其实是两个模块。
   2.ppt生成的时候，模板中那些东西是固定的，那些是动态的。那些是需要两个结合的，都没有以前考虑清楚，都是写着写着才发现问题。
   3.技术选型的时候，我并没有先把技术方案先列出来作比较，导致在第一个技术方案上面花了比较多的时间。
   4.过于依赖GPT的代码。导致在调整GPT的代码上花了很多时候。有时候自己写反而会更快。(有时候是自己描述的需求不够清晰，导致的GPT的代码有BUG)
   5.实现自己没有做过的复杂功能时，先去gitee或者github上面搜一下相关字眼，会有很多项目可以给到思路。
   6.老大几句话交代的需求，其实是很模糊的，仔细分析下来，会发现里面所用的技术，所需要的时间，或者说注意的点，其实是很多的。包括熟悉各框架的API，整体的实现逻辑。
      如何提升用户的体验感等等。

   整个功能实现下来，花了三个星期。其中的一些时间都用在了试错上面，但是GPT也提供了很多的帮助。希望自己可以吸取教训，不再重蹈覆辙。