戏说移动江湖开发历程

大主线

细说移动开发历程

大技术

组件化开发

• 组件路由
• 组件配置动态加载
• 组件骨架架构

插件化开发

• 静态插件化
• 动态插件化

细节雕琢

• 网络层的优化和架构
• 动态埋点的实现
• 技术层架构(MVP，MVVM等模式)

前言

你可能的收获：

• 理解整个公司移动开发的基线和主线
• 学会移动开发组开发过程碰到问题和解决方案
• 学会移动开发过程各个技术的细枝末叶
• 希望能给读者开发项目有点启发和思索

正文

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

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

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

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

• 1.成长期
• 2.混沌期
• 3.统一期
• 4.分化期
• 成长期一般在公司的第1~2年;
• 混沌期一般在公司的第2~3年;

统一和分化期在公司第3年以后;其中统一和分化期有可能多次迭代进行。

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

此时开发技术选型都是以个人因素为走向，因此前期项目选型和架构都是个人技术喜爱占主导，自己熟悉的技术和框架才是最快最有效的，可以快速追赶上线进度。

譬如喜欢rxjava,喜欢mvp模式很快就会在这个项目就起主导方案和技术架构.甚至有些开发同仁直接从网上所谓架构好的现成项目开干怼。

此时段公司的唯一宗旨就是首战市场产出产品，快速迭代占据每个开发人员的脑海中，细节等一切可以忽略，要啥自行车。

接下来，随着公司业绩第一枪打响，同时融资也下来了，开始招兵买马大干一场，人员补给上来，开始出现混乱和磨合期，新来人员觉得老代码就是一坨翔，各种心底鄙视和不爽;

老员工觉得新员工桀骜不驯啥都不懂喜欢装逼。但是公司补给人员的目的是更加快速迭代项目，公司还动不动搞个什么敏捷开发鬼模式实现1~2周迭代一个版本(就喜欢搞事)。

需求继续开展代码还得迭代而新老开发人员依葫芦画瓢编写代码，慢慢的(可以N个)，慢慢的过段时间发现代码充斥各种耦合，不规范代码，文件包混乱，业务各种穿插，

一句话混乱的一锅粥，各种线上bug突突的冒出来;线上bug一统计，fuck指标超过5-10%，开始全组上下静心反思，产生出版本重构迭代统一思想。

项目重构功能改善等统一口号就出现了，此时一般分两波人马，一拨人马继续业务迭代而另外一波人马进行项目重构;此事的核心就是减少线上bug数的量级，

完成公司要求线上bug不能超过3%的指标，这个时候重构重点基于线上bug进行维度分析，通过问题按多少进行划分，差不多这个时候的问题如下：

1. Bug的可视化实时监控和统计;
2. 引用内存未释放导致crash的bug;
3. 内存泄漏导致crash的bug;
4. 进入市场机型问题引起的bug;
5. 网络访问慢的反馈;
6. 奇葩未知的bug;
7. 。。。

• 问题1的思考，引入第三方系统，例如bugly等
• 问题2的思考，引入Eventbus解决回调地狱问题和回调引起泄漏未释放问题;
• 问题3的思考，引进LeakCanary内存泄漏检测，和prof分析大法根据各个问题进行突破;
• 问题4的思考，无解，能解决一个是一个，主要公司机型跟不上，可以通过网上机型提供商进行问题测试，贵不说而且感觉没啥用;
• 问题5的思考，略;

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

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

长叹一声，埋在心头的那个一个极大隐患和不安慢慢露出来，项目中依旧充斥代码各种耦合和混乱，加上‘混乱代码加上新代码依旧还是混乱代码’定理一直压着头顶上，这项目框架肯定无法跟上公司新业务线的发展和规划;有压力就有动力，深思熟虑后不知觉分层分模块架构慢慢浮现出来，每个业务线都是一个Module模块，接下来每来一个业务线就按照这模块模样复制粘贴一份接着开怼业务。一般这种情况需要持续到三个业务线后基本就会出现模块间混乱调用，资源文件各种重复且代码到处飞，加上权限控制不到从而每个人都有权限编写基础库从而使各个业务公共代码下沉到基础库导致庞大臃肿，多模块混合编译速度极度慢等不良问题一大堆冒出来，回过头看看项目现状，我去，，又来了，忙不完的事。看看图二如果你把自己当处女座，你肯定会发狂，要么炒老板鱿鱼要么静下心思考分析。

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

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

（编辑：青岛站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!