有谁能具体介绍下Android软件的开发周期特点，其主流IDE工具，Go语言的优缺点？（50分）

Android系统试图尽可能长地保持一个应用程序进程，但是当内存低时它最终还是需要移除旧的进程。为了决定保持哪个进程及杀死哪个进程，Android将每个进程放入一个基于运行于其中的组件的重要性等级和这些组件的状态。重要性最低的进程首先被杀死，然后是次低，以此类推。总共有5个层次等级。下列清单按重要性顺序列出：前台进程，用户当前工作所需要的。一个进程如果满足下列任何条件被认为是前台进程：它正运行着一个正在与用户交互的活动（Activity对象的onResume()方法已经被调用）。它寄宿了一个服务，该服务与一个与用户交互的活动绑定。它有一个Service对象执行它的生命周期回调（onCreate()、onStart()、onDestroy()）。它有一个BroadcastReceiver对象执行他的onReceive()方法。

双城网站建设公司创新互联公司,双城网站设计制作，有大型网站制作公司丰富经验。已为双城成百上千提供企业网站建设服务。企业网站搭建\成都外贸网站建设要多少钱，请找那个售后服务好的双城做网站的公司定做！

在给定时间内仅有少数的前台进程存在。仅作为最后采取的措施他们才会被杀掉——如果内存太低以至于他们不能继续运行。一般来说，就在那时，设备达到一个内存？？？状态，因此杀掉某些前台进程以保持用户界面响应。可视进程，他没有任何前台组件，但是仍然能影响用户在屏幕上看到东西。一个进程满足下面任何一个条件都被认为是可视的:它寄宿着一个不是前台的活动，但是它对用户仍可见（它的onPause()方法已经被调用）。举例来说，这可能发送在，如果一个前台活动是一个对话框且运行之前的活动在其后面仍可视。它寄宿着一个服务，该服务绑定到一个可视的活动。

一个可视进程被认为是及其重要的且不会被杀死，除非为了保持前台进程运行。服务进程，是一个运行着一个用startService()方法启动的服务，并且该服务并没有落入上面2种分类。虽然服务进程没有直接关系到任何用户可见的，它们通常做用户关心的事（诸如在后台播放mp3或者从网络上下载数据），因此系统保持它们运行，除非没有足够内存随着所有的前台进程和可视进程保持它们。后台进程，是一个保持着一个当前对用户不可视的活动（已经调用Activity对象的onStop()方法）。这些进程没有直接影响用户体验，并且可以在任何时候被杀以收回内存用于一个前台、可视、服务进程。一般地有很多后台进程运行着，因此它们保持在一个LRU（least recently used，即最近最少使用，如果您学过操作系统的话会觉得它很熟悉，跟内存的页面置换算法LRU一样。）列表以确保最近使用最多的活动的进程最后被杀。如果一个活动执行正确地执行它的生命周期方法，且捕获它当前的状态，杀掉它对用户的体验没有有害的影响。空进程，是一个没有保持活跃的应用程序组件的进程。保持这个进程可用的唯一原因是作为一个cache以提高下次启动组件的速度。系统进程杀死这些进程，以在进程cache和潜在的内核cache之间平衡整个系统资源。Android把进程标记为它可以的最高级，即进程中活跃的组件中重要性最高的那个（选取重要性最高的那个作为进程的重要性级别）。例如，有一个进程寄宿着一个服务和一个可视活动，进程的级别被设置为可视进程级别，而不是服务进程级别（因为可视进程级别比服务进程级别高）。此外，一个进程的排名因为其他进程依赖它而上升。一个进程服务其它进程，它的排名从不会比它服务的进程低。例如，进程A中的一个内容提供者服务进程B中的一个客户，或者进程A中的一个服务绑定到进程B中的一个组件，进程A总是被认为比进程B重要。因为一个运行一个服务进程排名比一个运行后台活动的进程排名高，一个活动启动一个服务来初始化一个长时间运行操作，而不是简单地衍生一个线程——特别是如果操作很可能会拖垮活动。这方面的例子是在后台播放音乐和上传相机拍摄的图片到一个网站。使用服务保证操作至少有“服务进程”的优先级，无论活动发生什么情况。

如何看待go语言泛型的最新设计？

Go 由于不支持泛型而臭名昭著，但最近，泛型已接近成为现实。Go 团队实施了一个看起来比较稳定的设计草案，并且正以源到源翻译器原型的形式获得关注。本文讲述的是泛型的最新设计，以及如何自己尝试泛型。

例子

FIFO Stack

假设你要创建一个先进先出堆栈。没有泛型，你可能会这样实现：

type Stack []interface{}func (s Stack) Peek() interface{} {

return s[len(s)-1]

}

func (s *Stack) Pop() {

*s = (*s)[:

len(*s)-1]

}

func (s *Stack) Push(value interface{}) {

*s = 

append(*s, value)

}

但是，这里存在一个问题：每当你 Peek 项时，都必须使用类型断言将其从 interface{} 转换为你需要的类型。如果你的堆栈是 *MyObject 的堆栈，则意味着很多 s.Peek().(*MyObject)这样的代码。这不仅让人眼花缭乱，而且还可能引发错误。比如忘记 * 怎么办？或者如果您输入错误的类型怎么办？s.Push(MyObject{})` 可以顺利编译，而且你可能不会发现到自己的错误，直到它影响到你的整个服务为止。

通常，使用 interface{} 是相对危险的。使用更多受限制的类型总是更安全，因为可以在编译时而不是运行时发现问题。

泛型通过允许类型具有类型参数来解决此问题：

type Stack(type T) []Tfunc (s Stack(T)) Peek() T {

return s[len(s)-1]

}

func (s *Stack(T)) Pop() {

*s = (*s)[:

len(*s)-1]

}

func (s *Stack(T)) Push(value T) {

*s = 

append(*s, value)

}

这会向 Stack 添加一个类型参数，从而完全不需要 interface{}。现在，当你使用 Peek() 时，返回的值已经是原始类型，并且没有机会返回错误的值类型。这种方式更安全，更容易使用。（译注：就是看起来更丑陋，^-^）

此外，泛型代码通常更易于编译器优化，从而获得更好的性能（以二进制大小为代价）。如果我们对上面的非泛型代码和泛型代码进行基准测试，我们可以看到区别：

type MyObject struct {

X 

int

}

var sink MyObjectfunc BenchmarkGo1(b *testing.B) {

for i := 0; i  b.N; i++ {

var s Stack

s.Push(MyObject{})

s.Push(MyObject{})

s.Pop()

sink = s.Peek().(MyObject)

}

}

func BenchmarkGo2(b *testing.B) {

for i := 0; i  b.N; i++ {

var s Stack(MyObject)

s.Push(MyObject{})

s.Push(MyObject{})

s.Pop()

sink = s.Peek()

}

}

结果：

BenchmarkGo1BenchmarkGo1-16     12837528         87.0 ns/op       48 B/op        2 allocs/opBenchmarkGo2BenchmarkGo2-16     28406479         41.9 ns/op       24 B/op        2 allocs/op

在这种情况下，我们分配更少的内存，同时泛型的速度是非泛型的两倍。

合约（Contracts）

上面的堆栈示例适用于任何类型。但是，在许多情况下，你需要编写仅适用于具有某些特征的类型的代码。例如，你可能希望堆栈要求类型实现 String() 函数

Go语言实践模式 - 函数选项模式(Functional Options Pattern)

大家好，我是小白，有点黑的那个白。

最近遇到一个问题，因为业务需求，需要对接第三方平台.

而三方平台提供的一些HTTP(S)接口都有统一的密钥生成规则要求.

为此我们封装了一个独立的包 xxx-go-sdk 以便维护和对接使用.

其中核心的部分是自定义HTTP Client,如下:

一些平台会要求appKey/appSecret等信息，所以Client结构体就变成了这样，这时参数还比较少, 而且是必填的参数，我们可以提供构造函数来明确指定。

看起来很满足，但是当我们需要增加一个 Timeout 参数来控制超时呢?

或许你会说这还不简单，像下面一样再加一个参数呗

那再加些其他的参数呢？那构造函数的参数是不是又长又串，而且每个参数不一定是必须的，有些参数我们又会考虑默认值的问题。

为此，勤劳但尚未致富的 gophers 们使用了总结一种实践模式

首先提取所有需要的参数到一个独立的结构体 Options，当然你也可以用 Configs 啥的.

然后为每个参数提供设置函数

这样我们就为每个参数设置了独立的设置函数。返回值 func(*Options) 看着有点不友好，我们提取下定义为单个 Option 调整一下代码

当我们需要添加更多的参数时，只需要在 Options 添加新的参数并添加新参数的设置函数即可。

比如现在要添加新的参数 Timeout

这样后续不管新增多少参数，只需要新增配置项并添加独立的设置函数即可轻松扩展，并且不会影响原有函数的参数顺序和个数位置等。

至此，每个选项是区分开来了，那么怎么作用到我们的 Client 结构体上呢?

首先，配置选项都被提取到了 Options 结构体重，所以我们需要调整一下 Client 结构体的参数

其次，每一个选项函数返回 Option,那么任意多个就是 ...Option，我们调整一下构造函数 NewClient 的参数形式，改为可变参数，不再局限于固定顺序的几个参数。

然后循环遍历每个选项函数，来生成Client结构体的完整配置选项。

那么怎么调用呢？对于调用方而已，直接在调用构造函数NewClient()的参数内添加自己需要的设置函数(WithXXX)即可

当需要设置超时参数，直接添加 WithTimeout即可,比如设置3秒的超时

配置选项的位置可以任意设置，不需要受常规的固定参数顺序约束。

可以看到，这种实践模式主要作用于配置选项，利用函数支持的特性来实现的，为此得名 Functional Options Pattern，优美的中国话叫做「函数选项模式」。

最后, 我们总结回顾一下在Go语言中函数选项模式的优缺点

本文题目：go语言惊人优缺点 go语言 优缺点
网页地址：http://hbruida.cn/article/ddoedcd.html