MTK代码的最大问题

wangzhengh · 发表于 2010-5-4 16:21:17

以下是引用hztianxie在2010-5-4 9:10:15的发言：
？

其实你可以看看MTK的对手公司MSTAR,也是一家台湾公司

同样是芯片公司，同样有N多的DH追随，MSTAR的方案是分开的，独立的，A芯片一个程序版本，B芯片一个程序版本，规划的比较好，而且编程风格也不错。

而且MTK这样做，自己累死，设计公司的开发人员又学不到什么东西。

我之前的设计公司，很多方面速度上超过原厂了。为什么？因为我们从来不做开开关管的动作，就算是原厂做好的代码，我们也要查看，是不是正确，是不是有改进的地方。

所以我们会把整个代码的来龙去脉搞的非常熟，当然，优点很多，缺点也有，就是开发进度会比较慢点，尤其是前期。

但是同一系列的芯片足够多，我觉得还有可行的，比如，MSTAR的AXXX BXXXX CXXXX DXXXX 芯片,架构一样，风格一样，就是功能不同，那么你第一个项目架构改好，其他项目，基本可以做到半个月到1个月就可以量产.当然第一个项目可能就需要3-6个月。人员配备大概是2个软件 1个硬件

如果就单一芯片，另外的芯片程序架构完全不同了，那就没必要采取这样的做法

小一点的MTK的DH的软件配置两三个人够了，同样要满足23/25/53众多客户的不同需求以及各芯片的软件版本维护需求，如果各芯片代码差距非常大，靠两三个软件人员是根本无法做到的。
同样为什么众多小的DH很少有做展讯平台的，原因除了展讯不稳定之外，软件的可维护性差也是一个重要原因。

aquasnake · 发表于 2010-5-4 17:05:25

楼上仔细研究一下MOCOR，就应该可以知道展讯的代码维护不会如你想象。MOCOR把所有的代码分成与硬件无关的通用代码和与硬件相关的专用代码。所有D/M/R/H/L都可以统一到这个系统中，只要你想做。目前D/M已经淘汰。

展讯的全平台MOCOR代码，压缩成RAR，代码量250M左右，MTK的话一个25平台代码量翻倍都不止。

代码不是越多越好。维护复杂度和代码量成正比。

aquasnake · 发表于 2010-5-4 17:07:38

MTK，展讯我都做过，展讯BUG很多。

但是从代码撰写与编程风格上，展讯比MTK好。

系统成熟度，MTK高

aquasnake · 发表于 2010-5-4 17:13:10

软件写的庞大了，可复用性，开放性就很重要。

比如一个模块，我要添加一个应用，好的架构只要写一个C文件就可。如果封闭性的代码，则需要改写所有相关的接口，工作量就非常大了。

比较软件架构的优劣，其实只要看代码量，好的代码越升级代码量越精简。差的代码反之

wangzhengh · 发表于 2010-5-4 22:49:17

我在闻泰待了近四年，对展讯还是有一些了解的，D/M/H/R/L都做过。当年展讯的MMK代码是不对外开放的，我们也是最早拿到这块源代码的非展讯员工之一。展讯平台确实复杂度相对简单，编译速度非常快，分布式编译new一次也就5分钟左右。
MTK令人最大的不爽就是编译太慢，而编译慢的最大原因就是那几个带有宏开关的头文件(MMI_features.h/MMI_features_switch.h)，如果你创建一个新的文件，一行代码都没有写，而仅仅包含这两个头文件的话，编译时代码展开之后都有几万行了，因此MTK的代码编译起来特别的慢，在没有分布式的机器上或者分布式机器比较少的环境下编译都比较慢。
虽然MTK的某些应用写得也是不够规范，但是从整体上来说，MTK的代码还是比较规范的，基本也符合软件工程的要求。底层的代码几乎没有一行的warning，就这点来说，就够展讯好好学习了（当然远远不止这一点）。看看展讯MOCOR最新的代码，光是Warning就得有上万个。
展讯的代码规范性在此不再多说，坛子上已经有好多大虾对此有深入批判了。MOCOR相对D/M/H来说已经有比较大的改善了（但是怎么看也是感觉像向MTK靠拢？）
但是展讯的核心问题还是它的架构搭建的扩展性太差，举个简单例子，拿资源的文本编码来说，D/M只支持gb编码，做外文版就得自己改资源工具(为此展讯只能将资源工具的源代码开放给客户端)。H/R支持了ucs2编码，但是中文是gb码，L则把所有的编码都改成了ucs2码，但是L在做这项改动的时候，没有考虑对R/H的兼容性，直接把表示文本的数据结构改了，这使得MMI的代码同步起来非常困难。
L之前的string结构
typedef struct
{
   uint8 *str_ptr; /*!< string pointer */
   uint16 length; /*!< string length in bytes */
   BOOLEAN  is_ucs2; /*!< string is ASCII or UCS2 */

}MMI_STRING_T;
L之后的string结构
typedef struct
{
wchar* wstr_ptr;
uint16 wstr_len;

}CAF_STRING_T;
typedef CAF_STRING_T MMI_STRING_T;
在我看来，这些改动都是展讯为之前早期对软件的设计不当而一再地买单。而这种设计上的问题，展讯还存在很多很多。
另外，展讯平台在lcd虚拟层、socket接口的实现都有很大的问题。lcd的问题之前有人说过，socket中最大的问题就是没有socket数据到的通知消息，而需要开发人员开个循环定时器去查socket是否有数据，这种接口的封装应该由协议层来实现而不是让应用程序开发者来实现这些功能，目前L平台仍然没有改变这套机制。
展讯的问题太多太多，短短几句也没法说清楚，做了展讯平台看了之后就会明白展讯和MTK的差距在哪里了。

wangzhengh · 发表于 2010-5-4 23:17:56

在个人看来，上游芯片厂商对软件的质量和规范要求做的更高和更好，则下游的设计公司的工作量就越少，软件达到量产的时间也越短。
原因很简单，上游厂商多产生一个bug，如果有100个下游厂商就得需要测试人员测试出100个bug，需要软件开发人员花时间去解决100个bug，造成人力物力和时间的浪费。

hztianxie · 发表于 2010-5-5 08:45:06

说道编译的WARNING

我对MTK很不满意，但是由于我刚入手手机行业，不怎么区分驱动和MMI，

反正我看了LOG，觉得里面这么多WARNING,我看着就担心，以前我们做MSTAR方案的时候，要求0警告的。

有些警告是没关系的，比如定义了函数变量，没调用

但是有些警告却是致命的。说不定哪个时候爆发出来，你根本就不知道是这个原因引起的

hztianxie · 发表于 2010-5-5 08:48:28

而且，我看了MTK的代码，根本不能算精品，很多语句多些了，有些开关多加了

我觉得编程的原则是：不需要的函数，坚决不多些一句

打个比方，画一个字符串时调用A函数，

A函数包含了B函数 C函数，B函数里有画STRING的语句，C函数里也有，虽然不会造成问题，但是我觉得编程者思路不清楚。

hztianxie · 发表于 2010-5-5 08:52:36

关于SWITCH语句

虽然没有一个人说过用我下面的方式，但是个人认为在语句比较简短，语句类似的情况下，可以参考我下面的做法，程序时用来阅读的，我觉得这样的编排更容易比较，容易阅读

仅以工厂菜单音量曲线的函数为例

<img src="attachments/dvbbs/2010-5/201055857073499.jpg" border="0" onclick="zoom(this)" onload="if(this.width>document.body.clientWidth*0.5) {this.resized=true;this.width=document.body.clientWidth*0.5;this.style.cursor='pointer';} else {this.onclick=null}" alt="" />

hztianxie · 发表于 2010-5-5 09:04:29

以我个人经历，你如果想在水平上高过同行，你最好利用空余时间吧MTK的部分代码自己重新写一遍。全部代码是不太可能的，毕竟MTK的代码相当庞大。

做DH的人，往往只停留在表面功夫，涉及到深层次的东西，就一问三不知了。

字符串，估计做MMI的都会加，但是你可以问问，周围做MMI的，有多少人知道字符是怎么存储的，怎么调用，怎么显示的，ADD_APPLICATION_STRING2这个函数是怎么实现功能的？

敢拍胸脯说自己100%知道过程的几乎很少吧，

davidson · 发表于 2010-5-5 09:08:43

如果学习提升自己水平的话，还可以，最好还是尽量利用现有资源做尽量多的事情。

babyvox1999 · 发表于 2010-5-5 09:56:18

有利必有弊，哪里有完美的方案

fireyou · 发表于 2010-5-5 11:15:03

MTK做的还是不错的了
任何方案都是有缺点的

0警告是很难实现的

hztianxie · 发表于 2010-5-5 12:44:10

以下是引用fireyou在2010-5-5 11:15:03的发言：
MTK做的还是不错的了
任何方案都是有缺点的

0警告是很难实现的

为什么很难实现？

警告是因为有问题，既然有问题，提示了，就要去改。

改了就没警告了

比如ENUM的最后一个选项是没，号的

所以应该这么写

enum
{
AAAA
,BBBB
,CCCC
}

这样你加编译开关完全不需要考虑逗号的问题。

ly85206559 · 发表于 2010-5-5 14:54:57

楼主很有见地啊！刚接触MTK平台2个月，发现宏的嵌套确实让人不爽，不过适应了觉得还是有一定道理的，凡事不可能完美的嘛。不过MTK编程规范还是不错的，看了华为的编程规范感觉类似哦。

hztianxie · 发表于 2010-5-5 16:46:52

以下是引用ly85206559在2010-5-5 14:54:57的发言：
楼主很有见地啊！刚接触MTK平台2个月，发现宏的嵌套确实让人不爽，不过适应了觉得还是有一定道理的，凡事不可能完美的嘛。不过MTK编程规范还是不错的，看了华为的编程规范感觉类似哦。

整天看凤姐，当然不知道兽兽有多性感了

caz28 · 发表于 2010-5-5 17:01:30

void mtk_xxxxx{
if(){

}else{

}

}
这种风格是正常的，属于常见风格，楼主少见多怪了。

enum
{
AAAA
,BBBB
,CCCC
}
你要真写成这样，倒是没有警告了，但也太不符合人类习惯了吧。

风格要统一，不要变来变去，能做到这样就是高人了。
最后要说，MTK的代码很不错，他们代码控制的很好。不信你搞那么一堆试试

wangzhengh · 发表于 2010-5-5 17:10:37

楼主提到的很多都是关于编程习惯的，编程习惯因人而异，不能因为熟悉一种编程风格而去抨击另外一种编程风格。
比如说你非常鄙视的代码写法
void mtk_xxxxx{
if(){

}else{

}

}
以及一些大量宏的使用，在linux开源社区都是非常常见的东西，比如zlib/sdl，有空可以去多研读这些代码。

hztianxie · 发表于 2010-5-5 17:25:56

以下是引用caz28在2010-5-5 17:01:30的发言：
void mtk_xxxxx{
if(){

}else{

}

}
这种风格是正常的，属于常见风格，楼主少见多怪了。

这种风格是常见，在我几年的工作生涯中，程序我做过很多家了，不过没做过手机而已。

但是存在不一定合理，你看哪一本编程规范里推荐这么写的？

高质量C/C++编程，也是反对这么写的。

[此贴子已经被作者于2010-5-5 21:30:05编辑过]

aquasnake · 发表于 2010-5-6 17:15:55

以下是引用wangzhengh在2010-5-5 17:10:37的发言：
楼主提到的很多都是关于编程习惯的，编程习惯因人而异，不能因为熟悉一种编程风格而去抨击另外一种编程风格。
比如说你非常鄙视的代码写法
void mtk_xxxxx{
if(){

}else{

}

}
以及一些大量宏的使用，在linux开源社区都是非常常见的东西，比如zlib/sdl，有空可以去多研读这些代码。

格式不对齐，缩进无规律。阅读很累

		自动登录	找回密码
密码			注册

[讨论] MTK代码的最大问题