app开发具备清晰的逻辑架构和思维，开发者的价值，是通过技术和产品体现的，对于西安App开发来说，除了实现业务之外，最重要的莫过于开发的速度、质量和可维护性，速度决定你能否支撑公司抢占市场，质量决定你们能不能站稳位置不被迅速踢走，可维护性决定你们继续前行时能否保持轻快的步伐。速度、质量和可维护性,对速度、质量和可维护性的要求，其实就是又快，又稳，又清晰的要求。快：快其实是最容易做到，或者说最容易知道能不能做到的事情，熟悉的Android开发的朋友都知道，如果能理清业务逻辑，不受干扰地投入开发，开发速度可以很快，一般普通规模的App，一到两周就能完成。稳：稳不像快，可以简单地用时间进行即时的量化评价，我们要等大量bug出现之后，才知道稳不稳，可是一般赶工速度一快起来，就很容易出现大量bug。其实Android常见问题无非是内存、异步、响应等，要排除和解决这些问题很容易，难的是怎样确保不出现这些问题。清晰：清晰是最难做到的，快可以通过时间量化，稳可以通过bug统计量化，但是清晰是很难量化的，代码审查和可扩展性都是主观评价，而且相当滞后，很多情况下，往往要等到需要实现扩展，甚至换人接手代码时，才知道代码不清晰。
对于开发者来说，怎样才能又快又稳又清晰地开发App，这里梳理了我的几点心得。
有限参与业务设计
从职责分工上，业务设计是运营部门和产品经理的工作，确实不应由研发负责，但我说的是参与，研发（包括测试）应当尽早参与业务设计，一方面提前发现问题，另一方面可以引导和建议技术路线。
研发参与设计，可以规避很多问题，例如通信压力、加载速度、延迟时间、硬件负载等移动开发特有问题，不能指望运营和产品能像专业的研发一样面面俱到，考虑周翔。另一方面，研发参与设计还可以引导技术路线，例如采用原生App、混合App还是ReactNative形式，采用单用户体系还是多用户体系，采用什么收费形式等。
在实际操作中，业务设计诸如收费形式，异常提示，乃至于业务逻辑上的严密性，你都可能发现漏洞。
当然，参与设计必然会占用研发时间，有人会觉得委屈，感觉这是替产品做了他们的工作，但其实研发参与设计，省下的还是自己的时间，因为无论产品如何设计，最终都需要技术来研发实现，如果设计上出了问题，你修改代码的投入，可比产品改文档的那点儿投入大多了。
当然，公司层面也应有清楚的定位，研发对设计的投入，必须是有限的指导性的，如果大量把研发投入到设计工作，就是另一种形式的浪费了。
异常处理
在实际开发过程中，除bug其实占了相当一部分工作量，有时候好好的开发计划，因为几个诡异的bug就得耽误半天，所谓“码字5分钟，排错两小时”是也。所以，能否尽早尽快处理异常，是非常影响开发效率的。
处理异常，我有这么几条心得：
提前考虑异常处理，在写正常流程的业务代码之前，先考虑异常，“未虑胜，先虑败”，沿着业务流程分支，先把异常情况都处理掉，例如获取在线数据显示一个列表，先考虑网络异常、服务器报错、数据失败等异常情况，并依次给出相应提示，最后才处理数据正常的情况，你本来就要写正常业务代码和异常处理代码，你只需要调换一下工作的先后顺序，其实你投入的开发时间没有增加，但是你的效率却大大提升了，因为一旦出现异常，我们可以迅速判断异常原因，节省大量时间。
这样做还有一个好处，在你的思维陷入复杂的业务逻辑之前，先处理相对简单的异常分支，可以避免你被业务逻辑搞到大脑缺氧后，再回来处理异常分支时一时疏忽手滑，写错或者写漏异常处理。
隔离前后台对接的数据接口，最好不要直接使用后台提供的数据，中间加一层映射，一方面，如果后台数据出了问题（数据异常、变更字段等），你在映射数据时就能发现和定位问题；另一方面，也有利于你采用更适合App的数据形式进行数据持久化。
另外，建议做一个接口录入与检查工具，形式不论，但要能轻松地维护前后台接口，最好能自动检测接口反馈是否正常（服务器负载过大、字段变更、第三方服务过期等）。
异常信息的收集、汇总和数据持久化
如果出现异常，最重要的是采集到异常代码行(如MainActivity第61行)和异常原因(如空指针异常)，并记录为本地文件以备上传和查看，具体见：
结构分层
使用框架是必须的，Model层，View层必须职责单一，至于使用MVP、MVVM还是别的什么就看个人偏好和项目需要了。
个人比较偏好MVP，感兴趣可以看一看MVP框架的演化，当然，Rx链式编程也不错。
个人在结构分层上，有这么几个经验：
高内聚的数据层，把与数据读写相关的处理，网络读写、本地读写、缓存数据等，包括模拟数据，都集中到数据层，通过回调或链式调用等方式抛出数据给业务层，通过多版本机制切换模拟数据和真实数据。
松耦合的Activity，界面应该是与业务相关最低的，主要提供一个显示载体，并触发生命周期处理，Activity应该可以很容易地被替换掉。
独立且方便测试的业务层，业务层应该可以实现自动化测试，这非常重要，即使你不去实施自动化测试，把代码写成可以自动化测试的，也能帮你优化代码，该抽象的抽象，该剥离的剥离。
必要时抽象特殊控件，如果控件需要复用，就不要让控件融合进Activity，而是抽象为独立的显示控件，这样既能解耦合，又方便复用。
不要过度设计
敏捷开发里有一个实践原则，就是不要过度设计，开发的价值不在于写出漂亮的代码，在于实现产品并支撑其正常运转，在能实现产品功能的前提下，代码逻辑其实是越简单越好，简单往往就意味着高可靠性+低维护成本，如果将来需要扩展功能，可以通过修改和重构实现。
当然，简单并不意味着随意，要把事件做复杂很容易，要做简单却很难。能做到逻辑清晰、线程安全、内存安全，又容易修改和扩展的同时，还能保持代码简洁，其实反而更考验功力的。
其实不仅在开发新功能时要避免过度设计，在维护和扩展旧代码时，也要注意，能正常运行的代码，都是好代码，我觉得在维护旧代码时，其实也适用开放封闭原则，对不得不改，不改就崩的旧代码，是开放的，可以修改的；对能正常运行的代码，哪怕你觉得再难看再手痒，那也是封闭的，是不可以修改的。
回到那句话，开发的价值不在于写出漂亮的代码，在于实现产品并支撑其正常运转。
通用库的建立与维护
我们知道，项目管理有四个要素，时间、成本、范围、质量，这四个要素一般是不能兼得的，要时间，就得砍一些范围的项目目标，降成本，就容易牺牲质量，等等，不过，建立和维护通用库，却能同时对四个要素都有好处。
加快开发速度，专注于具体业务（时间）
降低团队成员熟悉项目的成本，为新业务开发提供基础，加快开发迭代速度，有利于更快地发布版本
提高代码复用率，降低开发投入（成本）
稳定的公共模块采用依赖组件库方式，提供给各个业务线协作使用，减少重复开发和升级维护工作量
提升开发效率，更容易实现项目目标（范围）
对已实现过的功能/业务，抽象出通用模块，再有类似的需求，能够迅速实现，更容易实现项目的业务需求
提升产品质量，持续改进通用功能（质量）
频繁使用的功能/业务模块采用组件复用方式，更有利于暴露缺陷，一处修改，多处受益，提高产品质量
代码注释
一般来说，程序员看自己一个月前写的代码，是完全陌生的，我也一样，基本上过一个月就没印象了，但是如果要修改/扩展怎么办，这时候，就得看代码注释了。
就个人经验而言，有这么几个地方，一定要写注释：
接口，特别是MVP的Contract接口，这里面基本定义了你的主要业务行为，谁来加载数据，谁来显示数据，谁触发的下一步操作，这些内容写明白了，以后读代码，只要看接口就知道主要业务是怎么回事儿了。
服务、广播等，服务和广播因为没有界面，容易游离在业务逻辑链条之外，在业务逻辑上缺少上下文，就必须有详尽的注释，说明其业务场景。初始化、注入等，如果自定义了一些扩展的功能或控件，要求执行某些初始化函数，或者要注入特定功能的，就必须写好注释，提示调用者进行必要的操作。
