搜狐面试准备内容

android开发

搜狐公司发布于2013-08-26

• 工作城市：北京
• 每月薪水：2000及以上
• 招聘对象：实习生

• 所属行业： 互联网
• 职位类别： 技术研发
• 公司性质： 私营·股份制企业
• 公司规模： 1000人以上
• 所在部门： ---
• 招聘人数： 1人

1.有良好的 Java 基础，编程习惯良好，对 Android 平台兴趣较大。 
2.了解 Android各大组建,多层框架,对跨平台开发有一定了解. 
3.自我学习能力强，有责任心，愿意通过学习提高自身水平. 
4.对移动互联网（盈利模式、发展前景）有一定了解，并有自己独到见解者优先。 
5.有 Google Play 或其他应用市场上架程序者优先。 
6. 愿意同时掌握并学习Iphone开发者优先..

时间要求：

实习时间 6个月以上 , 每周工作5天

这是搜狐的招聘实习内容。。我发现明天就要面试了可以我啥都不懂。。所以打算赶紧通宵学习一下。。。

Android各大组建

Activity、Service、BroadcastReceiver、ContentProvider

 

Activity {

    从视觉效果来看

    一个Activity占据当前的窗口，相应所有的窗口事件，具备有控件、菜单等界面的元素。从内部逻辑来看

    Activity为了保持各个界面的状态，需要做很多持久化的事情，还要妥善管理生命周期、跳转逻辑等..

    对于开发者而言，就需要派生Activity的子类，然后埋头苦干上述事情。

}

 

 

Service {

    服务，从最直白的角度来看，就是剥离了界面的Activity，

    他们在很多概念方面比较接近，都是封装有一个完整的功能逻辑实现。

    Service就如成功男人背后的女人，那个默默无声坚实的后盾

 

    话又说回来，换个角度来看，

    Activity是跳，从一个跳到另一个。

    Service是等，等上层来连接它，然后产生一段持久缠绵的通信，

    就像用了Ajax，看着没啥变化，暗地里偷偷摸摸的不知和Service眉来眼去的多少回。

 

    但它和一般的Service还是有所不同的，Android中的Service是和其他三大组建一样的，其进程模型都是可

    以配置的，调用方和发布方都可以有权利来选择是把这个组建运行在同一个进程下，还是不同的进程下。

    如果一个Service期望运行在与调用方不同于的进程下时，这就需要利用Android提供的RPC机制，为其不熟一套进程间的通信策略。

 

    RPC ｛

        基于代理模式的一个实现，在调用断和服务端都去生成一个代理类，做一些序列化和反序列化的事情，

        使得调用断和服务端都可以调用一个本地接口一样使用RPC接口

 

        Android中用来做序列化的类是Parcel，封装了序列化的细节，向外提供了足够对象化的访问接口。

        Google号称实现非常高效。

 

        再就是AIDL(Android Interface Definition Language)，一种接口定义的语言，

        服务的RPC接口，可以用来AIDL描述，着用，ADT就可以帮助你自动生成一整套的代理模式需要用到的类。

 

        Service的实现：

        定义好需要接受的Intent，提供同步或异步的接口，在上层绑定它之后，通过这些接口进行通信。

        在RPC接口中使用的数据、回调接口对象，如果不是标准的系统实现(系统可序列化的)，则需要定义DIDL。

    ｝

 

    Service从实现角度看，最特别的就是这些RPC的实现了，其他内容都会接近与Activity的一些实现。

}

 

 

 

BroadcastReceiver {

    在实际应用中，我们需要等，等待系统或其他应用发出一道指令，为自己的应用指明方向。

    而这种等，在很多平台上都会需要付出不小的代价。

    比如Symbian中，你要等待一个来电消息，显示归属地之类的，

    必须让自己的应用忍辱负重偷偷摸摸的开机启动，消除图标，隐藏任务项，潜伏在后台，监控着相关的事件，

    等待转瞬即逝的出手机会，不但拜拜浪费了系统资源，还留了个流氓软件的骂名，费力不讨好。

 

    但在Android中，充分考虑了广泛的这类需求，于是就有了BroadcastReceiver这样的一个组件。

    每个BroadcastReceiver都可以接收一种或若干种Intent作为触发事件，当事件触发，

    系统会负责唤醒或传递消息到该BroadcastReceiver，任其处置。而在此之前和这以后BroadcaseReceiver是否

    在运行都不重要了，绿色环保。

 

    这个实现机制显然是基于一种注册方式的，BroadcaseReceiver将其他正描述并注册在系统中，可分为两种。

    1、事件发生 -> 通知Broadcast -> 实施处理 (通常是在OnResume事件中通过registerReceiver进行注册,

    在OnPause等事件中反注册)

    2、启动应用 -> 监听事件 -> 实施处理

 

    除了接收消息的一方有多种模式，发送者有很选择权。通常发送者有两类

    一类是系统本身，我们称之为Broadcase消息。

    除了系统，自定义的应用也可放出Broadcase消息，通过的接口可以是Context.sendBroadcase或Context.sendOrderedBroadcase

    前者走的是共产主义路线，所有关注该消息的Receiver都有机会获得并且进行处理

    后者走的是具有中国特色的社会注意路线、接收者按资排辈，有权有势的先吃饱了，后面的吃剩下的。

    要是还没轮到你就吃没了，那你就只能去喝西北风了

 

    当BroadcaseReceiver接收到相关的消息，他们通常是一些简单的处理，然后转换为一条Notification，

    一次震动、一个响铃、一个Activity进行进一步的交互处理等，虽然Broadcase整个逻辑不复杂，却足够好用，

    它统一了Android的事件和广播模型。

}

 

 

ContentProvider {

    听这名就觉得跟数据库有一腿，没错，这就是Android提供的第三方数据库的访问方案。

    在Android中，对数据库的保护是很严密的，除了放在SD卡中的数据库，一个应用所持有的数据库、文件等，

    都是不允许第三方直接访问的。

    但有时候沟通是必要的，不光对别人，对自己也是。

    比如一个联系人管理的应用，如果不允许第三方应用对其联系人数据库进行增删改查，那整个应用就失去了可拓展能力，

    必将被其他应用所抛弃，只能宅在家里自己安慰自己了。

 

    Android为所有应用都准备了一扇窗，这就是ContentProvider。

    应用想对外提供数据，可以通过派生ContentProvider类，封装成一枚ContentProvider，

    每个ContentProvider都用一个uri作为独立的标识，形如：content://com.xxx...所有的东西都看起来像REST的样子，

    但实际上它比REST更灵活。和REST累死，uri也可以有两种类型，带id的、列表的。

    但实现着不一定非按照这个模式来做，给你id的uri你也可以返回列表类型的数据，只要调用者明白，就无妨。

    另外，ContentProvider不像REST只能接收uri，ContentProvider还可以接收Projection、Selection、OrderBy等参数，

    这样就可以像数据库那样进行投影、选择和排序。查询到的结果以Cursor的形式进行返回，调用者可以移动Cursor来访问各列的数据。

    ContentProvider内部常用数据库来实现，Android对Sqlite的支持非常强大，但很多时候也可以封装文件或其他混合的数据。

 

    在Android中，ContentResolver是用来发起ContentProvider的定位和访问的。不过它仅提供了同步访问的ContentProvider的接口。

    但通常，ContentProvider需要访问一些大数据源，因此Android提供了一个AsyncQueryHandler帮助进行异步访问ContentProvider。

}

 

 

在各大组件中，Service和Content Provider都是那种需要持续访问的。Service如果是一个耗时的场景，往往会提供异步访问的接口，

而Content Provider不论效率如何，都提供的是约定的同步访问接口。我想这遵循的就是场景导向设计的原则，

因为Content Provider仅是提供数据访问的，它不能确信具体的使用场景如何，会怎样使用它的数据，

而相比之下，Service包含的逻辑更复杂更完整，可以抉择大部分时候使用某接口的场景，从而确定最贴切的接口是同步还是异步，简化了上层调用的逻辑。

学习：Android框架

引言

通过前面两篇：

• Android 开发之旅：环境搭建及HelloWorld

• Android 开发之旅：HelloWorld项目的目录结构

我 们对android有了个大致的了解，知道如何搭建android的环境及简单地写一个HelloWorld程序，而且知道一个android项目包括哪 些文件夹和文件及相应的作用。本篇将站在顶级的高度——架构，来看android。我开篇就说了，这个系列适合0基础的人且我也是从0开始按照这个步骤来 学的，谈架构是不是有点螳臂挡车，自不量力呢？我觉得其实不然，如果一开始就对整个android的架构了然于胸，就不会误入歧途，能够很好地把握全局。 本文的主题如下：

• 1、架构图直观
• 2、架构详解
  • 2.1、Linux Kernel
  • 2.1、Android Runtime
  • 2.3、Libraries
  • 2.4、Application Framework
  • 2.5、Applications
• 3、总结

1、架构图直观

下面这张图展示了Android系统的主要组成部分：

图1、Android系统架构（来源于：android sdk）

可以很明显看出，Android系统架构由5部分组成，分别是：Linux Kernel、Android Runtime、Libraries、Application Framework、Applications。第二部分将详细介绍这5个部分。

2、架构详解

现在我们拿起手术刀来剖析各个部分。其实这部分SDK文档已经帮我们做得很好了，我们要做的就是拿来主义，然后再加上自己理解。下面自底向上分析各层。

2.1、Linux Kernel

Android基于Linux 2.6提供核心系统服务，例如：安全、内存管理、进程管理、网络堆栈、驱动模型。Linux Kernel也作为硬件和软件之间的抽象层，它隐藏具体硬件细节而为上层提供统一的服务。

如果你学过计算机网络知道OSI/RM，就会知道分层的好处就是使用下层提供的服务而为上层提供统一的服务，屏蔽本层及以下层的差异，当本层及以下层发生了变化不会影响到上层。也就是说各层各司其职，各层提供固定的SAP（Service Access Point），专业点可以说是高内聚、低耦合。

如果你只是做应用开发，就不需要深入了解Linux Kernel层。

2.2、Android Runtime

Android 包含一个核心库的集合，提供大部分在Java编程语言核心类库中可用的功能。每一个Android应用程序是Dalvik虚拟机中的实例，运行在他们自己 的进程中。Dalvik虚拟机设计成，在一个设备可以高效地运行多个虚拟机。Dalvik虚拟机可执行文件格式是.dex，dex格式是专为Dalvik 设计的一种压缩格式，适合内存和处理器速度有限的系统。

大多数虚拟机包括JVM都是基于栈的，而Dalvik虚拟机则是基于寄存器的。 两种架构各有优劣，一般而言，基于栈的机器需要更多指令，而基于寄存器的机器指令更大。dx 是一套工具，可以將 Java .class 转换成 .dex 格式。一个dex文件通常会有多个.class。由于dex有時必须进行最佳化，会使文件大小增加1-4倍，以ODEX结尾。

Dalvik虚拟机依赖于Linux 内核提供基本功能，如线程和底层内存管理。

2.3、Libraries

Android包含一个C/C++库的集合，供Android系统的各个组件使用。这些功能通过Android的应用程序框架（application framework）暴露给开发者。下面列出一些核心库：

• 系统C库——标准C系统库（libc）的BSD衍生，调整为基于嵌入式Linux设备
• 媒体库——基于PacketVideo的OpenCORE。这些库支持播放和录制许多流行的音频和视频格式，以及静态图像文件，包括MPEG4、 H.264、 MP3、 AAC、 AMR、JPG、 PNG
• 界面管理——管理访问显示子系统和无缝组合多个应用程序的二维和三维图形层
• LibWebCore——新式的Web浏览器引擎,驱动Android 浏览器和内嵌的web视图
• SGL——基本的2D图形引擎
• 3D库——基于OpenGL ES 1.0 APIs的实现。库使用硬件3D加速或包含高度优化的3D软件光栅
• FreeType ——位图和矢量字体渲染
• SQLite ——所有应用程序都可以使用的强大而轻量级的关系数据库引擎

2.4、Application Framework

通过提供开放的开发平台，Android使开发者能够编制极其丰富和新颖的应用程序。开发者可以自由地利用设备硬件优势、访问位置信息、运行后台服务、设置闹钟、向状态栏添加通知等等，很多很多。

开发者可以完全使用核心应用程序所使用的框架APIs。应用程序的体系结构旨在简化组件的重用，任何应用程序都能发布他的功能且任何其他应用程序可以使用这些功能（需要服从框架执行的安全限制）。这一机制允许用户替换组件。

所有的应用程序其实是一组服务和系统，包括：

• 视图（View）——丰富的、可扩展的视图集合，可用于构建一个应用程序。包括包括列表、网格、文本框、按钮，甚至是内嵌的网页浏览器
• 内容提供者（Content Providers）——使应用程序能访问其他应用程序（如通讯录）的数据，或共享自己的数据
• 资源管理器（Resource Manager）——提供访问非代码资源，如本地化字符串、图形和布局文件
• 通知管理器（Notification Manager）——使所有的应用程序能够在状态栏显示自定义警告
• 活动管理器（Activity Manager）——管理应用程序生命周期,提供通用的导航回退功能

2.5、Applications

Android装配一个核心应用程序集合，包括电子邮件客户端、SMS程序、日历、地图、浏览器、联系人和其他设置。所有应用程序都是用Java编程语言写的。更加丰富的应用程序有待我们去开发！

3、总结

从 上面我们知道Android的架构是分层的，非常清晰，分工很明确。Android本身是一套软件堆叠(Software Stack)，或称为「软件叠层架构」，叠层主要分成三层：操作系统、中间件、应用程序。从上面我们也看到了开源的力量，一个个熟悉的开源软件在这里贡献 了自己的一份力量。

现在我们对android的系统架构有了一个整体上的了解，我将用一个例子来深入体会一下，但是考虑到此系列希望0基础的人也能看懂，在介绍例子之前将介绍一下Android应用程序的原理及一些术语，可能需要几篇来介绍。敬请关注！

移动互联网盈利模式

在今天的 CSDN 2012 移动开发者大会上，李开复在谈到移动互联网盈利模式的时候表示，和互联网一样，移动互联网也有 1. 靠入口或者门户；2. 靠游戏或者虚拟货币、虚拟道具；3. 靠商业服务；4. 靠广告 这四种盈利模式。

1. 门户和入口：腾讯、360、豌豆荚、91 等一批公司一定程度上形成了入口，但未来也会有更多的机会；

2. 游戏：移动游戏和 PC 的端游戏收费模式很像，比如《望仙》和《世界 online》，月收入都达到 1200 万以上。他同时提醒游戏开发者不要小看 Android，“我们要做出一个预测，就是安卓很能赚钱，对一个游戏开发者来说，一定是安卓带来更多的机会。”

3. 商业服务：他对此表示担忧，但认为迟早要突破。

4. 广告：“未来会非常光明，只是可能要再等一下。”

他还同时表示 看好O2O，但目前线下商家尚未准备好。在讲话的最后，他做出判断：移动互联网融入主流生活与商业社会，货币化浪潮即将到来：

1. 高增速仍将继续，2012 年移动互联网将跨越 5 亿；

2. 简单通俗的娱乐化产品将爆发式增长；

3.2013 年将会诞生单月收入突破 4000 万的 Android 网游，整体市场规模将超 50 亿；

4.O2O 与线下多个行业的融合与碰撞将贯穿今后数年；

5. 移动互联网将取代桌面互联网，成为每个人连接世界、认知社会、传播智慧的首要渠道。