探讨：UI 界面到底应该由谁来拼？

    声明：这里探讨的是游戏行业，本人不太了解app开发的工作流程。因为本人最近是用unity，故这里大多以unity来说明。

    在我们游戏开发领域，特别是国产游戏，UI界面对应的玩法，是一个游戏的大头，特别是在一些弱化战斗体验，以数值玩法为主的游戏中，几乎所有玩法都是在UI上完成，UI的处理，成了一些游戏的重中之重。
    制作一个UI界面玩法，涉及到策划，美术，程序，最终一切整合，要由程序完成。在三者交互的过程中，就容易涉及工作内容分工和扯皮的情况。
常见的几种情况有：

•     程序觉得拼UI是个初级工作，希望转嫁工作成本，将拼UI的工作转移给策划或美术
•     美术制作了UI示意图，在如何切图细节上，和程序需要反复沟通修改（程序会要求细化切分，注意重用，或者整合成通用资源，或者考虑打包atlas）
•     美术觉得其他人拼接的最终UI界面，和自己的设计有出入（位置对齐，压缩导致模糊，字体不一样，文字是否有描边等等细节）
•     常见的，因为需求更改的原因，UI经常是一个需要反复修改的工作，涉及到换皮，甚至交互逻辑的修改
  

     除了我列出的几种，还有其他很多合作交流的问题，导致了做UI变成了一件挺痛苦的事情。
      对于程序来说，拼UI是个没有太多技术含量的事，导致程序方经常希望将这个事情交给策划，或者美术去做。故而诞生了UI编辑器（fairyGUI等），PSD2UGUI等工具或者解决方案，希望程序只关心逻辑，而显示方面的事情，交互方面的美术细节，交由策划和美术去打磨。
     这个想法很美满，但是现实是很骨感的。

1，首先，思维方式不同。
    程序在处理UI交互逻辑的时候，常常需要UI的prefab注意层级和控件之间包含关系。例如，要设计一个list，里面的item下有好几个元素，那么，程序可能会将这个item单独用一个container包起来，而不是分散在各处。
    如下图：程序来设计，可能会用一个item，将addBtn，name，和icon包起来，方便重用（copy，Instantiate），甚至会考虑这个item是否多个UI界面通用，而将这个item单独处理为一个独立的prefab。

     若果让策划，美术来做UI（无论是用UGUI，其他UI编辑器，或者PSD2UGUI等），可能最终得到的prefab如下：

     第一，美术和策划，一般不太会有将元素包起来，复用的概念，他们会平铺所有元素。第二，因为UI示意图上可能有三个item，他们可能会创建重复的三个零散的元素。

2，关注重点不同。

    策划关注后期结果，美术关注前期设计，以及后期是否符合设计。而程序贯穿了整个过程。
    在策划给出方案，美术开始设计之前，程序需要考虑（包括但不限于）：

• 新UI和其他UI的交互衔接，玩法，逻辑之间的交互衔接。
• 资源的重用性，是新建图集，还是要合并图集，是否要提取公共图集等。
• 逻辑的重用性，某些内部模块是否可以重用，是否和之前某个模块类似，能否提取成通用控件（例如表示星级的控件，一个道具的通用控件【包含icon，个数，等级，颜色等】）
• 是否在分辨率适配上可能有问题
• 
  

    在美术给出设计方案后，又要考虑（包括但不限于）：

• 是否有背景可以做九宫格优化，平铺优化。
• 某些图片元素，是否已经存在别的图集了（很多美术没有这个概念），提醒美术某些元素是否可以做成通用，以后其他界面也可以使用。
  

    在开始制作的时候，又要考虑（包括但不限于）：

• 如果基于玩法，配置数据，逻辑来构建UI（或prefab）的结构，哪里要分层，哪里要独立，哪里要分模块等等。
• 某些地方根据配置，或者玩法，可能需要不同的实现方式。例如，一个列表是固定item个数的，还是不定的，如果是固定5个item的list，我可能为了方便直接放5个item。如果是不固定个数的，就需要动态创建，那么prefab里面做一个item prefab即可。
• 根据界面的布局，在适配分辨率的时候，需要考虑不同元素的锚点，缩放方式的设置。
  

     以上罗列的这些考虑因素，经常是美术，或者策划无法理解的，美术的理解通常是平面的，静态的。策划会知道有交互的变化，但是通常无法像程序这样通盘考虑。

3，元素命名。
    逻辑和UI的交互，通常是通过名字来绑定，程序通过一定的名字，来获取UI元素，进而处理交互。故而对于UI元素的命名，通常是根据交互逻辑，或者展现的数据来命名。而这块美术和策划同样是没有概念的。
    再加上，普遍美术和策划英语相对程序比较差，拼写错误和查词典导致的生僻单词，导致希望由美术，策划来给UI元素命名，将是一个灾难。

    最后，即使克服了以上的问题，工作的流程，也将麻烦无比。在美术，策划做好了UI之后，如果出现以下情况如何处理：
    1，程序发现UI层级，元素关系，锚点等设计不对。
    2，元素命名错误。
    3，美术切图不规范，图片分的图集不合理。

    这种时候，我们是自己改了，还是通知美术，策划更改？这个反复的过程，将涉及到反复的沟通，扯皮。
    再有，美术，策划的学习成本，无论是用UGUI，外部编辑器（fairyGUI等），PSD2UGUI等，都有新的学习成本。在最终生成的prefab不合用的情况下，常常他们不知道应该如何改，那程序去手把手教吗？这个成本也是非常高的。
    如果我们程序方想当然地认为可以转嫁这块的工作给美术，策划，其实反过来只会造成自己的麻烦，多了很多很多的沟通，反复改的成本。
本来程序一个小时拼好的界面，反复下来，可能要好几个小时，而且在写代码的过程中，因为思路的变化，性能的考虑，逻辑的优化等，需要经常对UI的层级，逻辑，命名等修改，难道每 次都要让策划，美术去改吗？
    所以，我的结论是，程序为了自己，为了项目，为了少扯皮，应该自己拼UI，花一点时间，少无数其他麻烦。


    这里我略微吐槽一下PSD2UGUI，谦虚一点说，在我有限的认识内，这是一个想当然的，糟糕的解决方案。理想很好，但是在实际使用的过程中，因为各种原因，造成的美术，程序反复交互，工作效率会非常低下。在之前一个公司的时候，技术总监希望每个项目都用PSD2UGUI（他也是被一个项目的主程花言巧语打动了）。我解释过我的考虑和原因后，坚决坚定地拒绝了。最后，我听到了其他项目的吐槽和痛苦，最后PSD2UGUI还是被弃用，受到了程序和美术的双重鄙视。选择不当的工具，将会成为一个负担。

    说点感受，我们在做技术选型的时候，要考虑各方面的成本和麻烦，而不能迷信一些工具，框架，想当然地觉得这是个银弹。在没有深入思考和测试过，没有考虑过和项目类型，项目团队情况的匹配度，没有考虑整个工作流程的梳理，选型肯定会有问题。

    最后，如果程序觉得拼UI不是自己的事情，那么美术，策划凭什么要做这件事情呢，强加给他们是否合理呢？大家可以考虑下，这件事，是离谁更近呢？程序自己拼，是让UI制作这个整体流程更加可控，也是一种高内聚，低耦合的思路。处理好工作的边界，和处理好逻辑的边界同样重要。
当很多人笑话程序思维太逻辑化的时候，我们也要怀着慈悲的心，同情一下这些没有太多逻辑的策划，美术。

    PS：痛苦很多时候来源于行业内大多数策划不够专业。在游戏的设计上缺乏整体的考虑，很多策划都是体验型策划（知道某个东西好玩，但是不知道怎么做出来），并不能冲宏观到细节都有一个清晰的思路。导致行业内很多时候需要返工做很多事情。

更多精彩图片 请登录

（图文无关）

对策划，相信大家都已经是吐槽无力，就这样吧。