做一个 App 前需要考虑的几件事

标签: app | 发表时间:2016-07-06 00:00 | 作者:
分享到:
出处:http://limboy.me/

随着工具链的完善,语言的升级以及各种优质教程的涌现,做一个 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 会花费些时间,但跟收益相比还是值得的。


以上这些点是在感受不过不同量级的 App 开发后整理的,肯定还会有疏漏,不过如果真能做到这些,就已经很不错了,至少当有新人进来时,不会背上沉重的「历史包袱」。

相关 [app] 推荐:

App 和 iCloud

- 笑炊 - 爱范儿 · Beats of Bits
iCloud 的技术细节还在 NDA 的保护下. 但是大家的好奇心不能等到 NDA 失效再满足. 本文基于对 iCloud 的猜测写成,靠谱与否,等待时间检验. 打开浏览器,嗯,今天用 Safari , Chrome , IE 或者 Firefox. 输入 Twiter.com ,啊,不对,是 Twitter.com.

App Internet 革命

- Cary - Mr. Jamie 看網路與創投
Apple 公布最新一季的財報,3 個月賣出了破紀錄的 3,500 萬台 iDevices (iPhone, iPad & iPods). Google 公布最新數字,全球有 1.9 億支 Android 已經被啟用. 大家很興奮「智慧型手機」、「行動裝置」革命終於來到,我卻隱隱感覺到另一件更重大的事情正在發生,我們所熟知的「網路」,即將經歷另一次大幅度的轉變.

Mobile App 将死?!

- - Tech2IPO
日前,Mozilla 产品副总监 Jay Sullivan 称移动应用不久即将成为历史,未来将是移动 Web 应用的天下. 光盘好歹还能当杯垫,可怜 Mobile App,难道就这样一下跌落进历史的垃圾堆. Mozilla 的产品副总监杰 • 沙利文 (Jay Sullivan, 上图) 日前表示,移动终端应用(Mobile App)没有未来,真正有前途的是移动 Web 应用(Mobile Web App).

浅析App Engine

- - 搜索研发部官方博客
在国内外,云计算正在大步的走向商业化的道路,也得到了越来越多公司的重视. 其中平台即服务(Platform-as-a-Service  PaaS)已经称为业界探讨云计算的热点方式之一,采用PaaS模式来构建应用运行平台App Engine是一种重要的实现方式. 本文主要是对App Engine的背景、特点、需求等进行分析整理,并据此对业界主要的App Engine进行了调研分析.

APP已死?

- - 商业不靠谱
APP目前面临的几大窘境将促使搜索引擎由Search向Service、Getting 转变以适应用户在APP时代养成的简洁、高效等习惯. 《未来移动终端应用 C/S Vs B/S 架构》 许永硕——物联网智库. 参照PC软件的发展历程,B/S架构或许是破解APP难题的出路,目前,微信开放平台、手机QQ等在尝试扮演Browser(http://open.weixin.qq.com).

欺诈 app 追杀 — 给 App Store 的信

- Webto - Wangling
感谢 @apple4us 的建议. 我深知如果等着别人相助,此事大概会不了了之,届时只徒留一篇愤概文章. 所谓“追杀”,敌未死,我未停,正如给“动车追尾”事件的受害人追讨公道,公道未到,追讨不止. 于是,我刚给 App Store 发了信,如下:. 每人干掉一个坏蛋…,坏蛋没那么多;每一百个人、每一千个人、甚至每一万个人干掉一个坏蛋,世界都会美好许多.

Web App和Native App 谁将是未来

- - 互联网旁观者
未来是Web App的天下,还是Native App的天下. 作为设计师,我们是应该努力把客户端的体验提升到最优,还是在网页应用层面上做更多的设计. 那么,我们首先应该立体的认识一下Web App和Native App. Web 无需安装,对设备碎片化的适应能力优于App,它只需要通过XHTML、CSS和JavaScript就可以在任意移动浏览器中执行.

Blogger也有App了!

- 幻幽 or A書 - Jas9 Taipei.
感覺上,彷彿自從Google+推出之後,所有Google的既有產品服務都積極活動了起來. 繼上週Blogger的新後台從Draft轉到正式版更新上線之後,Google終於也推出期待多時的官方版本Blogger App.

创建Chrome Web app

- Hobbes - Marshal's Blog
编写了一个Chrome下使用的Web app. 点击这个应用,就可访问我的博客. 其实有它特殊的好处,直接访问网站,程序无法自动获取HTML5的权限,比如存储限制. 安装应用,相当于安装了一个配置文件,浏览器将打开必要的权限. 如果你也使用Chrome,可以通过这里下载安装. 开发这样的应用并不难,过程类似以前开发Chrome扩展(编写最简单的chrome扩展).

iOS Web App初步

- - 新浪UED
iOS Web App开发,配合HTML5,是目前比较热门的话题. 今天,先抛开HTML5,我们来尝试在PhoneGap框架上进行简单的开发. PhoneGap是一个使用HTML,CSS和JavaScript的,创建移动跨平台移动应用程序的快速开发平台. 它使开发者能够利用iPhone,Android,Palm,Symbian,WP7,Bada和Blackberry等智能手机的核心功能——包括地理定位,加速器,联系人,声音和振动等,此外PhoneGap拥有丰富的插件,可以以此扩展无限的功能.