App架构理解

作者: 长不大的帅小伙 | 来源:发表于2019-07-02 18:25 被阅读0次

    这篇文章主要谈一下自己对App架构的理解,以及如何封装UI,如何拆分代码库。

    1. 良好的App代码结构

    我整理了一个App架构图,围绕这幅图来说明一下我对App整体结构的理解。 App架构图

    如图所示,从上到下,上层依赖下层,下面对每一层的职责具体说明:

    • 零业务耦合基础能力层

    这一层是整个App最重要的部分,一个公司的所有App都应该在这一层的基础上建立起来。他必须严格遵守一个规则:零业务耦合,不能掺杂任何业务,必须经过严格的code review才可以入代码库。
    我把这一层分两部分:

    1. 优秀三方库,对于github上开源的优秀三方库,我的建议是能用则用,原因很简单,即使自己有封装能力,也很难写到优秀三方库那么好,能站在巨人的肩膀上编程,为啥还要自己造轮子。
    2. 基础base层,这一层是最能体现一个公司技术功底的,这一层的能力越强大,App的技术能力越强大。对于那种零业务耦合的基础能力,都可以放在这一层,例如:可灵活控制的UI,公司统一的网络请求库(依赖AFN做的封装),工具Categroy等等。
    • 通用基础能力层

    这一层是有轻度业务耦合的,例如,针对公司统一封装固定样式的UI,公司通用的分享模板,公司通用的业务模块(比如IM),都可以放这一层。

    • App层

    这一层是真正的业务代码层,各个App根据自己的业务去堆叠代码,一个App可以说百分之九十的代码量都在这一层。有时根据业务要求的特殊性,通用基础能力层不能满足业务要求,那么各个App端,会在零业务基础层的基础上去开发自己的业务base库,供自己专业。当App业务越来越多,可以对App进行模块化拆分,对模块可以进行组件化拆分,关于模块化和组件化我这里不做说明,感兴趣的可以看看我之前总结的iOS组件化、模块化

    吐槽:App结构虽然简简单单几句话就概括了,看似简单,然而实际我的工作经历中,却很少有公司能做到代码库归类明确的,这个归类小细节貌似关注的人少,尤其是上图说的零业务基础能力层、通用基础能力层容易混到一起去,甚至有的还把App层的业务base也归类到基础能力层,长此以往,雪球就越过越大,一旦雪球大了,基础层的东西就不太好重构了,因为基础层的修改牵扯到公司所有App,所以我会关注,零业务耦合基础层一定要经过严格的code review,对这部分代码严格确保质量

    下面通过如何拆分代码库、如何封装UI,来说明一下我对代码归类的理解。

    2. 如何拆分代码仓库

    我通过一个分享库的拆分来说明一下,库的拆分原则。
    相信不少公司会对项目中的分享库独立拆分,比如一个公司有多个App,最初开发的那个A-App在拆分分享库的时候很可能也会把自己的业务模板也归类到分享库中。当公司的第二个B-App也需要分享库的时候,肯定会引入之前A-App封装好的分享库,这样一来,就会耦合A-App中的业务,对于B-App来说,却导入了A-App中的东西,不仅包会变大,而且增加了不必要的维护负担。那么如果A-App在拆分分享库的时候,拆分合理,那么就不会出现这种混乱的现象。

    分享库如何拆分

    这幅图能很好的说明一个好的分享库应该如何去拆分,ShareService针对三方提供的shareSDK做一层封装,这部分只提供分享的基础能力,不涉及任何业务耦合,图中右边baseShareSDK就可以归类在上面App架构中的零业务耦合基础层。为了快速响应业务迭代,公司可以封装一个通用分享模板放在通用基础能力层,各个App端可以有选择性的选择是否要用通用分享模板,如果App需要独立特性的分享模板,那么有了基础的分享能力层,再来开发分享模板也是很方便的,甚至是去其它App中copy分享模板过来改,也不能直接引入代码库。

    这里只是拿了分享库举例,如果每个库都经过仔细思考归类,相信代码库会清晰很多

    3. 如何封装UI

    相信不少公司都会统一封装不少基础UI组件,使得使用方便,提升开发效率,然而依然会出现基础UI组件归类混乱的现象。比如说封装了一个统一的弹窗,这个弹窗的字号、颜色、样式布局等都是固定的,然而这部分代码却被作为归类在了基础UI库中,基础UI库在零业务耦合层。这样一来,其它App都会引入零业务耦合层,而对于其它App来说,这个弹窗不是他想要的。
    那么如何封装UI会更好一些呢?

    UI封装的基础理论模型: UI封装模型

    举例说明


    轮播UI组件封装过程举例

    多样化的轮播组件在电商App中非常常见,那么如何去对这部分代码归类封装呢,从图示可以看出,(UICollectionView + layout + NSTimer)可以实现灵活多样化样式的轮播,这部分是零业务耦合的,所以当然要放在零业务耦合层的基础UI库中。为了方便开发者使用,开发者只需传一个url列表,及相关属性去控制轮播样式就能快速实现了,所以再之前的基础上包装一层,BannerLoopView,这一层也依然是没有业务耦合的,依然可以归类在零业务耦合的基础UI库中,那么各个App端只需要根据自己的业务要求去依赖BannerLoopView实现自己独特样式的视图就行了,所以这部分应该是跟着各个App走的,归类在各个App层中,如果需要统一样式的通用轮播,可以在通用基础能力层提供一个通用轮播,各个App端可以有选择性的使用。

    以上是我对App整体架构的一个肤浅的理解,记录一下做个总结,也方便大家参考和交流。

    相关文章

      网友评论

        本文标题:App架构理解

        本文链接:https://www.haomeiwen.com/subject/edgzcctx.html