女朋友练手作品~
Android&iOS Language Blog
之前写过一篇《写代码的四个境界》,那个时候,大部分时候我还是愉快地写着自己的代码。Code review 也是每天工作的一部分,但是相对而言花的时间还是有限的。
最近一是因为角色转换,二是突然来了很多新人。花在 code review 上的时间比写代码多出了好多,也有一些心得和感触,随便写写吧。
总的说来,硅谷稍具规模的公司 code review 的流程都是比较规范的。模式也差不多。一来所有的 PR 都必须有至少一个人 stamp,才能 merge。如果改的东西涉及到多个项目,则需要每个项目都有人 stamp 才行。还有一些特别关键的代码,比如支付相关的,通常也会需要支付组的人 stamp 才行。
NOTE: PR (pull request, a set of changes someone tries to push to a GitHub repository. Once a PR is sent, interested parties (peer engineers) can review the set of changes, discuss potential modifications, and even push follow-up commits if necessary.
在 stamp 前,通常是 github page 上可以给出各种 comments,page 是共享的,所以谁都能看到。有些 comments 是询问,那么代码作者直接回复或解释就行。有些 comments 是指出代码的问题,这样代码作者可能会依此改动;也可能不同意,那就回复 comments,有的时候关于一个实现细节,讨论的 comments thread 可以多达十几条。这样对于大家达成共识很有帮助。
以前遇到有朋友说:
“看到代码写的太烂,觉得来回扯皮效率不高,干脆扑上去自己写。”
曾经我也有过类似的想法。不过最近遇到的一些事让我慢慢地意识到这种想法很要不得。
首先就是从对方的角度来说。对方写不好,可能是对业务不熟悉,可能是对语言不熟悉,也可能是对公司代码的大架构不熟悉。如果你是帮他/她 “写” 而不是耐心指出哪里有问题,那么下一次,他/她可能还是不知道。不仅无益于别的人成长,有的时候甚至会让别人有挫败感。
再然后就是这种方式的可扩展性很差。即使 code review 会花掉哪怕十倍于你自己写的时间和精力,但它会让人明白代码应该怎么写,从长远来看,这其实是在一定程度上 “复制” 你的生产力。你不能什么都自己写。尤其是你慢慢开始带项目、带新人。每天 review 五个人的代码,和写五个人的代码,你觉得长期而言哪个更合算?
此外,如果说写代码是一个学习过程,怎么做一个好的代码审核人更是一个学习和成长的过程。自己绕过一个坑不难,难的是看到别人那么走,远远地你就能告诉他/她那里有个坑。而他/她在经你指出多次后,下一次他/她也会帮着指出别人的类似的问题。
这一点最近感触尤为深刻。前一阵组里咔咔咔接二连三来了好多新人,老大说,你少写点代码,多做点 review。于是那几天我几乎工作的一半时间都用来看代码,写 comments。可是最近就会发现,他/她们相互之间大部分时候已经可以很好的相互 review 了,于是我又腾出好一些时间来做别的工作。
Code review 做多了,发现其实也是有一定套路的,试着归纳如下:
1.代码格式方面。很多公司都有 coding style guideline。大家的约定俗成,避免公司的代码风格不一致,也避免一些不不要的为了 “要不要把闭括号另起一行” 而无谓地争论,除非是不小心,通常大家都不会弄错。但是新员工往往会在这方面还不太熟悉。这一类问题也比较容易指出。
2.代码可读性方面。这包括一个函数不要太长,太长就 break down。所有的变量名尽量能够说明它的用意和类型。比如 hosting_address_hash,一看就知道是房东地址,而且是个 hash 类型。不要有嵌套太多层的条件语句或者循环语句。不要有一个太长的 boolean 判断语句。如果一个函数,别人需要看你的长篇注释才能明白,那这个函数就一定有重构的空间。另外,如果不可避免有一些注释,则一定要保证注释准确且与代码完全一致。
3.帮代码作者想想他/她有没有漏掉任何 corner case。很多时候这是业务逻辑相关的,尤其需要比较老的工程师帮助指出需要处理的所有情况。
4.Error handling。这是最常见也是代码审核最容易帮别人看出的问题。举个例子,下面一段简单到不能再简单的代码就至少有三个潜在的问题:params 里面需要 validate 是不是有 user_id 和 new_name 这两个 key;能不能找到这个 user_id 对应的 user;save 的时候会不会有 DB level 的 exception,应该怎么处理。
5.测试例和防坑。测试例不用说了,每段代码都应该有测试例。但是对于一些你能预见如果别人改动代码会引起可能问题的情况,一定要额外的加测试例防止这种事情的发生。这一点没有例子参考也不太好说。怎么写好测试例,本身就值得写一篇文章了。
6.小架构。什么意思呢,就是一个文件或者类内部的代码组织。比如如果有重复的代码段,就应该提取出来公用。不要在代码里随意设常数,所有的常数都应该文件顶部统一定义。哪些应该是 private,等等
7.大架构。这个就更广了。包括文件组织,函数是不是应该抽象到 lib 或者 helper 文件里;是不是应该使用继承类;是不是和整个代码库的风格一致,等等。
当然,视具体情况可能还有很多别的需要在 code review 中注意的。但是如果按照这个 checklist 过一遍,一些明显的问题就可以避免个八九不离十了。
另外,代码 review 和写代码是我们每个工程师都应该致力的两个方面,缺一不可。可能在工作中的某个阶段或者某个项目里,你会花更多的时间在某一面,但长久看来,两个技能缺一不可。
代码审核是工作,不要抱有情绪化。我曾经干过一件事,一个外组同事的代码,别人已经 stamp 了,可是我觉得有问题,于是把 stamp revert 掉了,在 comments 里写了为什么有问题,和建议的改法。当时心里还有点觉得好像怪得罪人的。可是后来发现同事反而很客气地接受并道谢了。心里也是很感激有这样的工作环境。
另外,经常会遇到有些 review 的 comments 里出现不同意见,其实是两个人在编程习惯和约定俗成上没有共识。如果在不违背公司 style guideline 的情况下,没必要一定让对方和你有一样的习惯。如果你真的觉得这样更好,通常我也只会写 “I personally would prefer A over B, but no strong opinion.” 或者 “How about change it to A, since … However, this is not a merge blocker. ”
人都有不周到的时候。多几双眼睛一起帮你看一遍,就可以很大程度地减少代码里的错误。另外,相互 review 的过程中还能从彼此那里学到很多编程的小技巧和好习惯。细想来,很多 Java 和 Ruby 的特别好用的 feature,我都是在 code review 的过程中学到的。
一年一年、又一年!
1.元旦 微信 小范围内测朋友圈打赏看图片
2.支付宝 春节 集五福 、微信春晚 抢红包
3.滴滴、快递合并 移动支付大战 暂告一段落
4.直播大战&自媒体 一直播、秒拍 等 ,微博重新火热起来了
5.共享单车(经济) 摩拜、ofo(校园单车)…优拜?
6.乐视资金链、各大互联网裁员风波
7.小米Mix、苹果Watch二代、Air Pods耳机、三星note7 爆炸门、iPhone6s 电池门、锤子M1、M1L情怀不敌现实,要先活下去
8.高通821、3D曲面屏、iPhone7双摄、内嵌玻璃指纹、W1芯片
9.VR&AR Pokemon go、萌宠大作战(Ali山寨)、谷歌白日梦VR平台、
HTC VR
10.支付宝 圈子(校园日记) VR红包
11.p2p 借贷宝 等
12.游戏 手游份额日益增长(阴阳师) 守望先锋超越英雄联盟、电子竞技有望成为奥运赛事
13.网盘关闭、智能硬件不再火热
14.微信小程序 跨平台
15.知识付费 知乎live、分答
16.Google开发者平台,部分回归
靠谱的互联网,越来越少,不靠谱的事,越来越多,2016年互联网寒冬?!
概述
PC优化手段在Mobile侧同样适用
在Mobile侧我们提出三秒种渲染完成首屏指标
基于第二点,首屏加载3秒完成或使用Loading
基于联通3G网络平均338KB/s(2.71Mb/s),所以首屏资源不应超过1014KB
Mobile侧因手机配置原因,除加载外渲染速度也是优化重点
基于第五点,要合理处理代码减少渲染损耗
基于第二、第五点,所有影响首屏加载和渲染的代码应在处理逻辑中后置
加载完成后用户交互使用时也需注意性能
优化指南
[加载优化]
加载过程是最为耗时的过程,可能会占到总耗时的80%时间,因此是优化的重点
· 减少HTTP请求
因为手机浏览器同时响应请求为4个请求(Android支持4个,iOS 5后可支持6个),所以要尽量减少页面的请求数,首次加载同时请求数不能超过4个
a) 合并CSS、JavaScript
b) 合并小图片,使用雪碧图
· 缓存
使用缓存可以减少向服务器的请求数,节省加载时间,所以所有静态资源都要在服务器端设置缓存,并且尽量使用长Cache(长Cache资源的更新可使用时间戳)
a) 缓存一切可缓存的资源
b) 使用长Cache(使用时间戳更新Cache)
c) 使用外联式引用CSS、JavaScript
· 压缩HTML、CSS、JavaScript
减少资源大小可以加快网页显示速度,所以要对HTML、CSS、JavaScript等进行代码压缩,并在服务器端设置GZip
a) 压缩(例如,多余的空格、换行符和缩进)
b) 启用GZip
· 无阻塞
写在HTML头部的JavaScript(无异步),和写在HTML标签中的Style会阻塞页面的渲染,因此CSS放在页面头部并使用Link方式引入,避免在HTML标签中写Style,JavaScript放在页面尾部或使用异步方式加载
· 使用首屏加载
首屏的快速显示,可以大大提升用户对页面速度的感知,因此应尽量针对首屏的快速显示做优化
· 按需加载
将不影响首屏的资源和当前屏幕资源不用的资源放到用户需要时才加载,可以大大提升重要资源的显示速度和降低总体流量
PS:按需加载会导致大量重绘,影响渲染性能
a) LazyLoad
b) 滚屏加载
c) 通过Media Query加载
· 预加载
大型重资源页面(如游戏)可使用增加Loading的方法,资源加载完成后再显示页面。但Loading时间过长,会造成用户流失。
对用户行为分析,可以在当前页加载下一页资源,提升速度。
a) 可感知Loading(如进入空间游戏的Loading)
b) 不可感知的Loading(如提前加载下一页)
· 压缩图片
图片是最占流量的资源,因此尽量避免使用他,使用时选择最合适的格式(实现需求的前提下,以大小判断),合适的大小,然后使用智图压缩,同时在代码中用Srcset来按需显示
PS:过度压缩图片大小影响图片显示效果
a) 使用智图( http://zhitu.tencent.com/ )
b) 使用其它方式代替图片(1. 使用CSS3 2. 使用SVG 3. 使用IconFont)
c) 使用Srcset
d) 选择合适的图片(1. webP优于JPG 2. PNG8优于GIF)
e) 选择合适的大小(1. 首次加载不大于1014KB 2. 不宽于640(基于手机屏幕一般宽度))
· 减少Cookie
Cookie会影响加载速度,所以静态资源域名不使用Cookie
· 避免重定向
重定向会影响加载速度,所以在服务器正确设置避免重定向
· 异步加载第三方资源
第三方资源不可控会影响页面的加载和显示,因此要异步加载第三方资源
[脚本执行优化]
脚本处理不当会阻塞页面加载、渲染,因此在使用时需当注意
· CSS写在头部,JavaScript写在尾部或异步
· 避免图片和iFrame等的空Src
空Src会重新加载当前页面,影响速度和效率
· 尽量避免重设图片大小
重设图片大小是指在页面、CSS、JavaScript等中多次重置图片大小,多次重设图片大小会引发图片的多次重绘,影响性能
· 图片尽量避免使用DataURL
DataURL图片没有使用图片的压缩算法文件会变大,并且要解码后再渲染,加载慢耗时长
[CSS优化]
· 尽量避免写在HTML标签中写Style属性
· 避免CSS表达式
CSS表达式的执行需跳出CSS树的渲染,因此请避免CSS表达式
· 移除空的CSS规则
空的CSS规则增加了CSS文件的大小,且影响CSS树的执行,所以需移除空的CSS规则
· 正确使用Display的属性
Display属性会影响页面的渲染,因此请合理使用
a) display:inline后不应该再使用width、height、margin、padding以及float
b) display:inline-block后不应该再使用float
c) display:block后不应该再使用vertical-align
d) display:table-*后不应该再使用margin或者float
· 不滥用Float
Float在渲染时计算量比较大,尽量减少使用
· 不滥用Web字体
Web字体需要下载,解析,重绘当前页面,尽量减少使用
· 不声明过多的Font-size
过多的Font-size引发CSS树的效率
· 值为0时不需要任何单位
为了浏览器的兼容性和性能,值为0时不要带单位
· 标准化各种浏览器前缀
a) 无前缀应放在最后
b) CSS动画只用 (-webkit- 无前缀)两种即可
c) 其它前缀为 -webkit- -moz- -ms- 无前缀 四种,(-o-Opera浏览器改用blink内核,所以淘汰)
· 避免让选择符看起来像正则表达式
高级选择器执行耗时长且不易读懂,避免使用
[JavaScript执行优化]
· 减少重绘和回流
a) 避免不必要的Dom操作
b) 尽量改变Class而不是Style,使用classList代替className
c) 避免使用document.write
d) 减少drawImage
· 缓存Dom选择与计算
每次Dom选择都要计算,缓存他
· 缓存列表.length
每次.length都要计算,用一个变量保存这个值
· 尽量使用事件代理,避免批量绑定事件
· 尽量使用ID选择器
ID选择器是最快的
· TOUCH事件优化
使用touchstart、touchend代替click,因快影响速度快。但应注意Touch响应过快,易引发误操作
[渲染优化]
· HTML使用Viewport
Viewport可以加速页面的渲染,请使用以下代码
1
· 减少Dom节点
Dom节点太多影响页面的渲染,应尽量减少Dom节点
· 动画优化
a) 尽量使用CSS3动画
b) 合理使用requestAnimationFrame动画代替setTimeout
c) 适当使用Canvas动画 5个元素以内使用css动画,5个以上使用Canvas动画(iOS8可使用webGL)
· 高频事件优化
Touchmove、Scroll 事件可导致多次渲染
a) 使用requestAnimationFrame监听帧变化,使得在正确的时间进行渲染
b) 增加响应变化的时间间隔,减少重绘次数
· GPU加速
CSS中以下属性(CSS3 transitions、CSS3 3D transforms、Opacity、Canvas、WebGL、Video)来触发GPU渲染,请合理使用
PS:过渡使用会引发手机过耗电增加
###1、登录接口
请求地址:
account/dlu
请求参数:
请求方式:
Http/Get
请求实例:
http://xxx.xxx.xxx/account/dlu?name=xxx&password=xxxx
返回值:
|
|
|
|
###2、注册接口(手机号)
请求地址:
Account/zcheMobile
请求参数:
请求方式:
Http/Get
请求实例:
http://xxx.xxx.xxx/Account/zcheMobile?mobile=xxx&password=xxxx&&phonecode=1235&&agreeok=1
返回值:
|
|
|
|
###3、注册接口(邮箱)
请求地址:
Account/zcheEmail
请求参数:
请求方式:
Http/Get
请求实例:
http://xxx.xxx.xxx/Account/zcheEmail?email=xxx&password=xxxx&&validatecode=1235&&agreeok=1
返回值:
|
|
|
|
###4、校验用户名是否存在 用于注册
请求地址:
Account/ValidateUserName
请求参数:
请求方式:
Http/Get
请求实例:
http://xxx.xxx.xxx/Account/ValidateUserName?name=xxx
返回值:
|
|
|
|
###5、校验用户名 用于找回密码
请求地址:
Account/CheckName
请求参数:
请求方式:
Http/Get
请求实例:
http://xxx.xxx.xxx/Account/CheckName?name=xxx
返回值:
|
|
|
|
###6、校验手机验证码 用于找回密码
请求地址:
Account/ValidateCode
请求参数:
请求方式:
Http/Get
请求实例:
http://xxx.xxx.xxx/Account/ValidateCode?phone=xxx&&code=1234
返回值:
|
|
|
|
###7、修改密码 用于找回密码
请求地址:
Account/ChangePasswordNew
请求参数:
请求方式:
Http/Get
请求实例:
http://xxx.xxx.xxx/Account/ChangePasswordNew?phone=xxx&&SID=1234&&newpassword=11&confirmnewpwd=11
返回值:
|
|
|
|
###8、发送手机验证码
请求地址:
Account/CreateMobilePhoneCode
请求参数:
请求方式:
Http/Get
请求实例:
http://xxx.xxx.xxx/Account/CreateMobilePhoneCode?phone=xxx
返回值:
|
|
|
|
我在IT公司工作了六年,有着三年面试官的经历。在面试中,我发现很多人都不能写好一份求职简历,所以今天不谈iOS开发,谈谈如何写一份针对互联网公司的求职简历。
我主要想分享的内容包括:
简历的页数不要超过两页(最好一页)
删掉不必要的信息
如果你实在太牛逼,最多写2页
重要的信息写在最前面
你的联系方式
你最重要的工作经历
不要简单罗列工作经历
列出你的工作中有价值的细节(有哪些技术上的困难等)
不要写任何虚假或夸大的信息
类似精通java,精通C/C++等
不要附加任何可能带来负面印象的信息
不要加照片
不要写政治面貌
不要写奇怪的爱好(打游戏,喝酒,抽烟)
不要写参加过某某培训公司的iOS培训
尽量用专业邮箱
用PDF格式
###简历不要超过两页(最好一页)
互联网公司和传统企业有着很大的区别,通常情况下,创新和效率是互联网公司比较追求的公司文化,所以体现在简历上,就是超过一页的简历通常会被认为不够专业。
更麻烦的是,多数这种简历很可能在HR手中就被过滤掉了,因为HR每天会收到大量的简历,一般情况下每份简历在手中的停留时间也就10秒钟左右。而超过一页的简历会需要更多的时间去寻找简历中的有价值部分,对于HR来说,她更倾向于认为这种人通常是不靠谱的,因为写个简历都不懂行规,为什么还要给他面试机会呢?
那么我们应该如何精简简历呢? 简单说来就是一个字:删!
删掉不必要的自我介绍信息,很多求职者会将自己在学校所学的课程罗列上去,例如:C语言,数据结构,数学分析。。。好家伙,一写就是几十门,还放在简历的最上面,就怕面试官看不见。对于这类信息,一个字:删!面试官不Care你上了哪些课程,而且在全中国,大家上的课程也都大同小异,所以没必要写出来。
删除不必要的工作或实习、实践经历。如果你找一份程序员的工作,那么你参加了奥运会的志愿者活动,并且拿到了奖励或者你参加学校的辩论队,获得了最佳辩手这些经历通常是不相关的。诸如此类的还有你帮导师代课,讲了和工作不相关的某某专业课,或者你在学生会工作等等。删除不相关的工作、实习或实践内容可以保证你的简历干净。当然,如果你实在没得可写,比如你是应届生,一点实习经历都没有,那可以适当写一两条,保证你能写够一页的简历,但是那两条也要注意是强调你的团队合作能力或者执行力之类的技能,因为这些才是面试官感兴趣的。
删除不必要的证书:最多写个4、6级的证书,什么教师资格证,中高级程序员证,还有国内的各种什么认证,都是没有人Care的。
删除不必要的细节,作为iOS开发的面试官,很多求职者在介绍自己的iOS项目经历的时候,介绍了这个工程用的工作环境是Mac OS,使用的机器是Mac Mini,编译器是XCode4.x,能够运行在iOS4.3以上环境,还有一些人,把这个项目用到的开源库都写上啦,什么ASI, AFNetworking, Cocoapods啥的。这些其实都不是重点,请删掉。后面我会讲,你应该如何介绍你的iOS项目经历。
自我评价,这个部分是应届生最喜欢写的,各种有没有的优点都写上,例如:
性格开朗、稳重、有活力,待人热情、真诚;工作认真负责,积极主动,能吃苦耐劳,用于承受压力,勇于创新;有很强的组织能力和团队协作精神,具有较强的适应能力;纪律性强,工作积极配合;意志坚强,具有较强的无私奉献精神。对待工作认真负责,善于沟通、协调有较强的组织能力与团队精神;活泼开朗、乐观上进、有爱心并善于施教并行;上进心强、勤于学习能不断提高自身的能力与综合素质。
这些内容在面试的时候不太好考查,都可以删掉。通常如果有HR面的话,HR自然会考查一些你的沟通,抗压,性格等软实力。
我相信,不管你是刚毕业的学生,还是工作十年的老手,你都可以把你的简历精简到一页A4纸上。
###重要的信息写在最前面
将你觉得最吸引人的地方写在最前面。如果你有牛逼公司的实习,那就把实习经历写在最前面,如果你在一个牛逼的实验室里面做科研,就把研究成果和论文写出来,如果你有获得过比较牛逼的比赛名次(例如google code, ACM比赛之类),写上绝对吸引眼球。
所以,每个人的简历的介绍顺序应该都是不一样的,不要在网上下载一个模板,然后就一项一项地填:教育经历,实习经历,得奖经历,个人爱好,这样的简历毫无吸引力,也无法突出你的特点。
除了你的个人特点是重要信息外,你的手机号,邮箱,毕业院校,专业以及毕业时间这些也都是非常重要的,一定要写在简历最上面。
###不要简单地罗列工作经历
不要简单地说你开发了某某iOS客户端。这样简单的罗列你的作品集并不能让面试官很好地了解你的能力,当然,真正在面试时面试官可能会仔细询问,但是一份好的简历,应该省去一些面试官额外询问你的工作细节的时间。
具体的做法是:详细的描述你对于某某iOS客户端的贡献。主要包括:你参与了多少比例功能的开发? 你解决了哪些开发中的有挑战的问题? 你是不是技术负责人?
而且,通过你反思这些贡献,你也可以达到自我审视,如果你发现这个项目你根本什么有价值的贡献都没做,就打了打酱油,那你最好不要写在简历上,否则当面试官在面试时问起时,你会很难回答,最终让他发现你的这个项目经历根本一文不值时,肯定会给一个负面的印象。
###不要写任何虚假或夸大的信息
刚刚毕业的学生都喜欢写精通Java,精通C/C++,其实代码可能写了不到1万行,我觉得你要精通某个语言,至少得写50万行这个语言的代码才行,而且要对语言的各种内部机制和原理有了解。那些宣称精通Java的同学,连Java如何做内存回收,如何做范型支持,如何做自动boxing和unboxing的都不知道,真不知道为什么要写精通2字。
任何夸大或虚假的信息,在面试时被发现,会造成极差的面试印象,所以你如果对某个知识一知半解,要么就写“使用过”某某,要么就干脆不写。如果你简历实在太单薄,没办法写上了一些自己打酱油的项目,被问起来怎么办? 请看看下面的故事:
我面试过一个同学,他的面试时非常诚实,问他一些简历上的东西,他如果不会,就会老实说,这个我只是使用了一下,确实不清楚细节。对于一些没有技术含量的项目,他也会老实说,这个项目他做的工作比较少,主要是别人在做。最后他还会补充说,“我自认为自己数据结构和算法还不错,要不你问我这方面的知识吧。”
这倒是一个不错的办法,对于一个没有项目经验,但是聪明并且数据结构和算法基础知识扎实的应届生,其实我们是非常愿意培养的。很多人以为公司面试是看经验,希望招进来就能干活,其实不是的,至少我们现在以及我以前在网易招人,面试的是对方的潜力,没有项目经验根本关系不大。
总之,不要写任何虚假或夸大的信息,即使你最终骗得过面试官,进了某公司,如果能力不够,在最初的试用期内,也很可能因为能力不足而被开掉。
###不要附加任何可能带来负面印象的信息
任何与招聘工作无关的东西,尽量不要提。有些信息提了可能有加分,也可能有减分,取决于具体的面试官。而有些信息大部分情况下都是减分的,我罗列一下我认为是减分的信息。
不要在简历中附加个人照片。个人长相属于与工作能力不相关的信息,也许你觉得你长得很帅,那你怎么知道你的样子不和面试官的情敌长得一样? 也许你长得很漂亮,那么你怎么知道HR是否被你长得一样的小三把男朋友抢了? 我说得有点极端,那人们对于长相的评价标准确实千差万别,萝卜青菜各有所爱,加上可能有一些潜在的极端情况,所以没必要附加这部分信息。这属于加了可能有加分,也可能有减分的情况。
不要写你的政治面貌。你以为现在互联网公司还看重你是否是D员吗? 就算看重,你怎么知道他们认为这是加分还是减分? 我知道有一家公司,只要是D员的都直接拒掉。所以,除非你是面试的国企,在互联网公司,这一条最好不要写,写了有可能是平分,也有可能是减分,加分的可能性极小。
不要写各种奇怪的爱好。喜欢打Dota,喝酒,这类可能带来负面印象的爱好最好不要写。的确有些公司会有这种一起联机玩游戏或者喝酒的文化,不过除非你明确清楚对于目标公司,写上会是加分项,否则还是不写为妙。(顺便说一句,据我了解,阿里的朋友特别喜欢喝酒,面试阿里写上这个可能是加分的,但如果你要是遇到阿里里面正好不喝酒的Team或面试官,不要怪我。)
不要使用word格式的简历,使用PDF的格式。我在招iOS程序员时,好多人的简历都是Word格式的,mac下的office那么难用,公司好多人机器上都没有mac office。我真怀疑这些人真是的想投简历么? PDF格式的简历通常能展现出简历的专业性。
不要使用QQ号开头的QQ邮箱,例如 12345@qq.com ,邮箱的事情我之前简单说过,有些人很在乎这个,有些人觉得无所谓,我个人对用数字开头的QQ邮箱的求职者不会有加分,但是对使用gmail邮箱的求职者有加分。因为这涉及到个人的工作效率,使用gmail的人通常会使用邮件组,过滤器,IMAP协议,标签,这些都有助于提高工作效率。如果你非要使用QQ邮箱,也应该申请一个有意义的邮箱名,例如 tangqiao@qq.com 。相关的讨论可以参见知乎上的讨论:《用人单位拒绝聘用使用 QQ 邮箱发应聘邮件的求职者,这一行为是否合理?》
不要写参加过某某培训公司的iOS培训,特别是那种一、两个月的速成培训。这对于我和身边很多面试官来说,绝对是负分。面试当中,经验是一个考查点,但是学习能力比经验重要多了,如果你是参加培训学习的iOS开发,很可能说明你没有自学能力。这一点似乎很多人都没有搞清楚,大家可以看看 @老赵 在他的个人博客上发表的 《为什么我要反对北大青鸟》。 我在2年前也写过一篇博客《我们必须自学》,详细解释了我的看法。
Posted by 唐巧 Dec 22nd, 2013 summary
Introduction
http://square.github.io/picasso/
Images add much-needed context and visual flair to Android applications. Picasso allows for hassle-free image loading in your application—often in one line of code!
|
|
Many common pitfalls of image loading on Android are handled automatically by Picasso:
Handling ImageView recycling and download cancelation in an adapter.
Complex image transformations with minimal memory use.
Automatic memory and disk caching.
Sample application screenshot.
Features
ADAPTER DOWNLOADS
Adapter re-use is automatically detected and the previous download canceled.
IMAGE TRANSFORMATIONS
Transform images to better fit into layouts and to reduce memory size.
You can also specify custom transformations for more advanced effects.
Pass an instance of this class to the transform method.
PLACE HOLDERS
Picasso supports both download and error placeholders as optional features.
Picasso.with(context)
.load(url)
.placeholder(R.drawable.user_placeholder)
.error(R.drawable.user_placeholder_error)
.into(imageView);
A request will be retried three times before the error placeholder is shown.
RESOURCE LOADING
Resources, assets, files, content providers are all supported as image sources.
Picasso.with(context).load(R.drawable.landing_screen).into(imageView1);
Picasso.with(context).load("file:///android_asset/DvpvklR.png").into(imageView2);
Picasso.with(context).load(new File(...)).into(imageView3);
DEBUG INDICATORS
For development you can enable the display of a colored ribbon which indicates the image source. Call setIndicatorsEnabled(true) on the Picasso instance.
Debug ribbon indicators
Download
↓ v2.5.2 JAR
The source code to the Picasso, its samples, and this website is available on GitHub.
MAVEN
GRADLE
compile ‘com.squareup.picasso:picasso:2.5.2’
Contributing
主要讲解Android Studio中生成aar文件以及本地方式使用aar文件的方法。
在Android Studio中对一个自己库进行生成操作时将会同时生成.jar与.aar文件。
分别存储位置:
两者区别:
*.jar:只包含了class文件与清单文件,不包含资源文件,如图片等所有res中的文件。
*.aar:包含所有资源,class以及res资源文件全部包含
如果你只是一个简单的类库那么使用生成的.jar文件即可;如果你的是一个UI库,包含一些自己写的控件布局文件以及字体等资源文件那么就只能使用.aar文件。
使用方式:
*.jar:拷贝到:libs目录,eclipse直接导入即可,AndroidStudio项目中添加:
dependencies {
compile fileTree(include: ['*.jar'], dir: 'libs')
}
重新编译一次项目既可完成加载。
*.aar:有两种方式,分别为本地加载以及网络加载,由于网络加载涉及到发布到mavenCentral托管的问题这里不做讨论;另外eclipse很久没有使用了也不做讨论;在这里给大家说一种本地加载的方式,简单快捷。
这里演示的aar文件为:”genius.aar“
第一步:拷贝到:libs目录
第二步:build.gradle 配置文件中更改为
repositories {
flatDir {
dirs 'libs'
}
}
dependencies {
compile(name:'genius', ext:'aar')
}
分别添加了”repositories“与更改了”dependencies“,然后重新编译一次项目就可以正常使用了。
这时打开你的项目地址”uildintermediatesexploded-aar“你会发现下面多了一个文件夹”genius“打开后能看见里边包含了一个”classes.jar“文件与一些资源文件和”R.txt“文件。
\
这就是Android Studio自动解析了aar文件后出现的东西。
前言
这两天看到一篇文章很火,详细见:http://stormzhang.com/android/2015/03/01/android-reference-local-aar/
我大概看了下,然后搜索了下相关资料,作者说的没有错,我很欣赏这种行为,其实是已经在Google上搜刮过了,然后进行总结写文章。就如作者说的,就算官网上对于aar的描述也是凤毛菱角。简单来讲,jar包中封装的大多是一些方法,但是aar其实就是一个完整的Android App,所以包括了所有的资源文件等,我们可以很好的使用已经封装好的一些风格,包括UI界面显示等。
感谢作者的文章,我也是看了之后想试试看例子,不过网上找了一圈,发现都是在Gradle正式release前的例子,所以就还是自给自足啦。
创建一个aar
既然我们要做,首先先创建一个aar包咯。本次的demo全部是本地化的引用。首先我们new一个新的Module出来。
我们新建了一个Android Library,我们从结构中可以看出和一个Android App的Project没有什么区别。
唯独的区别在于build.gradle,需要定义apply plugin: ‘com.android.library’,告诉studio这是一个library。定义如下:
apply plugin: ‘com.android.library’
android {
compileSdkVersion 22
buildToolsVersion “22.0.0”
defaultConfig {
minSdkVersion 10
targetSdkVersion 22
versionCode 1
versionName "1.0"
}
buildTypes {
release {
minifyEnabled false
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
}
}
}
dependencies {
compile fileTree(dir: 'libs', include: ['*.jar'])
compile 'com.android.support:appcompat-v7:22.0.0'
}
我们现在来修改下我们的主方法,添加一个如下的方法(记得还是修改下主类名):
public static void DisPlayToast(Context context){
Toast.makeText(context,"this is aar toast",Toast.LENGTH_LONG).show();
}
接着我们就可以来编译啦。进入library,执行gradle assembleDebug,接着我们可以在~/AndroidLibrary2/mylibrary/build/outputs/aar/目录下找到我们编译好的aar文件。是不是很简单
本地加载aar
我们有了aar之后,将这个文件放入我们app工程的libs目录下,这样我们就可以进行调用啦。修改app的build.gradle如下:
apply plugin: 'com.android.application'
android {
compileSdkVersion 22
buildToolsVersion "22.0.0"
defaultConfig {
applicationId "com.example.monkey.androidlibrary2"
minSdkVersion 17
targetSdkVersion 22
versionCode 1
versionName "1.0"
}
buildTypes {
release {
minifyEnabled false
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
}
}
}
repositories {
flatDir {
dirs ‘libs’
}
mavenCentral()
mavenLocal()
}
dependencies {
compile(name:'mylibrary3-debug', ext:'aar') //这里我因为尝试了几次,所以都是数字编号了,大家可以无视
compile fileTree(dir: 'libs', include: ['*.jar'])
compile 'com.android.support:appcompat-v7:22.0.0'
}
开始对app进行编译,这样的话工程会自动将这个aar文件解析出来。使用gradle assembleDebug。我们可以看到在/app/build/intermediates/exploded-aar/目录下已经有了我们增加的aar包的文件引用。如下
修改app代码如下
其实从maven和jcenter()上下载也是一个逻辑,没有什么太大区别。只不过貌似在Gradle 1.0之前本地引用是有bug的。
代码地址:https://github.com/monkeytest15/Gradle_aar/tree/master/AndroidLibrary2
后续
我发现我sdk更新的不完善,我表示我要回家更新完整之后再做后续的讨论了。
缺失模块。
1、在博客根目录(注意不是yilia根目录)执行以下命令:
npm i hexo-generator-json-content --save
2、在根目录_config.yml里添加配置:
jsonContent: meta: false pages: false posts: title: true date: true path: true text: true raw: false content: false slug: false updated: false comments: false link: false permalink: false excerpt: false categories: false tags: true