谈一谈App的架构设计 _App

文章插图

我们可能已经在研发的这条道路上持续了5年，甚至更久的时间，如何才能拉开和大众的距离，让自己的工作能力提升一步？架构设计应该是其中一个方向，大到App整个的设计，小到每一个页面、功能，都需要设计。这篇文章根据我的研发经验谈一谈App的架构设计。
一、代码需要可读性可读性是十分必要的，我们甚至可以在一个UIViewController中完成一个APP的所有功能，它可能有几万行，几十万行代码，该怎么维护，怎么读，写的时候只有你和天明白是怎么回事，过了几天就只有天知道代码为什么这么写了。因为代码太复杂，几十万行的逻辑在你脑子里，估计脑袋会炸掉，现在在MVC框架中Controller有一千行代码，都觉得都痛苦了，更何况是几十万。
所以要本着一个原则，可读性。代码可以不漂亮。
针对可读性，我们老一辈得人，做了很多尝试，最后有一些被证明是合适的，用起来蛮舒服的，这样的尝试，被总结出来，形成了原则，我们大家共同去遵守，达成共识。比如：六大设计原则。
感谢他们，我们是站在他们的肩膀上。
二、代码需要扩展性扩展性、仁者见仁智者见智，这是十分考验得内功得事情，有些人开始时就可以做出很好的架构，也有工作几年的人依旧不能做出前瞻性得技术思考。代码的扩展性按照我的理解需要有注意如下几个方面：

产品思维
设计规范
技术选型

代码需要产品思维代码的扩展性与产品思维是离不开的，你要知道产品现在做的什么功能，以后可能会做什么功能，以及要和产品经理聊天，直到他们大致的规划；可能有些产品在实践的过程中慢慢就会发生变化，工程师也要跟随着一起做出改变，而且一旦反向改变，一定要在代码上果断的做出改变，否则，后续的问题会越来越严重。
比如产品定位于直播，那么相应的技术栈就出来了：FFmpeg、GPUImage、AVFoundation、OpenGL ES、Metal、即时通信。可能会有直播带货，网页，支付等。
当产品经理的操作过于复杂时，记得要battle，（如：产品自己讲着讲着就懵逼了，这是一定battle）,不然出来的代码也是一片狼藉，用户估计也不会喜欢。
查看竞品软件更直观、更有效。我们通过以下手段获取有用信息：

竞品的现有功能
竞品的技术选型（简单的逆向、分析出用的Swift还是OC、FFmpeg还是GPUImage、以及用的第三方框架都有哪些）
竞品的规划方向

设计规范驱动代码为什么代码的扩展性还要考虑设计呢？
我们在研发的过程中很多时候都是和设计打交道，可以说一个好的设计师，可以让我们的代码质量提升，可以减少我们的研发时间，那么对于工程师什么是好的设计师呢？

有规划（知道自己现在以及未来，将会做出是什么样的设计，能找出共性，会抽象）
有逻辑（好的设计图管理、交互的逻辑性，各种极端情况的考虑：如无网络，无数据，大屏幕、小屏幕、全面屏，错误提示，完成提示）

如果设计不够成熟，让他多去看看大厂得软件，学习去吧。同时我们也要帮助设计童鞋进行抽象。
技术选型是骨架根据产品的方向类型，进行技术选型，技术选型包含以下几个方面：

语言： OC、Swift、RN
编程方式：面向对象、函数式、面向协议
第三方库：这是个自己造轮子还是用别人的轮子的问题
布局方式：autolayout、frame、xib、storyboard

做技术选型时，要调研好社区情况，是否活跃，是否继续维护，支持的IOS系统。比如目前的SwiftUI目前就不适合作为一个商业项目的选型，Flutter，目前也不适合，要考虑之后项目新人的接手难度，招聘情况，虽然各大厂不断鼓吹Flutter,真正用到的很少很少，甚至我发现，各大厂不断开Flutter交流会，但是本身并不使用。无论是SwiftUI还是Flutter距离使用都还有一段考验期，小厂不要去考虑，大厂可以尽情折腾。
2016年，在一家创业公司，用Swift2.0写项目，现在想想，那是一个错误的决定，不成熟的Swift并不友好，尤其是每个版本不兼容，一年一度的升级，让我们不堪重负，拖累我们的研发进度。
竞品的技术选型是一个重要的参考方向。
三、App需要加速框架（知识库）公司要积累自己的知识库，也成为加速框架，比如网络，肯定要自己再封装一层吧，各个项目的网络库统一用同一个，这样节省开发者的时间；通常这些加速框架与App的耦合程度不大，可以独立封装。常见的加速模块：