安卓平板的ttl在哪里找

A. 移动应用开发需要学什么

经过参与各种各样的移动项目，我总结出一些要考虑的方面。当你设计或构建一个移动应用时候，需要把它们记在脑中。

移动app开发考虑的方面
认证层(Authentication Layer)
这应该是你开发链中的第一步。为了应对各种各样的认证请求与inflight request，这一层应该有足够可扩展性。需要留意认证令牌的刷新，令牌刷新失败或类似情况时的错误处理。
自动编译
要确保你为安卓和iOS建立了一个能自动编译的安装程序，并且有把他们分配给测试者的渠道。
舒适的移动体验
如果因为一些原因，即使是没有网络或者api停止工作了，也需要保证用户能够返回并从app退出。用户应该总能够点击到导航栏，这样还能够进入缓存中的页面，注销，当网好的时候重新加载，或退出app等。一定避免用户不得不强行终止app进程的情况。这是需要提前考虑的另一个设计特点。
数据封装
当设计数据封装时候一定要考虑API的存留时间(ttl)，用默认的ttl，缓存层，采用多数据源传送以标准表或者键值存储的数据。
推出更新
如果app的数据频繁改变，人们想要看到更新的消息，那么这个特性会很有用。这对于那些展示实时事件更新的app很需要。
崩溃分析
把崩溃分析与app联系起来非常重要，这样如果用户的app崩溃了，我们就能知道原因并可以更快的在下个版本修复。许多工具都可以做到这些。
数据存储
从app设计出发，这是需要考虑的最重要方面。有很多种在手机中存储数据的方法。比如WebStorage(LocalStorage, SessionStorage) , InMemory, SQLite. Localstorage的大小是10MB，如果你的要存的数据比这个小，它是个好选择。它的缺点之一是，当你的内存满了以后，操作系统会清空Localstorage数据。SQLite是基于文件的数据库，而且对于更大的文件更加稳定。它是嵌入式关系型数据库，如果你想把大量数据存储/缓存在客户端，它会是你的好朋友。
导航堆栈
当需要在不同页面间导航，并且有不止一种入口可以到达需要的页面时，它就是app最重要特性之一。它同样可以被分为不同的导航堆栈，比如：App导航，Tab导航，菜单导航等。要时刻考虑到各种情况，这样用户就不会陷入循环依赖 (死胡同)而需要强制停止app。
网络连接
开者经常假定人们总是有良好的互联网，按照这个逻辑设计app并把它推出。这也是当app不工作或不能持续下载数据时，大部分新手开发者受到打击的一点，最终导致了app在apple/google商店的低评价。一旦app已经推出，修复这类问题就很不容易，需要大量的退化。所以设计app时，这是需要考虑的重要一点。
检查平台
别忘了这个app是建立在哪种平台上的。保证所有的开发者/测试者都在机器上安装了相关程序，并且把这些程序列入文档，这样任何新来的开发者都可以很快掌握。要清楚开发者和测试者要怎样进行测试。
对于安卓，至少需要安装Android Studio, Gradle.
对于iOS你需要创建签名请求来生成证书，还有配置文件。(如果你事先不知道它至少花费一天，你会觉得这个过程很长。建议去找已经做过这一步的人，这一步就会缩减到15分钟)。不管你用哪种架构，要进行iOS开发你都需要至少一个Mac和iPhone。
付费
如果你的app需要付费，需要遵照Google和苹果付费规则文件。注意：你同样需要建立一些后端，这样当用户为你的app付费时候就可以去处理收据，并且你需要在服务器端保存这些单据。
本地特性
用列表列出app上需要本地设备支持的特性。例如：相机，状态栏，定位服务，通知等。并检查这些支持是否提供给了框架内所有内容。
推送服务
如果你的app需要推送服务，提前决定你要用哪家服务。检查针对选择的框架所用的插件是否有效。第一次用iOS测试这些时，为了让设备接收推送，需要添加一个app证书。同样也要决定你需要基于主题推送还是基于设备。

B. 安卓开发音频mic口怎么接收20khz的波形

安卓开发音频mic口接收20khz的波形的方法？
一、手机音频通信的特点
1、 通用性强：在智能手机普及的今天，手机的对外通信接口多种多样，而其中以3.5mm的音频接口通用新最强，基本所有的手机、平板电脑都会有这个接口，所以在一些要求通用性的设备上，音频接口登上了舞台。
2、 速率低：由于手机音频部分的采样频率一般为44.1KHZ（部分国产山寨为8KHZ），这极大的限制了音频通讯的速率。我们都知道44.1KHZ的采样频率，那么最高的信号频率只能为20KHZ左右，而信号周期也不可能只有2个采样点，通常要到10个以上，这样层层下来通讯速率可想而知。
3、 小信号：音频通信的信号都是毫伏级的，各个手机厂商略有不同，但通常最大不超过200mv，通常我们通信使用的信号强度也就100mv左右，这导致信号比较容易受干扰，且在开发阶段对工具有着种种限制。
二、 手机音频通信分类
1、 无线方式：
a) 无线方式大家可能不太熟悉，容我慢慢道来。我们都知道人耳能听到的声音频率为20HZ~20KHZ，而手机通信的信号频率最高也就20KHZ，所以无线通信方式是可行的。因为虽然人耳的极限听力能到20KHZ，但普通人一般在19KHZ以上时基本就听不到了，所以如果信号的强度比较弱，且控制在19KHZ到20KHZ之间，那么我们就可以将之当做是“超声波”来看待了。
b) 其实在此提到手机音频通信的无线方式，算是给大家一种产品开发思路吧。它的通讯半径在10M左右，前景还是很广阔的，大家有兴趣的可以试试。（其实已经有这方面的产品了）
2、 有线方式：
a) 有线方式分为单向（设备→手机）和双向两种，单向的限制少，开发难度也小一些，但实际应用时会受限制。而双向通信限制多，开发难度也大一些，但实际应用时更方便些。
b) 设备→手机：曼彻斯特编码；FSK；DTMF；自定义正弦波
c) 手机→设备：由于手机输出的音频信号很小，无法直接使用，要么用运放发大到合适的范围，要么用电压比较器转换成TTL方波。
三、手机音频通信硬件通信方式分类：手机音频通信的硬件通信方式大体可分为方波和正弦波两种。
1、 方波：方波通常使用的是曼彻斯特编码方式（什么是曼彻斯特编码自己去查），它的好处是可以用单片机直接输出方波，经过衰减后即可使用，方便简单。缺点是兼容性不好，因为手机音频部分有这样一个特性，它只识别变化的电平信号，当麦克输入的信号长时间保持在某一非零电平时，手机会将其视为零，而强行拉回零电位。这就是采用方波通讯方式的兼容性不好的最大原因了，并且方波也容易受干扰。
2、 正弦波：正弦波不会出现上面所说的方波的问题，故正弦波的兼容性和稳定性更好一些。通常采用方案有FSK、DTMF、信号发生器、或方波转正弦波等。（后面会对以上方案逐一分析）
3、 通信信道分析
a) 我们知道音频接口有4根线，MIC、地、左、右声道。设备→手机用MIC，手机→设备用地、左、右声道中的任意一个。这里说一下，实际产品中，有一些厂家会更换地线，即将原本左、有声道中的一根改为地线来用，其实道理是一样的。因为音频通信的信号时交流信号，而地其实也是悬浮地，即便地线换了，最终的波形还是一样的，因为最终手机解析信号时需要的是频率和幅值。这样还剩下一个声道，通常被用来帮助设备进行上电识别，因为音频通信的设备通常都是电池供电的。
b) 另外还要在MIC和地之间并联一个4.99K的电阻，因为手机是通过检测MIC和地之间的阻抗是否为4.99K（也有其他阻值的）来判断是否有设备（耳机）插入，这一点要谨记。
四、各个通信方案对比分析
1、 设备→手机：
a) 曼彻斯特编码：在诸多通信方式中，曼彻斯特编码是最灵活简便的一种方法，编码信号可由单片机直接产生，经衰减电路衰减后便可直接使用。注意事项：曼彻斯特编码信号的生成有两种方式，一种是用PWM生成，一种是用定时器中断翻转IO，我个人比较倾向于定时器中断方式。因为我们知道曼彻斯特编码中有宽沿河窄沿之分，且宽沿和窄沿可能会灵活变化，而用PWM方式不容易精确控制宽沿、窄沿输出的变化，而定时器中断方式则非常灵活且容易控制。（后面会送上我自己写的曼彻斯特编码、解码函数）
b) FSK、DTMF方式：FSK和DTMF两种方式大同小异，使用时通常都是用集成的芯片来生成的，而这些芯片通常都是遵守固定的通信协议的的要求（FSK为Bell202或V.23协议，DTMF记不清名字了）。这两种通信方式的优点是采用正弦波通信、稳定性好且使用简便。但由于固定通信协议的限制导致通信速率、比特率也受到限制而缺乏灵活性。在这里跟他家推荐一款英国的通信芯片CMX系列，这个系列的芯片融合的FSK、DTMF的编码、解码，还是很不错的，大家有兴趣可以试试。（相关手册在附件里）
c) 信号发生器、锁相环方式：这种方式用信号发生器或者锁相环来产生方波或正玄波，由单片机来控制波形的输出，也可以实现音频通信，且十分灵活。但缺点是电路较复杂，且不同频率信号之间衔接不好掌握，用不好反而是麻烦。（相关手册在附件里）
d) 在这里送上一种我个人认为比较好的方案：就是曼彻斯特编码加低通滤波器，由单片机输出曼彻斯特编码，再经由低通滤波器将方波滤成正弦波后输出。既解决了FSK、DTMF灵活性的问题，又解决了曼彻斯特编码方波稳定性、通用性的问题。在低通滤波器方面我个人采用的是“集成低通开关电容滤波器”，它成本虽然高一些，但好处也是明显的，电路简单，使用方便，且占用的空间亦很小。（相关手册在附件里）
2、 手机→设备：
a) 放大电路方式：将手机输出信号经放大电路放大到合适的幅值，然后有锁相环或者结成FSK、DTMF芯片进行解析。该中方式难度最大，需要非常强的模拟电路功底，我个人水平有限，故采用的另一种方式。
b) 电压比较器方式：将手机输出的交流信号经电路强行拉到Vcc/2级别，然后加到电压比较器一端，另一段接比较电压Vcc/2，这样交流信号即被转化为TTL方波信号，此时再进行解析就变得很简单了。
五、研发注意事项（通讯方案分析部分由于过长，放到最后来讲）
1、 一个好手机录音软件是必须的，最好能在手机上直接看到波形的。
2、 建议用笔记本电脑进行开发，而非台式机。因为音频信号很小，容易受干扰，而台式机干扰较大，笔记本还有一个好处是必要时可将外接电源拔掉，用电池供电。
3、 一个好录音笔必不可少，有时需要得到纯净的音频信号，方便更加准确的分析。
4、 做一个转接板，一边接音频母座，一边接音频公头，将MIC、地、左、右声道4跟线用排阵引出，方便录音。
5、 做一个信号衰减电路，可将设备电路产生的信号衰减至音频接口能承受的范围内。前期调试时，我们可以用该电路将信号录进电脑进行信号分析。（推荐一个电脑音频信号分析软件：Goldwave）
6、 录音用的音频线切记不要太长，不然会给你带来不少麻烦。最好自己做，用音频裸头、杜邦线、排阵即可制作，方便好用。

曼彻斯特编码的编码解码函数如下：
/**********************************************************************

注释：编码函数都是采用定时器中断的形式，以曼彻斯特编码的窄沿作为定时器周期。

发送的数据包括1个起始位、8个数据位、1个奇偶校验位、3个停止位。

***********************************************************************/

static void VIC_VECT_Fucton_00(void)//发送编码数据中断函数

{

TIMER0IS =0x0;

if((send_time%2==0) && (send_start==1))

{

switch(FSK_txState)

{

case STARTBIT:

if((GPIODATA&0x00000002)==0x00000000)//如果检测到数据发送管脚为零

send_time++;

else

{

currentSym=0;

FSK_txState = BYTE;

}

break;

case BYTE:

if(txBit < 8)

{

currentSym = (send_byte >> txBit) & 0x01;

txBit++;

txParity += currentSym; //奇偶校验位

}

else if (txBit == 8)

{

currentSym = txParity & 0x01; //发送奇偶校验位

txBit++;

}

else if(txBit>8 && txBit<12)

{

// next bit is the stop bit

currentSym = 1; //发送停止位

txBit++;

}

else if(txBit == 12)

FSK_txState = STOPBIT;

break;

case STOPBIT :

txBit=0;

FSK_txState=IDLE;

send_start=0;

txParity=0;

send_byte=0;

break;

}

if(lastSym!=currentSym)

{

timer1_num++;

lastSym=currentSym;

}

}

if(timer1_num%2==0)

GPIODATA&=0xFFFFFFFD;//输出管脚复位

else

GPIODATA|=0x00000002;//输出管脚置位

timer1_num++;//用来控制IO口的电平翻转

send_time++;//用来控制发送的字节的每一位

Delay++;//Delay就是延时函数

}

/**********************************************************************

注释：解码函数采用外部IO中断形式（上升沿或下降沿中断，即电平电平跳变中断），

用一个定时器作为时钟，每次产生中断时便从定时器见时间值取出，并和上一次的

记录做差求出时间间隔，以此来判断当前为宽沿还是窄沿。

***********************************************************************/

static void VIC_VECT_Fucton_04(void)//接受解码数据中断函数

{

GPIOIC|=0x00000001;//清楚上一次中断内容

RX_time=TIMER1VALUE;

if(RX_lasttime>=RX_time)

RX_diff=RX_lasttime-RX_time; //lasttime初始值为0

else

RX_diff=65535-RX_time+RX_lasttime;

RX_lasttime=RX_time;

switch(RX_state) //启动代码时state已经被配置为STARTBIT

{

case STARTBIT_FALL:

if ((SHORTINTERVAL<RX_diff) && (RX_diff<LONGINTERVAL))

{

if(RX_ones<5) //ones初始值为0

{

RX_ones = 0;

}

else

{

RX_state = DECODE; //将状态配置为解码

}

}

else if(RX_diff < SHORTINTERVAL)

RX_ones++;

else

RX_ones=0;

break;

case DECODE:

/**************通过间隔长短来判定数据**************/

if ((SHORTINTERVAL<RX_diff) && (RX_diff<LONGINTERVAL))// 若间距在范围内则当前数据位值和前一个相反

{

currentbit=(currentbit+1)&0x01;

RX_times+=2;

}

else if( RX_diff < SHORTINTERVAL)

{

currentbit=currentbit;

RX_times++;

}

else

RX_state = DATAINIT;

/****************接受数据位，从低位接起****************/

if(RX_times%2==0)

{

if(RX_bitcounter<8)

{

if (currentbit==1)

{

uartByteRx = (uartByteRx >> 1) + (1<<7);

rxParity++; //奇偶校验位

RX_bitcounter++; //接受数据位数

}

else

{

uartByteRx = (uartByteRx >> 1);

RX_bitcounter++;

}

}

else

{

rxParity&=0x01; //进行奇偶校验

if(rxParity==currentbit)

{

RX_bitcounter++;

RX_finish=1;

RX_state=DATAINIT;

}

else

RX_state=DATAINIT; //若奇偶校验错误则，重新检测

}

}

break;

case DATAINIT : //初始化参数状态

RX_bitcounter=0;

RX_ones=0;

rxParity=0;

currentbit=0;

RX_state=STARTBIT_FALL;

RX_times=0;

break;

default:

break;

}

}