西安尚学堂安卓培训专家：做App 前要考虑的几件事

随着工具链的完善，语言的升级以及各种优质教程的涌现，做一个App的成本也越来越低了。尽管如此，有些事情最好前期就做起来，避免当App有了一定规模后，再感慨当初为什么没有多留点心。

完善的日志系统

以iOS为例，有时图方便，就直接用NSLog了，甚至线上都一直开着。一方面会影响性能，尤其是输出比较频繁的时候，另一方面也容易泄露敏感信息，所以一般做法是在Release模式下禁用NSLog，比如在pch文件中，通过对环境的判断，对NSLog做不同的处理。

但这样仍会有问题，比如我们发现线上的App在特定场景下会有某种异常的表现，这时就很希望能有日志来提供更多的信息。可以考虑使用像cocoalumberjack这样功能更完善的第三方日志工具，在线上仍然开着日志，但不消费，这样就不会泄露敏感信息。当我们需要看日志时，可以通过“调试模式”打开它，然后连上iOS Console来看。

因为Log是一个很普遍的行为，所以最好前期就规范起来，后期遍地都是NSLog时，再要改动会有点麻烦，当然也可以偷懒点，直接把NSLog的宏定义改了。

Commit Message 规范

在前期开发的时候，往往为了快速实现功能，而忽略了Commit Message的规范，然后就会出现很随意的Commit信息。这样别人在Review代码时就会很累，写某个版本的Release Notes也会变得艰辛，甚至过一段时间自己都不知道这些Commit代表的意思。而如果自己也讲不清这次改动究竟该怎么描述时，往往是这次改动混杂了较多的信息。

这篇文章简洁精确地描述了为什么要写好Commit Message，以及如何写。遵守这些规范后，就很方便产出这样的Release Notes了。

代码规范

这个最好在前期就抓起来，如果前期不做约束，每个人的风格往往会有比较大的差异，导致代码看起来会比较累，甚至有些人是从其他语言转过来的，还会保留之前语言的一些书写习惯，就容易有“出戏”的感觉。一致的代码规范不仅看起来舒服，而且让团队更像一个整体。

这个实施起来会有一定难度，尤其是团队中有一些“老人”的时候，他们往往积累了一套自己的编程习惯，而且不容易被说服。

准备一份编程守则

里面包含了“最佳实践”和“不要踩的坑”，这个可以一定程度上提高开发效率，避免一些低级错误。比如以iOS为例，“不要随便使用通知”，因为通知使用起来太方便了，用得多了调试起来就会很累，而且也不好管理;“通知用完之后记得remove observer”;不要使用containsString (如果还需要支持iOS 7 的话)。随着时间的累积，这份守则里的内容会越来越多，也是一件挺宝贵的财富。

页面布局规范

这个在Android相对还好，基本都是通过xml来进行布局。在iOS里玩法就多了，有用storyboard的，有用xib的，有直接计算坐标和大小的，有用原生autolayout的，有用第三方布局类的。总之就是各显神通，尽量用同一种布局规范(但不建议直接计算坐标和大小)，看起来也会方便些。

统计埋点

这是很重要的一块，客户端所有的数据基本就靠它了，所以尽量选择一个灵活、稳定的数据方案，同时最好在他们提供的SDK上再封一层，方便做一些额外的事情(比如想同时接入另一家服务作对比)。

统计埋点还有很重要的一点是“验证”，是否有错打、漏打等现象;iOS / Android是否有用同一个点;有些点还需要额外的参数，这些参数的格式是否正确等。这些工具往往只能自己来做了，这也是比较花时间的一部分。

App 架构

App架构会随着业务、人员的增长而演进，所以当发现当前的架构无法满足日常的业务迭代时，就需要考虑对它做调整了。一般来说，大方向上也就是MVP / MVVM，等人员多起来时，基本就是组件化开发，当然组件化也会有它的问题(比如资源/类重用、组件间通信等)，这里就不展开了。

在前期选择一个相对轻量级，但比较清晰的架构(尽量不要选择MVC)，大家都遵守这个架构开发，也能一定程度上提高效率。

页面跳转机制

虽然Android、iOS都原生支持open特定scheme的url，不过可能的话，还是通过router统一处理会比较方便，也更灵活。比如可以知道注册了哪些URL;可以知道页面的跳转成功率;方便处理一些奇奇怪怪的需求等。

在线配置

在线配置可以赋予App极大的灵活性，比如运营的一些活动、banner位调整、首页弹窗等;还可以针对特定机型、系统分发特定的内容，结合规则引擎甚至可以给一部分有相同特征的用户发推送;可以做流量切分等。所以一个强大/稳定的配置中心就显得尤为重要，A/B Test也可以基于配置中心来做。

这里有些注意事项，因为不少配置的值是运营填的，她们对value不那么敏感，所以会出现value为空，或者不是想要的类型，或者配了张图片，但是体积超大等，有可能造成客户端crash / OOM等异常表现，所以客户端要有足够强大的容错能力。

选择合适的Crash平台

Crash会给用户造成极大的负面体验，所以需要经常关注Crash情况，尤其是刚发版的那段时间。这块fabric做的比较好，只是由于是国外的服务，会有些许数据上的丢失，不过问题倒也不是很大，也可以考虑国内的一些服务，如bugly，毕竟腾讯自己也在用。

Code Review

这也是容易忽视的一点，当业务需求压过来时，先把功能实现了再说，而且在初期往往人手也不够，抽不出时间来做Code Review。如果是这样的话，可以先Review一些核心的点，保证重要的代码是经过Review的，不太重要的业务代码可以先放放，等人员充足后再覆盖更大的范围。

Code Review的主要作用是保障代码质量，同时促进双方成长，一个担心点是质量偏低的代码比例如果较大的话，会影响开发者的心情，增加维护成本，日积月累就成了重重的“历史包袱”。

选择合适的开发模式

如果是使用git来做源码管理的话，可以采用flow模式，基本能满足大部分的需求，而且不少git工具也内置了flow的支持。这样当需要处理feature / hotfix / 发版等场景时，就会很方便。

持续集成

持续集成的目的是让产品在快速迭代的过程中还能保证质量，当有错误发生时，可以第一时间被检查出来，方便修复。如果想偷懒的话，可以直接使用成熟的服务，如travis，也可以自己基于Jenkins来搭，iOS的话，配合fastlane效果会更好。自己搭的好处是灵活度更大，可以加入一些个性化需求。

如果有打包平台的话，还可以定时出一个包，这样当发现某个功能使用起来有问题，代码上又没什么头绪时，可以对比以前的包来定位。

Bug 管理系统

这个Bug包括测试阶段和线上的Bug，Bug管理工具有很多，使用在线服务或自己搭都可以，但要有，不然很有可能忘了还有哪些问题需要修复，哪些已经修复了。

项目管理工具

在App开发初期，人员较少，沟通起来比较方便，所以很多需求当面就说了，一些原型/设计图可能也是直接AirDrop过来的，这样效率自然高，但不便管理。比如没有prd，产品、开发的理解可能不一致，到头来发现做的不是产品想要的，或者一些细节不符合要求;设计图有更新，但没有同步到所有的开发;需求有变更，但当时在专心做某个feature，可能就忘了，或者没有理解全面等。所以最好还是有一个项目管理工具来统一处理，再结合敏捷开发，项目的质量和进度就容易得到保障。

Checklist

一个App发布上线之后，要保证不出大的问题，就要在发布之前，先检查一下“一定不能出问题”的点是否正常，就像飞机起飞之前一定会走一遍checklist一样。比如推送是否正常、log是否关闭、组件版本是否正确等，随着App功能的增加，这个list也会越来越长，虽然过一遍checklist会花费些时间，但跟收益相比还是值得的。