提纲

  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