经验272 米
在线时间0 小时
版本V7.2.2.0.KHICNDA
积分 285, 距离下一级还需 215 积分
积分 285, 距离下一级还需 215 积分
机型红米Note 4G版
MIUI版本V7.2.2.0.KHICNDA
V8.2.2.0.NAACNEB
升级后感觉不如以前流畅 有的应用有点卡
分享到微信朋友圈
打开微信，点击底部的“发现”，使用 “扫一扫” 即可将网页分享到我的朋友圈。
已关联31个BUG提交人处理状态
经验1763 米
在线时间68 小时
版本7.6.20
机型未知设备
签到次数113
MIUI版本7.6.20
您好，看了一下您的日志，主要是刚升级完成，应用都在后台升级自身内容导致的，一段时间后就不会存在同样的问题了。
此外，观察到您在使用猎豹清理大师的时候，卡住了整整5.6秒，从日志里看到，是猎豹自己在后台更新内容没更新完，前台在等待导致，属于猎豹自己的问题。
Copyright (C) 2017 MIUI
京ICP备号 | 京公网安备34号 | 京ICP证110507号赞同最多的答案还是更多在初级理论上的说明，实战不足，为了防止误导太多人，详细解释下我的看法。&br&&br&其他答案主要集中在&br&1. 布局太深 &br&淘宝、支付宝这个根本不算复杂布局，自己写个类似的布局就知道了，这么点层次根本不会有如此明显的卡顿 。&br&而且淘宝的卡顿不仅在页面加载时。&br&&br&只要有过一两年开发经验的，知道界面卡顿只是表象，就能理解这个问题不是简单的界面渲染所致。&br&&br&2. 图片造成 GC &br&先搞清楚 young GC 和 full GC 的区别及耗时差异，我就问一个问题，大部分图片会被 young GC 还是 full GC 回收？&br&&br&另外大多数图片缓存对 GC 的影响几乎没有区别，只要不和明显有内存泄露的写法对比。&br&&br&对于目前的系统来说，young GC 的耗时对性能影响很小。&br&&br&这两方面原因会有，但绝对不是主要的，甚至影响很小！！&br&&br&说下我觉得主要的原因&br&1. 任务过多且执行调度不够好&br&根据评论反馈解释下：这里的任务调度不是线程调度，是对所有任务执行时机、在哪个线程执行、最大并发数等的总称。毕竟系统资源(CPU、IO、网络等)有限、移动端更甚，主线程也有 ANR。&br&&br&任务也包括很多，不列举，大家可以想想自己做过的大项目中的各种任务。&br&&br&他们会发生在很多时刻，启动、页面跳转、按钮点击、定时任务等，绝大部分还是发生在我们看不见的后台。&br&&br&至于为什么变成这样，我觉得有几方面原因&br&(1) 历史原因&br&老代码及设计的原因&br&(2) 业务太多&br&(3) 团队及成员太多&br&太多代码合并及插入。&br&(4) 个别程序员问题&br&个别人的渣代码&br&&br&上面四点是个人根据一般大项目中常有问题的猜测，未实际证实，但应该相差不多。
赞同最多的答案还是更多在初级理论上的说明，实战不足，为了防止误导太多人，详细解释下我的看法。 其他答案主要集中在 1. 布局太深 淘宝、支付宝这个根本不算复杂布局，自己写个类似的布局就知道了，这么点层次根本不会有如此明显的卡顿 。 而且淘宝的卡顿…
我竟然无聊到想去找找看AppStore和GooglePlay上都有哪些同样的ICON……&br&&br&是这样题主，如果要去美国告，你需要赶在Google之前注册美国区关于这个ICON设计的专利。这个专利是分国家地区的，你在美国打官司就需要用到在美国注册的专利。然而我也不清楚你自己的这个风车在中国有没有注册过……反正按常识走这条路是来不及了。&br&但更重要的是，这两个图案从相似度来说……至少在中国和美国的法律里都构不成抄袭。&br&&br&那么你只好曲线救国，比如去美国注册一些关于“某种行为”的专利（也有可能已经被别人注册了）相比专利来说，“谁先做出来/谁先想出来”这种事情真的不重要。你看人家苹果，每次都是看到哪个公司做出个什么新产品然后就跑去注册个相关专利回来搞人。&br&&br&注意，专利描述需要非常准确并且又模棱两可才能无懈可击。那么你打算写个什么样的专利描述呢？&br&&br&1、“将红蓝黄绿4色风车图案作为设备（描述所有移动电子设备等）应用图标”&br&Google：4色？你瞎吗？我们的中间有个白色块你看到不&br&2、“将红蓝黄绿，中间空隙为白色，5种颜色构成的风车图案作为设备（描述所有移动电子设备等）应用图标”&br&Google：其实加上白色块，我们这个图标也不光是五种颜色，你看每个叶片上都是分为两种颜色的。（你再来我把所有渐变色一个像素一个像素列给你看。）&br&&br&这时候你一定已经发现过于详细的专利描述命中率实在太低。于是你决定精简描述，希望自己的专利能甩出地图炮的效果：&br&3、“将风车图案作为设备上的应用图标”（这样能不能注册下来我真不知道了）&br&Google：滚你麻痹谁告诉你我这个是风车啦。&br&&br&要成为专利巨魔，你首先要有很多钱把自己能想到的关于这个ICON的所有描述都注册一遍，你要有很多钱来维护海量的专利库，即使不考虑公关和诉讼方面的预算，在打赢一笔大官司前也要忍受长期的巨额支出，一旦熬成婆就是三年不开张，开张吃三年。&br&&br&然而我估计你能想到用来对付Google的专利早就被苹果注册了。&br&他们手上这种无聊专利几千几万，堪称核武库。&br&当年欺负Android阵营小弟的时候用的各种“吃饭要用嘴”专利，简直无敌：&br&&br&对HTC&br&“手机上能安装应用程序”&br&“手机上能打开文件”&br&“手机能通过有线或无线的方式传输数据”&br&&br&对三星&br&“手机左右边框到手机屏幕边缘距离相等”&br&“手机应用图标以矩阵排列”&br&“手机正面是个圆角长方形，上面有一个屏幕，屏幕下方有一个按钮”（专利中描述了此按钮形状的所有可能性，连三角形都没放过）&br&&br&甚至在柯达申请破产保护时苹果还从草丛里跳出来补了一刀：&br&“设备上有一个屏幕可用于预览已拍摄的照片”&br&&br&你要知道的是，如果你想在美国告Google，你最大的竞争对手其实是苹果。&br&&br&———最后———&br&&br&如果要在中国告，除了上述方案以外你还可以去查查看Google有没有在中国区注册这个风车图标，要是没有的话赶紧拿他自己这个图标抢注一个。到时候Google带着Photos正式进中国市场了你就可以讹他一笔。&br&&br&———坠吼的坠吼———&br&&br&刚看了你在问题中补充的回复。我也再补充一点点吧。&br&1、Google Photos作为独立应用也有很长时间了，两年啃腚是有的，具体时间我不记得。这一次的I/O主要是说弱化了它和Google Plus之间的关系并且一定程度上重新设计了这个相册的使用方式。而不是你印象中的“刚刚从Google Plus的内置功能变为独立应用”。&br&&br&（这里说的”Photos从Google Plus独立出来“，你可以理解为所谓的”湾湾独立“指的是湾湾要减少对中华人民共和国的某种依赖，独立自强，而不是说他们要独立成一个国家，因为他本来就是一个独立的主权国家——中华民国）&br&&br&2、关于赔偿的问题，现在我们假设Google的风车ICON确实100%都是复制了你的设计，完全侵犯了你的知识产权。那么你需要向法院证明Google通过侵权行为获得的非法收益以及这种侵权行为对你造成的实际经济损失。因为Photos并非盈利项目，并且你的应用也没有因Google的侵权行为遭受损失。所以最终你可能很难得到期望的赔偿金额，甚至得不偿失。你可以要求Google停止侵权行为（最多就是Google不再使用这个ICON）也可以要求Google花钱买下你版权地区的ICON使用权。但如果你开价太高的话他们只要做个新的ICON甚至稍微在原基础上改一下细节就能避开你的专利了。&br&&br&3、无关乎是不是大专生，我也觉得题主还是需要再提高一下各方面的姿势水平——具体哪方面呢？关于设计方面的鉴别水平？其他专业水平？关于知识产权的认知？或者在某些心态方面？总之你根据自己的需要来选择即可。对于这个问题本身，大家的回答中有许多嘲讽也不奇怪。（我的回答不也是有嘲讽的意思吗）事实上虽然这些话对问题本身不一定有帮助。但排除情感色彩，他们当中的一些看法相比你在评论中提出的观点，（我个人认为）他们的可能更正确一些。当然你如果能从各种不同的态度和非正面评价中选择得到真正对自己有益的那部分信息，这是坠吼的。
我竟然无聊到想去找找看AppStore和GooglePlay上都有哪些同样的ICON…… 是这样题主，如果要去美国告，你需要赶在Google之前注册美国区关于这个ICON设计的专利。这个专利是分国家地区的，你在美国打官司就需要用到在美国注册的专利。然而我也不清楚你自己的…
首先，Java基本没问题是不是太自信了。Java的集合框架，多线程并发，NIO/AIO，JVM相关比如GC，内存模型等等搞清楚了没有；学一门语言不是仅仅学会调用一些简单的API。&br&&br&算法用什么实现没有任何关系，用C能写出来，Java也是分分钟。&br&&br&针对你的打算：&br&1. 数据库没有那么重要，可能在Android里面对应的就是ContentProvider，但是用的不频繁，对于应届生了解即可。&br&2. 脚本语言有精力学习比较好，属于锦上添花；鉴于你大四了，时间不多，还是一门心思Android吧。&br&3. 设计模式也没那么重要，懂些简单常用的，比如单例，观察者，委托，代理等即可；不要陷入无法自拔。&br&4. 英文很重要！！百度的搜索结果和google的能同日而语吗，最前沿的技术都是英文写的，可以不会写不会说，但是必须看得懂。&br&&br&然后说说Android。&br&完成App当然可以，但是Android开发远远不止完成一些界面那么简单。如果你能在面试的时候说出一些系统的原理，我相信一定会惊艳。&br&1. Thread/Handler/Looper机制&br&2. Android系统View的绘制流程&br&3. View的事件传递机制；了解以上两点，能给面试官讲清楚作为一个应届生就很不错了；很多工作了的都不完全知道；更深入的，&br&4. Activity的启动流程，ActivityManagerService，PackageManagerService等如何工作的&br&5. 结合4，尝试了解一些Android的IPC机制，如果你能对Binder讲个头头是道，Special Offer等着你。&br&6. DexClassLoader机制，延伸到插件框架，基本算是前沿技术之一，如果你能走到这一步，那么惊为天人。&br&&br&一年时间不多，以上除了第一点，每一个搞清楚都需要相当的精力；特别是Binder于许多其他的知识相关联；不要一口吃成一个胖子，精力也不要分散，做好一点即可。比如，主攻View，搞清其中的原理，写出酷炫的动画，还愁没人要？
首先，Java基本没问题是不是太自信了。Java的集合框架，多线程并发，NIO/AIO，JVM相关比如GC，内存模型等等搞清楚了没有；学一门语言不是仅仅学会调用一些简单的API。 算法用什么实现没有任何关系，用C能写出来，Java也是分分钟。 针对你的打算： 1. 数据库…
谢邀。&br&&br&我们这边社招常年在招人，5月份的时候还入职了两名实习生。前段时间实习生招聘，也锁定了一些优秀的同学，虽然很多最终没有入职，但都在保持联系，平时也会经常交流，秋招的时候我会帮忙内推。就我自己的感受来说，这两年没什么区别，基本每周都会有猎头或者HR通过微信、LinkedIn、知乎等途径联系到我，一开口都是去做技术经理，年薪60W+期权。我目前并没有跳槽的打算，全都直接谢绝了。&br&最近面了一些社招的同学，基本都是所在公司的技术骨干。从简历和面试的过程，看的出来他们都很努力，做了很多工作，不停的在学习，其中有些工作了6，7年的同学，看能力都到不了T2-3的水准，最后面试也没有通过。差距在学生时代还不明显，工作了以后随着整个工作，环境，项目，自身能力等，不停的放大，到工作几年之后，差距已经不可逆转。&br&所以饱和其实是个伪命题，就像很多朋友说的，只是你的水准达不到公司要求罢了。移动开发经过了这么多年的发展，开始从井喷进入到了稳定阶段，之前随便做个DEMO或者培训两个月就能找到工作的时代过去了，仅此而已，大浪淘沙，真有能力的人完全不用担心什么。&br&在之前的回答中（&a href=&/question//answer/& class=&internal&&&span class=&invisible&&https://www.&/span&&span class=&visible&&/question/3927&/span&&span class=&invisible&&4138/answer/&/span&&span class=&ellipsis&&&/span&&/a&）我表达过一个观点：&br&&blockquote&一名优秀的开发者首先是一个优秀的人，能淹死在现在茫茫开发人员中的人，我相信做别的事情也很难脱颖而出。&br&&/blockquote&现在我还是持有这样的观点，并且从中推导出的二八定律同样适用于开发者：&b&20%的人拿到80%的Offer, 剩下80%的人争抢20%的工作。&/b&开发者的能力本来就有差别，即使进入到移动开发的稳定阶段，有人还是Offer收割机，更多的人还是找不到好工作，很残酷，但这就是现实。&br&我的天赋并不高，但走到现在各方面至少不算太差，如我身上真的有些优点，我认为是对自己的定位清晰，善于规划，思考并且有执行力。说了这么多，希望题主能对大环境和自己都有个准确的认识，根据自己的定位，找到合适自己的学习方法，并且真正努力的去做，我相信能做到这些，已经超越了大部分人。当然如果题主对自己的能力有信心，我们这常年招聘，如不嫌弃，请投递简历。&br&&br&PS:&br&如果还有个人问题欢迎通过值乎提问：&a href=&/zhi/people/810368& class=&internal&&&span class=&invisible&&https://www.&/span&&span class=&visible&&/zhi/people/72&/span&&span class=&invisible&&0368&/span&&span class=&ellipsis&&&/span&&/a&
谢邀。 我们这边社招常年在招人，5月份的时候还入职了两名实习生。前段时间实习生招聘，也锁定了一些优秀的同学，虽然很多最终没有入职，但都在保持联系，平时也会经常交流，秋招的时候我会帮忙内推。就我自己的感受来说，这两年没什么区别，基本每周都会有…
既不重要, 又很重要. &br&&br&对于大部分国内用户而言, 他们是不知道也很难意识到 Android 和 iOS 在设计上有什么差别的. 而国内主流的 ROM (没错, 我说的是 MIUI) 在 UI 上也模仿了非常多 iOS 特色, 在这样的大环境下, 用户很难意识到两个平台设计规范的差异. &br&&br&但是人是会进步的. 而国外优秀应用大部分都遵循着平台规范, 国内的新晋应用和开发者也渐渐都开始遵循规范, 当用户用过了更优秀, 符合平台规范的应用之后, 他们中的一部分会渐渐意识到规范的优越性, 体会到遵循规范的应用具有更高的一致性. 而不同的平台毕竟是不同的平台, 一个平台的应用会渐渐趋于遵循一致的视觉规范 —— 只要这个规范&b&&具有足够的说服力&&/b&, 平台内应用间统一感会不断增强. &br&&br&具体到 iOS 和 Android 上, 举一个例子, iOS 的设计规范并没有针对大屏手机进行优化, 而 Android 上开发者可以在规范内作出极为大屏有好的 UI/UE. &br&&br&&br&而对于开发者, 尤其是跨平台开发者而言, 分别遵循不同平台的设计规范会为设计带来更大的压力 —— 对于大部分应用而言, 需要设计多一套视觉样式 (对于很多设计师/开发者而言, 还需要重新设计一套交互逻辑 —— &b&尽管这是毫无必要的&/b&), 必然会增加工作量. 但是, 遵循平台设计规范能够让开发者更好的发挥一个平台的实力 (调用自带标准控件节省性能, 不需调用外部库实现模仿 iOS 的视觉/交互效果, 标准布局更容易实现, 等等). &br&&br&&br&关于跨平台 UI/UE 设计, 我搜集了一些正面的例子以供参考: &a href=&///?target=http%3A///cross-platform-android-ios-1/& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&跨平台 UI/UX 设计示例 —— Android & iOS 篇&i class=&icon-external&&&/i&&/a&, &a href=&///?target=http%3A///cross-platform-android-ios-2/& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&跨平台 UI/UX 设计示例 —— Android & iOS 篇 (之二)&i class=&icon-external&&&/i&&/a&.
既不重要, 又很重要. 对于大部分国内用户而言, 他们是不知道也很难意识到 Android 和 iOS 在设计上有什么差别的. 而国内主流的 ROM (没错, 我说的是 MIUI) 在 UI 上也模仿了非常多 iOS 特色, 在这样的大环境下, 用户很难意识到两个平台设计规范的差异. 但是…
最近我公众号刚好不少人问我这个问题，昨天刚好写了篇文章解答，反响挺强烈的，直接在这里贴出原文吧！&br&&br&&b&原文：&/b&&br&&p&其实不管你是自学的还是培训的，是在校生还是毕业生，最终都逃离不开这个话题，不管你是找实习工作还是全职工作，性质都一样。今天我就来给大家详细说下&strong&自学 Android 到什么程度才有资格找到一份说得过去的工作！&/strong&&/p&&br&1. Java基础&br&&p&Java语言其实应用很广泛，对于Android开发来说只需要你掌握 Java SE 就够了，尤其对于一个Android初学者只需要掌握Java基础就行，这包括哪些呢？我粗略的列了下，主要包括：&/p&&br&&p&Java基本语法、面向对象相关的基本概念与思想，常用String类的api，异常处理，IO基础，容器，多线程，内存管理与垃圾回收， 知道并最好知道几种常见的 Java 设计模式等，建议可以找些网上Java面试宝典之类的文章，熟悉下面试常遇到的一些Java知识点，一般都是Java基础。&/p&&br&2. Android基础&br&&p&Java 如果算基础中的基础，那这部分才是你找工作的核心技能，毕竟你要从事的是Android开发，所以Android基础一定要牢固，这部分包括：&/p&&br&&p&Android基础UI控件的熟练掌握，也就是指 Button、TextView、EditText、CheckBox、RadioButton、ImageView、Spinner、ProgressBar、SeekBar、ListView、RecycleView、ScrollView等，可能不全，以上只是一时想到的，可自行补充。&/p&&br&&p&Android四大组件的理解与熟练掌握，四大组件就不必说了吧，具体掌握到什么程度呢？如果我问到「Activity的生命周期」你还支支吾吾的那我就没心情继续问下去了，其他一些如Activity的四种启动模式，Fragment的生命周期、Fragment与Activity之间的关系，BroadcastReceiver、ContentProvider、Service的使用场景与具体用法，更细节点的如 BroadcastReceiver 的广播类型与不同的注册方式的区别等都应该关注并理解到位。&/p&&br&&p&动画相关也是必须掌握的，不管是矢量动画还是属性动画的api都应该熟练，一些简单的动画应该随手就能写出来才行。&/p&&br&&p&自定义View得会吧？这个在实际的开发中经常遇到，因为基本的那些UI控件不可能完全满足你的需求。&/p&&br&&p&Sqlite与SQL语句得掌握吧，数据库虽然说在客户端开发上只有特定的业务或者场景才用得到，但是SQL语句这是基础，基本的操作sqlite相关的api也必须要掌握。&/p&&br&&p&常见的数据格式与解析方法得了解吧，虽然目前常用的数据格式就是json，解析库也有很多，如Gson、Jackson、Fastjson等。&/p&&br&&p&网络编程相关的基础知识要掌握，如http协议相关，如http method, status code, request & response, http cache, request header, params等，Android请求网络相关的api，虽然现在成熟的网络请求库很多，但是自己应该试着用 HttpUrlConnection 封装一个网络库，哪怕封装的很烂，自己也要尝试着写一下。&/p&&br&&p&还有...暂时想不到了，以上都是随手想到的，后面如果再想到就补充下。&br&&/p&&br&3. 项目经验&br&&p&其实大部分人都觉得自己的基础掌握的还算可以，但是为什么就找不到一份工作呢？其实项目经验这个才是很关键的，因为编程行业是一个非常注重能力的行业，你理论基础掌握的再好，没有实践验证都是不可靠的。&/p&&br&&p&那有些人又说了，我一个自学的，或者一个在校生，没有工作过哪来的项目经验啊？那你就错了，项目经验并不单纯指工作中的项目经验，你自己完全可以写一个业余练手项目，这都可以算作项目经验。&/p&&br&&p&但是这些练手项目哪里来呢？我只会写Android，其他都不会啊，哪那么容易就写一个项目出来了？&/p&&br&&p&在现在这个时代随便写一个项目练手还真的非常容易，现在有各种开放的api，你完全不用关心后端数据问题，举个例子，新浪微博有api，我就基于新浪微博api写个简单的微博客户端，有多简单呢？我甚至只能查看微博，其他啥都干不了，完成了查看这一步，再接着慢慢完善其他功能，不要觉得写一个微博客户端遥不可及。如果微博需要登录授权，可能稍难点，有更简单的直接读取数据的，如知乎日报，如对糗百进行数据抓包，写一个糗百的简易客户端，这类就完全不用授权，再比如我写个天气的客户端，关于天气现成的接口不要太多。&/p&&br&&p&至于我怎么知道有哪些现成的api可以直接用？就知道你要问这个问题，给你找好了，百毒有个api store，收集了太多可以直接用的开放api，地址：&a href=&///?target=http%3A///& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&API Store_为开发者提供最全面的API服务&i class=&icon-external&&&/i&&/a&&/p&&br&&p&（PS：别借机黑我，抵制百毒不代表百毒的所有东西都是垃圾，有一说一，这个 api store 对开发者来说还是蛮不错的！）&/p&&br&&p&最后，可能不是特别详细，如果我有时间，我甚至都想搞份超详细的教程课表给你们，可惜精力真的有限，没那么多时间去做。但是大的方向绝对ok的，如果你掌握了以上列举的基础，然后又自己从头到尾做了一个还算完整的项目，相信我，找到一份实习或者工作很轻松。如果你没找到，那可能只是运气跟机会的问题罢了，自己有能力完全不用担心，只是机会还没到，缺的只是时间而已！&/p&
最近我公众号刚好不少人问我这个问题，昨天刚好写了篇文章解答，反响挺强烈的，直接在这里贴出原文吧！ 原文： 其实不管你是自学的还是培训的，是在校生还是毕业生，最终都逃离不开这个话题，不管你是找实习工作还是全职工作，性质都一样。今天我就来给大家…
&p&看到这个问题忍不住要分享一点自己的想法。本人Google工作两年，入职之前也是前端后端摸个遍，单撸网站app从coding到deploy什么的都不在话下，所以找工作的时候也是在自己简历上写下了一笔Full stack engineer。&/p&&p&现在两年后回头再看觉得自己太天真了！都不用说全栈，就单单一个前端，吃不透的地方就太多太多了。跟当年自己玩的project不同，从工程的角度来开发一个项目，要考虑的事情真不一样。比如你用angular，乱watch会让UI变慢；写个api，可拓展性怎么样，迭代起来向后兼容性怎么样；你的style有考虑过从左向右的语言界面是什么样吗；一个函数，不给外部用的就一定要定义为私有的，不然将来想改它的时候还要到处搜有没有人用这个函数（虽然谷歌有code review，但这种code还是很常见）；怎么debug test？怎么写前端的integration test？怎么写前端＋后端的integration test？chrome console玩的够溜吗？考虑到后端那事情就更多了，数据库设计不好等PM提出一个feature的时候你可能就要用非常复杂，耗时的手段才能得到你想要的数据...所有这些单独拿出来都是个课题，都值得钻研。&/p&&p&所以我建议新人切忌贪多，先找家公司干着，自己去把坑踩一遍，然后去搜索成熟的解决方案，学习其背后的原理。这样渐渐的，你未必会成长为一个全栈工程师，但你一定会成为一个独当一面的工程师。祝好：）&/p&
看到这个问题忍不住要分享一点自己的想法。本人Google工作两年，入职之前也是前端后端摸个遍，单撸网站app从coding到deploy什么的都不在话下，所以找工作的时候也是在自己简历上写下了一笔Full stack engineer。现在两年后回头再看觉得自己太天真了！都不用…
以下比较基于 Android 4.2（原生系统） 和 iOS 6（未越狱）。&br&在此申明，问题问的是 iOS 应该从 Android 学什么，所以我说的当然都是 Android 的好处，iOS 的弱处。要是觉得 iOS 有很多好处，请去这里「有什么事情是 iOS 设备能做，而 Android 做不到、做不好的：&a href=&/question/& class=&internal&&&span class=&invisible&&http://www.&/span&&span class=&visible&&/question/2066&/span&&span class=&invisible&&8767&/span&&span class=&ellipsis&&&/span&&/a&」把你的观点写出来。或者在评论下指出我的错误，感激不尽。&br&&br&1，用 Android 拍的照片会自动同步到 Google 上，没有天数限制。 Photo Stream 只能存 30 天，有个毛用…要么无限量，要么帮我存到 Google 上。&br&&br&2，地图，Android 上的比 iOS 好用很多。这个也没办法了…&br&&br&3，iOS 上，通知系统的 X 永远也按不到，还要我按两次，这是在逗我玩？而且突然顶部肿起来那么一条通知真的是，严重污染视线，影响操作，经常遮挡住导航条…iOS 应该好好学学 Android 通知系统的各个方面。&br&&br&4，中文输入法…有那么多中国厂家做了输入法，随便收购一家都比现在的强。iOS 上我第一次用拼音输入「颖」这个字，找了整整一刻钟，结果还是用了奇淫巧技才输入进去了。&br&&br&5，Android 只要 Beam 或者 蓝牙就可以传文件和照片，这个一直是 iOS 的诟病。&br&&br&6，Android 上我用相机拍的照片可以在相册直接分享到 Path，微博，dropbox，等等，只要我安装了这些软件，就可以分享。iOS 要跋山涉水才能完成这些任务。&br&&br&7，Android 上联系人同步很方便，iOS 上就…不过 Apple 的这方面技术一向很烂…&br&&br&8，可以在电脑网页上浏览自己喜欢的 Android app 并直接安装到 Android 设备，这意味着你只需要一个浏览器就可以安装 Android app 了，比如你可以用 iPad 登录 Google Play 来购买 Android app，然后会自动安装到你指定的 Android 设备。而 iOS 必须通过 iTunes 或者设备本身，比如你在用 iPhone 看新闻，发现了一个很棒的 iPad app，那你只能去拿 iPad 或者打开电脑来安装这个 app。&br&&br&9，同一个 app，在 iOS 上所占据的存储空间几乎都比 Android 上的大，这个原因有很多，比如各种华而不实的图片素材，iPad 和 iPhone 共用一个 app 等等（不过 Universal app 也有它的好处 ，所以只能说是一个特点吧，不能说是缺点，有利也有弊）。&br&&br&10，Android 上要隐藏一个自己不想看到的 app 很容易。iOS 上的那个晃眼的杂志书架以及其他原生 app 就是永远去不掉。&br&&br&11，Android 现在可以在锁屏添加 widget，不用解锁就可以查看想要的信息。iOS 的解锁屏什么都没。并且 Android 的解锁方式个人觉得比 iOS 的方便很多。&br&&br&12，Android 可以将自己喜欢的浏览器、短信软件、电话软件等设为默认，iOS 只能用系统给你的，但是系统自带的又没有做到比别家的都出色。&br&&br&13，有人觉得 iOS 的优点在于不需要你做出选择，只给你一条路走。在我看来这是极大的缺点。Android 系统同样给了你一条路，如果你不想选择，完全可以走那条默认路线，但是你若摸索一下，还可以找到一条更适合你的捷径。但 iOS 只给你一个选择，而这个选择有时候对你来说并不是最佳的，甚至是条弯路。&br&&br&再次强调，以上比较基于 &u&&b&Android 4.2（原生系统） 和 iOS 6（未越狱）&/b&&/u&。&br&不要来拿山寨或定制安卓机说事。我可没用「金苹果双卡双待XP」来黑 iPhone。觉得哪个好，就用哪个。我反正两个系统都用。&br&&br&以下内容请勿阅读：&br&反正 iOS 已经从最炫最酷的系统变成…了，尤其是我用了 Android4.2 之后更加这样感觉。从以前被疯狂模仿，到现在疯狂模仿别人，还四不像。很多事情，它自己做得一塌糊涂，又不让别人做，顽固又自大。&br&我觉得 iOS 现在最应该从 Android 学习的，是 Stay hungry, stay foolish.
以下比较基于 Android 4.2（原生系统） 和 iOS 6（未越狱）。 在此申明，问题问的是 iOS 应该从 Android 学什么，所以我说的当然都是 Android 的好处，iOS 的弱处。要是觉得 iOS 有很多好处，请去这里「有什么事情是 iOS 设备能做，而 Android 做不到、做不…
差别主要在于图形的&b&视线流引导&/b&，这是设计当中一个基础的知识，不懂的可以百度一下。&br&并且这种差别，在箭头尺寸比较大时比较明显。请看图，黄色代表视线流引导。&br&&img src=&/3db015dd9ad_b.jpg& data-rawheight=&328& data-rawwidth=&460& class=&origin_image zh-lightbox-thumb& width=&460& data-original=&/3db015dd9ad_r.jpg&&&br&&br&当箭头尺寸较大时，边缘直角的箭头会在红色箭头处有一个视线流引导发散，并没有真正的引导出「向左」的意思，反而有点引导用户向上看。所以，在地铁，机场，公园导向系统内，大都不会采用这种箭头，就像现在排名第一的答案说的那样。&br&&br&但是如果两个箭头尺寸都很小的话，边缘是直角或者平角，对视线流的引导是没有影响的，所以都可以使用，甚至也存在边缘是圆角的箭头。&br&&br&不同手机系统内的箭头使用不同的边缘方式，就像他们的短信图标都设计得不同那样，本身是没有什么区别。只是对自身设计风格的遵从而产生的设计结果而已。&br&&br&谈不上孰优孰劣。
差别主要在于图形的视线流引导，这是设计当中一个基础的知识，不懂的可以百度一下。 并且这种差别，在箭头尺寸比较大时比较明显。请看图，黄色代表视线流引导。 当箭头尺寸较大时，边缘直角的箭头会在红色箭头处有一个视线流引导发散，并没有真正的引导出「…
iOS 系统的推送（APNS，即 Apple Push Notification Service）依托一个或几个系统常驻进程运作，是全局的（接管所有应用的消息推送），所以可看作是独立于应用之外，而且是设备和苹果服务器之间的通讯，而非应用的提供商服务器。你的例子里面，腾讯 QQ 的服务器（Provider）会给苹果公司对应的服务器（APNs）发出通知，然后再中转传送到你的设备（Devices）之上。当你接收到通知，打开应用，才开始从腾讯服务器接收数据，跟你之前看到通知里内容一样，但却是经由两个不同的通道而来。&br&&br&而 Android，就不同，更像是传统桌面电脑系统做法。每个需要后台推送的应用有各自的单独后台进程，才能和各自的服务器通讯，交换数据。另外其实 Android 也有类似 APNS 的 GCM（Google Cloud Message），属于开发者可选，非强制。（更多请看本回答评论区里面 &a class=&member_mention& data-hash=&f5ee79e5a1fb& href=&///people/f5ee79e5a1fb& data-hovercard=&p$b$f5ee79e5a1fb&&@Bill Cheng&/a& 的补充）&br&&br&所以你大概看出来区别，iOS 的消息推送机制面世之时是一种全新的解决方案（堪称平台中的平台），应用本身不能有常驻的后台进程，系统的开销少，内存使用更少，电量也更少（把更多的运算和资源开销放在云端，非设备端）。而 Android 的特点，虽然开销大，优点是更稳定快速，但不明显。&br&&br&&br&更多请阅览话题：APNs - 知乎 | &a href=&/topic/& class=&internal&&&span class=&invisible&&http://www.&/span&&span class=&visible&&/topic/1969906&/span&&span class=&invisible&&3&/span&&span class=&ellipsis&&&/span&&/a&&br&以及开发文档：Apple Push Notification Service (APNs) | &a href=&///?target=http%3A///library/mac/%23documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/ApplePushService/ApplePushService.html& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&http://&/span&&span class=&visible&&/lib&/span&&span class=&invisible&&rary/mac/#documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/ApplePushService/ApplePushService.html&/span&&span class=&ellipsis&&&/span&&i class=&icon-external&&&/i&&/a&
iOS 系统的推送（APNS，即 Apple Push Notification Service）依托一个或几个系统常驻进程运作，是全局的（接管所有应用的消息推送），所以可看作是独立于应用之外，而且是设备和苹果服务器之间的通讯，而非应用的提供商服务器。你的例子里面，腾讯 QQ 的服…
这是两者的系统架构不同导致。&br&&br&首先是iOS对屏幕反应的优先级是最高的（Touch-Media-Service-Core架构），也就是说用户只要碰了屏幕，系统最优先去处理屏幕显示，然后才是其他。而安卓则是传统的Application-Framework-Library(JAVA虚拟机)-Kernal架构，图形图像处理在Library这层，优先级不是那么高。如果系统负荷较高，则无暇顾及用户触摸的反应。&br&&br&其次是iOS对图像的各种特效处理（放大、缩小、旋转、滚动等）都是基于GPU硬件加速的，与APP无关。这是APPLE采用封闭式硬件的优势。而安卓为了适应不同的手机硬件，做不到这点，很多APP的图形特效都靠APP自己去进行软件渲染，效率低。最新的4.1已经改进，但也无法做到所有特效都靠GPU硬件加速。&br&&br&最后就是安卓的JAVA虚拟机：相对iOS的Objectiv-C，JAVA天生运行效率低下，需要占用大量内存来换取执行速度，而不定期的内存自动回收机制，直接导致安卓界面的卡顿现象，无论如何优化也不可能改掉。2.3版安卓就是为改善此设计而发布：引入了一种新的并行内存回收机制来减轻这种卡顿影响，但也仅仅是减轻，而无法彻底消除。也因此2.3版成为安卓重要的里程碑。
这是两者的系统架构不同导致。 首先是iOS对屏幕反应的优先级是最高的（Touch-Media-Service-Core架构），也就是说用户只要碰了屏幕，系统最优先去处理屏幕显示，然后才是其他。而安卓则是传统的Application-Framework-Library(JAVA虚拟机)-Kernal架构，图形…
Quantum Paper，确认无疑！&br&不过不同的是，我非常支持 Google 的这次改版，UI 设计不仅仅是样式！&br&我们先看下，这次 Google IO大会的网站截图：&br&&a href=&///?target=https%3A///events/io/experiment& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&https://www.&/span&&span class=&visible&&/events/io/ex&/span&&span class=&invisible&&periment&/span&&span class=&ellipsis&&&/span&&i class=&icon-external&&&/i&&/a&&br&&br&&br&&img src=&/503acafafa2f604dc6d7d62a4cac67b4_b.jpg& data-rawwidth=&1008& data-rawheight=&1026& class=&origin_image zh-lightbox-thumb& width=&1008& data-original=&/503acafafa2f604dc6d7d62a4cac67b4_r.jpg&&&br&&img src=&/db9dfc41b170dab8762df_b.jpg& data-rawwidth=&1101& data-rawheight=&1128& class=&origin_image zh-lightbox-thumb& width=&1101& data-original=&/db9dfc41b170dab8762df_r.jpg&&&img src=&/7af722a2abdb3e945be1a_b.jpg& data-rawwidth=&1296& data-rawheight=&1133& class=&origin_image zh-lightbox-thumb& width=&1296& data-original=&/7af722a2abdb3e945be1a_r.jpg&&&br&Paper!&br&没错，这个都是纸张的样式，有的人可能会觉得似曾相识，看下图：&br&&img src=&/c960a5e719d96da7be89a_b.jpg& data-rawwidth=&800& data-rawheight=&600& class=&origin_image zh-lightbox-thumb& width=&800& data-original=&/c960a5e719d96da7be89a_r.jpg&&Google 的 Loading (Web 和 iOS 应用使用的）&br&&br&结合文章的内容以及这些，再次肯定
Quantum Paper 无疑！&br&&br&&br&-------------------------------强势的分割-------------------------------&br&&br&&b&上面都是举证，下面才是理解.&/b&&br&&br&&br&那么我说说我的理解吧：&br&&br&Android Design仅仅是Android Design，只是在进步而已。而这次的改版，我认为是蓄谋已久的一次改版，也是 Google Web Design 的延续，之前有一个报道：&br&&br&&a href=&///?target=http%3A///2014/04/a-conversation-about-design.html& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&A conversation about design&i class=&icon-external&&&/i&&/a&&br&&br&这个里面 Google 再次将设计提高到一个很重要的层级（再次是因为 Larry Page 回归后做的第一件事就是 设计的改版与统一，主要是搜索和 Web ,文章地址：Redesigning Google: how Larry Page engineered a beautiful revolution | The Verge
&a href=&///?target=http%3A////3904134/google-redesign-how-larry-page-engineered-beautiful-revolution& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&Redesigning Google: how Larry Page engineered a beautiful revolution&i class=&icon-external&&&/i&&/a&） Android的设计急需一次改版，让 Google 的设计语言更加的统一起来。&br&&br&&br&&br&&b&从Quantum Paper 的设计来说，我觉的代表了一个方向和隐喻：这是个全新的世界，区别于现实的世界，它是科技的、光滑灵动的，多彩的。&/b&&br&&br&iPhone定义了 手机UI 的设计模式无疑，他带来的是将触摸与手机操作的完美结合，iOS 7 前时代的设计是真实世界的反射，质感的、纹理的，OK，很精美，但是当你手机触摸屏幕的瞬间，屏幕是如此的光滑和冰冷，告诉我们这里和现实，不是一个世界。iOS 7的设计是光滑的，而 Android 也应该是这样的一个方向. (&a href=&/mylcl/& class=&internal&&UI 设计的“触感” - LCLの海 - 知乎专栏&/a& 兔斯霁的文章有详细的描述，点10010个赞 ) &br&&br&从色彩上来说，Android终于变的明亮起来，白色的背景，色彩丰富的点缀，和Google 的 iOS 、Web更加的统一，这不是一个新的风格，而是 Web design 的一个衍生和发散。&br&&br&从图标上来说，Action bar 的图标变的更小更精致,缩小视觉大小，放大点击区域，也能提高点击率，老的风格的图标很多真的很丑 且不统一。&br&&br&从侧边栏的导航来说，显然新的侧边栏样式更易于被用户发现。&br&&br&从交互动画来说，额，好像看不到，但是从 Google IO 2014的网站来看，一定不会失望。&br&&br&总之，我觉得 Goole对这次的 IO 大会信心满满，等待 Android Design 的华丽转身！&br&&br&暂时好像就这么多了，干活去了。&br&&br&----------------&br&&br&补一张图，Google DOCS的设计，Android 和 iOS 的，已经说明了新的设计风格的改变与设计统一。（侧边栏、小图标、明亮的颜色、卡片纸的设计）&br&&br&&img src=&/f4f2ac266c10993d6bdfae7a_b.jpg& data-rawwidth=&1200& data-rawheight=&1000& class=&origin_image zh-lightbox-thumb& width=&1200& data-original=&/f4f2ac266c10993d6bdfae7a_r.jpg&&
Quantum Paper，确认无疑！ 不过不同的是，我非常支持 Google 的这次改版，UI 设计不仅仅是样式！ 我们先看下，这次 Google IO大会的网站截图：
Paper! 没错，这个都是纸张的样式，有的人可能会觉得似曾相识，看下图： Google 的 Load…
认真的说。。。别买这书了。。书总是慢上好几拍的，真心想好好学学的话去看官方的文档，特别是初学者部分，英文不好就查字典看，查字典也不会的话就看国内翻译的版本也比书强多了。把上面的例子做一做，跑一跑。&br&----分割线－－－&br&由于有朋友问，初学者看官方文档真的能上手么？刚好手头有空就详细的说下吧，毕竟我自己当时是看官方文档入门的，而且当时还是09-10年之间，Dev Guide 远没有现在详细，现在的 Dev Guide 简直业界良心好嘛～哈哈，下面多图预警～～～&br&&br&打开官网 你会看到这样的 &a href=&///?target=http%3A///develop/index.html& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&Develop Apps&i class=&icon-external&&&/i&&/a&&br&&img src=&/7a059fd3d486f2be5ec670f4b06836bb_b.png& data-rawwidth=&1248& data-rawheight=&586& class=&origin_image zh-lightbox-thumb& width=&1248& data-original=&/7a059fd3d486f2be5ec670f4b06836bb_r.png&&&br&我特地看了上面的四步，特别清晰明了&br&第一步 Set up Android Studio 教你怎么搭建环境，而且是最新的 Android Studio 哟，再也不用担心纠结 Eclipse 还是 Android Studio 了&br&点进去后是非常详细的 Android Studio 的说明书，从下载 IDE，如何编译，如何管理项目，如何发布，如何测试等等，还有一些常用功能介绍都有，左边是目录，右边是内容，截图如下，这部分是教你怎么玩 Android 的模拟器&br&&img src=&/627b04e65e8b1cfc695b21_b.png& data-rawwidth=&1309& data-rawheight=&580& class=&origin_image zh-lightbox-thumb& width=&1309& data-original=&/627b04e65e8b1cfc695b21_r.png&&&br&我们来看第二页 Build your first App &a href=&///?target=http%3A///training/index.html& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&Getting Started&i class=&icon-external&&&/i&&/a&&br&这部分就是手把手写代码了，和很多书上的 Demo 类似，从怎么创建项目到加入一个 Activity 加入 Actionbar 等等，各种常用组建，还有面试必考 Android 四大金刚怎么用等等应有尽有，而且一步步深入浅出，非常适合完全没做过 Android 开发的人依样画葫芦的学习一遍 Android 开发流程。放一张 Activity 的图。&br&&br&&img src=&/3e6e74ff17abc779d26d7a0_b.png& data-rawwidth=&1279& data-rawheight=&586& class=&origin_image zh-lightbox-thumb& width=&1279& data-original=&/3e6e74ff17abc779d26d7a0_r.png&&&br&第三步是 Learn about android &a href=&///?target=http%3A///guide/index.html& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&Introduction to Android&i class=&icon-external&&&/i&&/a&&br&其实这一步才是真正的 Android 介绍，我个人认为把 Android 详细的介绍放在这里是很合适的，经过上面两步，其实已经有个感性认识了，而且动手做过后肯定会有很多疑问。这部分就是各种详细的介绍，比如资源怎么管理加载， AndroidManifest 是什么鬼，国际化怎么做，传感器怎么玩等等。这部分其实是比较难啃的部分，可以先看一遍有个概念，后续遇到了具体问题再回来看会效果更好。&br&&img src=&/79324fbd9665edb49edb6997_b.png& data-rawwidth=&1224& data-rawheight=&620& class=&origin_image zh-lightbox-thumb& width=&1224& data-original=&/79324fbd9665edb49edb6997_r.png&&&br&第四步 Sample Projects &a href=&///?target=http%3A///samples/index.html& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&Samples | Android Developers&i class=&icon-external&&&/i&&/a&&br&这个不用说了，就是一堆 Demo 大部分都提供了 Github 的库，很方便也很全面，从基本组件到动画到各种细节小功能或多或少都有一些。（早年就没几个 Demo 一看就看完了，现在好丰富了，我也建议遇到啥方面问题就去找啥方面 Demo 效果比较好）&br&&img src=&/dfe2dc61f9ac_b.png& data-rawwidth=&1251& data-rawheight=&632& class=&origin_image zh-lightbox-thumb& width=&1251& data-original=&/dfe2dc61f9ac_r.png&&&br&&br&&br&如此业界良心完整的官方文档不看真是太可惜了吧。而且更新速度和详细程度都是很多书籍无法比拟的，唯一的困扰大概就是英文吧，这个么，电脑现在都有划词翻译了，也不费事儿啊，是吧。
认真的说。。。别买这书了。。书总是慢上好几拍的，真心想好好学学的话去看官方的文档，特别是初学者部分，英文不好就查字典看，查字典也不会的话就看国内翻译的版本也比书强多了。把上面的例子做一做，跑一跑。 ----分割线－－－ 由于有朋友问，初学者看官…
直到 5.2 的版本，WeChat for Android 才真正称得上 for Android 。之前的版本，准确说只能说是 WeChat for iOS 的 Android 移植版。&br&&br&微信 Android 团队能从之前在知乎等平台强硬表示采用 iOS UI 是因为 iOS UI 就是好设计，到现在终于由于种种原因（ &a data-hash=&797cd37c474b0aef8cb9& href=&///people/797cd37c474b0aef8cb9& class=&member_mention& data-tip=&p$b$797cd37c474b0aef8cb9& data-hovercard=&p$b$797cd37c474b0aef8cb9&&@NovaDNG&/a&
等推崇/推广 Android design 的先锋们功不可没）能做出 Android design 版的微信可以说是极其不容易的，首先要对微信 Android 团队点个赞(然后再喷)。&br&&br&首先说 logo，logo简直毫无诚意啊，万年不变的圆角方形？不加边框会死？虽然微信标识本身会有种两边重量不平衡的感觉，但加框好歹也加个 Android 特色的框吧，还保持 iOS 的圆角方形算怎么回事？同样地问题还出现在通知栏图标里，依旧彩色，依旧不符合 Android design 的要求。不知道是测试版改变未完全的原因还是别的，这点依旧不能让人满意。&br&&br&应用载入 splash。按照Android design的标准，是不推荐使用 splash 载入画面的，但新版微信依旧使用了，不过纯色背景+微信logo比原来的月亮人影好看多了有木有。从标准上说这又是一点不符合的部分，但鉴于改的splash还能看而且毕竟就看一次，所以相比老版分数不增不减。&br&&br&主界面。这次 Android design 版微信主页确实遵从了Android design的标准，使用 action bar，tab host 进行切换内部界面。平庸无奇没有什么能让人眼前一亮的地方。虽说符合了标准，不过这样的样式应该是两年前推崇的样式了吧。无论如何毕竟这真的是 Android design 的微信了呢。不过呢，之前的滑动删除/置顶聊天的功能被砍了真的挺可惜的呢（难道微信团队你不知道左划不行还是可以右划的嘛）。就算是长按进行操作也可以使用 Contextual Action Bar 允许对多个会话同时操作嘛，一个个操作真的很累的。&br&&br&然后就是最重要的聊天界面了。聊天界面也是改变巨大，图标，输入框什么的改变的比较像样了，不像之前版本的那么违和（你在说什么，明明原来整个应用就是个违和的四不像），（在没打字的情况下）终于没有了丑陋“发送”按钮，不过。。。一旦打字，“发送”君又会出现。难道微信 Android 团队就这么看不起 Android 用户的智商？改成图标用户就不知道这是个发送的功能了？恐怕不至于。乔老爷是说过要把用户当做白痴来看待，但，那是说的07年的用户，现在的用户，使用了大量的应用，积累了一定的操作经验，找到一个发送的按钮应该是不在话下的（而且就算妹纸找不到去问蓝孩纸们也正好给蓝孩纸们创造了机会不是么）。哦，对了，这聊天界面和主界面的头像怎么到现在都还是圆角的？连 iOS 版都换成直角方形了好吗！算了，不要在意这些细节。。。&br&UPDATE：正式版5.2里已经把头像全部改成直角！&br&&br&再说说通知。这。。。这他喵的就是个完完全全的槽点好吗？作为一款 IM 应用，居然不支持Android 4.1+ 的 Expandable Notification？都已经5.2版了，只要新消息数&2，通知栏显示的永远是“ XXX 发来 XX 条消息 ”，或者 & XX位用户发来 XX 条消息 &。敢问这样的通知有半点用处吗？通知不光是通知，既然显示出来，就还有预览的功能。直至今日这点依旧没有任何改进（从微信 for Android诞生至今通知栏只有一次改进，就是加入了新消息发送者的头像）！毫无悬念的差评！&br&&br&不过！即便还是有很多的槽点，还是应该给微信Android团队点个赞不是么？起码这真的是一个符合 Android design 的微信啊！微信Android团队居然浪子回头了！&br&&br&以前说微信 for Android 不按照 Android 开发规范开发，一方面说的是设计，另一方面是功能。设计不必多说，照搬 iOS 界面负分滚粗好吗。&b&更重要的是功能&/b&。Android SDK 已经发展到 v19 了，可是微信到现在通知都还是那么糟糕，新信息来不会让正在放的音乐音量降低以突出通知，通知显示内容太有限，消息推送依旧不支持GCM推送，导致长期驻留后台占据大量内存。最后一点着重强调，微信想要走出国门真正实现国际化，一方面设计要跟上，要让人愿意在手机上留住这个应用，另一方面功能也得跟上，国行手机无法使用GCM但国外并非如此啊（何况国内还有大量用户群体使用含有Google服务套件的水货机器）。一个应用后台保留两三个服务，内存占据超过100M（甚至我看到有一次占用了160+M），如果一不小心关掉后台短时间内还收不到消息，这样的 IM 应用恐怕没谁愿意使用吧。想要国际化，就得踏踏实实把产品做好，而不是靠不停地吹牛做广告。&br&&br&现在的 微信5.2 for Android 在 UI 上已经开始遵循 Android design 的标准，希望能更快在功能上符合Android 开发标准。
直到 5.2 的版本，WeChat for Android 才真正称得上 for Android 。之前的版本，准确说只能说是 WeChat for iOS 的 Android 移植版。 微信 Android 团队能从之前在知乎等平台强硬表示采用 iOS UI 是因为 iOS UI 就是好设计，到现在终于由于种种原因（
我又要嘲讽了：&b&幼稚的程序员才会执着于需求变更&/b&&br&&br&程序员分很多种，开发人员从前端到后端，从初级到高级，从代码开发到结构设计，众多门类各种层次，就被三个字“程序员”给概括了。&br&&br&这也许就是一个抖机灵的答案排第一的原因吧。&br&&br&需求与业务的符合度，需求的明确程度，以及完善的需求管理，这三者都比“不让需求变化”重要得多，也容易控制得多。&br&&br&&blockquote&&b&&i&唯有符合业务目的的代码才能永存&br&
------上官人&/i&&/b&&/blockquote&&br&需求是什么？我们口中的“需求”，一般指“软件需求规格说明书”、“Software Requirement Specification (SRS)”。下文引自百度百科&a href=&///?target=http%3A///link%3Furl%3Darwx_ZGx0m9OeSsN_P50XeBwLZywaE7Gobb1ydzOmDa9dsmmvYrYmgVuAWqlsXreCX0rmQE36YiuAMYxK7sMl_& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&软件需求说明书&i class=&icon-external&&&/i&&/a&&br&&blockquote&SRS(Software Requirements Specification), &a href=&///?target=http%3A///view/37.htm& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&软件&i class=&icon-external&&&/i&&/a&需求说明书的编制是为了使用户和软件开发者双方对该软件的初始规定有一个共同的理解， 使之成为整个开发工作的基础。包含硬件、功能、性能、输入输出、接口界面、警示信息、保密安全、数据与数据库、文档和法规的要求。&/blockquote&这样一篇文档，由需求工程师们或产品经理们开发，最终交付给开发团队。而我们的“程序员”们，到底看了其中的多少内容呢？你是不是直接跳过背景、目的、范围，跳过业务描述等所有内容，直接找到跟自己相关的功能描述，开始干活呢？&br&&br&如果你真的是这样工作的，那就不要怪我，把你归入“幼稚的程序员”这个行列。因为你压根不懂需求规格说明书该怎么使用，这是因为你压根不懂什么是需求，而这是由于你不知道你自己的开发工作与需求是个什么关系。你连自己在干吗都不知道。&br&&br&与其枯燥的描述，不如讲故事。我来给你讲，我的故事。&br&&br&我最初是一名垃圾级程序员，不同的是，我做过软件测试。做软件测试的时候，我依照需求规格说明书给别人挑毛病，做垃圾程序员的时候，我被人家挑毛病。这是一个痛苦的地狱，一方没完没了的攻，一方没完没了的受。攻也攻得很辛苦，受也受得很痛苦，而先做攻再做受的更痛苦，生理上痛苦，心理上更痛苦。&br&&br&软件缺陷中，如果是代码错误，例如if(a==&1&)这种，其实没什么好说的，这就是2B了；经常有争议的是这种，我认为需求说的是这样的，而测试人员则认为应当是那样的，这样就争执不休，找到产品负责人，让他定夺。如果是我对需求理解有误，那还好说，怕的是，产品一看，哦，自己写的需求写错了，让我改。&br&&br&蛋疼啊！你为啥不在一开始就写清楚捏？我浪费这么多时间，用了这么大力气才开发出来的东西，结果全是无用功。这时候我会很自然的问产品，你确定就这样了么？不改了？产品肯定一口咬定，不改了！&br&&br&没出一个星期，个狗B就又改口了！再过一个月，没准又改。这样改来改去没完没了，我就此绝望：&b&安得需求最终版，大庇系统功能俱实现，产品&/b&&b&测试&/b&&b&笑开颜&/b&！&br&&br&但是在我读过一些书之后，我明白，这是不现实的。&br&&br&还记得，老罗在一个理想主义者的创业故事2014中说过的话么，一款手机的热度只能持续不到4个月；还记得国内游戏为什么没有完善的测试那个问题下的最佳答案么？因为开发周期非常短。&br&&br&我所在行业也是一样，产品人员是在分析了一款产品的市场现状和前景以及竞争对手的动态后设计出来的，这个产品具有时效性，它必须尽快上线，以填补市场空白，在与竞争对手的产品竞争中获得先机。你第一个投放市场，用户习惯就以你为准，后面的只能向你兼容。&br&&br&所以，产品经理注定是无法清晰完整的写出一个完美的需求的，遑论最终版？在开发过程中产品经理并不是就闲在那里等着，而是需要继续调查，推敲业务，寻找最终用户试用并收集反馈等等，需求怎么可能不改？&br&&br&接受这个现实吧，需求将永远不停歇的变更，开发过程中变更，系统上线后继续变更，只有一种情况下需求不会变更，就是产品没人用了。&br&&br&&br&&br&-----------------------------接受了这样的设定后，我觉得天都塌下来了-----------------------------------------------&br&&br&&br&&br&CMMI为什么强调需求管理？因为我们要控制需求变更，不能让需求变更随意的影响开发过程。&br&&br&为什么流行敏捷？就是因为要快速响应需求变更啊！&br&&br&软件开发方法论上的东西就不在此赘述了，这里重点谈，&b&作为一个成熟的程序员，什么样的需求对你来说，是好需求&/b&？&br&&br&需求是分层次的。&br&&br&简单划分，最顶层是行业需求，包括行业规范，文件，法律法规，潜规则等等&br&&br&然后是业务需求，设计业务以满足行业需求中的各种规定&br&&br&然后是用户需求，设计人机交互以满足业务需求&br&&br&最后是系统需求，设计系统间/内交互以满足用户需求&br&&br&自上而下，上层决定下层，下层必须满足上层的全部要求。上层是下层设计的依据和动机，下层是上层的具体实现。因此，越往下，变化越频繁越剧烈，越往上，变化越缓慢越轻微。&br&&br&一般人认识的需求规格说明书，包含且仅包含用户需求，用户需求使用功能列表和用户用例来描述。而用户需求作为整个需求体系的第三层次，变化是相当剧烈的。当然，对于程序员最蛋疼的人机界面的变更等等，并不是用户需求的主体，属于用户需求的边角余料。&br&&br&例如，依据《如何编写有效用例》一书的描述，符合用户需求的用户用例描述应当是：&br&&br&&b&操作员输入用户名和密码，系统验证用户名和密码的正确性，展示欢迎界面&/b&。&br&&br&至于登录页面什么样，欢迎页面什么样，都应扔进附录里，与用例解耦。&br&&br&那么，从需求的角度来说，如果你觉得需求变更没完没了，不厌其烦，那么，你应当期望需求规格说明书包括更加高层次的需求，这样，你就能把我用户需求的编制依据，这样，需求中的错误，疏漏，自相矛盾，你就可以第一时间发现；你也可以反思自己的编码是否符合业务目的，唯有符合业务目的的代码才能永存。&br&&br&所以，在我眼里，一本好的需求，必然也必须包括尽可能完整的业务描述和业务目的描述。好的需求是从背景开始展开的，从行业谈起，到该项业务的设计，到用户需求的设计，层次清晰，条理清楚。这样才能帮助读者把握整个文档的思路和脉络。
我又要嘲讽了：幼稚的程序员才会执着于需求变更 程序员分很多种，开发人员从前端到后端，从初级到高级，从代码开发到结构设计，众多门类各种层次，就被三个字“程序员”给概括了。 这也许就是一个抖机灵的答案排第一的原因吧。 需求与业务的符合度，需求的…
完全可以，而且在淘宝、微信等 App 已经实现并应用，主要利用 Java ClassLoader 的原理，对于 Android 来说是 DexClassLoader，如下&br&&div class=&highlight&&&pre&&code class=&language-text&&DexClassLoader pluginClassLoader = new DexClassLoader(dexPath, optimizedDirectory, libraryPath, parentClassLoader);
&/code&&/pre&&/div&可动态加载的内容包括 apk、dex、jar 等&br&&br&我也利用这个原理及开源项目实现了一个版本，并且整理了 Android 插件化的作用、概念以及不错的资料(包括开源项目)和解决方案。&br&&br&其中包括 65535 问题，Android 插件化、Android 组件化、Android 动态加载、Android 动态升级；介绍 DexClassLoader 和 PathClassLoader 的区别；如何解决生命周期管理、资源访问问题，如何消除公共依赖&br&&br&详细可见我的博客：&a href=&///?target=http%3A///android/android-plugin/& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&利用 DexClassLoader 实现 Android 插件化，从而达到动态加载&i class=&icon-external&&&/i&&/a&&br&&br&&img src=&/a12b820f0e03ef4ee6a7_b.jpg& data-rawwidth=&1358& data-rawheight=&2308& class=&origin_image zh-lightbox-thumb& width=&1358& data-original=&/a12b820f0e03ef4ee6a7_r.jpg&&
完全可以，而且在淘宝、微信等 App 已经实现并应用，主要利用 Java ClassLoader 的原理，对于 Android 来说是 DexClassLoader，如下 DexClassLoader pluginClassLoader = new DexClassLoader(dexPath, optimizedDirectory, libraryPath, parentClassLoader)…
不管我多么喜欢Material Design，甚至目前在做小网站打发时间的时候都去读了数遍谷歌的Material Design设计规范。&br&&br&但是，我不认为MIUI应该全面转向Material Design。&br&&br&在这里，我不想去讨论国内的乱相究竟是谁造成该谁负责。我只想简单说一些事实。&br&&br&&ul&&li&总体审美水平大抵如此。&/li&&/ul&你看看那些各个ROM内应用商店里大量下载的主题你就明白这句话了。不得不承认，MIUI还是远比Material Design讨好大部分人的眼球的。&br&&ul&&li&Material Design的学习难度还是略高。&/li&&/ul&就这么和你们说吧，有些人刷知乎刷了大半年都不知道左侧栏是可以滑出来的。&br&我也曾看过不少人想象中的Material Design风格的微信，确实，我觉得好看到哭。可是，真的没多少人会用，尤其是父母们。&br&&img src=&/1fa7a95adfbf926e882c29e82607bdba_b.jpg& data-rawwidth=&720& data-rawheight=&1280& class=&origin_image zh-lightbox-thumb& width=&720& data-original=&/1fa7a95adfbf926e882c29e82607bdba_r.jpg&&&br&当年只是简单把底栏移上去就遭来了多少骂声？&br&&br&当然，我也希望MIUI能适当的借鉴一下Material Design。毕竟，Material Design已经比较优秀了。&br&&br&但是，我很厌恶某些人站到道德制高点去指责非Material Design。国内今日的现象非MIUI一己造成，再说当年MIUI出来的时候也不看看安卓做的是多么恶心。&br&&br&我爱Material Design，但是我知道不爱的更多。我尊重他们的喜好，不觉得他们愚蠢，但我亦坚守自己的喜好。&br&&br&就这样吧。
不管我多么喜欢Material Design，甚至目前在做小网站打发时间的时候都去读了数遍谷歌的Material Design设计规范。 但是，我不认为MIUI应该全面转向Material Design。 在这里，我不想去讨论国内的乱相究竟是谁造成该谁负责。我只想简单说一些事实。 总体审美…
正是因为卡，用户才会操厂商的心，估算内存够不够。&br&&br&iPhone流畅，所以用户才不计较内存，因果顺序不能反。
正是因为卡，用户才会操厂商的心，估算内存够不够。 iPhone流畅，所以用户才不计较内存，因果顺序不能反。
这几个问题是我根据自己的面试经历总结的，朋友 &a data-hash=&feab7bda6d& href=&///people/feab7bda6d& class=&member_mention& data-editable=&true& data-title=&@AndWang& data-tip=&p$b$feab7bda6d& data-hovercard=&p$b$feab7bda6d&&@AndWang&/a& 帮分享出来，大家一起交流学习。&br&&br&其实不一定面试时才了解这些，并且了解绝对不是重点，而是实践，绝知此事要躬行是真理，这样的问题也似乎没有“最佳答案”，但是可以发表一下自己观点和实践结论。&br&&br&有些做法或观点一下子想不起来，需要具体做的时候再google一下，或者跟朋友沟通拓展一下，所以先做个简单的回答，请大家补充。&br&&br&&b&1. App性能如何探测，有哪些方面，什么指标，怎么保证更流畅？&/b&&br&&br&性能可以根据帧率、内存、CPU、GPU等指标的数据和表现辅助判断，可以从/proc文件夹下读取文件获取cpu、内存等信息，也可以用dumpsys命令获取帧率等信息，也可以通过android API获取相关信息。&br&&br&还有很多性能相关的分析工具很重要，辅助判断和分析，比如Heap Tool、Memory Monitor、Lint、HierarchyView、WireShark、TraceView等。&br&&br&保证流畅有很多点可以去研究，比如布局、代码、缓存、网络、数据库、异步并发等方面的优化，涉及很多的知识点，可以google下，先简单说下，有时间再细述。&br&&br&&ul&&li&&b&布局&/b&充分利用include、viewstub、merge 等标签，控制层级，避免过度渲染（绘制）。&/li&&li&&b&代码&/b&上尽量使用final、局部变量、系统函数如arraycopy等、位移操作是否可以代替乘除、for循环是否可以避免size计算和new对象等等。&/li&&li&&b&缓存&/b&方面，线程、位图、视图、网络数据是否可以被缓存，IO用缓冲流。&/li&&li&&b&网络&/b&方面，如尽量避免轮询，控制节奏和频率，IP直连，采用SPDY方案（或HTTP2.0）来实现压缩header、多路复用、双向通信等，API数据压缩，多个请求是否可以合并，数据压缩和尝试protocol buffer相关序列化方案。&/li&&li&&b&数据库&/b&方面，尝试用SQLiteStatement代替SQLiteDatabase完成操作，索引和事务的充分理解和使用，注意SQL语句语法和拼接，采用部分查询和延迟加载。&/li&&li&&b&异步并发&/b&方面，全App只有一个线程池，控制核心并发数量，控制超载时排队数量和策略，合理调度任务，优化业务逻辑。&/li&&li&最后关于&b&帧率&/b&，你看到的视觉卡顿，直接原因基本是“掉帧”。关于帧率，尽量保证主线程里做的事情，不会超过16毫秒（其实这挺难的），16毫秒大法好，具体可以去理解下CPU、GPU、屏幕三者如何配合完成渲染的，推荐老罗的博客。&/li&&/ul&&br&&b&2. 谈谈架构。大项目，逻辑多怎么办，如何应对多App和多终端？&/b&&br&&br&适当参考我在知乎的一个回答 &a href=&///?target=http%3A//zhi.hu/hfMB& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&怎样搭高质量的Android项目框架，框架的结构具体描述？ - 马天宇的回答&i class=&icon-external&&&/i&&/a& ，结合模块化、组件化思想去做，多实践一下mvp、mvvm等策略。&br&&br&&b&3. android的发展大事件和主要技术发展&/b&&br&&br&额，挺多的，朋友们补充吧。&br&这个问题蛮好的 &a href=&/question/& class=&internal&&Android 开发有哪些新技术出现？ - Android 应用&/a&&br&&br&&b&4. avtivity（service）启动流程简述&/b&&br&&br&可以自己阅读源代码，结合罗老师的博客，研究的非常棒：&a href=&///?target=http%3A//blog.csdn.net/luoshengyang/article/details/6689748& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&Android应用程序启动过程源代码分析&i class=&icon-external&&&/i&&/a&&br&&br&&b&5. 动态化的几种方案&/b&&br&&br&早期的H5方案，通过js和java互通增强h5的能力。&br&还有DexClasssLoader结合反射代理的方案。&br&还有React Native方案，手淘的Weex框架。&br&还有Lua等脚本实现动态化方案。&br&&br&&b&6. 热修复的原理&/b&&br&&br&Github上读一下AndFix这个项目的源码，还有xposed、dexposed。&br&&br&大致原理就是将java方法通过c/c++修改属性变为public native方法，上下文携带到native层，然后根据上下文指向另一个java方法，从而“偷梁换柱”，如果是支持ART的手机，那么策略不一样，将bug method的关键信息（classloader、theadid等）保留，将修复过的方法的各种信息赋给bug method，完成“移花接木”。&br&&br&另外，其实有挺多的策略改变运行时行为的，比如：&br&&ul&&li&Javasisst：字节码修改类库，依赖字节码修改和DX类库，可以完成动态替换和切面编程。&br&&/li&&li&AspectJ：依赖字节码编织器，需要按照其语法来编写，需要一点“编织”时间。&br&&/li&&li&Xposed方案，简直是一个Bug，神器般的存在，没准以后会被Android系统修复呢，不仅可以改变自己的类行为还可以hook系统的方法，root过的机器还可以hook其他App和系统进程。&br&&/li&&/ul&&br&&b&7. 网络这块怎么优化&/b&&br&&br&尽量避免轮询，控制节奏和频率。&br&&br&IP直连节省DNS解析时间。&br&&br&尝试其他数据序列化方案比如protocol buffer等。&br&&br&采用SPDY方案（或HTTP2.0）来压缩header、多路复用、双向通信等。&br&&br&服务器做优化，比如分布式、缓存之类的，减少API涉及的业务操作所需要的时间嘛。&br&&br&API接口数据精简，多个请求是否可以合并，增量请求啊、GIP压缩啊什么的，等等。&br&&br&&br&&b&8. 数据库性能怎么保证&/b&&br&&br&尝试使用SQLiteStatement取代SQLiteDatabase对象完成操作，避免直接使用SQLiteDatabase提供的update、inset等方法。&br&&br&索引和事务的充分理解和使用，批量操作使用事务极大提升速度，这个我是做过试验的，效果惊人。&br&&br&SQL语句拼接和本身的优化，仅查询部分局部数据，使用延迟加载策略。&br&&br&10万条数据插入比系统SQLiteDatabase操作快一倍，推荐我的LiteOrm数据库框架 &a href=&///?target=https%3A///litesuits/android-lite-orm& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&GitHub - litesuits/android-lite-orm: LiteOrm is a fast, small, powerful ORM framework for Android. LiteOrm makes you do CRUD operarions on SQLite database with a sigle line of code efficiently.&i class=&icon-external&&&/i&&/a&。&br&&br&&br&&b&9. 线程安全怎么保证，异步并发这块你怎么做的&/b&&br&&br&理解并使用ReentrantLock，Synchronized保护对象或过程，final来保护不可变对象，无状态和只读对象是安全的，合理使用一些 concurrent容器，比如ConcurrentHashmap等，重量级耗时任务考虑是否可以释放锁，多线程下实例化或延迟加载需要保护起来，保护多线程下关键数据访问的原子性，等等还有很多的。。。&br&&br&推荐研究下Doug Lea主写和设计的java concurrent包，理解CountDownLatch、CyclicBarrier、Semaphore、FutureTask等对象。&br&&br&具体开上，我使用自己写的SmartExecutor，直接继承ExecutorService，封装了一个公共线程池，全App保证只有一个线程池。源码在这个开源项目里：&a href=&///?target=https%3A///litesuits/android-lite-http& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&GitHub - litesuits/android-lite-http: LiteHttp is a simple, intelligent and flexible HTTP framework for Android. With LiteHttp you can make HTTP request with only one line of code! It could convert a java model to the parameter and rander the response JSON as a java model intelligently.&i class=&icon-external&&&/i&&/a& 。&br&&br&在一个 App 中 SmartExecutor 可以有多个实例，每个实例都有独立核心和等待线程数指标，每个实例都有独立的调度和满载处理策略，但它们 &b&共享一个线程池&/b&。这种机制既满足不同木块对线程控制和任务调度的独立需求，又共享一个池资源。独立又共享，最大程度上节省资源，提升性能。&br&&br&控制核心并发数，尽量和CPU核数保持一致（或者多两个）我认为吞吐量是最佳的，线程过多则调度线程消耗CPU和时间，过少则不能充分利用多核的能力。&br&&br&控制排队策略和排队数量，是否考虑新任务先处理，过度超载丢掉最老的任务。&br&&br&还有就是业务上，合理调度任务，优化业务逻辑，不要胡搞乱搞，不作恶。&br&&br&&br&最后我想推荐一下我的个人开源项目：&a href=&///?target=http%3A//%3Ff%3Dzh_perf& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&http://&/span&&span class=&visible&&?&/span&&span class=&invisible&&f=zh_perf&/span&&span class=&ellipsis&&&/span&&i class=&icon-external&&&/i&&/a&，欢迎关注嘛。
这几个问题是我根据自己的面试经历总结的，朋友
帮分享出来，大家一起交流学习。 其实不一定面试时才了解这些，并且了解绝对不是重点，而是实践，绝知此事要躬行是真理，这样的问题也似乎没有“最佳答案”，但是可以发表一下自己观点和实践结论。 …
&p&谢邀……题主这个问题让我回忆起了一件事。&/p&&p&我当年跟题主一样都是自学的，相比知乎上遍地留学生和Top3，我都不好意思写我大学，于是自称“野鸡大学”，专业更是冷门的地理系，冷到我入学时候这个专业在“野鸡大学”还没有毕业生，算是“开系元老”级别的……不同的只是，我大二时候自学从Java后端开始入门的，后来因为是Google的脑残粉，才无脑入了Android这个坑。&/p&&p&跟有个匿名的答主差不多，当时因为是自学，而且学校比较糟糕，也信息闭塞，光自学不知道怎么证明自己（当然当时可能还是技术水平菜），而且没有实习经验。很多知乎上现在说“找不到工作”，意思都是找不到“薪酬高or福利好or公司背景大”的工作，我当时找不到工作是真的啥工作都找不到。处于没头苍蝇的绝望状态，用人单位一看我简历：&b&野鸡大学，专业非CS，没工作经验……&/b&很多时候笔试机会都得不到，更别提面试了。&/p&&p&给我印象最深的一件事，是有一次北京的一家小公司来我校做宣讲会，宣讲会完了之后会提供笔试。结果可能是运气好，也可能是准备比较充分，我从笔试一路到一面、二面……&/p&&p&直到所谓的“终面”的时候，我忘记当时是HR面还是技术主管面我了，我只记得是一个独立办公室，面试官坐在写字台后面的皮椅子上。他在看我简历，我在做自我介绍，3分钟后，我说完了，他只对我说了一句话&/p&&blockquote&&b&我们不招地理专业的，你走吧&/b&&/blockquote&&p&&b&然后当着我的面把我简历丢垃圾桶了。&/b&&/p&&p&后来找了一个月吧，找到第一份工作，算是刚成立的一个项目组，还是做外包项目，还是整个组里就我一个做Android开发（另一个偶尔能给我提意见的架构师算半个吧）。反正有人要我就签了工作合同，毕竟当务之急对彼时的自己来说是觉得赶快有工作经验，至少先挤进这行再说。后来也算自己勤勉，offer算不愁了。&b&但是每年我都会去之前丢掉我简历的那家公司面试一回，&/b&换个名字，换个邮箱，换个手机号，简历上项目经验改一改，每次都会拿到offer，讨价还价很久，然后敲定日期，然后就是不入职。很幼稚对吧，其实连我自己都不知道这是图个啥。&/p&&p&故事讲完了，回到问题上来。&/p&&p&1. 如果你真的看好移动端开发这一行，创业公司也好外包公司也好，薪酬低也好加班多也好。当你技术水平没有达到给你选择权的时候，先挤进这一行是重要的。&b&像我之前说的，说找不到工作一般都是“薪酬高or福利好or公司背景大”的工作找不到，而真找不到工作往往不太可能。&/b&关于面试我有开过一个live，重点讲过如何准备简历和面试：&a href=&/lives/154304& class=&internal&&知乎 Live - 全新的实时问答&/a& 。&/p&&p&2. 如果你不是那么坚定的想做Android开发。&b&如果家庭条件允许，出国读个研镀个金未尝不可，我之前不去出国读研纯粹是因为家里实在太穷了&/b&，我有赚钱养家的压力在那里摆着&b&。&/b&至于方向，上面有答案劝你考研走机器学习这条路，我建议你至少先看看机器学习公开课（网易公开课好像有翻译）和周志华老师的书，看看自己数学基础能不能听得懂再做决定。&/p&&p&3. 兴趣是支持你在这一行走下去的基础，如果实在没兴趣，只是单纯觉得这行饭“容易吃”，又没有办法读研，那还是算了吧。至于你说的焦虑感，我已经工作第七年了都没有缓解。永远有学不完的新技术，补不完的旧基础，如果自学的过程都感觉痛苦，可能这一行并不适合你。Python是一个有趣又有用的语言，做哪行都可以把它当做工具语言，把编程当做额外兴趣，也未尝不可。&/p&&p&4. 上一条很重要。&/p&&br&&p&P.S. 如果只是单纯想进入互联网行业……我觉得程序猿是最难走的一条路了。运营、产品和测试的门槛相对都会低一些吧。&/p&
谢邀……题主这个问题让我回忆起了一件事。我当年跟题主一样都是自学的，相比知乎上遍地留学生和Top3，我都不好意思写我大学，于是自称“野鸡大学”，专业更是冷门的地理系，冷到我入学时候这个专业在“野鸡大学”还没有毕业生，算是“开系元老”级别的………
已有帐号？
无法登录？
社交帐号登录}