189 8069 5689
因为所接触的业务复杂度高、技术难度大，不能像之前开发APP那样拿到需求后画画流程图、定一下各领域的时间节点和项目里程碑就开干，因为不对技术做抽象并输出技术方案设计文档是讲不清楚项目的整体实现方案的，即使做出了功能，只要技术指标不达标（比如准确率低、耗时长等），就很难达到和产品预期相符的用户体验。所以需要有和类似于大型项目的服务端技术方案设计一样，对客户端APP做技术方案设计的环节，设计出高性能和高扩展性的技术方案，避免项目风险大、项目目标难达预期、技术债务堆积等问题。
新华ssl适用于网站、小程序/APP、API接口等需要进行数据传输应用场景，ssl证书未来市场广阔！成为成都创新互联公司的ssl证书销售渠道，可以享受市场价格4-6折优惠！如果有意向欢迎电话联系或者加微信：18980820575（备注：SSL证书合作）期待与您的合作！
移动端的技术方案设计，同样要遵循合适（合适优于业界领先）、简单（简单优于复杂）、演化（演化优于一步到位）的原则，以高可用、高性能和高扩展性为目标。相比于服务端的技术方案设计，做事的思路和方法都差不多，只是侧重点不一样而已。
在做技术方案设计时，我对自己的要求是需要遵循如下几大原则：
1、成事心态：作为架构师，在设计技术方案时要想方设法达成产品需求和目标。即使产品需求实现难度大、目标不切实际、技术上存在瓶颈，经过严谨的分析验证后，在客观陈述技术瓶颈的同时还要基于对用户需求的洞察给出自己对产品方案的建议，推动其它领域一起去促成项目目标的达成；
2、全球视野：对于技术难度大或没有头绪的事情，多看看同行头部企业是怎么做的，尤其是自己不了解、认为有难度的地方，要通过查阅资料、深入交流等方式，去开阔自己的视野，切忌成了井底之蛙在坐井观天；
3、说到做到：方案设计出来不是架构师工作的终点，而是工作的起点，架构师的厉害之处在于不仅能设计出合适的技术方案，还能将技术方案落地，达成预期目标。要通过在落地过程中遇到的问题去反思复盘，优化自己做技术方案设计的方法、加深对技术的理解。
下面讲讲我对迹哪顷移动端技术方案设计流程的理解：
一、需求分析：
需求分析包括产品需求分析和技术需求分析，产品需求主要为功能性需求，技术需求主要为非功能需求，比如性能、稳定性、安全性等，技术需求往往是设计技术方案时的约束。
对产品的需求分析，最基本的是要了解做什么？解决用户什么问题？什么时候做完？需要做成什么样子？即要弄清楚产品功能、用户需求、时间节点和产品规格。除了弄清楚这几点之外，还要基于对用户需求的洞察，去挖掘文字背后的隐藏信息，这些你洞察到但产品需求中没有呈现出来的信息，往往就是潜在的需求变更点，即使你将洞察到的需求和疑虑告知产品，产品回复暂时不做考虑，在设计技术方案时也要将这些可能的需求考虑进去增姿陆强技术方案的拓展性。具体做法是假想自己就是用户，去模拟用户在特定场景下可能的行为。
对技术的需求分析，主要是要识别出如果要保障产品在生命周期内持续安全稳定的运行，需要做些什么，这通常都属于非功能性需求，比如：
1、安全性问题：被劫持、被逆向、被抓包等；
2、兼容缓旅性问题：在不同设备上运行可能存在的兼容性风险；
3、性能问题：内存泄漏、卡顿、高CPU占用等可能导致整机流畅度和功耗等问题；
4、 合规问题：技术上可能存在的法律风险，比如使用第三方开源库等。
二、方案设计：
需求分析的主要工作是知道做什么？要做成什么样？什么时候做完？做什么、做成什么样是目标，什么时候做完是约束。技术方案设计的主要工作是在产品和技术的约束下，设计技术方案实现项目目标。其实技术方案的设计就是一个工作拆解的过程，现在的项目通常都很复杂、涉及领域众多，只有拆成一个一个地模块，然后由团队相互协作，才能更好的达成项目目标。架构师要做的就是抽象问题、拆解模块、串联各模块搭建方案以及明确每个模块的实现方案，具体到工作上就是三个方面的工作：输出技术架构图、输出核心流程图、明确各模块的技术实现方案。
技术架构图就是抽象问题和拆解模块的工具，架构图分很多种，其中分层、分模块的架构图最为流行，做技术方案设计的首要任务就是画出基于项目的技术架构图，通过划分为多个抽象的层级实现逻辑上的拆分、通过对单个层级下划分为多个模块实现物理上的拆分。Android平台架构图就是典型的分层、分模块架构，具体如下图所示：
三、方案总结：
技术方案设计完成后，需要给出总结性的结论，答复团队和领导的疑虑。因为团队中领域众多，大家对技术的理解和认知各有不同，关注的重点也各不相同。所以在给出结论时要用直白简练而非技术性的语言，解答各干系人的关注点。
结论通常包含如下几个方面的内容：
1、 技术上能否实现？
2、 技术上能做到什么程度？
3、 项目上存在哪些风险？有何应对方案？
4、 整个项目的投入情况如何？
用一句话描述技术上能否实现即可，技术上可行/不可行。前提是要基于项目的约束，包括产品上和技术上的。
如果可行，需要输出整个项目以及各技术子模块的技术规格，讲清楚衡量技术能力的指标以及能做到什么程度。
接下来需要阐述清楚在项目过程中存在的潜在风险，风险包括：
1、 进度风险：进度上存在的风险；
2、 资源风险：人力等资源上存在的风险；
3、 涌现风险：多个技术组合、并行存在的风险，比如功耗、系统资源瓶颈等问题；
4、 体验风险：比如耗时长、操作繁琐等和产品预期不一致的风险问题；
5、 指标风险：受限于项目约束和技术瓶颈，无法达成产品规格的风险。
风险的应对方案包括：
1、 消除风险：风险可以消除且对项目没有影响，这种通常不用写出来；
2、 规避风险：无法正面解决，但可以曲线救国的方案，这种情况可能对用户体验或其它方面有影响，必须写出来讲清楚，要在项目上达成一致；
3、 减小风险：风险无法消除但可以降低风险对项目的影响。
最后需要讲清楚项目在人力、资金方面的投入成本，便于领导决策项目的价值。是否值得投入，或调整项目策略。
四、方案落地：
在方案设计完成，且通过项目内、领导的决策后，接下来需要按照设计的方案落地达成技术规格，在落地的过程中需要重点关注如下几个方面：
1、 分里程碑拆解目标，类似于敏捷开发小步快跑的方式及时交付、遇到问题能快速调整，降低风险，避免一条路走到黑、迟迟看不到效果。
2、 分点专项验证各技术点的达成情况，各个关键的技术点都需要针对性验证和验收，齿轮的质量有保障，多个齿轮组成的系统联动才会有保障。
3、 遇到异常时优先尝试去解决，如果在一段时间内没有进展需及时调整方案；只要是在方案设计阶段经过严格的验证，遇到异常时首先不应否定自己的方案，要想办法尝试解决遇到的问题。如果实在解决不了，要及时调整避免对项目进度造成影响。
4、 工程化的优化是锦上添花的操作，但要正确理解工程化的优化，不是打补丁，而是方案层面的优化，比如多个技术并行减少运行时的耗时；
5、 项目结束后及时复盘总结，优化后续的技术方案设计流程和方法。
下面是对整篇文章的总结：
1、 技术方案的设计要以全球视野去想方设法做成项目，并且方案设计出来后要能亲自落地，达成项目目标；
2、 技术方案设计要充分洞察产品和技术需求，基于需求通过架构图拆解模块，并通过流程将各模块中的技术点串联起来使整个项目运行起来。对于关键的技术点，要基于严谨的验证分析做出方案选型；
3、 技术方案的评审要给出明确的结论，以各领域都能懂的语言表达清楚技术的可行性、技术规格、风险和应对方案以及项目投入情况；
4、 技术方案设计评审通过不是架构师工作的终点，把技术方案落地达成项目目标才是终点。
下面简单介绍一种或许可行的方案，仅供参考
------------------------
1）默认要有一个版本更新接口
告诉客户端当前版本是否还在兼容范围内，假如不是，强制升级。（假如还可以用且不是最新，建议升级）
2）接口多版本并存规则
同一个业务接口，可能存在多个版本。
如 购物下单，可能由于业务需求的变更，导致存在着 1.0 / 2.0 / …… 等多个接口
[version] //默认版本
public void Order()
[version(1.2)] //1.2版本
public void Order()
[version(2.0-3.4)] /拍核/ 2.0-3.4版本
public void Order()
多版本管理，特殊版本则调用特殊方法，不存在特殊版本/不掘贺团在特殊版本内，则调用通用方法。
假如是未来那个版本做大变更了（将成为通用版本），那么无外乎就是把主/特殊 对调一下
[version] //默认版本
public void Order()
[version(1.0-1.1)] //1.0-1.1版本
public void Order()
[version(1.2)] //1.2版本
public void Order()
3）给客户端分配版本号并管理好
调用方式可以类似所有请求加版本号，从原来的 …… 变更为 …… 表示当期客户端用的是 1.0版本接口
4）其他说明
这个方案需要关判橘注的是，客户端对接口版本调用的对应关系的管理。
用HTTPS通信，另外APP往服务器接口发送的参数带token，还要加核槐裂上签名，服务器端验签名（以防参改闭数被篡改），校明稿验token；同时加上时间戳，防止重放。（签名算法、密钥的分配安全存储要设计好）
对服务器接口要有监控，监控到异常情况要有处理方案。