开源项目Running Life 源码分析(一)

项目简介

基于HeathKit和高德地图开发健康跑步App,实现实时绘画运动轨迹、健康数据管理功能。
做这个项目出于两个原因:
1、喜欢跑步(也为了减减肥);
2、喜欢运用自己的知识实际,里面有我自己写的一些开源组件( 技术有限,设计得不好的地方,大家多多指导);

运行效果如下:

图片标题

项目目录

111fd8fe6f59cef14dde334b328e2f7667

title

Config目录:接口配置文件、宏定义和头文件配置文件;
AppINit目录:关于App的启动设置,如第三方SDK初始化、界面初始化、HeathKit初始化配置;
Module目录:业务模块,由以下这几个模块组成:公共模块、跑步模块、记录模块、个人模块、设置模块、登陆注册模块;
Resource目录:图片资源和字体资源;
RunKit目录:一些类的拓展、工具类、网络层方案、持久化存储层方案;
Vendor目录:一些不支持Cocoapod第三方库;
Pod:支持Cocoapod第三方库;

业务层架构

124197db2f9bc8d42034917e1a760f479a

MVVM架构(使用Facebook的KVOController实现view和viewModel的绑定,项目往ReactCocoa迁移中)

viewModel如何设计?

viewModel负责从原始数据源获取原始数据,运用对应的数据处理逻辑,转化为view层显示的数据。他不引入UIKit相关类,所以他与UI无关,也方便我们进行单元测试。实际上,它就是一层function core,理想上对于相同的输入会导出相同的结果。所以viewmodel得设计主要包含三部分内容:输入、输出、命令,简化成函数表达就是y = f(x),f函数指的是命令,x是输入,y就是输出,这里要注意输出对外界来说只是一个只读属性。示例如下:

viewModel与view如何绑定?

绑定的目的就是为了解决view与viewModel通信的问题。MVVM天然最好的绑定机制就是Facebook的ReactCocoa,它是函数式响应式编程思想的一个体现,它的核心就是响应数据的变化、统一异步编程模型,绑定的具体做法就是view层通过订阅viewModel上面的信号,先模拟处理一遍,这里模拟的意思是先从脑海里过一遍逻辑,实际不响应,当有信号发过来的时候才实际触发。
但是他需要一定的学习成本,学习成本较大,本人也在不断学习当中,所有我们换种方式来实现这种响应机制。想一下,cocoa中是不是有提供这种监听-响应的机制,没错,就是KVO,但是原生KVO写起来会恶心死人,所有我们可以借助Facebook提供一个KVO框架(kvoController)来实现优雅的绑定。(Facebook真是为了iOS的开发做出很多贡献,开源了那么多好用的工具)。
绑定方式就是view层 kvo viewModel层的readonly属性,一旦属性变化就触发响应的处理逻辑。示例如下:

功能实现

项目搭好条条框框,现在来分析具体的功能实现。本项目有两个功能,一个是跑步,另外一个就是记录,每个大功能点下又分几个小功能点,功能的示意图如下:

13ba9d97fde99ee5b4539fea48dde26af8

跑步

这里主要分析跑步过程的具体逻辑,界面如下:

14dd0fedfe024ccec3fca75b7f517a618b

源码在这个文件:”NewRunViewModel.m”

跑步数据源

跑步数据来源定位,这里定位SDK选择高德SDK,虽然原生也是高德地图,但经过测试发现原生的定位很不准,我也不知道具体原因是什么。
定义一个定位管理器,设置好相应的配置参数,因为为了跑步数据的精确度,所以将定位的准确度设置为最好,调用 [self.locationManager startUpdatingLocation]开启持续定位,具体实现如下:

定位成功后会不断的回调AMapLocationManagerDelegate的- (void)amapLocationManager:(AMapLocationManager )manager didUpdateLocation:(CLLocation )location方法,并不是所有定位数据都是有效,需要对数据进行过滤,过滤的依据就是horizontalAccuracy和时间偏差。horizontalAccuracy表示水平准确度,这么理解,它是以定位点为圆心的半径,返回的值越小,证明准确度越好,如果是负数,则表示corelocation定位失败,我们知道GPS信号会受地域的影响,有时强,有时弱,设置30是一个中和的做法,因为我们不能保证每次定位回来的数据都是绝对精确,如果设置得太小,可能过滤得到的数据很少,太大就会误差太大。howRecent用于计算定位结果与当前时间偏差,如果偏差超过2秒就过滤,这个2秒也是一个中和值。过滤完数据就可以计算跑步的距离,保存在_distance这个全局变量中。

获取数据之后怎么实时刷新UI呢?
我的做法是在NewRunViewController开启一个定时器,时间间隔是1s,每隔1秒往VM传运动时间,运动时间相当于函数的自变量,经过VM处理后,它会给C发数据改变的信号,信号相对于函数的因变量。实现如下:

智能判断跑步状态

通过CMMotionManager(是苹果的运动管理器框架,可以获取设备加速计、陀螺仪的即时数据)来智能判断跑步状态,以决定是否继续记录。这个功能点体现在当用户运动幅度变小的时候,小到一定程度的时候,app就判断用户处于休息阶段,当这个阶段持续超过8秒就暂停跑步记录,进入以下状态:

16ac737cab4b028e368e98c3d09cb46d9b

但用户又开始运动的时候,运动幅度到达一定程度的时候,有开启跑步状态。
它的实现原理是通过陀螺仪来实现(暂时还没适配旧版本手机,因为iphone5以下没有陀螺仪),一般我们跑步的时候,手机拿在手上或者放在裤袋里,所以y轴和z轴偏移最大也最频繁,所以通过判断y轴和z轴的加速度,如果他们的加速度小于2,则用户不处于跑步状态,这个2的值是自己试出来- -,如果大家有更好的依据欢迎到github issue我。具体实现如下:

运动轨迹

我将运动轨迹的绘画逻辑分离到MapViewController中,里面也有一个定位管理对象,定位成功也会不断的回调,相比NewRunController回调的处理,这里的处理多了对地图的处理,通过两个坐标确定一条线,并把线添加到地图上,代码如下:

通过mapView的一个delegate方法设置轨迹的相关属性

保存跑步记录

数据保存在本地数据库中,出于学习的目的,我这边持久层选择了CoreData,它是苹果推荐的持久层存储框架,底层是sqlite,做了面向对象的封装。上手有点难度,需要一定的学习成本,关于CoreData的具体使用,大家自行Google或baidu,在这里就不展开将。我们通过.xcdatamodeld可以十分方便地创建我们的实体对象,该项目主要有两个实体对象:跑步记录、实时位置数据,两者是有关联的,一次跑步数据关联着一系列实时位置数据。

17d79039cbfa3031670b4ced810070c3e3

1834843d89124bc5fe82600075074e58ae

当时在设计数据存储方案的时候,遇到这样一个问题:
如果用户没登录就发起跑步,跑步结束后数据插入到数据库,这些数据是没有用户认领的。当用户登陆的时候,这部分无用户态的数据该如何处理。当用户退出登陆的时候,原有记录的数据是保存还是清除?保存又该如何处理呢?
后来我参考了Nike的Running的处理逻辑,一旦登陆用户,这些无用户态的数据就被登陆用户认领,退出登录数据保存在本地。
既然处理逻辑想好了,这么数据存储方案要如何让设计呢?
大家可以看我基于CoreData封装的CoreDataManager:

为了让大家更好地了解这个方案,我普及一点点CoreData的知识,CoreData框架包含三层内容:
1、底层数据库;
2、持久化存储助手,作为业务层与持久层的协调对象,负责从数据库获取数据并返回适合的数据给业务层:
3、管理上下文对象,参与具体的业务交互;
一个数据库对应一个上下文对象,所以我的方案设计了两个上下文对象,一个对应着存放临时数据的数据库,另一个对应存放用户数据的数据。tempManagedObjectContext主要作用是为了获取临时数据用于合并数据库,平时业务交互直接用managedObjectContext就行,因为底层会根据当前活跃的数据库切换相应的上下文对象。切换数据库的实现原理:

用一个static变量存放数据库的名字,数据库的命名规则是以用户的账户名的MD5哈希值作为用户的数据库名。因为切换了数据库,上下文对象改变了,持久化存储助手也改变,因为两个都是懒加载,置为nil,到时会重新调用他们的getter方法,getter方法内部根据对应的DBNAME创建相应的对象。
切换数据库的应用场景有三个:app初始化的时候、登陆的时候、退出登陆的时候。

跑步结果

效果如下:

1980f75c13c3d879de09e4ade0e434350c
这边有个功能点就是根据不同速度绘画不同颜色的运动轨迹。
实现原理:创建一个MKPolyline(地图轨迹类)的派生类MultiColorPolyline,该类多了一个属性color,用来记录当前轨迹的颜色。将普通的轨迹转化为带颜色的轨迹实现逻辑放在MathController这个转换的工具类中,具体代码如下:

遍历获取最大速度和最小速度,根据速度与最大速度和最小速度比较,设置一个比例,根据比例调配相应的颜色,颜色的计算算法如上,就不展开讲了。

小结

今天分析了大体框架和跑步模块一些细节的实现,关于记录模块的分析我打算放在第二篇来分析,先做下预告,内容主要有三个:
实现view的复用机制解决内存暴涨问题、贝塞尔曲线与动画实现一个优雅的数据展示界面、HeathKit框架的使用。
项目地址:github.com/caixindong/Running-Life—iOS,有问题欢迎大家提出讨论,大家觉得不错,就赏个star。

1 1 收藏 评论

相关文章

可能感兴趣的话题



直接登录
跳到底部
返回顶部