零、最后的挣扎
今天外面风太大了，吹得头疼，到家被迫睡了一觉，时间就所剩无几了。如果不是参与七日打卡的活动，今天肯定不会写文章了。Live2DView 的封装思路在脑内构思了两天了，但未经实测，估计有些细节还存在问题，尤其是 OpenGL 的部分。
下面就分析一下 Live2DView 的功能需求，等以后真的写完代码再做个对比，看看想和做的差距到底有多大。
一、需求分析
就像日常开发工作一样，编写代码之前，程序员必须先确保自己是完全理解需求的，否则开发过程中就容易逐渐跑偏，凭空增加工作量。Live2DView 的表面需求很简单，只要给一个 GLSurfaceView 增加模型路径配置再集成 Cubism SDK 进行渲染即可，我们就按这个思路开始，从概括到细节确认需求点。
需求 1：Live2DView 首先是一个 View
Live2DView 需要能在 xml 中合理布局，支持 match_parent 和 wrap_content 的测量。由于加载的模型可以缩放，wrap_content 可以采取跟 match_parent 相同的策略，parent 给多少空间咱就用多少。
GLSurfaceView 跟普通的 View 相比还不太一样，View 动画的功能只能酌情支持了。
需求 2：Live2DView 需要处理模型错误问题
如果传入的模型文件本身有错误或者版本不支持，显示错误信息总要比黑屏更合理一点。Live2DView 可以继承自 FrameLayout，正常显示的时候只需要添加一个全 match_parent 的 GLSurfaceView，其他情况根据状态添加加载中或者错误提示的 View。
需求 3：Live2DView 可以跟模型交互
我们可以用 View 的 onTouchEvent 替代 Demo 中 Activity 的 onTouchEvent，实现基本的交互，缺点是只能随机触发动作或者表情，我们的目标需求应该是让 Live2DView 的使用者自行控制这一切。也就是说，需求是将模型支持的操作暴露出去，让用户获取到对应信息，再根据信息调用函数操作模型。
当然，模型的控制完全暴露出去会提高使用门槛，提供一套默认的动作配置也很重要。这里暂定为点击可以顺序/随机播放全部支持的操作，静置状态下固定时间间隔顺序/随机执行动作。
需求 4：Live2DView 回调
加载模型、执行动作、修改表情等等操作都是需要时间的，不能即时返回结果，至少需要一个是否执行完成的动作的回调，帮助业务判断时机。
二、其他设计思路
涉及 C++ 和 Java 的混合项目有一条天然的分界线，JNI。用简洁的 JNI 设计将 Java 层和 C++ 层隔离开，项目会更好维护，比较好用的一条就是尽量避免 C++ 直接调用 Java 代码。
Live2DView 本身不应该直接提供 native 方法，把 Live2D 相关的操作委托出去更好。这样既方便 Live2D 操作和控制部分的修改，又可以支持用户自定义 GLSurfaceView 实现扩展。
时间有限，还没想通的思路就在代码文档里补充吧。
打卡活动结束啦，感谢所有阅读点赞评论过的大佬们，祝你们新的一年工作顺利，升职加薪~
经过这些天痛苦地学习和瞎编，我写东西的速度好像提高了不少，有下次打卡活动的话一定继续参加，没有的话就自己努力周更吧。
