前言

从开发过程中使用的技术来划分,移动端的开发大致可以分为:

游戏 游戏这类应用比较特殊,考虑到开发成本的问题,大部分游戏都是使用的跨平台游戏开发引擎来开发的,比如Unity/Cocos3d之类的。其开发过程更多的是基于引擎的能力,也有少部分会利用到不同平台的特性。

专业应用 这类应用则更多的是利用移动端特有的能力,比如摄像头、重力感应器、加速度感应器、GPS等等能力,具有较强的平台差异性。

普通应用 这类应用更多的则像是一种服务接入窗口,提供服务的是后台庞大的服务系统,而这类应用负责接收用户的输入并展示服务的结果。有点像是早期大型机的终端。这一类应用的数量庞大,也让移动终端化身为个人数字助理。

今天主要聊聊这类应用的的一些特点。

数据,一起皆是数据

程序的世界里,一切都是数据。程序员写的代码是数据,用户信息也是数据,点击应用的按钮这一动作最终投射到程序里的还是数据(点击操作的数据)。不论何种应用,归根结底都是在处理各种数据。

移动端开发和后台开发,其处理数据的规模有着数量级上的差别。后台服务器需要处理的数据都是亿万级别,所以要求超高的数据处理速率和容错能力。由于单台服务器的能力有限,渐渐发展出了服务器集群,而支撑集群能力则需要各类分布式系统、调度系统、分布式存储和数据同步机制。

但是移动端的数据量则小得多,移动设备的处理能力足以应付,尤其是现在设备的CPU和内存越来越强、越来越大,数据处理这块的消耗基本可以忽略不计。尤其是现在多线程的概念已经深入人心,一个O(n²)和O(nLogn)的差异在数据规模只有1000乃至100时约等于无。

那么,对于移动端来说比较核心的是什么问题呢?

UI 流程

UI开发仿佛处于程序员鄙视链的最底层,然而离用户最近的却是UI。好的UI会给用户带来愉悦的感官享受,而最终能留住客户的则是对其核心需求的满足。核心需求的满足需要优秀的数据处理流程。UI让用户驻足,流程笼络留住用户。

UI是否美观?操作是否流畅?流程是否合理?从这几点观察,可以评论一个应用的好坏。但是大众的审美会变化,用户的需求也会逐步迁移,而流程的合理性更是不可能一步到位,需要不断的试探。凡此种种,导致了移动端应用的快速变化的特性,一月一个版本那是常态,一周一个版本也时而有之。

那么,从开发的角度来看,该如何应对这种快速变化呢?

开发

自从GoF提出设计模式,以及Java的三大框架问世。程序员们言必谈框架,语必称设计模式,仿佛不谈这些就不配当程序员。其实这两者也并无深奥之处,大部分设计模式都是实践经验的总结,有经验的程序员根本不必思索使用何种模式,而是自然的就能写出合适的代码来解决问题。其核心根本不过就是固定不变的,开放变化的。庞大的项目需要框架来做那些固定的不变的东西,而显然通过接口的封装正是处理复杂变化的手段。

这两者都是自然而然的东西,没必要拿出来炫耀,在没有具体场景时,更无任何谈论的价值。

但是现在却被滥用了。明明不适合抽离的被抽离出各种接口。接口的目的是为了不同的实现,但是很多接口却只有一种实现,而且也不会再出现第二种实现。这种滥用,导致复杂度暴增,各种虚类层出不穷,实在是移动开发的一大忌讳。然后传去出,其设计者反而沾沾自喜,自以为多懂设计模式。

私以为,移动开发中,诸如文件操作、网络、数据库等等业务明确且不会变动 的东西适合组装到框架里,这些属于基础架构,不参与业务。而对于业务的逻辑层,则适合抽离不同接口,提供相应实现,以便后续修改和扩展。对于直接面向用户的UI,则是越扁平越好,扁平化的UI结构,结合适当的组件化,一来可以快速构建UI,而且也利于后期的维护和修改,即便是换全新的UI,抛弃的成本也不会太大。