组内会议总结(一)

1.fragment

activity加载fragment时的代码：

fragmenta   fm1=new  fragmenta (); 
FragmentManager FM = getSupportFragmentManager();
FM.beginTransaction().replace(R.id.main_ FrameLayout, fm1).commit();

fragment与fragment之间切换的代码：

	@Override//核心代码
     public void onClick(View v) {
         //获取fragment的实例
       Fragment fragment=new Fragment();
        //获取Fragment的管理器
        FragmentManager fragmentManager=getFragmentManager();
       //开启fragment的事物,在这个对象里进行fragment的增删替换等操作。
       FragmentTransaction ft=fragmentManager.beginTransaction();
       //跳转到fragment，第一个参数为所要替换的位置id，第二个参数是替换后的fragment
       ft.replace(R.layout.fragment1_layout,fragment);
        //提交事物
      ft.commit();
    }

fragment跳转到activity的代码：

 Intent intent = new Intent(getActivity(),MainActivity.class);
  startactivity(intent);

listfragment的用法

Activity横竖屏切换时生命周期变化：

http://blog.csdn.net/ryantang03/article/details/7749108

2.xml解析

在Android中，常见的XML解析器分别为SAX解析器、DOM解析器和PULL解析器.

SAX解析器和使用Dom方式解析：

SAX（Simple API for XML)

  SAX处理的优点非常类似于流媒体的优点。分析能够立即开始，而不是等待所有的数据被处理。而且，由于应用程序只是在读取数据时检查数据，因此不需要将数据存储在内存中。这对于大型文档来说是个巨大的优点。事实上，应用程序甚至不必解析整个文档；它可以在某个条件得到满足时停止解析。一般来说，SAX还比它的替代者DOM快许多。

【优势】
     ①不需要等待所有数据都被处理，分析就能立即开始。
     ②只在读取数据时检查数据，不需要保存在内存中。
     ③可以在某个条件得到满足时停止解析，不必解析整个文档。
     ④效率和性能较高，能解析大于系统内存的文档。

【缺点】
     ①需要应用程序自己负责TAG的处理逻辑（例如维护父/子关系等），文档越复杂程序就越复杂。
     ②单向导航，无法定位文档层次，很难同时访问同一文档的不同部分数据，不支持XPath。

演讲者总结

DOM：

  解析器读入整个文档，然后构建一个驻留内存的树结构，然后代码就可以使用 DOM 接口来操作这个树结构。

   优点：整个文档树在内存中，便于操作；支持删除、修改、重新排列等多种功能；

   缺点：将整个文档调入内存（包括无用的节点），浪费时间和空间；

   使用场合：一旦解析了文档还需多次访问这些数据；硬件资源充足（内存、CPU）

SAX：

   事件驱动。当解析器发现元素开始、元素结束、文本、文档的开始或结束等时，发送事件，程序员编写响应这些事件的代码，保存数据。

   优点：不用事先调入整个文档，占用资源少

   缺点：不是持久的；事件过后，若没保存数据，那么数据就丢了；无状态性；从事件中只能得到文本，但不知该文本属于哪个元素；

  使用场合：只需XML文档的少量内容，很少回头访问；一次性读取；机器内存少；

  注意:SAX 解析器不创建任何对象。

具体网站：http://blog.csdn.net/comeonyangzi/article/details/25722275

4.四大组件

activity的四种启动模式：

（1） standard   默认标准的启动模式， 每次startActivity都是创建一个新的activity的实例。适用于绝大大数情况
（2）singleTop  单一顶部，如果要开启的activity在任务栈的顶部已经存在，就不会创建新的实例，而是调用 onNewIntent() 方法。应用场景： 浏览器书签。 避免栈顶的activity被重复的创建，解决用户体验问题。
（3）singletask 单一任务栈 ， activity只会在任务栈里面存在一个实例。如果要激活的activity，在任务栈里面已经存在，就不会创建新的activity，而是复用这个已经存在的activity，调用 onNewIntent() 方法，并且清空当前activity任务栈上面所有的activity应用场景：浏览器activity， 整个任务栈只有一个实例，节约内存和cpu的目的。注意： activity还是运行在当前应用程序的任务栈里面的。不会创建新的任务栈。
（4）singleInstance  单态 单例模式，单一实例，整个手机操作系统里面只有一个实例存在。不同的应用去打开这个activity 共享 公用的同一个activity。他会运行在自己单独，独立的任务栈里面，并且任务栈里面只有他一个实例存在。应用场景：呼叫来电界面 InCallScreen

四个模式的区别：

这些模式主要区别在以下四点： 
  哪个任务存放着activity，用来对行为进行响应。 对“standard ”和“singleTop ”模式来说，这个任务是产生行为(并且调用startActivity() )的那个——除非行为对象包含了 FLAG_ACTIVITY_NEW_TASK 标记。在这种情况下，像前面那节Affinities and new tasks  描述的一样，将会选择一个不同的任务。 
  它们是否可以有多个实例。 "standard "和“singleTop ”类型的activity可以被实例化多次。它们可以属于多个任务，一个特定的任务也可以拥有同一个activity的多个实例。 
作为比较"singleTask "和"singleInstance "类型的activity只限定有一个实例。因为这些activity是任务的根。这个限制意味着，在设备上不能同时有超过一个任务的实例。 
是否能有其他的activity在它所在的任务中。"singleInstance " 类型的activity是它所在任务中唯一的activity。如果它启动了其他的activity，不管那个activity的启动模式如何，它都会加载到一个不同的任务中——好像行为对象中的FLAG_ACTIVITY_NEW_TASK 标记。在其他的方面，"singleInstance "和"singleTask "模式是相同的。 
  其他三种模式运行任务中有多个activity。"singleTask "总是任务中的根activity，但是它可以启动其他的activity并分配到它所在的任务中。"standard "和"singleTop "类型的activity可以出现在任务中的任何地方。 
  是否启动一个新的实例来处理一个新的行为。 对默认的"standard "模式来说，对于每一个行为都会创建一个新的实例来响应。每个实例只处理一个行为。对于"singleTop "模式，如果一个已经存在的实例位于目标任务activity栈的栈顶，那么他将被重用来处理这个行为。如果它不在栈顶，它将不会被重用，而是为行为创建一个新的实例，并压入栈中。 
  例如，假设，一个任务的activity栈由根activity A和 B,C,D从上到下按这样的顺序组成，所以这个栈就是A-B-C-D。一个行为指向类型为D的activity。如果D是默认的"standard "加载模式，一个新的实例会被启动，栈现在就是这样A-B-C-D-D。但是，如果D的加载模式是"singleTop "，已经存在的实例会用来处理这个行为(因为它在栈的顶端)并且栈中还应该是A-B-C-D。 
  在前面提到，"singleTask "和"singleInstance "类型的activity最多只有一个实例，所以他们的实例应该会处理每个新的行为。"singleInstance "类型的activity总是在栈的顶端(因为他是任务中唯一的一个activity)，所以总是能够适当的处理行为。然而，"singleTask "类型的activity也许会有其他的activity在它的上面。如果是这样的话，那就不能处理这个行为，这个行为被丢弃。(即使这个行为被丢弃了，它的到来也会导致那些应该保留不变任务显示到前台来)。

Android四大组件之——Service

Service（服务）是一个没有用户界面的在后台运行执行耗时操作的应用组件。其他应用组件能够启动Service，并且当用户切换到另外的应用场景，Service将持续在后台运行。另外，一个组件能够绑定到一个service与之交互（IPC机制），例如，一个service可能会处理网络操作，播放音乐，操作文件I/O或者与内容提供者（content provider）交互，所有这些活动都是在后台进行。

Service有两种状态，“启动的”和“绑定”

通过startService()启动的服务处于“启动的”状态，一旦启动，service就在后台运行，即使启动它的应用组件已经被销毁了。通常started状态的service执行单任务并且不返回任何结果给启动者。比如当下载或上传一个文件，当这项操作完成时，service应该停止它本身。

还有一种“绑定”状态的service，通过调用bindService()来启动，一个绑定的service提供一个允许组件与service交互的接口，可以发送请求、获取返回结果，还可以通过夸进程通信来交互（IPC）。绑定的service只有当应用组件绑定后才能运行，多个组件可以绑定一个service，当调用unbind()方法时，这个service就会被销毁了。

另外，在官方的说明文档中还有一个警告：

意思是service与activity一样都存在与当前进程的主线程中，所以，一些阻塞UI的操作，比如耗时操作不能放在service里进行，比如另外开启一个线程来处理诸如网络请求的耗时操作。如果在service里进行一些耗CPU和耗时操作，可能会引发ANR警告，这时应用会弹出是强制关闭还是等待的对话框。所以，对service的理解就是和activity平级的，只不过是看不见的，在后台运行的一个组件，这也是为什么和activity同被说为Android的基本组件。

Android四大组件之—— BroadcastReceiver

（1）你的应用可以使用它对外部事件进行过滤，只对感兴趣的外部事件(如当电话呼入时，或者数据网络可用时)进行接收并做出响应。广播接收器没有用户界面。然而，它们可以启动一个activity或serice来响应它们收到的信息，或者用NotificationManager来通知用户。通知可以用很多种方式来吸引用户的注意力，例如闪动背灯、震动、播放声音等。一般来说是在状态栏上放一个持久的图标，用户可以打开它并获取消息。

（2）广播接收者的注册有两种方法，分别是程序动态注册和AndroidManifest文件中进行静态注册。

（3）动态注册广播接收器特点是当用来注册的Activity关掉后，广播也就失效了。静态注册无需担忧广播接收器是否被关闭，只要设备是开启状态，广播接收器也是打开着的。也就是说哪怕app本身未启动，该app订阅的广播在触发时也会对它起作用。

http://www.2cto.com/kf/201404/296055.html

Android四大组件之—— content provider

（1）android平台提供了Content Provider使一个应用程序的指定数据集提供给其他应用程序。其他应用可以通过ContentResolver类从该内容提供者中获取或存入数据。

（2）只有需要在多个应用程序间共享数据是才需要内容提供者。例如，通讯录数据被多个应用程序使用，且必须存储在一个内容提供者中。它的好处是统一数据访问方式。

（3）ContentProvider实现数据共享。ContentProvider用于保存和获取数据，并使其对所有应用程序可见。这是不同应用程序间共享数据的唯一方式，因为android没有提供所有应用共同访问的公共存储区。

（4）开发人员不会直接使用ContentProvider类的对象，大多数是通过ContentResolver对象实现对ContentProvider的操作。

http://blog.csdn.net/zuolongsnail/article/details/6566317

http://xiechengfa.iteye.com/blog/1415829

http://www.cnblogs.com/devinzhang/archive/2012/01/20/2327863.html

5.android调试

调试需要注意单步调试F6，进入函数内部F5，跳向下一个断点F8.

注意的是for循环的根据条件调试想要的结果。

6.android出现anr原因

第一：什么会引发ANR？
 
    在Android里，应用程序的响应性是由Activity Manager和WindowManager系统服务监视的 。当它监测到以下情况中的一个时，Android就会针对特定的应用程序显示ANR：
1.在5秒内没有响应输入的事件（例如，按键按下，屏幕触摸）
2.BroadcastReceiver在10秒内没有执行完毕
造成以上两点的原因有很多，比如在主线程中做了非常耗时的操作，比如说是下载，io异常等。
   
    潜在的耗时操作，例如网络或数据库操作，或者高耗时的计算如改变位图尺寸，应该在子线程里（或者以数据库操作为例，通过异步请求的方式）来完成。然而，不是说你的主线程阻塞在那里等待子线程的完成——也不是调用 Thread.wait()或是Thread.sleep()。替代的方法是，主线程应该为子线程提供一个Handler，以便完成时能够提交给主线程。以这种方式设计你的应用程序，将能保证你的主线程保持对输入的响应性并能避免由于5秒输入事件的超时引发的ANR对话框。
 
第二：如何避免ANR？
 
1、运行在主线程里的任何方法都尽可能少做事情。特别是，Activity应该在它的关键生命周期方法（如onCreate()和onResume()）里尽可能少的去做创建操作。（可以采用重新开启子线程的方式，然后使用Handler+Message的方式做一些操作，比如更新主线程中的ui等）
 
2、应用程序应该避免在BroadcastReceiver里做耗时的操作或计算。但不再是在子线程里做这些任务（因为 BroadcastReceiver的生命周期短），替代的是，如果响应Intent广播需要执行一个耗时的动作的话，应用程序应该启动一个 Service。（此处需要注意的是可以在广播接受者中启动Service，但是却不可以在Service中启动broadcasereciver,关于原因后续会有介绍，此处不是本文重点）
 
3、避免在Intent Receiver里启动一个Activity，因为它会创建一个新的画面，并从当前用户正在运行的程序上抢夺焦点。如果你的应用程序在响应Intent广 播时需要向用户展示什么，你应该使用Notification Manager来实现。
 
总结：anr异常也是在程序中自己经常遇到的问题，主要的解决办法自己最常用的就是不要在主线程中做耗时的操作，而应放在子线程中来实现，比如采用Handler+mesage的方式，或者是有时候需要做一些和网络相互交互的耗时操作就采用asyntask异步任务的方式（它的底层其实Handler+mesage有所区别的是它是线程池）等，在主线程中更新UI。