By

本文档定义了我司移动端对第三方公司开发APP项目的流程规范，主要是基于项目的研发流程进行规范：从UI（UE）设计、移动端开发、后台开发和测试这四个环节我司进行了规范。规范包括我司提出的要求和建议，也包括我司可以提供的服务和支持。
本文档的预期读者包括：我司和第三方公司的设计（UI）人员、开发人员及测试人员。

统一的账号

  • 邮箱账号【暂时负责人各自申请】
  • 手机号码【NA】
  • 支付宝
  • 微信

UI/UED规范

效果图规范

效果图统一标注，各个移动端平台用一个主流分辨率进行标注，减少工作量，也方便统一管理。

  • Android用1080P分辨率进行坐标、配色的标注。
  • IOS用3倍屏（6Plus）进行坐标、配色的标注。

切图规范

Android尽量只是一套切图，减少资源包大小。

  • Android用1080P分辨率尺寸进行图片组件切图。
  • IOS2倍屏、3倍屏均切。

公共组件规范

我司UI设计提供公共组件：加载框、提示框、弹出窗、标题、底部栏、列表为空的显示，列表上下拉的显示等。

颜色值规范

颜色值统一罗列，方便管理。

像素值规范

效果图里面的像素值统一用dp或者pt表示。

测试规范

测试用例

  • 普通测试用例（后台和客户端）
  • 关键测试用例（后台和客户端）

Monkey测试

NA

测试报告

NA

BUG提交

【问题描述】：
【预期结果】：
【实际结果】：
【复现路径】：【NA】
【测试用例号】：

代码规范

Android签名统一管理

代码规范

  • Android代码规范
  • IOS代码规范

单元测试

NA

代码review

项目开发期间每个星期进行1次代码review，发现的问题单要记录归档，提交服务器。并且问题单要在下一次代码review前解决。

版本提测

  • 版本提交测试的时候必须要跑通《测试用例》
  • 版本名字符合规范：aorise-[项目名字]-[版本号]-[日期]-[类型].后缀

    　Eg: aorise-education-v1.0.0-20160921-release.apk

代码静态检查

  • Android的检查工具：findbugs、lint
  • IOS：NA

代码混淆

NA

BUG修复

【问题单号】：
【原因分析】：
【解决方案】：

Android规范

开发环境规范

统一开发工具和开发环境。

  • Android Studiio 2.3.1
  • Java 8
  • Gradle2.3.1(Android Studiio 2.3.1 默认配置即可)

启动页规范

APP的桌面icon，启动页图片，登录（注册）模块要统一。

  • APP桌面的Icon图片，显示文字我司提供。
  • 启动页我司提供720P分辨率的背景图片。
  • 登录（注册）—— 预留接口或者配置，以后可以统一接入我司SDK。

包名规范

我司域名反写+项目名字，项目名字我司会提供。例如cn.aorise.[项目名字: platform | education | petition]。具体项目名字见附录表一。

Res资源规范

Res资源文件夹里面的全部文件名字和资源ID加项目名字做前缀。理论上所有颜色值，像素值，字符串等资源全部提取到res文件中，也要加项目前缀。

  • drawable文件夹里面的全部文件名字加项目前缀。
  • anim文件夹里面的全部文件名字加项目前缀。
  • layout文件夹里面的全部文件名字加项目前缀。
  • values文件夹里面的全部文件colors,demens,interger,strings,styles等全部资源ID加项目前缀。

Assets和Raw资源规范

assets和raw里面的全部文件名字加项目前缀。

数据库名字规范

移动端项目里面如果用到本地数据库，数据库的名字一定要加项目前缀：项目.db或者项目-xxx.db。

依赖规范

第三方数据库，网络图片显示和网络请求等外部依赖我司可以提供SDK提供调用（或者我们提供第三方依赖的版本）。

包结构规范

采用我司提供的sample样例结构，方便我司后期维护和整合。

开发规范

采用我司提供的sample样例框架，方便我司后期维护和整合。

  • Activity继承BaseActivity
  • Fragment继承BaseFragment
  • 列表页面继承BaseListActivity
  • Webview页面继承BaseWebActivity
  • 还有统一的toolbar,dialog等相关处理，具体参考sdk里面的sample样例。

DataBinding开启规范

Android Studiio开启dataBinding支持，不一定要支持MVVM开发模式，起码通过dataBinding模式找view，不需要通过findViewById写大量的view成员变量。

IOS规范

开发环境规范

统一开发工具和开发环境

  • objective-c
  • Xcode 8.2.1 （必须用最新的正式版）适配最新ios系统

启动页规范

APP的桌面icon，启动页图片，登录（注册）模块要统一。

  • APP桌面的Icon图片，显示文字我司提供。
  • 启动页根据最大屏（目前5.7）提供。
  • 登录（注册）—— 预留接口或者配置，以后可以统一接入我司SDK。

包名规范

BundleID统一用我司域名反写+项目名字例如cn.aorise.[项目名字: platform | education | petition]。具体项目名字见附录表一。

Assets资源规范

为了方便管理控制，一般的ios端的所有图片资源全部存放于Assets文件中，为了规范命名，推荐以下命名方式:模块前缀加上项目。

Bundle资源规范

除了图片资源，一些工程里面需要用到的其他资源文件 、Xib和Storyboard文件全部存放于Bundle文件里面，方便后期项目打包成库，命名也必须加上前缀。

Eg：EDUMainViewController.storyboard。

数据库名字规范

不管是用苹果自带的数据库CoreData也好，还是其他第三方数据库FMDB、Realm等等，为了保证项目与项目之间的唯一，也必须加上前缀。

依赖规范

第三方数据库，网络图片显示和网络请求等外部依赖我司可以提供SDK提供调用（或者我们提供第三方依赖的版本）。

开发规范

采用我司提供的ios版样例框架，方便我司后期维护和整合。为了以后app项目合并，我司做法是把app打包成FrameWork库，资源文件打包成Bundle文件这种形式快速整合。为保统一，外包的第三方app也必须按照这种方式来。
IOS Deployment Target 必须保持一致（目前8.0）。

后台规范

接口文档规范

接口文档清楚完整，有详细的入参和出参描述，并且每个接口附带有请求和响应的完整输入和输出用例。

{
  "code": 1,
  "msg": "success",
  "data": null
}

统一登录接口规范

登录接口的入参和出参描述。
入参：账号，密码（游客登录，第三方账号登录等）
出参：

{
  "code": 1,
  "msg": "success",
  "data": {
    "account": "XX平台",
    "id": "431125201702133114",
    "sex": "男"
  }
}

推送规范

APP推送统一采用个推。

桩数据建议

提供每一个接口请求的完整桩数据。

风险

65536限制（Android）

Android应用程序（APK）在Dalvik可执行文件的形式包含可执行的字节码文件（DEX）文件，其中包含已编译的代码来运行你的应用程序。Dalvik可执行规格限制一个Dex文件包含65536个方法：包括Android框架方法、Library方法的总数、和你自己的代码方法总数。因为65536等于64×1024，这一限制被称为“64k引用限制”。

目前有一些解决方案（不过都有一定的风险）：

  • 代码混淆（技术难度大，工作量大，尤其还有混淆第三方项目）。
  • 设置multiDexEnable（android4.0以下版本可能不支持，某些第三方库可能有问题）。

数据库版本限制（Android/IOS）

Android应用程序使用的使用的本地数据库必须要统一，否则可能出现问题。本来各个APP使用任意第三方数据库都没有问题。不过如果以后我们要把各个APP整合到平台APP里面，就必须提前规范第三方公司采用的第三方数据库版本。

目前规范的数据库版本：

  • Android第三方数据库版本是：org.greenrobot:greendao:3.2.0
  • IOS用自带的数据库coreData(FMDB和Realm待定)。

第三方库版本限制（Android/IOS）

Android或者IOS的第三方APP开发某些功能相同的情况下，怎么样规范他们采用的技术标准也是一个可能的风险。

例如民生和城管两个APP，都用到地图功能。

  • 如果一个APP采用百度地图1.0的库，一个APP采用了百度地图2.0的库。我们在整合成平台APP的时候就可能冲突。
  • 如果一个APP采用百度地图的库，一个APP采用了高德的库。我们在整合成平台APP的时候又可能让平台APP出现无所谓的臃肿。

统一登录和注册的限制

多个APP统一登录注册可能存在风险。

注册可能有几种方式：

  1. 没有注册，直接进入APP。
  2. 需要注册（手机号码，邮箱等）。

登录可能有几种方式：

  1. 游客模式（IOS）。
  2. 账号密码模式。
  3. 第三方账号授权模式。

这个需要公司产品有一个明确的需求，明确我们目前统一登录和注册体系的一个方案，才好进行设计。

SDK版本限制

为了统一UI体验，统一登录注册账号体系，统一第三方库版本，必须第三方公司采用我司提供的SDK进行开发，这样可能存在的风险。
因为公司内部还没有利用SDK进行过一次完整的独立开发，实际开发过程中肯定会出现经常改动或者优化SDK的情况，这个对于公司内部的开发基本上影响不大。不过频繁更新SDK，会影响第三方公司的开发进度。除外对接的时间和人力成本也比较高。

附录

  • 项目名字
项目名字cn 项目名字en 项目包名
智慧城市 platform cn.aorise.platform
样例 sample cn.aorise.sample
互联网+民生服务 live cn.aorise.live
综治网格化 grid cn.aorise.grid
数字化城市管理 city cn.aorise.city
阳光信访信息管理 petition cn.aorise.petition
教育 education cn.aorise.education
医疗 hospital cn.aorise.hospital
交通 traffic cn.aorise.traffic

注：项目名字中aorise,common,component等均为保留字段，请后期添加项目的时候不要使用。另外添加项目名字请使用英文名字，并且考虑到资源文件均需要增加项目名字做前缀，请尽量控制英文名字短小。