（国内知名Android开发论坛 eoe开发者社区推荐：http://www.eoeandroid.com/）
网易科技讯，好耶公司产品副总裁徐国洪博士在eoe移动开发者论坛上接受了媒体的专访。最近几年，随着移动互联网的蓬勃发展，PC互联网广告营销平台也面临着向移动互联网业务倾斜、转型的需求。好耶公司产品副总裁徐国洪博士对媒体表示，好耶也制定了从广告代理业务向广告技术产品转型的战略。
好耶广告核心资源在于拥有国内1000家品牌广告主客户，其中包括苹果公司等世界一流的企业，目前年营业额20亿元人民币，是目前中国最大的互联网广告代理公司。总部在上海，包括上海、北京、深圳分公司，总共1000余人，此外在美国硅谷还有20人的研发团队。
好耶移动部门成立于2013年初，虽然相对于竞争对手，好耶进入移动广告领域要晚一些，但徐国洪博士认为，移动广告市场还是一个比较初级的市场，在2011年，刚开始有公司在移动广告市场获得收入；到了2013年才出现了在移动广告市场收入规模过亿的公司，从市场规模看，还有足够大的发展空间。
对于好耶在移动该广告市场的策略，徐国洪博士介绍，具体来说，好耶采取产品的差异性策略。
好耶针对移动开发者，在今年6月上线了一款免费服务性产品——PlayData移动应用数据统计分析平台，这个平台为开发者提供app基本流量分析，用户行为&属性分析，移动广告效果分析，和推广渠道效果分析。可以用多种形式的报表给开发者做展示，方便开发者及时了解产品的用户、使用行为、推广渠道效果等，并依据这个及时的调整产品和运营、推广策略。简而言之，就是帮助开发者解决app数据统计分析挖掘需求的。
此外，针对品牌广告主对移动广告缺乏认识，效果很难评估，不敢投入大的预算的情况，好耶即将上线针对广告主的一站式、便捷的移动广告需求方平台——移动DSP，这款产品服务于广告主客户，连接开发者和广告主。通过RTB协议实现广告位的实时竞价。
PlayData与移动DSP是相辅相成的关系，徐国洪博士表示，好耶有很好的品牌广告主资源积累，数据平台类产品PlayData能在移动端研究移动媒体的用户属性，广告效果监测分析等，通过移动DSP来帮助广告主精准进行移动广告投放，同时通过好的效果评估，让广告主能把更多预算投入移动互联网，对行业发展也有促进。
对于facebook在移动广告上获得很好收益的原因，徐国洪博士认为，这主要是由于Facebook的广告技术的独到之处。
徐国洪博士认为，移动广告形式的创新非常难的，他举例，新浪微博巨大的流量才带来4、5亿人民币的广告收入，说明移动产品的广告形式创新非常难。需要有强大的技术支撑。
徐国洪博士还认为，好耶在移动互联网广告领域有两个大方面的创新，一是在基于大数据收集和分析，做精准定向，还有就是好耶不断探索移动广告形式本身的创新。
作为好耶的移动产品部门领导者，徐国洪博士制定的规划是，期望在未来2年内，将PlayData和移动DSP两款产品在市场上做到领先位置，争取做到第一。
徐国洪博士对刚刚进入移动互联网领域的开发者提出建议，要将技术排在第一位，掌握好移动相关的技术，而对于成熟的，已经拥有产品和一定用户量的移动开发者，除了用户体验外，更要重视数据化，要学会用第三方的专业的工具做数据分析，进而支撑产品变现以及对用户的理解。
eoe成立于2009年，创办了最早也是目前为止最大的中文移动开发者社区：www.eoe.cn ，超过160万的移动开发者汇聚在eoe，共同讨论最前沿最精彩的技术话题。eoe一直致力于为移动开发者提供全方位的服务。
<!--EndFragment-->
更多内容请关注eoe移动开发者社区：http://www.eoeandroid.com/
聽聽聽聽聽 锛堝浗鍐呯煡鍚?span >Android寮€鍙戣鍧?/span>eoe寮€鍙戣€呯ぞ鍖烘帹鑽愶細http://www.eoeandroid.com/锛?/span>
聽
銆€銆€9鏈?4鏃ワ紝eoe绉诲姩寮€鍙戣€呭ぇ浼?/strong>姝ｅ紡鍦ㄥ寳浜浗瀹朵細璁腑蹇冨彫寮€锛屼竷鐗涗簯鍌ㄥ瓨CEO璁稿紡浼熷厛鐢熷仛浜嗕笓棰樻紨璁层€婂揩閫熸墦閫犵Щ鍔ㄥ簲鐢ㄣ€嬶紝涓婃柟缃戠涓€鏃堕棿閲囪浜嗚寮忎紵鍏堢敓锛岃鎬诲氨浜戝偍瀛樻妧鏈浣曚笌绉诲姩娓告垙鐨勭爺鍙戠浉缁撳悎鍒嗘瀽浜嗕富瑕佺殑鎶€鏈粡楠屻€?/p>
聽
銆€銆€涓冪墰浜戝偍瀛楥EO璁稿紡浼?/p>
銆€銆€浜戝偍瀛橈細闄嶄綆娓告垙灏哄瀹炵幇鏇撮珮鐨勫垎鍙戝埌杈剧巼
銆€銆€涓婃柟缃戯細涓冪墰鐨勪富瑕佷笟鍔℃槸浠€涔?
銆€銆€璁稿紡浼燂細涓冪墰鐨勪富瑕佹湇鍔℃槸闈㈠悜寮€鍙戣€呯殑锛屼粠涓氬姟绫诲瀷鏉ヨ锛屼竷鐗涙槸涓嶅垎PC绔笌绉诲姩绔殑锛屽彧瑕佹槸涓€绉嶉潤鎬佺殑鏂囦欢锛屼緥濡傚浘鐗囷紝闊抽锛岃棰戠瓑閮藉睘浜庝竷鐗涚殑涓氬姟鑼冨洿銆?/p>
銆€銆€涓婃柟缃戯細绉诲姩娓告垙浼氫骇鐢熷摢浜涢潤鎬佺殑鏂囦欢?
銆€銆€璁稿紡浼燂細浠庝粙璐ㄦ潵璁诧紝绉诲姩娓告垙浼氫骇鐢熷浘鐗囷紝浠ュ強鍐呴儴鐨勭敤鎴风ぞ浜や骇鐢熺殑淇℃伅銆傚悓鏃讹紝绉诲姩娓告垙鐨勫畨瑁呭寘锛岃ˉ涓佸寘閮藉睘浜庨潤鎬佹枃浠躲€?/p>
銆€銆€涓婃柟缃戯細绉诲姩娓告垙涓骇鐢熺殑闈欐€佹枃浠讹紝浠ラ偅浜涙柟寮忓鐞嗕細鏇村ソ?
銆€銆€璁稿紡浼燂細绗竴绉嶆槸鐩存帴灏嗛潤鎬佹枃浠舵斁鍦ㄦ父鎴忕殑瀹夎鍖呴噷锛岀敤鎴峰彲浠ョ洿鎺ヤ笅杞芥父鎴忥紝杩欑鎯呭喌鏇撮€傜敤浜庢瘮杈冨皬鐨勮交搴︽父鎴忋€傚彟涓€绉嶆儏鍐垫槸锛屾父鎴忔湰韬璁′腑鍖呭惈鏈夊緢澶氱殑璧勬簮锛屾父鎴忕殑瀹夎浆鍖呭彲鑳戒細闈炲父澶э紝浼犵粺鐨凱C绔父鎴忕殑瀹夎鍖呮湁鏃跺彲鑳戒細杈惧埌1G锛岀敋鑷?0G浠ヤ笂锛岀Щ鍔ㄦ父鎴忓湪鏈潵涔熷皢鍛堢幇杩欐牱鐨勮秼鍔裤€備絾鏄繖閲屽瓨鍦ㄧ潃浼樺寲鐨勫彲鑳斤紝渚嬪锛岀Щ鍔ㄦ父鎴忎腑鐨勮棰戞枃浠讹紝鍙互鎵撳寘鎶曞叆瀹夎鍖呬腑锛屼篃鍙互鏀惧湪缃戜笂锛屽湪娓告垙杩愯涓啀鎷変笅鏉ャ€傛墦鍖呮斁鍦ㄥ畨瑁呭寘涓殑鍋氭硶锛屼細缁欑Щ鍔ㄦ父鎴忔湰韬殑鍒嗗彂甯︽潵楹荤儲锛屾父鎴忕殑灏哄姣忔彁鍗囦竴涓。娆★紝浣犵殑娓告垙鐨勫垎鍙戝埌杈剧巼灏变細涓嬮檷锛岀敤鎴蜂笅杞戒綘鐨勬父鎴忓氨浼氳姳璐规洿澶氭椂闂淬€備絾鏄紝濡傛灉閲囩敤浜戝偍瀛樻妧鏈皢杩欎簺璧勬簮鏀惧湪缃戜笂鐨勮瘽锛岀敤鎴蜂笉鑱旂綉灏遍毦浠ユ甯歌繘琛屾父鎴忥紝涓ょ瀛樺偍鏂瑰紡鍚勬湁鍒╁紛銆?/p>
銆€銆€涓婃柟缃戯細涓冪墰鐩墠鐨勪笟鍔″湪鎮ㄧ殑浠嬬粛涓紝浼间箮鏄潪甯镐笓涓氱粏鍖栫殑椤圭洰?
銆€銆€璁稿紡浼燂細涓冪墰鐨勪富瑕佷笟鍔＄殑纭槸闈炲父鍨傜洿鐨勶紝浠讳綍涓€瀹剁綉绔欑殑娴侀噺缁濆ぇ澶氭暟閮芥槸鏉ユ簮浜庤棰戯紝鍥剧墖杩欎簺鈥滃瘜娴侀噺鈥濓紝澶ф鑳藉崰鍒?0%锛屼竴涓綉绔欏鏋滃叏閮ㄤ緷闈犺嚜宸辨潵澶勭悊杩欎簺娴侀噺锛屽緢鏈夊彲鑳戒細琚帇鍨€?/p>
銆€銆€澶ц秼鍔匡細绉诲姩娓告垙蹇呯劧浼氬皢鏇村璧勬簮鏀惧湪缃戜笂
銆€銆€涓婃柟缃戯細鍚屾牱鐨勬儏鍐垫槸鍚︿篃浼氬彂鐢熷湪绉诲姩娓告垙涓?
銆€銆€璁稿紡浼燂細绉诲姩娓告垙鐩墠灏嗚祫婧愬叏閮ㄦ斁鍦ㄧ綉涓婄殑杩樻瘮杈冨皯锛屼絾鏄〉闈㈡父鎴忕粷澶ф暟鏂囦欢灏辨槸鏀惧湪缃戜笂鐨勶紝鏅€氱殑鎵嬫父涔熶細鍚戦〉娓歌繖绉嶆柟鍚戝彂灞曪紝浠庨暱杩滄潵鐪嬶紝绉诲姩娓告垙瀹夎鍖呯殑灏哄涓嶈兘姘歌繙澧炲ぇ锛岃€冭檻绉诲姩娓告垙鍒嗗彂鐨勫埌杈剧巼鐨勫疄鐜帮紝绉诲姩娓告垙蹇呯劧浼氬皢涓€閮ㄥ垎璧勬簮鏀惧湪缃戜笂銆?/p>
銆€銆€鏈潵绉诲姩缃戠粶鏀瑰杽涔嬪悗锛屾父鎴忕殑鐮斿彂鍘傚晢涔熶細鏇翠箰浜庡皢娓告垙鐨勮祫婧愭斁鍒扮綉涓娿€備粠闀胯繙鏉ョ湅锛岃繖灏嗘槸涓€涓ぇ瓒嬪娍锛屽叾浠栫殑APP浼氳〃鐜板緱鏇翠负鏄庢樉銆傛湭鏉ユ父鎴忎腑锛屽繀鐒朵細浜х敓寰堝浜や簰鎬х殑闈欐€佹枃浠讹紝姣斿銆婁綘鐢绘垜鐚溿€嬭繖娆炬父鎴忓氨姣旇緝鏄庢樉銆?/p>
銆€銆€涓婃柟缃戯細涓冪墰浼氬府鍔╃爺鍙戣€呮洿蹇湴鎺ㄥ嚭APP锛屾偍鑳戒粙缁嶄竷鐗涚殑鏌愪簺鐞嗗康鍚?
銆€銆€璁稿紡浼燂細涓冪墰鍙互鍒╃敤鑷韩鐨勬湇鍔℃彁鍗囩Щ鍔ㄥ簲鐢ㄧ爺鍙戞柟鐨勫搧璐紝甯姪鐮斿彂鑰呬笌瀵规墜鎷夊紑宸窛锛屼竷鐗涚殑鏈川灏辨槸鈥滃瓨鈥濆拰鈥滀紶杈撯€濓紝瀛樼殑鏇村彲闈狅紝浼犵殑鏇撮€氱晠锛屽彧瑕佸拰杩欎袱鏂归潰鏈夊叧鐨勯兘鏄竷鐗涢渶瑕佽В鍐充笌澶勭悊鐨勩€?/p>
銆€銆€涓婃柟缃戝皬璇?/p>
銆€銆€浜戝偍瀛樻妧鏈洰鍓嶅凡缁忓箍娉涘湴鐢ㄤ簬浜掕仈缃戞暟鎹殑瀛樿串涓庝紶杈撳綋涓紝鍙楅檺浜庡浗鍐呯Щ鍔ㄤ簰鑱旂綉鐨勫彂灞曠幇鐘讹紝澶ч噺鐨勭Щ鍔ㄦ父鎴忛毦浠ュ皢娓告垙鐨勫昂瀵稿仛鐨勬洿澶с€傝寮忎紵鍏堢敓鏈鍒嗕韩鐨勭粡楠屼富瑕佹槸鑰冭檻浜戝偍瀛樻妧鏈湪鏈潵绉诲姩缃戝閮ㄧ幆澧冧笉鏂敼鍠勭殑鍓嶆彁涓嬶紝濡備綍淇濊瘉娓告垙璐ㄩ噺锛屽苟闄嶄綆娓告垙鐨勪笅杞藉昂瀵革紝瀹炵幇鏇撮珮鐨勫垎鍙戠巼銆傚叾涓叿浣撶殑鎶€鏈紝蹇呭皢鍦ㄧЩ鍔ㄤ簰鑱旂綉鍙戝睍鐨勫ぇ濂藉墠鏅笅锛岄€愭瀹炵幇銆?/p>
銆€銆€鈥滄父鎴忎箣涓娾€濇槸涓婃柟缃戞帹鍑虹殑涓€涓師鍒涚被鐨勯珮绔璋堣妭鐩紝璁胯皥鍢夊鑱氱劍浜庣Щ鍔ㄦ父鎴忛鍩熻緝鏈夌煡鍚嶅害鐨凜EO锛岄珮绠★紝璁胯皥褰㈠紡涓€鑸敱涓婃柟缃戠殑缂栬緫閫氳繃闈㈠闈€佺數璇濄€佺數瀛愰偖浠剁瓑褰㈠紡锛岄拡瀵硅涓氬唴鐨勬柊闂讳簨浠躲€佺儹鐐硅瘽棰樸€佹柊娓告垙涓婄嚎鎺ㄥ箍銆佽涓氭垬鐣ュ竷灞€绛夎瘽棰樿繘琛岃璋堛€?/p>
聽
聽聽聽聽eoe鎴愮珛浜?009骞达紝鍒涘姙浜嗘渶鏃╀篃鏄洰鍓嶄负姝㈡渶澶х殑涓枃绉诲姩寮€鍙戣€呯ぞ鍖猴細www.eoe.cn聽瓒呰繃160涓囩殑绉诲姩寮€鍙戣€呮眹鑱氬湪eoe锛屽叡鍚岃璁烘渶鍓嶆部鏈€绮惧僵鐨勬妧鏈瘽棰樸€俥oe涓€鐩磋嚧鍔涗簬涓虹Щ鍔ㄥ紑鍙戣€呮彁渚涘叏鏂逛綅鐨勬湇鍔°€?/span>
聽聽聽聽鏇村鍐呭璇峰叧娉?/span>eoe绉诲姩寮€鍙戣€呯ぞ鍖猴細http://www.eoeandroid.com/
在前一篇中，我们提到了contiki需要一个系统嘀嗒，称之为systick，在本篇中，我会结合我的程序，详细的叙述systick。
一、systick初始化
我们在main函数中，有这样一句clock_init();这是对系统时钟的初始化
void clock_init()
{
SysTick_Config(clock_get(CLOCK_SYSTICK)/ CLOCK_SECOND);
}
#define CLOCK_SECOND CLOCK_CONF_SECOND
#define CLOCK_CONF_SECOND 100
static __INLINE uint32_t SysTick_Config(uint32_t ticks)
{
if (ticks > SysTick_LOAD_RELOAD_Msk) return (1);
SysTick->LOAD = (ticks & SysTick_LOAD_RELOAD_Msk) - 1;
NVIC_SetPriority (SysTick_IRQn, (1<<__NVIC_PRIO_BITS) - 1);
SysTick->VAL = 0;
SysTick->CTRL = SysTick_CTRL_CLKSOURCE_Msk |
SysTick_CTRL_TICKINT_Msk |
SysTick_CTRL_ENABLE_Msk;
return (0);
}
这里涉及到几个寄存器的控制：
SysTick->LOAD 对应硬件寄存器STRELOAD,设置寄存器的重载值。一旦寄存器递减至零，就会从这个寄存器中取出重载值，然后实现下一个systick
SysTick->VAL对应硬件寄存器STCURR，这里当前的值设置为0
SysTick->CTRL对应硬件寄存器STCTRL，这里我们将其设置为7，即：将系统节拍时钟源选择为CPU时钟，系统节拍中断使能，系统节拍计数器使能。
关于重载值的问题，LPC1788官方的文档上面也有详细的阐述：
下列示例说明如何根据不同的系统配置选择系统节拍定时器的值。 在所有示例中，都使用10毫秒的中断间隔进行计算，就像系统节拍定时器的设计用法一样。
示例1)
该示例适用于使用100MHz的CPU时钟（CCLK）运行的系统节拍定时器。
STCTRL=7。当STCTRL为7时会使能定时器及其中断，并选择CCLK作为时钟源。 RELOAD = (cclk / 100) - 1 = 1,000,000 - 1 = 999,999 = 0xF423F
在该例中，不存在舍入误差，所以结果与CCLK一样精确。
同样的，我的CPU时钟频率是120MHz，将此作为systick时钟源，那么
RELOAD=(120,000,000/100) - 1 = 0x124F7F,且不存在误差。
二、systick中断
当systick到来的时候，也就是current value值减为零后，系统会发出一个中断，这个中断就是systick的中断，我们要想通过systick驱动etimer,必须在systick的中断中实现。
下面是systick中断的实现
void SysTick_Handler(void)
{
SCB->ICSR = SCB_ICSR_PENDSTCLR; /*!< Clear pending SysTick bit */
TickCounter++;
if (etimer_pending() && etimer_next_expiration_time() <= TickCounter) //timerlist不为空且还没有etimer到期，则执行etimer_request_poll
{
etimer_request_poll(); //让etimer_process更快地再次获得执行。
}
if (--second_countdown == 0) {
current_seconds++;
second_countdown = CLOCK_SECOND;
}
}
在程序中，我们看到有一个Tick_Counter的变量自加，这个counter就是systick了。
contiki维护着几个counter，一个是Tick_Counter，这个是系统嘀嗒，描述的是系统在一段时间内跑了多少个嘀嗒；一个是current_seconds，这个是系统跑了多少秒。我们知道，一个systick是10ms，那么一个surrent_seconds就是100个系统嘀嗒，这个数字100，正好是我们之前定义的CLOCK_CONF_SECOND 。了解到这一点，我们就明白这段程序后面，second_countdown的作用了。即：先将current_countdown赋值100，每次系统嘀嗒到来的时候，将其值减一，如果减到零了，说明1秒时间到了，那么当前的current_seconds要加一，然后将current_countdown赋值100，重新开始计数。
三、用系统嘀嗒做延迟检测
我们在主函数外，加入一段延迟的代码，用做延时的测试
void clock_delay(unsigned int len)
{
unsigned int i;
for(i = 0; i< len; i++)
{
;
}
}
然后参考前面的contiki的编程模型，写一个延时的进程
PROCESS(hello_world_process, "Hello world");
PROCESS(led_on_process, "led on");
AUTOSTART_PROCESSES(&hello_world_process,NULL);
PROCESS_THREAD(hello_world_process, ev, data)
{
static unsigned short start_time;
static unsigned short end_time;
static unsigned short diff_time;
static unsigned int i ;
PROCESS_BEGIN();
printf("Clock delay test, (1,200,000 x 20) cycles:\r\n");
i = 1;
while(i <= 20) {
start_time = clock_time(); // 记录开始timer
clock_delay(1200000 * i); // 软件延时
end_time = clock_time(); // 记录结束timer
diff_time = end_time - start_time; // 计算差值，单位为tick
printf("Delayed %u CPU tick; %u system ticks =~ %u ms\r\n", 1200000 * i, diff_time, diff_time * 10);
i++;
}
PROCESS_END();
}
测试的结果如下
测试是符合要求的。说明我们的systick已经OK了，进程也没有问题。
细心的你可能会发现：如果系统时钟设置为120MHz，那么我延时1200000次，1200000 / 120M = 10ms，那应该正好是1个systick才对，怎么会是4个systick呢？
问这个问题人都是很仔细的人，说明真正用心去思欧考了。这里我详细说明一下：
操作系统中，有机器周期，时钟周期和指令周期这一说法，一般的，1个指令周期=4个时钟周期=4个机器周期。在本例中，我们延时的时候，用的指令是“；”，其实不管用什么，都指的是指令周期，而机器在响应systick的时候，寄存器的值减一，却是时钟周期。
也就是说：延时一个指令周期，时钟周期要跑4次。所以计算出来的systick当然应该是4而不是1。