APP 研发中的若干注意事项

今年参与了一个全新 APP 的开发，本身也是一个学习成长的过程，本文会总结在研发期间一些需要注意的事项，想和大家一起交流学习下。

编码规范

• 如果是要开发一个全新的 APP，团队也很可能是全新组建的，团队的技术负责人就会建立各种各样的规范，一般他会根据他以前的工作经验来制定，或者是使用其他兄弟团队的现成规范。
• 作为一个新团队，规范制定是必需的，但实际情况是业务压力非常巨大，规范会很难落实，规范很容易会流于形式，也就是规范只是一份说明文档。在所有规范中，有一个最重要的规范，就是编码规范，相对来说是比较容易落实的，只要提供相应的 Lint 工具即可，这件事情建议提到最高优先级来做。
• 另外，像代码提交规范，也非常重要，建议趁早编写 Lint 脚本。

版本号

• 版本号，遵循 semver 规范 。开发重大功能时升级主版本号，日常版本使用次版本号，修订号用来修复线上问题。

版本发布

• 发版之前，安卓会进行为期数天的灰度，主要是查看崩溃率和兼容性问题，等问题都修复后再全量投放市场，QA会通知负责应用市场关系的运营同事，替换各大应用市场中的安装包。
• iOS由于苹果机制的特殊性，需要先提审，同时可以根据QA要求打出TF包发给内测人员进行测试，初审通过后，也可以再修复一些小问题，最后再提交正式版本。
• 注意，发版工作流程较长且固定，大公司一般都会研发效率平台支持发版工作，操作者可以是QA也可以是研发。
• 在规划版本时，需要避开国内外的节假日，一般都会提前停止审核工作，我们需要提前收集各个应用市场的规章制度。当然，公司内部也会有相应的制度，比如因要保障重大产品运营活动可能会封网等等。

版本修正

• 版本上线后，线上问题无法避免，线上问题优先级较高需要及时修复。安卓和iOS都需要重新走发布流程，但安卓的主要应用市场在国内，审核时间会比较快。

版本试验

• 有时我们需要测试一些功能是否实现正确，一般是技术方面的，比如底层SDK升级，因为影响范围大，直接跟着业务功能版本发布的话风险比较大。此时可以找某个特定的应用市场渠道，替换成升级SDK后的包，这样也能收集到一些必要的信息，如APP性能、崩溃率等等，为后续的技术决策做好准备。

能力预埋

• APP开发不同于Web页面开发，一个APP版本发布出去了，里面的代码再也无法改动。所以，APP开发中，需要考虑一个很重要的问题：如何兼容老版本APP？如果想让将来上线的功能在APP中能毫无顾虑地使用，也就是不用考虑老版本APP的问题，那么这项功能需要提前实现好，等到老版本的使用量已经少到可以忽略不计的时候，就可以使用之前预埋好的能力了。
• 举个例子，假设某个APP能接收服务端的很多种消息类型，根据不同的消息类型展示不同的文案，如果消息类型不识别，简单粗暴的做法是提示“该消息类型不识别，请升级新版本”。如果我们预先实现了类似消息模板（即消息中的部分内容是可以通过插值替换）的能力，那么老版本上的消息提示文案就可以显示为“最新版本APP新上线了XXX功能，快来点击升级吧”，提升了用户升级新版本的动力。

两端方案对齐

• iOS和安卓，一般都会保持功能的一致性，所以两端的技术方案需要对齐。在业务迭代中，技术方案由一端来出，出方案的同学要和另外端的同学做好充分的沟通，保证技术方案的一致性。
• 由于两端的编程语言不一样，安卓是Java或者Kotlin，iOS是OC或者Swift，这会导致技术方案的实现细节会有出入，这是需要权衡的。我个人的意见是技术实现原理两端须一致，并且都要保证可扩展性，实现细节允许存在差异。

网络问题排查

• 网络是APP的一个错综复杂的大问题，用户的网络环境差异，网络相关的硬件配置等等，在日常开发中都是很难遇到的。所以在排查网络问题时，IP代理工具是必须的，它可以将手机代理到指定区域的运营商。
• Web APM 也是一款必需的工具平台，它可以查看用户的网络状况，失败的网络请求等等。
• iOS用户首次安装APP时，可能没有正确设置网络权限。

行为日志和埋点

• 行为指的是用户使用APP的操作行为，可以通过自动化的页面曝光埋点，记录用户的操作路径。这是一项基础能力，大厂都具备。
• 行为日志，还可以将客户端发生的错误通过日志上传，提升线上问题的排查效率。不然只看用户反馈的现象，有时是很难解决问题的。
• 行为日志其实是一项很通用的技术基础建设，收集上来的日志数据可以用于大数据分析，产品可以做AB测试，数据结果也可以运用到推荐算法中。

应用日志

• 行为日志只记录用户的操作行为，但很多时候排查技术问题，光靠行为日志是远远不够的，最有用的日志还是应用本身打的日志，包括应用本身、三方、二方等SDK打的日志。
• 应用日志保存在用户本地，所以还需要通过某些方式将用户本地的日志上传到服务器上来，比如可以在反馈页面，通过开关，让用户选择上传本地的应用日志。

自助查询平台

• 在研发新APP时，尤其是刚上线的时候，会遇到很多客诉问题，相关的运营平台还没建设起来，一般查数据都是直接查数据库，效率很低，而且数据库权限也不是团队所有人都有。
• 在研发过程中，QA、研发、客户端等等都需要经常查询数据。
• 所以，研发一个自助查询平台是非常有必要的，可以节省团队非常多的宝贵时间。自助查询平台要提供什么功能，可以通过问询收集，按优先级排入开发，积极的同学可以利用业余时间去做，但建议一些重要的功能排入迭代版本，保证能尽早落地。

数据分析

• 数据分析一般由专门的部门负责，是一门大学问。数据来源有用户的设备信息、行为日志、API调用等等。
• 数据分析的方法及准确性，可以说是现代APP成败的关键之一了。

推荐算法

• 如果要推荐的数据池很大，此时靠普通的代码实现是不行的，需要专门引入针对海量数据的推荐算法，这个一般也是由专门的负责。
• 做推荐算法的同学可能不理解业务，此时业务方一定要有专人和算法同学保持沟通，解释业务，验证算法实现的正确性等等。

反垃圾

• 反垃圾指对涉黄、涉政、暴恐、恶心等等UGC内容进行过滤，保证这些垃圾内容不会出现在APP中，不管国内外，这都是共识。一般由专门的部门负责。

反作弊

• 反作弊，指将一些黑产团伙识别出来后进行封禁等操作。一般在有奖品的运营活动中要特别注意，不要被黑产薅了羊毛。一般由专门的部门负责。

业务和技术的平衡

• 随着业务的快速发展，前期的一些技术方案可能已经出现了短板，扩展困难，所以势必会出现一些急需解决的技术问题，还有诸如底层SDK升级等技术任务。
• 技术需求也要排入到正常的业务迭代中，因为这些技术需求也和APP息息相关，QA也要介入测试，不然很难保障落地。技术需求和业务需求可以按照优先级来PK。

其他

• 在大公司内部做一个APP，会依赖很多内部团队，比如客户端公技、服务端公技、技术中台、业务中台等等，这些团队有自己的迭代排期，业务方的排期要和这些团队保持一致。
• 要多和兄弟团队保持沟通，搞好关系，利用他们提供的能力，同时也要帮助他们去完善能力，比如通过抽象业务功能，将需求提给他们。
• 除了部门内容的兄弟团队，在大公司里面，还会和跨一级部门的团队进行合作，建议和他们要定期沟通，将业务发展情况同步给他们，让他们在重点业务上多投入资源。