基于掌微atlas3/atlas4方案的功能实现分析

    本来是去一家以前的同事介绍的公司应聘的时候，根据他们的需求临时报佛脚想的一些东西。他们好象之前是买方案来做的，象电话短信什么功能是由北京的一家公司在帮他们做，不过是要收取liscence的。听我同事说做了都半年了都还没出来(怎么会这么慢？)，现在想自己做这些功能好降低成本。面试的人看了后就是让工程师打电话问了我一些关于电话实现的问题就没下文了。我想是我开的薪水要求超出了他们的要求，这经济危机闹的，不管有没有受影响都利用这个机会来降低人力成本。出来混不容易啊

 

 

目录结构

一、功能分析

    1.1  基本的电话/短信功能

    1.2  来电/去电显地区

    1.3  来电防火墙

    1.4  收发邮件

    1.5  wap浏览

    1.6  彩信

    1.7  行业应用

    1.8  移动增值业务

二、UI设计

    2.1  基于MFC做UI

    2.2  基于WIN32自行开发轻量级的图形引擎

    2.3  QT(成功案例：Skype及Linux的桌面KDE)

三、前景分析

 

 

一、功能分析

1.1、基本的电话/短信功能(TODO)

1.1.1 功能描述：提供友好的人机交互界面，完成来电、去电、收发短信功能。

1.1.2 实现前提：

硬件：方案是主控+GSM模块；

软件：

a)能实现对模块的AT操作或底层已实现此部分功能封装接口

b)能够基于现有方案做二次开发

1.1.3实现难度：难度相对较小，需要一定的开发周期

 

1.2、来电/去电显地区(TODO)

1.2.1 功能描述：实现来电、去电自动显示号码所在地区功能。

1.2.2 实现前提：同第一项

1.2.3 实现难度：

a)需要号码段数据信息

b)在实现第一项的基础上实现

 

1.3、来电防火墙(TODO)

1.3.1 功能描述：在后台实现来电过滤及配置接口的功能。

1.3.2 实现前提：同第一项

1.3.3 实现难度：

a)来电防火墙原理

b)在实现第一项的基础上实现

 

 

1.4、收发邮件(OPTIONAL)

1.4.1 功能描述：提供友好的人机交互界面，实现email收发的功能。

1.4.2 实现前提：

硬件：需要GPRS模块

软件：

a)模块内置PPP和TCP/IP协议或者可自行定制内核增加相应功能

b)实现邮件收发客户端协议及应用

1.4.3 实现难度：需要开发周期

 

1.5、wap浏览(OPTIONAL)

1.5.1 功能描述：实现浏览wap网站的功能。

1.5.2 实现前提

硬件：需要GPRS模块

软件：

a)实现wap协议栈

b)实现wap浏览器

1.5.3 实现难度：如果自己实现，需要一个较长的开发周期

 

1.6、彩信(OPTIONAL)

1.6.1 功能描述：提供友好的人机交互界面，实现MMS收发的功能。

1.6.2 实现前提

硬件：需要GPRS模块

软件：实现彩信协议及应用

1.6.3 实现难度：如果自己实现，需要一个较长的开发期

 

1.7、行业应用(OPTIONAL)

1.7.1 证券

1.7.1.1 功能描述：提供友好的人机交互界面，实现证券行情查询、证券交易的功能。

1.7.1.2 实现前提

硬件：需要GPRS模块

软件：证券交易客户端

1.7.1.3 实现难度：

a)需要证券行情信息

b)如果要实现交易，需要保证其正确性、安全性，在现在GPRS网络情况下这是个难点

 

1.7.2 其它的行业应用

 

1.8、移动增值业务：与移动/联通合作，运营SP增值业务(OPTIONAL)

1.8.1 内置功能

1.8.1.1 功能描述：在方案中构建如移动"移动梦网"、三星手机内置"三星乐园"、诺基亚手机内置"诺基亚网站"的书签

1.8.1.2 实现前提：

硬件：需要GPRS模块

软件：

a)提供wap网站

b)实现wap浏览功能

c)方案中实现内置书签

1.8.1.3 实现难度：

a)需要SP资质

b)提供wap网站及一些应用

c)如自行开发wap浏览功能需要一个较长的周期

 

1.8.2 其它的增值项目

 

二、UI实现

2.1、基于MFC做UI

2.1.1 实现前提：方案能自行定制内核并做二次开发

2.1.2 优点：目前常用的开发方式之一，开发相关的资源丰富。

2.1.3 缺点：a)代码冗余多，产生的文件占用更多的闪存空间，且不易移植

                b)因内部实现细节封装，不易于进行维护。

 

2.2、基于WIN32自行开发轻量级的图形引擎

2.2.1 实现前提：方案能做二次开发。

2.2.2 优点：代码冗余量小，便于维护和扩展功能

2.2.3 缺点：开发周期长一些

2.2.4 实现：a)组件的事件通知机制

b)事件响应处理接口

c)组件的Set/Get方法

 

2.3、QT(成功案例：Skype及Linux的桌面KDE)

2.3.1 实现前提：方案能做二次开发

2.3.2 优点：可移植性高，如果将来采用Linux可将上层应用以较小的开销移植过去。

2.3.3 缺点：a)基于Wince的SDK好象出来不久，其稳定性需要实际验证。

            b)基于QT进行开发的人员相对较少

从网上看到的：通过运行Qt的例子，发现它的这个版本只是可以在CE编译运行，但是显得比较粗糙，感觉很仓促，不够精致，希望下个版本能好些；而且运行时加载的动态库比较大，往往有几兆，内存占用很大，如果不是特别的需要，建议还是不要用。

 

三、前景分析

优点：利用价值定价规则，在保持硬件成本增长不大的情况下，通过增强软件功能提升产品附加价值

缺点：产品的市场定位是PND，如果增加太多的手机功能会弱化其定位，在市场山寨机流行的情况下可能会降低产品的市场竞争力。