跑步节奏音乐匹配Android项目开发和调试经验

1.阅读开源计步器项目pedometer项目找到项目相关部件，paceNotifer。其在SenserEventlistener中被回调。

在其中判断本来直接更新到界面上面的步频范围数据。根据划分的范围触发不同的时间。

2.这里我第一次做的，对于我自己来说的突破性设计是状态机的编程。曾经以为比较难做，但是实现起来还是比较好做的。一个类里面设置各种状态量。然后一个公共函数进行调用。调用的过程中有两个重点，第一点是根据当前的状态和输入的状态二者共同判断对于输入的处理。第二点就是根据处理的结果设置这次的状态。以后的部件的处理也都是围绕这个思路。

3.根据2的思路进行部件的设计。其实这个设计也收到了源码当中对于每一步的判定的启发。包括环形队列求平均值进行出入滤波。录播结果和阈值比较超过某一范围进行触发。超过某一范围记录触发次数，到达阈值一定次数以后再次进行触发。触发进行事件业务以后重新设置阈值。使用线程sleep、

延时和标志位恢复进行状态禁止和恢复状态许可。

下面为涉及到的一下小知识点；

1.使用raw中的文件：

apk目录raw下的文件没有大小限制并且不会被编码。可以直接只用R.raw.“id”进行获取。

2.Math包下的abs可以去绝对值，ceil floor分别对应向上取整和向下取整。如果使用除法注意每个运算数尽量转化为float或者double。

3.关于随时需要获取的context对象。其实使用这个对象的时候就是操作系统需要判断你是哪个包里面进行的调用。如同你说要干什么，别人要先看看你是谁然后给你提供对应服务一样。这里面采用继承一个Application类进行，在其构造方法中使用getApplicationContext方法给定义的静态Context对象进行赋值。再写一个getContext的公用方法。以后的其他的地方用的时候直接用mApplication.getContext()就可以。注意着mApplication一定要在清单文件当中进行说明name才能被加载。

4.关于音乐播放的操作系统疑问。播放音乐的代码即使下载ui主线程也是可以进行正常使用的。只是这样的话如果在activity里面的话其生命周期会收到影响。所以往往都在service里面进行播放。而android系统会根据你的调用另起一个进程进行媒体播放，所有对于播放器控制的函数底层都是跨进程调用，所以不会产生阻塞问题。虽然一知半解，但是拓宽了我的思路。

5.项目移植问题。

eclipse移植到AS中要注意的问题。1.编码：重载后转换来排除乱码  2.清单文件的检查。因为功能被分配到gradle一部分，所以可能丢失一些信息。比如自己定义的 Application的名字的声明。这是一个bug。3.sdk的更新，以及其版本说明在gradle里面。

6.关于java传值，传引用的问题。

java只是传值，原来一直都是一知半解。今天遇到了在函数里面使用实参无法改变形参的值的问题。其实这就是在java里面的特性。实参复制了形参的引用，两个引用指向同一个对象。对其进行改变其实只是把实参的引用重新指向了其他的对象。而不会将原来指向对象进行改变。但是有一点很重要，就是如果你可以改变指向对象的公有属性，或者调用其公共方法。比如从mApplication中获取context就是这种。可以传入包含你要改变对象的数组，或者其父对象，这样就可以进行改变，而不必担心指向了其他地方。这里尤其容易犯错的就是对已基本类型知道无法改变形参而“聪明滴”使用了Integer等封装类型，结果也是一样不能改变，并且一切都对象类型都是如此。可见实践的重要性，只读书的话我永远都不会体会到这一点。

7.检测移动端的cpu占用率以及其他性能。如果使用eclipse，可以使用adb进行 。top -m 5 -t -d 3（-m 最大数；-t 显示进程名；-d刷新间隔）。当然提前要配置androd的环境变量。可以自己定义一个环境变量名然后使用双百分号添加到公共变量中。这里adb在toolsplatform-tools文件夹中。

使用AS可以进行cpu和其他参数的实时数据分析，并且可以对cpu占用进行trace录制。还是很有搞头的。

当然，从哲学层面上来讲，所有理论上的共识都会在实践中得到终极的验证。而只有在实践中进行验证的时候，对于理论的认识才可能达到完整和客观。