移动端技术方案设计的经验总结

        因为所接触的业务复杂度高、技术难度大，不能像之前开发APP那样拿到需求后画画流程图、定一下各领域的时间节点和项目里程碑就开干，因为不对技术做抽象并输出技术方案设计文档是讲不清楚项目的整体实现方案的，即使做出了功能，只要技术指标不达标（比如准确率低、耗时长等），就很难达到和产品预期相符的用户体验。所以需要有和类似于大型项目的服务端技术方案设计一样，对客户端APP做技术方案设计的环节，设计出高性能和高扩展性的技术方案，避免项目风险大、项目目标难达预期、技术债务堆积等问题。

        移动端的技术方案设计，同样要遵循合适（合适优于业界领先）、简单（简单优于复杂）、演化（演化优于一步到位）的原则，以高可用、高性能和高扩展性为目标。相比于服务端的技术方案设计，做事的思路和方法都差不多，只是侧重点不一样而已。

        在做技术方案设计时，我对自己的要求是需要遵循如下几大原则：

1. 成事心态：作为架构师，在设计技术方案时要想方设法达成产品需求和目标。即使产品需求实现难度大、目标不切实际、技术上存在瓶颈，经过严谨的分析验证后，在客观陈述技术瓶颈的同时还要基于对用户需求的洞察给出自己对产品方案的建议，推动其它领域一起去促成项目目标的达成；

2. 全球视野：对于技术难度大或没有头绪的事情，多看看同行头部企业是怎么做的，尤其是自己不了解、认为有难度的地方，要通过查阅资料、深入交流等方式，去开阔自己的视野，切忌成了井底之蛙在坐井观天；

3. 说到做到：方案设计出来不是架构师工作的终点，而是工作的起点，架构师的厉害之处在于不仅能设计出合适的技术方案，还能将技术方案落地，达成预期目标。要通过在落地过程中遇到的问题去反思复盘，优化自己做技术方案设计的方法、加深对技术的理解。

        下面讲讲我对移动端技术方案设计流程的理解：

一、需求分析：

         需求分析包括产品需求分析和技术需求分析，产品需求主要为功能性需求，技术需求主要为非功能需求，比如性能、稳定性、安全性等，技术需求往往是设计技术方案时的约束。

         对产品的需求分析，最基本的是要了解做什么？解决用户什么问题？什么时候做完？需要做成什么样子？即要弄清楚产品功能、用户需求、时间节点和产品规格。除了弄清楚这几点之外，还要基于对用户需求的洞察，去挖掘文字背后的隐藏信息，这些你洞察到但产品需求中没有呈现出来的信息，往往就是潜在的需求变更点，即使你将洞察到的需求和疑虑告知产品，产品回复暂时不做考虑，在设计技术方案时也要将这些可能的需求考虑进去增强技术方案的拓展性。具体做法是假想自己就是用户，去模拟用户在特定场景下可能的行为。

         对技术的需求分析，主要是要识别出如果要保障产品在生命周期内持续安全稳定的运行，需要做些什么，这通常都属于非功能性需求，比如：

1. 安全性问题：被劫持、被逆向、被抓包等；

2. 兼容性问题：在不同设备上运行可能存在的兼容性风险；

3. 性能问题：内存泄漏、卡顿、高CPU占用等可能导致整机流畅度和功耗等问题；

4. 合规问题：技术上可能存在的法律风险，比如使用第三方开源库等。

二、方案设计：

         需求分析的主要工作是知道做什么？要做成什么样？什么时候做完？做什么、做成什么样是目标，什么时候做完是约束。技术方案设计的主要工作是在产品和技术的约束下，设计技术方案实现项目目标。其实技术方案的设计就是一个工作拆解的过程，现在的项目通常都很复杂、涉及领域众多，只有拆成一个一个地模块，然后由团队相互协作，才能更好的达成项目目标。架构师要做的就是抽象问题、拆解模块、串联各模块搭建方案以及明确每个模块的实现方案，具体到工作上就是三个方面的工作：输出技术架构图、输出核心流程图、明确各模块的技术实现方案。

         技术架构图就是抽象问题和拆解模块的工具，架构图分很多种，其中分层、分模块的架构图最为流行，做技术方案设计的首要任务就是画出基于项目的技术架构图，通过划分为多个抽象的层级实现逻辑上的拆分、通过对单个层级下划分为多个模块实现物理上的拆分。Android平台架构图就是典型的分层、分模块架构，具体如下图所示：

图1 Android 平台架构图

        通过架构图能够清晰明了地知道整个项目有哪些技术领域和哪些技术点组成，如果要让整个项目运作，就需要通过流程将技术架构中的各模块串联起来，技术架构中的每一层和每个模块就像一个一个的齿轮，流程图就像是润滑油，让齿轮之间联动运行起来。在技术方案设计阶段，只需要画出项目的主流程和核心流程就可以了，其它子流程可以在详细设计的时候再画。

         明确整个项目的方案后，还需要明确技术架构中每个子模块的实现方案，在能够满足功能和指标需求的前提下，子模块尽量复用公司或社会现成资源，其中社会资源包括开源的项目以及通过商务合作的资源，因为快速低成本交付是项目的首要目标。如果没有现成的方案，就需要根据公司的技术能力和项目的约束，确定是自研还是寻找技术合作。如果是自研需要走预研流程，在有预研成果对项目有一定的把握后才能进入工程化。如果是寻找技术合作，需要做技术方案选型，技术方案选型要基于项目的各维度关注点来选出最合适而非最厉害的方案（合适优于业界领先），在方案选型中呈现的信息必须是经过实际验证得出的，切忌只是做信息的收集，避免因为信息不准确而误判导致潜在的项目风险。

三、方案总结：

         技术方案设计完成后，需要给出总结性的结论，答复团队和领导的疑虑。因为团队中领域众多，大家对技术的理解和认知各有不同，关注的重点也各不相同。所以在给出结论时要用直白简练而非技术性的语言，解答各干系人的关注点。结论通常包含如下几个方面的内容：

1. 技术上能否实现？

2. 技术上能做到什么程度？

3. 项目上存在哪些风险？有何应对方案？

4. 整个项目的投入情况如何？

        用一句话描述技术上能否实现即可，技术上可行/不可行。前提是要基于项目的约束，包括产品上和技术上的。

        如果可行，需要输出整个项目以及各技术子模块的技术规格，讲清楚衡量技术能力的指标以及能做到什么程度。

        接下来需要阐述清楚在项目过程中存在的潜在风险，风险包括：

1. 进度风险：进度上存在的风险；

2. 资源风险：人力等资源上存在的风险；

3. 涌现风险：多个技术组合、并行存在的风险，比如功耗、系统资源瓶颈等问题；

4. 体验风险：比如耗时长、操作繁琐等和产品预期不一致的风险问题；

5. 指标风险：受限于项目约束和技术瓶颈，无法达成产品规格的风险。

        风险的应对方案包括：

1. 消除风险：风险可以消除且对项目没有影响，这种通常不用写出来；

2. 规避风险：无法正面解决，但可以曲线救国的方案，这种情况可能对用户体验或其它方面有影响，必须写出来讲清楚，要在项目上达成一致；

3. 减小风险：风险无法消除但可以降低风险对项目的影响。

        最后需要讲清楚项目在人力、资金方面的投入成本，便于领导决策项目的价值。是否值得投入，或调整项目策略。

四、方案落地：

         在方案设计完成，且通过项目内、领导的决策后，接下来需要按照设计的方案落地达成技术规格，在落地的过程中需要重点关注如下几个方面：

1. 分里程碑拆解目标，类似于敏捷开发小步快跑的方式及时交付、遇到问题能快速调整，降低风险，避免一条路走到黑、迟迟看不到效果。

2. 分点专项验证各技术点的达成情况，各个关键的技术点都需要针对性验证和验收，齿轮的质量有保障，多个齿轮组成的系统联动才会有保障。

3. 遇到异常时优先尝试去解决，如果在一段时间内没有进展需及时调整方案；只要是在方案设计阶段经过严格的验证，遇到异常时首先不应否定自己的方案，要想办法尝试解决遇到的问题。如果实在解决不了，要及时调整避免对项目进度造成影响。

4. 工程化的优化是锦上添花的操作，但要正确理解工程化的优化，不是打补丁，而是方案层面的优化，比如多个技术并行减少运行时的耗时；

5. 项目结束后及时复盘总结，优化后续的技术方案设计流程和方法。

下面是对整篇文章的总结：

1. 技术方案的设计要以全球视野去想方设法做成项目，并且方案设计出来后要能亲自落地，达成项目目标；

2. 技术方案设计要充分洞察产品和技术需求，基于需求通过架构图拆解模块，并通过流程将各模块中的技术点串联起来使整个项目运行起来。对于关键的技术点，要基于严谨的验证分析做出方案选型；

3. 技术方案的评审要给出明确的结论，以各领域都能懂的语言表达清楚技术的可行性、技术规格、风险和应对方案以及项目投入情况；

4. 技术方案设计评审通过不是架构师工作的终点，把技术方案落地达成项目目标才是终点。