提纲


  1. 必要的趟坑
  2. app设计结构上进一步分层
  3. 数据输出接口&缓存策略实现
  4. 客户端实现的数据迁移
  5. 视频下载&管理
  6. Gradle多渠道自动打包&自定义apk名

###一.必要的趟坑


在正式PRD出来前,产品会和技术这边有个概念性和开放性的需求预期。
所以开发可以根据需求的预期,撇开业务,抽象成技术点.

  • 数据缓存
  • 视频离线&管理

数据缓存
数据缓存,最基本的点就是缓存容器的选择。
在考虑数据结构,灵活性,方便性上的平衡。
mobile&nosql&multi-platform
趟了差不多一周坑,基本确认Android上nosql平台选择.

视频下载&管理
这个功能模块的基本点是,断点续传,数据库,网络,线程等.
早期是想用Android自带的downloadmanager来实现,但是最后发现其在管理上提供的的接口太少。
比较适合给app升级模块下载apk使用~要有比较主动性管理下载内容,会有一些坑.
系统的api暂时pass,那么找网上一些开源代码,断点的功能现在网络上其实一抓一大把,但是考虑到稳定性,以及扩展性,最后是选择了选择了Android downloadprovider模块源码,来实现了下载管理功能(当然,因为找到是2.3的源码,后期同事在开发中又他做了一些扩展和优化),但是至少在争论和必要的尝试性下,确定了最终方案。

###二.APP设计结构上的进一步分离


洋葱数学设计结构:

APP在1.1版本简单结构


  • (第一层)应用上层: UI(Avtivity,Fragment,View,) & 管理工具类(manager,utils) & 插件支持(support).
  • (第二层)核心层core层:数据获取和处理接口模块(Titan) & 视频播放功能模块(Mediaplayer)
  • (第三层)网络数据层 :网络请求。

第一层基本:

  1. 获取到数据然后展示到视图
  2. 期间在UI交互和数据的二次转换上获取上提供一些管理类和帮助类.
  3. 第三方插件的支持类&辅助类。

第二层

  1. 暴露一个数据接口给第一层,根据输入需要的数据类型(基本就是API),调用数据层处理后输出给上层.
  2. 预留数据缓存功能。
  3. 其他一些核心功能机制模块。

第三层

  1. 数据层简单到只有一个网络请求管理类(netData)和偏好数据管理类

APP在1.2版本结构


第一层:不变

第二层:

  1. 暴露的数据接口层(在结构上不变,功能上有变动)
  2. 数据获策略层(新增数据获取策略层,针对新加的缓存功能)
  3. 不变

第三层:

  1. 网络数据层
  2. 本地数据层

APP在1.3+版本后的构想结构


第一层:不变
第二层:
新增

  • 在数据接口层和策略层中间引入一个独立的业务子层(数据接口层完全抽象为一个接口,路由到各自的业务子层,业务子层再来路由数据策略子层 & 数据处理.)tips,保证原来的1.2版本前的上层数据获取都无需改动,但是略显浮夸。也考虑直接将Titan直接分裂成独立的业务处理接口。

第三层: 不变

###三.数据输出接口&缓存策略


数据输出接口
定义数据获取接口Titan,在现在轻业务上场景下,所以直接提供一个最简单的统一接口。
Titan在数据获取上又通过缓存策略子层来分担和分离其功能.
1.2版本的Titan的功能是数据获取的路由选择 &以及网络数据—》本地数据缓存的处理过滤(数据迁移)。

之后的扩展可能考虑在通过一个业务处理核心子层来分担Titan,Titan完全作为一个对上层接口存在,Titan根据业务来路由选择相应的业务模块,业务模块根据缓存策略来路由选择数据获取(并且来实现各自的数据迁移功能)。
也就是面的 App结构上的进一步分离

缓存策略
保持APP永远有内容分呈现.
有网情况:

  1. 先获取本地,有数据,返回状态&缓存数据填充;其他,返回状态。
  2. 请求网络,获取正常返回状态&数据刷新;其他,返回状态。

无网情况:

  1. 获取本地,有数据,返回状态和缓存数据;其他,返回状态。

同时在网络请求获取数据上做网络缓存扩展,如网络获取设置了一个时间间隔,优化频繁刷新带来的网络性能和流量问题.

###四.客户端实现的数据迁移


App V1.2版本我们mobile数据库和PC的同步,需要做数据过滤(早期是直接服务端部署一个mobile数据库,定期跑脚本做数据迁移,返回的数据结构就是客户端呈现结构)。
数据同步后,返回的数据结构需要客户端来处理和过滤,那么就考虑到这个数据的处理和过滤在那一层来实现。
以及我到底存储是原始数据(远程 serverDb 数据),还是处理过滤的数据(即客户端来实现了v1.2版本前,后台实现的数据迁移过程)。

  • 原始数据存储的优缺点:利,和pc端数据同步,对后期迭代时数据上一劳永逸, 扩展性更高;弊,每次取出来的数据都需要做处理和过滤,过滤可以做在core层(Titan),或是在上层数据展现到View时做处理(只展示APP结构上需要的),做在core可能处理会太过频繁时性能问题,在上层做的话,现在改动较大(因为1.2版本在数据结构呈现上基本和1.1版本相同)
  • 处理过的数据存储优缺点:利,对于上层改动最小;弊,即原始存储的利.

目前因为迭代时间的问题,取了第二种。具体下个版本再看产品需求来平衡。

性能上有弊端(现在返回的结构树deep太大)&最小改动优点的平衡。

###五.视频下载&管理


完全可以开一个单独的版来介绍。
基本出发点是基于Google的原生下载管理做修改扩展
涉及到得技术:Service & Broadcast & notification & 数据库(contentprovider)& 线程 &线程池 & http网络编程 & 几种设计模式
目前实现了基本的下载管理需求,持续迭代。

###六.Gradle多渠道自动打包


脚本解放双手

配置渠道:

1
2
3
4
5
6
//配置渠道
productFlavors {
_guanghetv {
manifestPlaceholders = [UMENG_CHANNEL_VALUE: "guanghetv"]
}
}

配置apk name

1
2
3
4
5
6
7
8
9
10
//自定义输出的apk名
applicationVariants.all { variant ->
variant.outputs.each { output ->
def outputFile = output.outputFile
if (outputFile != null && outputFile.name.endsWith('.apk')) {
def fileName = "YCMath_Android_V${defaultConfig.versionName}${variant.productFlavors[0].name}.apk"
output.outputFile = new File(outputFile.parent, fileName)
}
}
}

终端命令

1
./gradlew assembleRelease