分类目录归档:日志

怎样使一个IP手游的第一次CBT拖延3个月

最近,参与的IP手游项目终于第一次CBT结束了。

IP手游真是件累人的事儿,各种监修各种限制,光游戏UI资源就换了至少4个版本,各种比较创新的玩法也被一一砍掉。本来的CBT时间点是在3月份的,然而,现在是7月份了。不得不喷下这大几个月在拥有众多资源的公司中开发IP手游碰到的问题。

  • 前期规划不足

规划的问题,其实是在各种项目中多多少少都会碰到的问题。既然负责客户端这边的开发,就只说说客户端统一性规划。涉及人员当然是策划、美术、程序 缺一不可。

项目开发过程中,我们的策划的每一个案子中控件的设置方法、摆放位置(涉及美术),乃至配置表字段的设计都是乱来的,怎么舒服怎么做,导致美术出的效果也不能统一,然后美术的设计风格也是一个界面一风格。如此,直到游戏基本成型后还需要重新大幅调整资源,统一设计风格,然后程序加班加点修改,这上面浪费了大量的时间精力。如果在项目初期就注意这些统一性的把控,游戏开发应该是更顺畅的体验吧?

  • 开发迭代不规范

再者,项目开发过程中,美术、程序的迭代过程不是不断优化的过程,而是不断替换之前成果,更关键是这种替换不是推到重来,而是回到之前的之前版本模式。

糟糕的迭代导致项目资源的严重浪费,我看到程序、美术在不断加班加点做着重复的工作,感觉好痛心。我在考虑一个问题,制作人在这种情况下是不是应该停歇一下,思考下项目为什么会进入这样恶性循环中,而不是任由此类态势发展下去,最终导致项目不断延期。

当然,这种无奈的情况不能排除IP游戏中特有的情况,如若真是如此,是不是负责监修方面的人员应该做的更到位一点?

  • 产品阶段模糊

在我们游戏CBT版本功能还没有定下的时候,就开始接入QA了。然后QA各种测试后,提交了各种bug,程序再修复bug,如此反复一个多月,直到一个多月后,才发现QA测试的很多功能是要砍掉的或是程序、美术要重新修改的功能。

项目开发中也频现类似的情况:策划分配策划案到美术、程序,之后相关创作人员进行功能制作。在程序获得美术资源进行功能开发的时候,美术的第二版、第三版资源就接踵而至,导致程序浪费大量时间在前段ui修改上,而不是代码性能及功能优化上。

诸如以上产品把控的乱入,直接造成项目资源的严重浪费。所以,想拖延项目进程的,照着上面做就行了。

2014->2015

最近跟朋友聊天,总或多或少听到提及时间过得好快啊。。之类的词语,巧的是,本人也有同样的感觉。

即将过去的一年,对于我的关键词简约了好多:生娃、手游。

生娃

我的宝贝女儿终于在这一年健健康康地来了,开始了她的精彩人生,我也算正式加入奶爸大军了。现在每天回家,还是只能跟他大眼瞪小眼,对视地傻笑,不过这样就够了。生之前总有计划着,生完后到现在,执行一片空白,突然发现这真是一种病,得改。

手游

本来想把做手游当成职业爱好,不想竟然真的做了一年多了,而且还真的做出了像样的作品了,而且成绩还算可以(对于处女作来说)。

虫虫消消乐没推广的情况下,在苹果AppStore上卖出了近3万拷贝,算是达到了自己的预期。但是在随后的版本更新中,自己引入了一个悔到肠青的bug,导致用户量和活跃用户急剧下降,希望吃了这一堑得长点智,修改bug,还是得有个完整的测试过程。

在google play上,虫虫消消乐卖了近5000拷贝,成绩不好的主要原因,我就归结为Android版本出得较晚,还有google play在大陆众所周知的处境。因为游戏中有内购功能,国内安卓平台限制个人应用集成内购功能,因此,Android版本没在国内的安卓平台上线,这应该也算Android版本不佳的原因吧。

关于吹过的牛逼

写了几年总结,发现年年都会吹一些牛逼,然后下一年终总有对不起的牛逼。

吹过的牛逼1——业余时间做2-3个手游。我其实业余只做了两个简单手游,一个虫虫消消乐,另一个也是消除类游戏,当然不是虫虫消消乐的玩法。但是,没上线,由于种种原因。。好吧,这是一种病。

吹过的牛逼2——再多看四五本书。其实是很简单的一件事,但是竟然还是没达成。现在想想,我总以太专注写代码来搪塞“为什么没时间看书”这样的理由,这也是加剧拖延症的主要原因之一,得治。

各种年度评选

今年年度人物毫无疑问是我的乖乖女儿——水灵灵的眼睛眨呀眨。

年度产品就将就发给虫虫消消乐吧。

2015

  • 看10本书;
  • 写12篇文章;
  • 努力赚钱,养家糊口;
  • 对得起吹过的牛逼;
  • 与拖延症顽抗到底。

写在201314

照旧,在2013的最后一天是该总结点东西。这个时候,整理那些思绪中混乱的时间碎片,都会感伤时间的飞快。先亮一下现在头壳中的那些标签云吧:游戏、微信、苹果、小米、3d打印、移动开发。这些是我今年在reader中关注比较多的词条。

可能因为有点过分专注于写代码了,这是沉溺在reader、微博、知乎比较少的一年了。简单地结个论,这是属于微信的一年,也是属于小米的一年,同样也是各种移动应用的爆发年,这行的国产企业的雄起,让我不用预测都知道2014它们会更加火热,加上易信、来往,各种支付以及各种手机厂商、各种云的乱入,2014将会上演更加精彩的业内诸企业争霸剧情,都忍不住想看了。

戏是大佬们演的好看,但还是得回到现实演好自己的屌丝泡沫剧。还是评评本屌丝泡沫剧的各种年度最佳抢镜:

年度抢镜关键词

  • 游戏:我有史以来专注在游戏行业上最多的一年,也更多地主动接触横跨端游、页游、手游各种游戏(我之前可不是个游戏迷)。工作上,负责away3d粒子编辑器编写,参与游戏编辑器的功能开发,这些都让我收获蛮多,业余上,基于cocos2d-x写了个三消游戏,也算学习了手游开发的流程,弥补了自己移动端的不足。

年度抢镜电子产品

今年是最低碳的一年,只添置了Amazon的kindle paperwhite,虽然仍有很多很酷的产品上线,但是貌似没促动我消费神经的产品?好吧,我不会告诉你其实是我没钱。。

  • mbp:这是前年的东东了,但是其实人家还没过时呢。装上osx10.9,各种崭新如初,写代码什么的各种方便,伦家unix系的就是霸道就是逼格高。额低调下,其实挺卡有时候,有钱了咱也升级。
  • ipad2:这是去年的,但是人家也没过时呢。升级ios7,依然各种顺畅崭新如初,各种场合看片游戏利器,加之百度网盘乱入,妈妈再也不用担心我看片不方便了。
  • kindle Paperwhite:其实这是老婆建议买的,但是万万没想到,因为翻页的拖延及闪烁,用惯了ipad的年轻人用起来不习惯,买后几乎是我在用,真是不幸中的万幸。借助它,我算是多看了点书(但是貌似还没把本钱看回来),而且看网页文章各种爽,还是得赞下amazon的send to kindle插件。

年度抢镜互联网产品

本来想分开pc和移动的,但是界限太模糊,不好操作。随着移动互联网的大势入侵,pc互联网很多都加大了移动互联网的打通力度,静候2014各种大战。

  • 微信:这个应该没有争议,因为它和新浪微博在国内大有统治之势头。在得入口者得天下这句话的号召下,如今业内可谓群雄并起,今年的第四季度易信、来往的突袭可见一斑。
  • 支付宝:新推出的余额宝让大佬们看到了网上支付可以这样玩期货,余额宝的成功将挑起更多的网上期货大战,诸如度娘的百度理财,加之微信微支付的乱入。唉,一想到这些战争就开心。
  • 百度网盘:打通web、pc、移动端的类dropbox,提供了2T空间让社会各界宅男乐开了花,有了2T的种子,他们的妈再也不用担心他们了吗?
  • 小米:暂且将小米归到互联网产品吧,因为人家不是说了互联网思维做产品嘛。不说什么,就冲3年弄出个100亿美金的公司,雷牛了。

年度抢镜业余作品

  • 三消游戏:基于cocos2dx做的一个手游,程序、美工、音效等等都自己包了,好累啊。
  • 微洛克:腾讯微博粉丝管理工具,帮微博运营的同学写的一个小工具。
  • 微信自动回复公共账号:微信号:musictee,叫我爱查歌词,提供歌词查询功能。

年度抢镜旅游

说到旅游,得说今年是悲催的一年,也就省内溜溜。

  • 福鼎太姥山:跟老婆和她得小伙伴们去的,因做为拎包员得以跟随。其实挺漂亮的那景色,要说也不比武夷山差多少,就是开发没跟上。

年度抢镜户外活动

  • 全程马拉松:参加了厦门国际马拉松,具体跑了多少就不说了,反正咱是在7个小时内,拿了牌的呢。好吧,还是说说吧,6个多小时,但是我是有理由的,中途吃了顿肯德基来着,不然,不然,走慢点也是6个多小时。说实话吧,都走那么慢了,脚还是酸了一周多的。

年度抢镜人物

  • 我老婆,还有我们的宝宝,要好好健康成长。
  • 老爸老妈,他们在变老,依旧奋战一线,做为儿子很是惭愧。

展望2014

  • 业余时间做2-3个手游;
  • 再多看四五本书;
  • 用好时间规划软件;
  • 努力赚钱,养家糊口。

读了“湿营销”后

实话说对营销这个东西没有什么概念,也就谈不上什么湿营销了。偶然在豆瓣上看到“湿营销”(作者Tom Hays和Michael S. Malone,曹蔓 译,见文章的插图)这本书,读者评价不错,就买了看看,也当做给自己空缺的一大片知识面填补一小块空白吧。基本上书本一半的内容是在上下班的地铁上看完的,所以可能错过细读一些精彩内容,有空继续补之,当然也不知道错过了多少与美女对视的惊险场面,给擦肩而过的美女们造成的不便之处敬请见谅(莫名自恋中。。弱弱地请帅哥们飘过~~)。好了,下面华丽地转正经切入主题。

看这本书是从三个推荐序看起的,看了第一个序“人是湿的”,觉得在瞎扯淡,而且是扯到蛋疼的那种,二序和三序还稍微让我懂了点那个啥湿营销;看完整书后再来看一序,还是觉得大部分在扯淡,但还是赞同了里边的“阴阳”论与“和而不同”论:这里描述的“阴阳”就是道教里阴阳结合,你中有我、我中有你的境界,但是阴和阳又有本质的区别,这样理解的话“阴阳”论也就与“和而不同”一个意思了。

作者从人类学、社会学、心理学的角度描述社会群体中的人的关系是趋向于亲密而自然的,这也是人性深处最本质的需求。人与人无论从思想、行动等等方面是有种种不同的,但又因为这种亲密自然的需求,就有了《周易.系辞》里的“方以类聚,物以群分”的道理。

“群分”不管是在原始社会里的部落还是现代社会的民族概念,或者讲小点到人们自发组成的各种兴趣爱好协会、小组、俱乐部等,这些都说明了人的“群分”本性。作者提到的一个有意思的人类学现象,人类的部落集群是有极限的,当一个组织机构的人数不断膨胀后,组织中人与人之间的直接交流会变得越来越困难,这样导致组织很有效率的交流及工作。

据研究,一个组织的人数一般在150人以内会保持效率及灵活性。这个在原始族群中就有明显的体现,在亚马逊里原始部落里,每个部落有一个萨满管理人们的生、死及族群发展的重大决定,而这个重大决定通常是关于族群的拆分,即把族群一分为二,这就是原始部落的组织拆分以方便首领的直接管理。同时从原始部落的集群还可以得出:一个人可以通过蜂窝式群体组织,让不同区域的人先组成较小的群体,而后较小的群体再组织成一个大圈子。

个人觉得马云的“Small is beautiful”的新型企业观点与以上这种群体的趋小化观点大同小异,只是马云说的是“Small is beautiful for 21st century”而已。这当然仍不能很好地解释SNS疯狂兴起的现象,但是不同的价值观、不同爱好等因素形成了SNS中不同的群体,不同的关注群组,这之中爆发的众多群体引爆了碎片化经济的圈子世界,开启所谓新的“湿营销”时代。

因为这本书主要讲的是湿营销,所以作者偏向的还是湿营销基于的所谓的新的互联网营销模式,而把传统的大众营销方式视为一定会被取代的模式,本人虽然也很不好意思地跟作者的观点类似,但是目前中国的传统的大众营销模式还是占据相当大的一部分市场的,这可能部分取决中国的消费者教育程度,因此在中国要谈新型网络营销完全取代传统营销仍有待时日,只能说前者在灰常迅速地奔跑。而传统大众营销由于一度地强奸用户,无论从电视、报纸、杂志,充满了人们不喜欢的“在广告中插播电视剧、在广告中插入新闻消息”等的硬性强加行为,估计会加速其灭亡。

在这个发展迅猛的碎片化经济时代,新型网络营销人员怎样为自己的产品做广告呢?书中讲的很大一部分也就是怎么融入各个有不同兴趣爱好,思想观点千差万别的群体们中。

作者从人们在社会群体中的极力维护群体观点(不管客观对错),排斥不同群体言论及成员,并竭力争取在群体中的地位以及群体中的个别观点或部分人观点如何通过明星效应等形成信息瀑的病毒式传播等等人类社会学观点,解释了SNS中群体间关系、消息的高速传播及SNS中很明显的明星效应,当然更重要的,所有的这些都是新型网络营销人员面临的挑战和机遇(承认这俩词好用且和谐)。个人觉得这部分精彩、描述的挺在理,毕竟接触的SNS看到的那些灰常厉害的明星效应、很尖锐的不同群体中的言论针锋相对(如twitter上针对那个啥裆的啥啥,有上推的笑而不语~)等等。

对碎片化经济时代的各种圈子现象的一大堆人类学阐述后,作者在后面的三篇分别从SNS用户消费者的思维,如何提供不同群体消费者所需,不冗余、不繁杂、不强硬(不小心搞出个“三不”,请原谅我的有才~)地参与SNS等网络媒介用户群体的讨论,并成为群体认同的成员切入,提出“身份即营销”的强大观点。

在湿营销时代一篇,讲到真实人性的回归,同样包含的人类学、社会学外加少许经济学的元素,讲到了“湿”的深层次含义,讲得我面红耳赤(请排除一切邪念阅读本句)。最后讲到湿营销的信任体系,也是营销人员如何融入立场坚定、极力排外的各种群体中最为基本的要素。

整书下来,人的社会群体生存之道、交流之道占书内容的很大部分,可以说很多观点都是围绕这个展开的,因此,看这本书是有点在学人类学、社会学、心理学的味道。这本书目前我只看了一遍,觉得看起来、理解起来还是通的,遍观现在的忒特、非死不可、新浪围脖等SNS或新型网络群体中的湿营销还是很常见的,说明新的碎片化经济是真的在迅猛发展。所以这书可以稍微关注下。

腾讯微博客邀请码发送

腾讯微博客邀请获取及使用方法:

1、如何获得邀请链接:以下有多个链接,请自取。(每个链接只能用一次,用过即失效,想获取更多链接,请你留下邮箱地址。)
http://t.qq.com/invite/767e6ec6e6bc1712f331

http://t.qq.com/invite/8519c41f10b6bdde6da9

http://t.qq.com/invite/9675033fa596d3ac96b3

http://t.qq.com/invite/16d3ca19f41c6f8a7f35

2、如何注册

点击以上链接即可注册。
注册成功之后,可以通过网页、手机和QQ(QQ2010Beta3)访问腾讯微博。

3、如何使用

3.1 在QQ客户端上使用

请点击这里下载最新的QQ版本
腾讯微博位于QQ主面板的第三个面板(注册成功之后显示)。

 

3.2 网页上使用

访问:http://t.qq.com/

3.3手机上使用

通过Wap:http://t.3g.qq.com

需求建立过程——让客户满意也让自己满意

本文纯属个人最近一次需求调研浅见,觉得本文肤浅、无价值的可游过~

注:之前一直从事幕后“积木搭建”工作,此次是第一次从需求调研开始到需求评审通过全程跟踪经历。在调研前,作者所属调研组计划在两周之内搞定需求过程,完成最终文档的评审工作,最后,现实花了我们一个月的时间完成预期的工作内容。

一、网上释义

对于需求调研,网上评价较高的相关文章是这样解释的:

1、需求调研是为需求说明书做前期工作,可以说需求说明书是从需求调研表中得到或抽取而出。

2、需求调研是要了解现实世界中做实际工作的人们真正需要什么样的程序的过程,再把这些需求进行细节整理由设计及开发部门设计开发,最后产出用户真正需要的产品。

二、需求文档的重要性及初期架设

结合以上解释,需求文档显然是重中之重,它将是需求的终极成果,在调研之初就要在做好最初架设工作。因此:

1、从需求调研开始调研者就应该对要呈现客户面前的需求文档结构(一般公司有提供模板)有一个清醒的认识;

2、在调研之初,根据合同要求的项目签订模块内容,架设自己脑中的项目原型(可以虚拟,至少有一个笼统性的意识);

3、把对项目的架设方案在文档中以清晰地层次关系记录编写,形成文档雏形(即使只有简单的各主标题、下层级标题的空文档)。

显然,在文档的初期架设并不是一个简单的过程,其中要求的一个很重要的条件是系统分析师必须对整个系统要有非常的深刻的认识,而且在对相关系统认识的面上要广。在作者接触的该需求过程中,因为之前都是完成逐个模块化功能完成“搭积木式”的开发工作,并没有对相关系统有一个全面深刻的认识,所以在需求文档的初步架设时,没能做好工作,也导致之后的需求调研会上的尴尬,吸取了不少经验教训。好在作者并不是一个人,强大的调研组让作者不用面对很多来自客户及第三方的尴尬。

三、建立、磨合与甲方项目负责人、相关人的关系

甲方项目负责人(以下简称项目负责人)负责整个项目的周期,负责系统研发过程中的甲方乙方的交流协同工作,是系统使用者与开发人员的沟通桥梁,把握好与项目负责人之间的微妙关系至关重要。项目相关人可能是上级领导、系统直接使用人、第三方开发者等,也直接关系到需求获取、变更、系统体验获取、改善等环节的交流,是项目研发过程不可缺少的成员,其重要性也可见一斑。至于如何把握好人际关系相信读者自有体会,在此不做相关讨论,作者只从项目需求角度作简要分析:

1、根据对甲方的预期需求的理解,针对不清楚之处,向项目负责人提出疑问,得到适当回答内容,做相应记录;

2、询问项目负责人相关项目的项目组人员,并由项目负责人介绍,会见相关人员;

3、初次会面时,针对相关人员、领导,介绍项目总体情况,征求相关意见并要求相关人员调研过程中给予配合,尤其是系统的直接使用者。

4、定期向项目负责人发送周报(非必要)。

四、做好每次调研会议计划

调研会议是需求调研中最为重要的环节,需求过程中所有的调研会议是需求获取的主要来源(其他来源还有项目负责人等,因为项目负责人对自己公司业务熟悉,对相关人员的业务描述较容易转化为系统实现,且会做相关的补充),要完成一次完美的调研会议,显然会议计划必不可少。基于本次的调研过程,作者认为调研会议计划需要注意:

1、系统分析人员事前必须非常清楚自己想要什么,要项目相关人员做些什么,要他们提供什么信息,这样才能有目的性的提出相关问题,避免偏题跑题的会议;

2、必须清楚本次调研内容的归口人,也就是说要有针对性地确定参会人员,每次会议都让一批人来听两个人的讨论会令人反感;

五、做好调研会的提问、讲解及演示

毫无疑问,这是调研人员必备素质,是调研过程中最为重要的内容。调研会议过程能体现出系统分析是的专业程度及项目分析方法的掌握程度,没有扎实的专业功底,在该环节会出现诸多尴尬,作者由于相关专业知识欠缺,便在这环节除了不少问题,此文就且当做经验之谈吧,寄望能在系统分析方面茁壮成长。基于本次各个调研会议,作者有以下认识:

1、提问时,对要问的问题有条理性,要想想当前功能点能否实现,之前是怎么实现的,可以怎么样实现等,相关功能点的提问尽量全面;

2、可以在提问的时候尽量引导客户往对项目和系统实际应用最佳的方式走,因为可能业务人员之前没用过相关系统,没有相关概念,很多标准是在需求时调研组帮客户定的,当然关键的是帮客户定的标准要保证充分的科学性;

3、在调研的提问、讲解及演示过程中,尽量少用业内专业术语,不要用系统研发方式语言跟客户进行交流,站在用户的角度提问、答问,这样才能让人知所以然,可能你觉得很简单的术语,在业务人员看来很生涩,这样会浪费更多的时间在解释上;

4、在交流过程中记得做关键点的记录,很多时候你觉得你明白的某个功能点经过几个小时的会议之后,又会是一片模糊,记得养成会议记录的习惯,这样不至于浪费更多的时间在同样问题上,而且方便需求获取的信息整理,方便需求文档的编写;

5、存在第三方接口的调研情况下,应该事先跟第三方达成一致,完后才跟客户进行确认、答疑,对客户或第三方提出不能实现的功能,给予回绝或转包;

6、需求讲解、演示的时候尽量抓重点讲,不用每个点都很细致地讲解,把握时间与会议内容的平衡,才不至于拖延会议时间或者没最终完成会议演示计划;

7、当客户谈及与系统无关或偏离系统需求的事情时,找适当时机把话题转回来,不要发生会议主题变质;

8、适当拉动调研会议气氛,让会议朝你想象的方向走。

六、需求文档该注意的

前面说过,需求文档是调研成果的体现,决不能在需求文档上含糊,需求文档是系统分析人员的基本功之一,系统分析人员应该把需求文档当成产品看待,让客户看到的各文档版本应该是可读、条理、规范、专业的产品化文档。作者在调研需求文档编写过程中,出现了很多专业分析员不应该出现的问题(作者目前非专业系统分析员),需求文档看上去只是很简单的一个文档,但是把调研过程的需求获取内容清晰有条理、以专业化的语言整合到一起,以文档形式展现,并非易事。在此暂不讨论需求文档如何编写之类问题,作者只谈需求整合过程中的感受:

1、每次调研会议结束后,理顺对每次的调研会议记录内容,根据会议内容对需求文档更新;

2、文档编写过程中,对功能点的描述尽量详细,有条理,让人知其所以然,做到让开发人员看到文档知道要做成什么样的功能,不要一笔带过、简单描述或内容杂糅。例如一个审批流程每个节点每个过程分点描述,不宜在一段话中描述一个流程从始至终的操作过程,这样会让阅读者感到吃力;

3、需求文档的编写是不断完善、不断改进的过程,不可能在一次的编写就完成主要功能点的描述,需要不断地鹅推敲、琢磨;

4、确认需求文档版本,保证每次提交给项目负责人及相关人员的文档版本不一样。

以上纯属作者实践后理论性理解,篇幅原因,文章较少实例分析,希望对阅读者略有帮助。

本文章归目油菜所有,转载请注明出处

关于WordPress固定链接自定义设置的问题

这是今天在WordPress后台设置中碰到的问题:

首页的所有文章点击评论、阅读全文等相关链接全部失效,因为之前忘数据库中导过备份,所以一直以为是数据的问题,试过多种设置,甚至把数据库导到本地环境。发现本地环境并没有相应的问题,而偏就它有问题了,这是为什么呢?

哈菜想了很久,最终,还是茫然,无奈,狠下心来,重新建个数据库,重装wp,一步一步测试,到底什么问题。

显然,刚装上的wp是没问题的,任你随便点都米问题。最后,让我点出灵感了,清晰地记得之前有设置过固定链接设置,于是乎,过去把固定链接自定义结构设置成之前设置的格式(哈菜设置成http://www.xiuchezu.com/2010/02/01/之类的格式),保存。再次首页秒点,果然,终于点不出来了,在回头改过来,保存,再秒点,果然,终于又出来了。最后,哈菜得出结论:问题就出在固定链接自定义格式上。可能是url解析之类的问题,种种原因,目前哈菜只是从很表面上解决问题,不晓得是不是wp的bug,望碰到相同问题已有更好解决方法或知其所以然的仁兄给以指点。

关于log4j.xml日志输出的配置

一、概述

在应用程序中添加日志记录总的来说基于三个目的:监视代码中变量的变化情况,周期性的记录到文件中供其他应用进行统计分析工作;跟踪代码运行时轨迹,作为日后审计的依据;担当集成开发环境中的调试器的作用,向文件或控制台打印代码的调试信息。 Log4j是Apache的一个开放源代码项目,通过使用Log4j,我们可以控制日志信息输送的目的地是控制台、文件、GUI组件、甚至是套接口服务器、NT的事件记录器、UNIX Syslog守护进程等;我们也可以控制每一条日志的输出格式;通过定义每一条日志信息的级别,我们能够更加细致地控制日志的生成过程。最令人感兴趣的就是,这些可以通过一个配置文件来灵活地进行配置,而不需要修改应用的代码。

二、实例简析

以下是某个系统log4j.xml具体的配置,在此以注释做简要解析,具体配置详述见详述说明:

<?xml version="1.0" encoding="GBK"?>
<log4j:configuration xmlns:log4j="http://jakarta.apache.org/log4j/" debug="false">
<!—================================================—>
<!— 控制台输出通道 —>
<!—================================================—>
<!—appender标签:设置通道A1和输出方式:org.apache.log4j.ConsoleAppender即控制台输
出方式—>
<appender name="A1">
<!—layout标签:定义输出样式—>
<layout>
<!—ConversionPattern参数:设置输出文件项目和格式—>
<param name="ConversionPattern" value="%d %-4r %-5p (%F:%L) %10c %3x - %m%n"/>
</layout>
<!—filter标签:滤镜设置输出的级别,此处设置的过滤最大和最小级别参数都为FATAL,
因此,在控制台输出的消息都为FATAL级别的消息—>
<filter>
<param name="levelMin" value="FATAL"/>
<param name="levelMax" value="FATAL"/>
</filter>
</appender>
<!—===================================================—>
<!— 文件输出通道 —>
<!—===================================================—>
<!—第二个appender标签:设置通道A2和输出方式:
org.apache.log4j.DailyRollingFileAppender即文件输出方式—>
<appender name="A2">
<!—设置File参数:日志输出路径及文件名:D:/DOCUMENT/logs/log.log—>
<param name="File" value="D:/DOCUMENT/logs/log.log"/>
<!—同第一个appender节点的layout标签—>
<layout>
<param name="ConversionPattern" value="%d %-4r %-5p (%F:%L) %10c %3x - %m%n"/>
</layout>
<!--filter标签:此处设置的过滤最小级别参数为WARN,最大级别参数为FATAL,
因此,在该日志文件输出的消息为WARN到FATAL级别的消息-->
<filter>
<param name="levelMin" value="WARN"/>
<param name="levelMax" value="FATAL"/>
</filter>
</appender>
<!—==============================================================—>
<!— category节点设置 —>
<!— category节点里边priority定义了相应类别相应级别以上的日 —>
<!— 志往appender传送,同时必须满足appender里边的最小输出级别 —>
<!—==============================================================—>
<category name="org.apache" additivity="true">
<priority value="WARN"/>
</category>
<category name="net.sf.hibernate" additivity="true">
<priority value="WARN"/>
</category>
<category name="com.sun.faces" additivity="true">
<priority value="INFO"/>
</category>
<category name="org.quartz.impl.jdbcjobstore" additivity="true">
<priority value="INFO"/>
</category>
<category name="com.opensymphony.oscache" additivity="true">
<priority value="WARN"/>
</category>
<!—===============================================================================—>
<!— root节点设置 —>
<!—设置接收所有输出的通道,当上面的category节点找不到相应的appender输出级别 —>
<!—设置的情况下,采用root节点里边的设置级别,同时采用的级别满足appender里 —>
<!—设置的最小级别,如此处设置warn,但A1这个appender设置的最小级别为FATAL, —>
<!—则采用的最小级别为FATAL —>
<!—===============================================================================—>
<root>
<priority value="WARN"/>
<!—appender-ref标签:定义日志输出的appender id—>
<appender-ref ref="A1"/>
<appender-ref ref="A2"/>
</root>
</log4j:configuration>

三、配置说明

(1).几个主要节点说明 appender里边filter定义了”levelMin”和”levelMax”,设置了最小和最大输出级别; category里边priority定义了什么级别以上的日志往appender传送,同时必须满足appender里边的最小输出级别; 当不配置category时,以root里边priority定义了什么级别以上的日志往appender传送,同时必须满足appender里边的最小输出级别,未在category范围内的输出日志遵照root里边级别; root里边appender-ref定义的是日志输出有哪些appender。

(2). 输出方式appender一般有5种: log4j提供了以下几种常用的输出目的地: org.apache.log4j.ConsoleAppender,将日志信息输出到控制台 org.apache.log4j.FileAppender,将日志信息输出到一个文件 org.apache.log4j.DailyRollingFileAppender,将日志信息输出到一个,并且每天输出到一个新的日志文件,按照不同的配置可以定义每月一个日志文件,或者每周,每天,每小时,每分钟等输出一个新的日志文件。 org.apache.log4j.RollingFileAppender,将日志信息输出到一个文件,通过指定文件的的尺寸,当文件大小到达指定尺寸的时候会自动把文件改名,如名为example.log的文件会改名为example.log.1,同时产生一个新的example.log文件。如果新的文件再次达到指定尺寸,又会自动把文件改名为example.log.2,同时产生一个example.log文件。依此类推,直到example.log. MaxBackupIndex,MaxBackupIndex的值可在配置文件中定义。 org.apache.log4j.WriterAppender,将日志信息以流格式发送到任意指定的地方。 org.apache.log4j.jdbc.JDBCAppender,通过JDBC把日志信息输出到数据库中。 org.apache.log4j.net.SMTPAppender,将日志信息以邮件的方式发送到指定的邮箱。

(3).appender中Layout标签说明 有时用户希望根据自己的喜好格式化自己的日志输出。Log4j可以在Appender的后面附加Layout来完成这个功能。Layout提供了四种日志输出样式,如根据HTML样式、自由指定样式、包含日志级别与信息的样式和包含日志时间、线程、类别等信息的样式等等。 其语法表示为: org.apache.log4j.HTMLLayout(以HTML表格形式布局), org.apache.log4j.PatternLayout(可以灵活地指定布局模式), org.apache.log4j.SimpleLayout(包含日志信息的级别和信息字符串), org.apache.log4j.TTCCLayout(包含日志产生的时间、线程、类别等等信息) PatternLayout 中ConversionPattern参数的格式含义如下:

%c 输出日志信息所属的类的全名

%d 输出日志时间点的日期或时间,默认格式为ISO8601,也可以在其后指定格式,比如:%d{yyy-MM-dd HH:mm:ss },输出类似:2002-10-18- 22:10:28 ;比如 %d{HH:mm:ss,SSS} 或 %d{dd MMM yyyy HH:mm:ss,SSS}格式可以参考 java类 SimpleDateFormat,不过按照此类的设置会影响速度。可以选择更快的方式%d{ISO8601},%d{ABSOLUTE}, %d{RELATIVE}.或者使用log4j的ISO8601DateFormat, AbsoluteTimeDateFormat,RelativeTimeDateFormat 和 DateTimeDateFormat 方式。

%f 输出日志信息所属的类的类名

%l 输出日志事件的发生位置,即输出日志信息的语句处于它所在的类的第几行

%m 输出代码中指定的信息,如log(message)中的message

%M 输出日志信息中所发生的方法名。

%n 输出一个回车换行符,Windows平台为“\r\n”,Unix平台为“\n”

%p 输出优先级,即DEBUG,INFO,WARN,ERROR,FATAL。如果是调用debug()输出的,则为DEBUG,依此类推

%r 输出自应用启动到输出该日志信息所耗费的毫秒数

%t 输出产生该日志事件的线程名
(4). 日记记录的优先级priority priority优先级由高到低分为: OFF ,FATAL ,ERROR ,WARN ,INFO ,DEBUG ,ALL。 Log4j建议只使用FATAL ,ERROR ,WARN ,INFO ,DEBUG这五个级别。 这几个级别声明如下: Logger.debug(Object message);//调试信息 Logger.info(Object message);//一般信息 Logger.warn(Object message);//警告信息 Logger.error(Object message);//错误信息 Logger.fatal(Object message);//致命错误信息

本文部分内容来自网上,有侵犯到您权益或发现错误内容请提出,将更正,目油菜保留部分内容得所有权。