关于安卓系统app怎么更新，你需要知道这些如何维护、升级Android老项目？

背景

大多数情况下，我们需要从前任那里继承老项目，运气好的话，可以从前任那里得到完整的产品PRD、功能说明书、代码模块说明、主要类说明、详细注释等。

但是，大多数时候只能拿到一份读起来恶心、看起来想吐的源代码，其他什么都没有。在这份源码中各种三方依赖满天飞、版本管理混乱、环境配置信息隐藏在代码中，AK到处随意定义......
在处于上诉后者这种情况下，我们如果不做点什么，那后续接入的需求就会呈现出本身已经是一坨粑粑了，我们还要继续炒这坨粑粑，炒完了我们自己还要吃下去，你说恶不恶心人？

一、分析问题、梳理项目功能拓扑图

我们可以通过以下手段来进行梳理项目功能

1. 通过现有文档、源码整理项目功能点。
2. 通过同事、业务部门、关键用户等收集信息。
3. 借助Xmind、ProcessOn等工具梳理项目功能图、关键节点流程图等。
4. 以表格的形式来统计各个模块使用的第三方依赖、JAR、SO等情况。
5. 根据项目情况把糅杂在一起的业务功能剥离、抽成不同的业务组件。

下面就我对某APP的功能整理、问题梳理等做一个展示，提供给大家参考：

某APP功能拓扑图

登录流程图

某APP问题一览表

二、制定详细的升级计划、预备方案

因为在升级项目的过程中难免会出现一些未知的、不可控的问题，所以在升级之前必须制定详细的升级计划，哪个时间节点该做什么，出现问题如何补救，是否遗留了未完成的bug，提前打好TODO，做好说明。

升级流程表(节选)

遗留问题记录

三、升级结束留档

当我们完成了某个功能的升级我们需要以文档的形式记录下来，一来是方便继任者维护，二来呢也算是提高自身的职业素养。

模块说明表

关键类说明

在每个模块下撰写README说明该模块的在主要功能，已经JAR包说明等

模块说明README

结语

升级老项目是一个繁琐且持续周期较长的一个过程，需要提前做好长期作战的心理准备。而且这个项工作对于业务部门、KPI、管理者来说是比较虚的，他们是看不到的，所以各位小伙伴在做这之前需要根据自身的场景去评估究竟有没有做的必要性、以及它给你带来的风险等情况。

推荐阅读

Android组件化框架搭建

搭建属于自己的Android MVP 框架