戏说移动江湖开发历程

大主线

细说移动开发历程复制代码

大技术

组件化开发 组件路由 组件配置动态加载 组件骨架架构 插件化开发 静态插件化 动态插件化 细节雕琢 网络层的优化和架构 动态埋点的实现 技术层架构（MVP，MVVM等模式）复制代码

大天地

后续按照大技术块各个技术点深刻浅出的分享出来，请订阅关注。
复制代码

前言

本文阅读须要8分钟。

你可能的收获：
   理解整个公司移动开发的基线和主线
   学会移动开发组开发过程碰到问题和解决方案
   学会移动开发过程各个技术的细枝末叶
   但愿能给读者开发项目有点启发和思索复制代码

正文

我理解的技术开发人员，除了业务和技术的热爱，其同时也需具有独立思考的能力。复制代码

在这个高速变换的二次元移动开发时代，不少产品和公司应付追赶突飞猛进之变化都是争分夺秒攻城略地，伴随而来的移动研发也是进随着'敲锣打鼓开天辟地'。

因此咱们有必要分析和思索当下移动开发的周期，就我的理解则把移动开发生命周期分四大周期，这个四个周期同步伴随着公司发展整个过程。

这个四个生命周期分别命名为：

1.成长期
2.混沌期
3.统一期
4.分化期

成长期通常在公司的第1~2年；
混沌期通常在公司的第2~3年；
统一和分化期在公司第3年之后；其中统一和分化期有可能屡次迭代进行。复制代码

      所谓的成长期，也就是传说中的野蛮发展，此时公司主导方向快速迭代跟进市场，做为研发里程以及人员数目这块都是从无到有的过程，其宗旨也是开发追赶产品实现快速上线过程。

      此时开发技术选型都是以我的因素为走向，所以前期项目选型和架构都是我的技术喜好占主导，本身熟悉的技术和框架才是最快最有效的，能够快速追遇上线进度。譬如喜欢rxjava，喜欢mvp模式很快就会在这个项目就起主导方案和技术架构。甚至有些开发同仁直接从网上所谓架构好的现成项目开干怼。此时段公司的惟一宗旨就是首战市场产出产品，快速迭代占据每一个开发人员的脑海中，细节等一切能够忽略，要啥自行车。

     接下来，随着公司业绩第一枪打响，同时融资也下来了，开始招兵买马大干一场，人员补给上来，开始出现混乱和磨合期，新来人员以为老代码就是一坨翔，各类心底鄙视和不爽；老员工以为新员工桀骜不驯啥都不懂喜欢装逼。可是公司补给人员的目的是更加快速迭代项目，公司还动不动搞个什么敏捷开发鬼模式实现1~2周迭代一个版本（就喜欢搞事）。

     需求继续开展代码还得迭代而新老开发人员依葫芦画瓢编写代码，慢慢的（能够N个），慢慢的过段时间发现代码充斥各类耦合，不规范代码，文件包混乱，业务各类穿插，一句话混乱的一锅粥，各类线上bug突突的冒出来；线上bug一统计，fuck指标超过5-10%，开始全组上下静心反思，产生出版本重构迭代统一思想。

     项目重构功能改善等统一口号就出现了，此时通常分两波人马，一拨人马继续业务迭代而另一波人马进行项目重构；此事的核心就是减小线上bug数的量级，完成公司要求线上bug不能超过3%的指标，这个时候重构重点基于线上bug进行维度分析，经过问题按多少进行划分，差很少这个时候的问题以下：

一、Bug的可视化实时监控和统计；
二、引用内存未释放致使crash的bug；
三、内存泄漏致使crash的bug；
四、进入市场机型问题引发的bug；
五、网络访问慢的反馈；
六、奇葩未知的bug；
七、。。。复制代码

问题1的思考，引入第三方系统，例如bugly等

问题2的思考，引入Eventbus解决回调地狱问题和回调引发泄漏未释放问题；

问题3的思考，引进LeakCanary内存泄漏检测，和prof分析大法根据各个问题进行突破；

问题4的思考，无解，能解决一个是一个，主要公司机型跟不上，能够经过网上机型提供商进行问题测试，贵不说并且感受没啥用；

问题5的思考，略；

关于公司指定的线上bug指标，是否完成也是须要多版本迭代现网运行后才能统计；既然是现网bug就有轻重之分，若是重大bug通常当即发布新版本更新，轻微的bug放到下一个版本迭代修复，那有没有现网bug热修复方案，确定有的，成熟的有tinker等第三方库；

虽然以上问题加班加点的搞完后，可是随着公司业务的发展和市场的强大推广，多个业务线如雨后春笋通常立项开干，看着当前项目架构模式(如图一)，

                                

                                                    图（一）

长叹一声，埋在心头的那个一个极大隐患和不安慢慢露出来，项目中依旧充斥代码各类耦合和混乱，加上‘混乱代码加上新代码依旧仍是混乱代码’定理一直压着头顶上，这项目框架确定

没法跟上公司新业务线的发展和规划；有压力就有动力，深思熟虑后不知觉分层分模块架构慢慢浮现出来，每一个业务线都是一个Module模块，接下来每来一个业务线就按照这模块模样复制粘贴一份接着开怼业务。通常这种状况须要持续到三个业务线后基本就会出现模块间混乱调用，资源文件各类重复且代码处处飞，加上权限控制不到从而每一个人都有权限编写基础库从而使各个业务公共代码下沉到基础库致使庞大臃肿，多模块混合编译速度极度慢等不良问题一大堆冒出来，回过头看看项目现状，我去，又来了，忙不完的事。看看图二（偷图，侵图删）若是你把本身当处女座，你确定会发狂，要么炒老板鱿鱼要么静下心思考分析。

                                                               图（二）

分析后得出如下几个急需解决的问题，

1. 模块间的调用进行解耦合实现模块热拔式方案
2. 是时候加上代码权限管理
3. 模块打包AAR实现模块间引入
4. 解决编译速度慢问题
5. 自动化打包问题
6. 。。。。复制代码

问题1的思考，既然实现解耦合同时实现热拔式方案，说白点就是当前模块开关关闭，被其余引用的模块没法感知到这个模块被关闭，即其余模块引用的代码必须不能硬编码此模块的方法和引用类等等，方案就是组件路由，调用方经过字符串path查询模块的服务和功能。

问题2的思考，代码权限管理通常经过git或者svn去实现。

问题3的思考，能够经过gradle脚本实现模块打包上传私服。

问题4的思考，gradle自己问题加上模块多致使编译速度慢，根据业务线的独立性那咱们能够经过编写业务模块时给此模块实现App模式，减小其余没必要要的代码编译和运行。实现方案大致以下：

在模块gradle编译脚本经过标识符来区分是模块仍是可独立运行的App

sourceSets {
        main {
            jniLibs.srcDirs = ['libs']
            if ("true".equals(FINANCE_IS_APPLICATION)) {
                manifest.srcFile 'src/main/diff/appmodule/AndroidManifest.xml'
                java.srcDirs = ['src/main/java', 'src/main/diff/appmodule/java']
                res.srcDirs = ['src/main/res', 'src/main/diff/appmodule/res']
                assets.srcDirs = ['src/main/assets', 'src/main/diff/appmodule/assets']
            } else {
                manifest.srcFile 'src/main/diff/libmodule/AndroidManifest.xml'
                java.srcDirs = ['src/main/java', 'src/main/diff/libmodule/java']
                res.srcDirs = ['src/main/res', 'src/main/diff/libmodule/res']
                assets.srcDirs = ['src/main/assets', 'src/main/diff/libmodule/assets']
            }
        }
}
复制代码

这样咱们须要单独运行此模块,在gradle.properies把FINANCE_IS_APPLICATION为true

而后编译就能够实现业务代码编写和运行。有人问，若是我须要实现主App里面的新业务，那你能够关闭其余无关的模块实现快速编译提升开发效率。

问题5的思考，随着项目的增大和多渠道的打包，此时须要进行考虑项目周边的业务服务，例如提供给测试人员的打包测试，正式版的发布等等自动化产出问题。

通常自动化服务能够经过搭建jenkins服务，或者配合python脚本实现自动化打包功能，其脚本的功能因公司而异。

                     

                                                               图（三）

因此此时迫切须要一个熟悉gradle，python等脚本的同志（gradle自己是grovvy语言）。保证新业务的开发的状况下整个过程的重构和完善至少须要半年时间（大公司除外）。

慢慢发现，组件化架构无声无息的出现了，是否是很神奇。回过头发现组件化架构已经进行了一小部分，信心十足，继续干，此时必须祭出毛爷爷的红本子，大声的朗读出来，我爱编程，皮肤好好！！

咱们发现已经作了业务模块化代码分离和模块间路由互调通讯以及gradle组件化脚本；

你的成长是创建在公司的成长上，随着公司业务发展庞大，种种原因业务伴随着也会出现分支独立，须要某些子业务线独立出App提供专业的服务和体验；须要撒播种子开花结果，原先的子模块可能变成独立App，因此发现目前的架构是无法实现，对，走过来，请在菩提树下思考；其根本原因就是组件化不彻底致使的。其中最大问题就是主项目模块涉及到大量的之前最先的业务代码和功能，如今最迫切问题是须要把主项目的业务剥离变成一个业务子模块加一个纯粹的项目骨架，其中项目骨架必须上升一级变成新的主项目模块，此主项目模块包含项目公共业务。说白点，把项目骨架套在其余子模块就是一个独立的App能够运行；做为对比，图四为原架构图，图五为主项目模块上升一级为项目骨架的架构图

其中主项目骨架必须包含的功能有：

一、项目升级降级功能；
二、第三方库的引用和初始化工做；
三、实现子模块加载和引入以及初始化工做；
四、周边服务或插件的引入和初始化工做；例如Tinker和bugly等
五、。。。复制代码

               

                                                        图（四）

                   

                                                                  图（五）

这个时候组件化大致已经完整成型，如今惟一须要作的就是经过gradle脚本去作粘合器，脚本配合jenkins动态实现模块间和主项目骨架的组合；上面说的组件化成型是主体骨架完整了，可是须要根据本身的公司业务继续进一步解耦和分离，通常如：

1. 全局配置文件的分离，实现配置文件根据子模块业务走，例如网络地址的配置和网络请求地址的分离；
2. 业务配置文件的分离，配合服务端一块儿实现模块化分离；
3. 各个子模块的公共业务动态加载块；
4. 耦合代码的分离和重构；
5. 。。。复制代码

此过程应该作到了项目模块以及代码的各类解耦和分离，看起来很是清爽和干净。不知觉又开始唱起了：我爱编程，皮肤好好！！

忽然有一天你听到有人说插件化，你内心暗暗一笑，咱们项目早就实现了热拔式插件化；一讨论发现原来不是你想的插件化，他们说的插件化是把业务模块动态存放到网上，须要的时候加载进来；哇咔咔，原来插件化分两种，一直静态插件化和动态插件化；不知觉的发现咱们已经实现了静态插件化功能，细水长流说的就是这个，哦，应该是水到渠成；动态插件化的前提必须是项目已经具有成型的组件化后才能实现动态插件化功能。

目前已经能够独立出各个子模块打包成AAR、JAR、APK；接下来就是须要在主项目骨架上添加一项动态插件化功能；完美如今动态插件化市面上有不少成熟的方案，由于这个不像组件化过程，组件化其实自己和业务和项目有很大关联，须要根据本身的业务以及已有的业务框架进行加工和架构实现；而

动态插件化实现机制和业务体系和自身架构无关系，能够大胆的引入第三方成熟的插件；例如美团公司，阿里公司的动态插件化。

其实，回味下整个过程，发现这些都是一步步的走下去的，不可能一步到位，这才人生；有人问是否是接下来高枕无忧，哈哈，too x too native， 这才是万里长征前几步而已，接下来须要细节上和技术上进一步雕琢，周边服务的完善和安全等配套实施都须要等你去实现；路遥茫茫。。。

细节上雕琢随便列举几个：

一、例如上面提到的bug中出现网络性能慢，这个就能够深刻挖掘各个实现，例如腾讯就这个小点实现了Mars开源框架；
二、业务UI框架的封装（减小重复开发以及性能问题）；
三、性能监控；
四、配置管理中心；
五、动态埋点；
六、各个业务核心点的优化；
七、编写的组件化的重构和优化；
八、技术层架构（MVP，MVVM等模式）
九、分布式架构；
十、。。。。复制代码

最终你会发现，不少功能只有在你组件化结束后或者插件化结束后再去实施会达到事半功倍效果，实现集中优化改动分布最小化，极大减小改动的风险和

bug

风险；

以上过程实际上是一个分久必合合久必分的过程。当项目走向作到极致的时候仍是无法应付庞大用户群和业务群，请转行养猪。。。复制代码

插件化路由实现，源码详见，以为好请点击star：个人路由