一点按钮出现Unable to start activity ComponentInfo

我们学习 Android 过程中会发现，我们的文件都是 .java 文件，也就是说 Android 开发还是用的 Java 语言来编写的。也正是这样，所以你们来学 Android ，也会让你们先学习一段时间 Java 。掌握好了 Java 的相关知识，学起 Android 来可谓是事半功倍。好了，你们是不是感觉有点扯远了啊，不是说好讲 ActivityThread 类的么，其实并不如此。 你们在刚开始从 Java 学习转到 Android 学习的过程中，有一个重大的改变不知道你们又没有发现。那就是 Java 中的 main() 方法，程序的入口不见了，取而代之的是 onCreate() 方法。你们没有一点疑惑么？初学阶段直接无脑接受是对的，但是作为一个工作几年了的人来说，就有必要去深入研究一下了。明明 Android 也就是 Java 语言也编写的，差别咋就这么大呢？ 其实呢， Android 中还是有 main() 方法的，只是隐藏的比较深而已。今天，就由我 AIqingfeng 来带你们一探究竟~！ 我们先找到 ActivityThread 这个类，看一下注释（ 较少 ，值得一看）： 翻译一下就是：在 Application 进程中 管理执行主线程，调度和执行 活动和广播 ，和活动管理请求的其它操作。 Android 上一个应用的入口，应该是 ActivityThread 类，和普通的Java 类一样，入口是一个 main() 方法。 好了，现在我们解决了我们开始的疑惑后，再来深度学习一下这个类的一些知识吧。 ActivityThread 有几个比较重要的成员变量，会在创建ActivityThread对象时初始化。 final ApplicationThread mAppThread = new ApplicationThread(); ApplicationThread继承自ApplicationThreadNative， 而ApplicationThreadNative又继承自Binder并实现了IApplicationThread接口。IApplicationThread继承自IInterface。这是一个很明显的binder结构，用于与Ams通信。IApplicationThread接口定义了对一个程序（Linux的进程）操作的接口。ApplicationThread通过binder与Ams通信，并将Ams的调用，通过下面的H类（也就是Hnalder）将消息发送到消息队列，然后进行相应的操作，入activity的start， stop。 final H mH = new H(); 这个 H 大家首先会想到什么啊，不要开车哈。看到 H 想到了 Handler 。发现 H 是 ActivityThread 内部类，继承自 Handler ，果然没错。所以大家遇到不清楚的，不要怕，大胆的猜测一下。 Handler 最重要的的也就是 handleMessage() 方法了。查看一下其方法： ActivityThread.java 点进来咯。 ActivityThread.java 兴趣是最好的老师。ActivityThread.java 先探索一下 Activity 创建这条路吧。最底层啦。Instrumentation.java Native方法，C语言啦，活动创建之路结束了。Class.java 再来看看 Activity 中 onCreate() 方法执行之路吧。 Instrumentation.java 到了 Activity 了，哪里我们自己 Activity 还远么~！ Activity.java 来，仔细瞅瞅~！ Activity.java

在源码ZygoteInit这个类里，用的是反射

以前一直都说Activity的人口是onCreate方法。其实android上一个应用的入口，应该是ActivityThread。和普通的java类一样，入口是一个main方法。public static void main(String[] args) {SamplingProfilerIntegration.start();// CloseGuard defaults to true and can be quite spammy. We// disable it here, but selectively enable it later (via// StrictMode) on debug builds, but using DropBox, not logs.CloseGuard.setEnabled(false);Environment.initForCurrentUser();// Set the reporter for event logging in libcoreEventLogger.setReporter(new EventLoggingReporter());Security.addProvider(new AndroidKeyStoreProvider());Process.setArgV0("<pre-initialized>");Looper.prepareMainLooper();ActivityThread thread = new ActivityThread();thread.attach(false);if (sMainThreadHandler == null) {sMainThreadHandler = thread.getHandler();}AsyncTask.init();if (false) {Looper.myLooper().setMessageLogging(newLogPrinter(Log.DEBUG, "ActivityThread"));}Looper.loop();throw new RuntimeException("Main thread loop unexpectedly exited");}

一个App的程序入口到底是什么？ 是ActivityThread.main()。 整个App的主线程的消息循环是在哪里创建的？ 是在ActivityThread初始化的时候，就已经创建消息循环了，所以在主线程里面创建Handler不需要指定Looper，而如果在其他线程使用Handler，则需要单独使用Looper.prepare()和Looper.loop()创建消息循环。 Application是在什么时候创建的？onCreate()什么时候调用的？ 也是在ActivityThread.main()的时候，再具体点呢，就是在thread.attach(false)的时候。 看你的表情，不信是吧！ 我们先看一下ActivityThread.attach() 这里需要关注的就是mgr.attachApplication(mAppThread)，这个就会通过Binder调用到AMS里面对应的方法 然后就是 thread是IApplicationThread，实际上就是ApplicationThread在服务端的代理类ApplicationThreadProxy，然后又通过IPC就会调用到ApplicationThread的对应方法 我们需要关注的其实就是最后的sendMessage()，里面有函数的编号H.BIND_APPLICATION，然后这个Messge会被H这个Handler处理 最后就在下面这个方法中，完成了实例化，然后通过mInstrumentation.callApplicationOnCreate实现了onCreate()的调用。 data.info是一个LoadeApk对象。 所以最后还是通过Instrumentation.makeApplication()实例化的，这个老板娘真的很厉害呀！

恩，顶上

startActivity启动失败，主要原因是AndroidManifest.xml文件中没有注册对应的模块Activity导致的问题。如：Intent intent = new Intent(this, RecordListActivity.class);startActivity(intent);主要问题是AndroidManifest.xml中没有注册对应的模块引起的，AndroidManifest.xml中需增加：<activity android:name=".RecordListActivity"></activity>

学过数电吗？

android程序如果出问题，因为实际是java程序，所以会抛出异常，比如这样。弹出的警告对话框中没有异常信息，如果需要看到日志内容，可执行：adb logcat即可见到异常信息。或者通过ddms，通过device》run logcat通过图形界面查看日志，和上面的命令效果一样。这是一个异常的内容：W/dalvikvm(26121): threadid=3: thread exiting with uncaught exception (group=0x4000fe70)E/AndroidRuntime(26121): Uncaught handler: thread main exiting due to uncaught exceptionE/AndroidRuntime(26121): java.lang.RuntimeException: Unable to start activity ComponentInfo{com.easymorse.activity/com.easymorse.activity.ActivityTest}: java.lang.SecurityException: Requires READ_PHONE_STATE: Neither user 10032 nor current process has android.permission.READ_PHONE_STATE.E/AndroidRuntime(26121): at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2268)E/AndroidRuntime(26121): at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2284)E/AndroidRuntime(26121): at android.app.ActivityThread.access$1800(ActivityThread.java:112)E/AndroidRuntime(26121): at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1692)E/AndroidRuntime(26121): at android.os.Handler.dispatchMessage(Handler.java:99)E/AndroidRuntime(26121): at android.os.Looper.loop(Looper.java:123)E/AndroidRuntime(26121): at android.app.ActivityThread.main(ActivityThread.java:3948)E/AndroidRuntime(26121): at java.lang.reflect.Method.invokeNative(Native Method)E/AndroidRuntime(26121): at java.lang.reflect.Method.invoke(Method.java:521)E/AndroidRuntime(26121): at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:782)E/AndroidRuntime(26121): at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:540)E/AndroidRuntime(26121): at dalvik.system.NativeStart.main(Native Method)E/AndroidRuntime(26121): Caused by: java.lang.SecurityException: Requires READ_PHONE_STATE: Neither user 10032 nor current process has android.permission.READ_PHONE_STATE.E/AndroidRuntime(26121): at android.os.Parcel.readException(Parcel.java:1234)E/AndroidRuntime(26121): at android.os.Parcel.readException(Parcel.java:1222)E/AndroidRuntime(26121): at com.android.internal.telephony.IPhoneSubInfo$Stub$Proxy.getLine1Number(IPhoneSubInfo.java:223)E/AndroidRuntime(26121): at android.telephony.TelephonyManager.getLine1Number(TelephonyManager.java:498)E/AndroidRuntime(26121): at com.easymorse.activity.ActivityTest.onCreate(ActivityTest.java:18)E/AndroidRuntime(26121): at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1123)E/AndroidRuntime(26121): … 11 more日志引用在android系统中获取imei号和其他手机信息 发送文章为PDF

出现了很多人反馈说“调试程序的时候直接闪退的问题”，经过几天折腾，小牛给大家提供解决方案，废话就不说了，试试这个方法吧。闪退不用共享库就行了。去掉勾选就可以了！

你的activity中使用的资源被系统释放了，所以需要你在onResume方法中，判断你使用的资源被释放的话，就在加载一次

空指针 看看是不是有控件没初始化

是NullPointerException空指针错误，检查下下面的点：1、maintestinfo.xml文件里面添加该activity了么？2、在activity中应用的控件，有没有用findViewbyId方法和xml中的id对应起来？

1、声明了没有？2、路径不对？3、不同平台用的JAR包不一样，无法识别（比如JAVA平台和eclipse就不一样）4、未知原因，请重新导入

android trace文件查看方法：1、DVM初始化时，设置信号屏蔽字，屏蔽要特殊处理的信号(SIGQUIT, SIGUSR1, SIGUSR2)。由于信号处理方式是进程范围起作用的， 这意味着该进程里所有的线程都将屏蔽该信号。 实现代码在init.c中如下：int dvmStartup(int argc, const char* const argv[], bool ignoreUnrecognized, JNIEnv* pEnv) { ... /* configure signal handling */ if (!gDvm.reduceSignals) blockSignals(); ... } 2、DVM 生成单独的信号处理线程，用来对三个信号做特殊处理 （init.c）：bool dvmInitAfterZygote(void) { ... /* start signal catcher thread that dumps stacks on SIGQUIT */ if (!gDvm.reduceSignals && !gDvm.noQuitHandler) { if (!dvmSignalCatcherStartup()) return false; } ... } DVM调用dvmCreateInternalThread()来生成一个新的内部线程 来专门处理dvm进程里的信号。 后面我们会看到，dvmCreateInternalThread()其实是使用pthread_create()来产生新的线程。 该线程的处理函数是 signalCatcherThreadStart()。 （dvm里所谓的 内部线程，就是用来帮助dvm实现本身使用的线程，比如 信号处理线程，binder线程，Compiler线程，JDWP线程等，而不是应用程序申请的线程。 在后面我们计划用专门的一章来讨论DVM线程模式）signalCatcherThreadStart() 实现框架如下：/* * Sleep in sigwait() until a signal arrives. */ static void* signalCatcherThreadStart(void* arg) { ... /* set up mask with signals we want to handle */ sigemptyset(&mask); sigaddset(&mask, SIGQUIT); sigaddset(&mask, SIGUSR1); #if defined(WITH_JIT) && defined(WITH_JIT_TUNING) sigaddset(&mask, SIGUSR2); #endif ... while (true) { ... loop: cc = sigwait(&mask, &rcvd); ... switch (rcvd) { case SIGQUIT: handleSigQuit(); break; case SIGUSR1: handleSigUsr1(); break; #if defined(WITH_JIT) && defined(WITH_JIT_TUNING) case SIGUSR2: handleSigUsr2(); break; #endif ... } 3、查看结果：DALVIK THREADS: (mutexes: tll=0 tsl=0 tscl=0 ghl=0 hwl=0 hwll=0) "main" prio=5 tid=1 NATIVE | group="main" sCount=1 dsCount=0 obj=0x400246a0 self=0x12770 | sysTid=503 nice=0 sched=0/0 cgrp=default handle=-1342909272 | schedstat=( 15165039025 12197235258 23068 ) utm=182 stm=1334 core=0 at android.os.MessageQueue.nativePollOnce(Native Method) at android.os.MessageQueue.next(MessageQueue.java:119) at android.os.Looper.loop(Looper.java:122) at android.app.ActivityThread.main(ActivityThread.java:4134) at java.lang.reflect.Method.invokeNative(Native Method) at java.lang.reflect.Method.invoke(Method.java:491) at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:841) at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:599) at dalvik.system.NativeStart.main(Native Method) 1. 第一行是 固定的头, 指明下面的都是 当前运行的 dvm thread ：“DALVIK THREADS:”2. 第二行输出的是该 进程里各种线程互斥量的值。（具体的互斥量的作用在 dalvik 线程一章 单独陈述）3. 第三行输出分别是 线程的名字（“main”），线程优先级（“prio=5”），线程id（“tid=1”） 以及线程的 类型（“NATIVE”）4. 第四行分别是线程所述的线程组 （“main”），线程被正常挂起的次处（“sCount=1”），线程因调试而挂起次数（”dsCount=0“），当前线程所关联的java线程对象（”obj=0x400246a0“）以及该线程本身的地址（“self=0x12770”）。5. 第五行 显示 线程调度信息。 分别是该线程在linux系统下得本地线程id （“ sysTid=503”），线程的调度有优先级（“nice=0”），调度策略（sched=0/0），优先组属（“cgrp=default”）以及 处理函数地址（“handle=-1342909272”）6 第六行 显示更多该线程当前上下文，分别是 调度状态（从 /proc/[pid]/task/[tid]/schedstat读出）（“schedstat=( 15165039025 12197235258 23068 )”），以及该线程运行信息 ，它们是 线程用户态下使用的时间值(单位是jiffies）（“utm=182”）， 内核态下得调度时间值（“stm=1334”），以及最后运行改线程的cup标识（“core=0”）；7.后面几行输出 该线程 调用栈。Trace文件是 android davik 虚拟机在收到异常终止信号 （SIGQUIT）时产生的。 最经常的触发条件是 android应用中产生了 FC （force close）。由于是该文件的产生是在 DVM里，所以只有运行 dvm实例的进程（如普通的java应用，java服务等）才会产生该文件，android 本地应用 （native app，指 运行在 android lib层，用c/c++编写的linux应用、库、服务等）在收到 SIGQUIT时是不会产生 trace文件的。

When the fox first saw

我之前也有这种情况建议楼主换下接入点就可以了。

com.example.tab/com.example.tab.MainActivity 这个类没有声明为public

java.lang.NullPointerException 应该是一个空指针异常。有代码调用了空对象的方法或属性。下面还有错误你没有全贴过来。在这些异常中你从上往下找第一个是你程序的代码，那就是异常发生的位置，点进去查看代码就行了。

mWebView.setWebViewClient(new WebViewClient(){ // 这个方法在用户试图点开页面上的某个链接时被调用 @Override public boolean shouldOverrideUrlLoading(WebView view, String url) { if(url!=null) { // 如果想继续加载目标页面则调用下面的语句 // view.loadUrl(url); // 如果不想那url就是目标网址，如果想获取目标网页的内容那你可以用HTTP的API把网页扒下来。 } // 返回true表示停留在本WebView（不跳转到系统的浏览器） return true; } });

处理如下：Java code try { mRecorder.prepare();//预期准备 Log.i(TAG, "recorder.prepare()" ); } catch (IllegalStateException e) { // TODO Auto-generated catch block Log.i(TAG,e.getMessage()); e.printStackTrace(); return false; } catch (IOException e) { // TODO Auto-generated catch block Log.i(TAG,e.getMessage()); e.printStackTrace(); return false; } try{ mRecorder.start(); //开始刻录 }catch (IllegalStateException e) { // TODO Auto-generated catch block Log.i(TAG,e.getMessage()); e.printStackTrace(); return false; }我对java不是很熟，不知道这样使用异常有没有问题？ 当一个进程再录音时，另一个进程启动时，我想得到mic的状态，类似于getStatuse（） 之类的函数，请问大家有没有好的办法？ 谢谢！出错信息如下：04-26 02:23:59.241: E/MediaRecorder(3197): start failed: -104-26 02:23:59.251: D/AndroidRuntime(3197): Shutting down VM04-26 02:23:59.251: W/dalvikvm(3197): threadid=1: thread exiting with uncaught exception (group=0x4001d800)04-26 02:23:59.462: E/AndroidRuntime(3197): FATAL EXCEPTION: main04-26 02:23:59.462: E/AndroidRuntime(3197): java.lang.RuntimeException: Error receiving broadcast Intent { act=android.provider.Telephony.SMS_RECEIVED (has extras) } in com.TS.SnsReceiver@44ef9be004-26 02:23:59.462: E/AndroidRuntime(3197): at android.app.ActivityThread$PackageInfo$ReceiverDispatcher$Args.run(ActivityThread.java:905)04-26 02:23:59.462: E/AndroidRuntime(3197): at android.os.Handler.handleCallback(Handler.java:587)04-26 02:23:59.462: E/AndroidRuntime(3197): at android.os.Handler.dispatchMessage(Handler.java:92)04-26 02:23:59.462: E/AndroidRuntime(3197): at android.os.Looper.loop(Looper.java:123)04-26 02:23:59.462: E/AndroidRuntime(3197): at android.app.ActivityThread.main(ActivityThread.java:4627)04-26 02:23:59.462: E/AndroidRuntime(3197): at java.lang.reflect.Method.invokeNative(Native Method)04-26 02:23:59.462: E/AndroidRuntime(3197): at java.lang.reflect.Method.invoke(Method.java:521)04-26 02:23:59.462: E/AndroidRuntime(3197): at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:868)04-26 02:23:59.462: E/AndroidRuntime(3197): at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:626)04-26 02:23:59.462: E/AndroidRuntime(3197): at dalvik.system.NativeStart.main(Native Method)04-26 02:23:59.462: E/AndroidRuntime(3197): Caused by: java.lang.RuntimeException: start failed.04-26 02:23:59.462: E/AndroidRuntime(3197): at android.media.MediaRecorder.start(Native Method)04-26 02:23:59.462: E/AndroidRuntime(3197): at com.TS.RcdMediaCtrl.StartRecord(RcdMediaCtrl.java:70)04-26 02:23:59.462: E/AndroidRuntime(3197): at com.TS.SnsReceiver.onReceive(SnsReceiver.java:53)04-26 02:23:59.462: E/AndroidRuntime(3197): at android.app.ActivityThread$PackageInfo$ReceiverDispatcher$Args.run(ActivityThread.java:892)

空指针了朋友，addView没有吧linearLayout没有添加进去

可能是不兼容吧

cn.edu.usst.c.TextActivity 这个类没有找到，确定这个Activity在AndroidManifest.xml定义了吗？

相关源码： 调用 startActivity 或 startActivityForResult 来启动Activity。那么启动的Activity有两种情况：第一种是启动同进程内的Activity; 第二种是启动不同进程的根Activity,比如在桌面点击启动App,就是启动不同进程的Activity。这两种情况的Activity的启动流程大致相同，其流程大致是以下三个过程： 以下逐一讲解这三大过程： 下图是调用进程向system_server进程发起请求的过程： startActivityForResult方法继续调用 Instrumentation.execStartActivity 方法。而Instrumentation类主要用来监控应用程序和系统的交互。 下图是ATMS处理startActivity过程，并回调启动进程的ApplicationThread ATMS. startActivity: ATMS类通过一系列方法调用最终来到 startActivityAsUser 的方法，该方法先检查调用进程的权限，然后通过 getActivityStartController().obtainStarter 创建 ActivityStarter 类，并把参数设置到 ActivityStarter.Request 类中，最后执行 ActivityStarter.execute() 方法。 ActivityStarter准备堆栈 在 ActivityStarter. executeRequest 方法中先做一系列的检查，包括调用进程的检查、Intent的检查、权限的检查、向PKMS获取启动Activity的ActivityInfo等信息，然后调用 startActivityUnchecked 方法开始对要启动的Activity做堆栈管理。 在 startActivityInner 方法中，根据启动模式计算出flag，在根据flag等条件启动的Activity的ActivityRecord是加入现有的Task栈中，还是创建新Task栈。为Activity准备好堆栈后，调用 RootWindowContainer.resumeFocusedStacksTopActivities 方法 ActivityStack对栈的管理： 对于启动Activity对应的 ActivityStack 来说，是管理其栈中Activity的显示逻辑。而后继续调用 ActivityStackSupervisor.startSpecificActivity ActivityStackSupervisor检查启动进程和回调ApplicationThread 在ActivityStackSupervisor中先检查要启动Activity的进程是否存在，不存在则创建进程，存在则调用 realStartActivityLocked ,realStartActivityLocked方法通过事务给回调 ApplicationThread. scheduleTransaction 方法。 下图为ActivityThread启动Activity过程的时序图： ApplicationThread类绕了一大圈，最后调用在ATMS阶段设置的ClientTransaction的CallBack的execute方法，也就是 LaunchActivityItem. execute 方法，此方法创建一个 ActivityClientRecord 对象，然后调用 ActivityThread. handleLaunchActivity 开启真正的Actvity启动。 真正启动Activity:

Android 系统为了保证应用程序的安全性做了规定，如果程序需要访问一些系统的关键性信息，必须在配置文件中声明权限才可以，否则程序将会直接崩溃，比如这里查询系统的网络状态就是需要声明权限的。打开AndroidManifest.xml 文件，在里面加入如下权限就可以查询系统网络状态了：<manifest xmlns:android="http://schemas.android.com/apk/res/android"package="com.example.broadcasttest"android:versionCode="1"android:versionName="1.0" ><uses-sdkandroid:minSdkVersion="14"android:targetSdkVersion="19" /><uses-permission android:name="android.permission.ACCESS_NETWORK_STATE"/>……</manifest>访问 http://developer.android.com/reference/android/Manifest.permission.html可以查看 Android系统所有可声明的权限。

首先你可以看出你缺少人文件，你检查下你的模拟器是那个版本，有没有添加sdcard。还有就是缺少权限： java.lang.SecurityException，可能这个应用在开发时的sdk版本比较低，现在用的模拟器版本较高，加强了权限控制。Cannot start volume "/sdcard" (volume is not bound)貌似没有sdcard，声音文件找不到：Couldn"t open fd for content://settings/system/notification_sound，自然无法启动media player，你检查下吧

你的class在运行後被gc了，需要重新载入，如果可以可以监听home键然後从新create一下这个就好了

一般来说出现这个异常的原因是：一个地方调用了不属于这个地方的库。比如我写java程序，但是我导入了android的相关包，调用android相关包时候会出发这个异常。再说另一个异常：java.lang.NoClassDefFoundError. 这个是我写android引用了一个java project里的类。显示类找不到定义异常。没有办法，直接把这个java project里的类复制到android 的工程里。

clear重新编译下。GameView的初始化有问题，里面的配置变了么

建议去贴吧！各种大神聚居于那里！

运行项目出错的话，你可以用虚拟机运行项目也是可以啊，或者说用实体机用实体机用USB连接电脑，然后运行到实体机也是可以的，虚拟机的话你可以用其他虚拟机的还是可以的。其他的话应该是没有什么太大的问题，因为调试的话实体机和虚拟机都可以，不一定用官方的虚拟或者说另外自己的虚拟机也是可以的。

提示的是初始化错误。ActivityThread.java的第1203行，有个handleMessage,handleMessage里处理的时候可能出错了。

来了小伙子，先自我介绍一下吧 什么？你精通Android系统？来，你给我说下Activity的启动流程。 Activity的启动过程是系统中比较有代表意义的过程，涉及到了各个进程之间的相互交互，以及生命周期的回调控制，这也是为什么在面试过程出现频率这么高的原因之一。 Activity的启动流程在API28以后变成了事务启动的方式，相比之前版本的逻辑有了一些变化，但是万变不离其宗，大致流程还是类似的，只是增加了一些类，用来更好的划分职责，更优的处理逻辑。 在开始之前，我们先简单普及下基础知识。 Activity 启动主要涉及到3个进程。 进程之间靠什么通信？ 我们都知道进程与进程之间是数据隔离的，无法相互访问数据，所以进程之间通信是靠Binder来完成的。 面试官可能会问你 为什么会用Binder通信，Binder相比Socket有什么优势呢？ 然而果然被追问了 为啥Binder能做到1次拷贝，而其他的技术是2次拷贝 好，可以描述下具体的映射怎么做的么？.... 这里我推荐一篇Binder的文章，我认为是大量介绍Binder的博客中描述的很透彻的，没有废话，适合急性子。有兴趣的同学可以学习以下， 防止面试的时候跟我一样叫大哥。 Android Binder通信一次拷贝你真的理解了吗？ Activity启动流程主要包含几步？ 我们以 点击Launcher的一个icon 为开始，整体扯一下Activity的启动过程，桌面其实就是LauncherApp的一个Activity Activity启动过程主要涉及哪些类 启动一个Activity一般通过startActivity() 源码层分析整个链路 我们先看下正常启动Activity的方式，一般我们都会通过以下的方式启动一个新的Activity。 其实这是在Activity中的调用方式，调用的即是父类Activity的startActivity()方法,因参数不同分为两个方法，具体如下 最终调用的是startActivityForResult() 核心逻辑是调用了Instrumentation.execStartActivity() ActivityManager.getService()这个获取的是谁？ 逻辑是从IActivityManagerSingleton.get()获取，那IActivityManagerSingleton又是谁？ IActivityManagerSingleton是这么定义的Singleton<IActivityManager> IActivityManagerSingleton get取出来的是IActivityManager,看这个大写I开头就知道是一个接口，实际调用过的是它的实现ActivityManagerService。 ActivityManagerService. startActivity() mActivityStartController.obtainStarter实际调用的是ActivityStarter.execute(),连带调用到ActivityStarter.startActivity() ActivityStarter.startActivityUnchecked()连带调用ActivityStackSupervisor.resumeFocusedStackTopActivityLocked(); targetStack为ActivityStack对象，ActivityStack.resumeTopActivityUncheckedLocked() ActivityStack.resumeTopActivityInnerLocked()调用了mStackSupervisor.startSpecificActivityLocked(next, true, true);其中mStackSupervisor为ActivityStackSupervisor。 ActivityStackSupervisor.startSpecificActivityLocked()中调用 ActivityStackSupervisor.realStartActivityLocked() 注意这个clientTransaction对象，通过这种方式初始化 ClientLifecycleManager.scheduleTransaction(clientTransaction); transaction.schedule();就要找到 mClient即是以上描述的ApplicationThread,因此我们跟进ApplicationThread.scheduleTransaction（） 我靠，调用了ActivityThread.scheduleTransaction(transaction),但是ActivityThread并没有scheduleTransaction(),所以我们找他继承的类ClientTransactionHandler，发现ClientTransactionHandler果然有scheduleTransaction() 以上消息通过ActivityThread H对象进行发送具体解析也在ActivityThread中 我们可以看下TransactionExecutor.execute(transaction); 这里我们主要看下executeCallbacks()方法 transaction.getCallbacks()就是上述过程中ClientTransaction创建过程赋值的LaunchActivityItem对象，因此主要看下LaunchActivityItem.execute() 此时的client为ActivityThread，因此调用ActivityThread.handleLaunchActivity() 主要跟进mInstrumentation.callActivityOnCreate() Activity.performCreate() 至此已经回调到了Activity的onCreate()方法，Activity也就正式启动了，后续就是对应的声明周期回调。

你是指使用中还是生产中？查看异常？既然你都知道有问题了，还要去查看吗？只是怎样去解决这些异常吧，比如常见的卡机，发热，电池鼓包，内存不够等等

Integer.parseInt()这样的方法中的参数不能为null。查查这里：给个参数

首先，让我们看一看AndroidLog的格式。下面这段log是以所谓的long格式打印出来的。从前面Logcat的介绍中可以知道，long格式会把时间，标签等作为单独的一行显示。[ 12-09 21:39:35.510 396: 416 I/ActivityManager ]Start procnet.coollet.infzmreader:umengService_v1 for servicenet.coollet.infzmreader/com.umeng.message.UmengService:pid=21745 uid=10039 gids={50039, 3003, 1015,1028}[ 12-09 21:39:35.518 21745:21745I/dalvikvm ]Turning on JNI app bug workarounds fortarget SDK version 8...[ 12-09 21:39:35.611 21745:21745D/AgooService ]onCreate()我们以第一行为例：12-09 是日期，21:39:35.510是时间396是进程号，416是线程号；I代表log优先级，ActivityManager是log标签。在应用开发中，这些信息的作用可能不是很大。但是在系统开发中，这些都是很重要的辅助信息。开发工程师分析的log很多都是由测试工程师抓取的，所以可能有些log根本就不是当时出错的log。如果出现这种情况，无论你怎么分析都不太可能得出正确的结论。如何能最大限度的避免这种情况呢？笔者就要求测试工程师报bug时必须填上bug发生的时间。这样结合log里的时间戳信息就能大致判断是否是发生错误时的log。而且根据测试工程师提供的bug发生时间点，开发工程师可以在长长的log信息中快速的定位错误的位置，缩小分析的范围。同时我们也要注意，时间信息在log分析中可能被错误的使用。例如：在分析多线程相关的问题时，我们有时需要根据两段不同线程中log语句执行的先后顺序来判断错误发生的原因，但是我们不能以两段log在log文件中出现的先后做为判断的条件，这是因为在小段时间内两个线程输出log的先后是随机的，log打印的先后顺序并不完全等同于执行的顺序。那么我们是否能以log的时间戳来判断呢？同样是不可以，因为这个时间戳实际上是系统打印输出log时的时间，并不是调用log函数时的时间。遇到这种情况唯一的办法是在输出log前，调用系统时间函数获取当时时间，然后再通过log信息打印输出。这样虽然麻烦一点，但是只有这样取得的时间才是可靠的，才能做为我们判断的依据。另外一种误用log中时间戳的情况是用它来分析程序的性能。一个有多年工作经验的工程师拿着他的性能分析结果给笔者看，但是笔者对这份和实际情况相差很远的报告表示怀疑，于是询问这位工程师是如何得出结论的。他的回答让笔者很惊讶，他计算所采用的数据就是log信息前面的时间戳。前面我们已经讲过，log前面时间戳和调用log函数的时间并不相同，这是由于系统缓冲log信息引起的，而且这两个时间的时间差并不固定。所以用log信息前附带的时间戳来计算两段log间代码的性能会有比较大的误差。正确的方法还是上面提到的：在程序中获取系统时间然后打印输出，利用我们打印的时间来计算所花费的时间。了解了时间，我们再谈谈进程Id和线程Id，它们也是分析log时很重要的依据。我们看到的log文件，不同进程的log信息实际上是混杂在一起输出的，这给我们分析log带来了很大的麻烦。有时即使是一个函数内的两条相邻的log，也会出现不同进程的log交替输出的情况，也就是A进程的第一条log后面跟着的是B进程的第二条log，对于这样的组合如果不细心分析，就很容易得出错误的结论。这时一定要仔细看log前面的进程Id，把相同Id的log放到一起看。不同进程的log有这样的问题，不同的线程输出的log当然也存在着相同的问题。Logcat加上-vthread就能打印出线程Id。但是有一点也要引起注意，就是Android的线程Id和我们平时所讲的Linux线程Id并不完全等同。首先，在Android系统中，C++层使用的Linux获取线程Id的函数gettid()是不能得到线程Id的，调用gettid()实际上返回的是进程Id。作为替代，我们可以调用pthread_self()得到一个唯一的值来标示当前的native线程。Android也提供了一个函数androidGetThreaId()来获取线程Id，这个函数实际上就是在调用pthread_self函数。但是在Java层线程Id又是另外一个值，Java层的线程Id是通过调用Thread的getId方法得到的，这个方法的返回值实际上来自Android在每个进程的java层中维护的一个全局变量，所以这个值和C++层所获得的值并不相同。这也是我们分析log时要注意的问题，如果是Java层线程Id，一般值会比较小，几百左右；如果是C++层的线程，值会比较大。在前里面的log样本中，就能很容易的看出，第一条log是Jave层输出的log，第二条是native层输出的。明白了这些，我们在分析log时就不要看见两段log前面的线程Id不相同就得出是两个不同线程log的简单结论，还要注意Jave层和native层的区别，这样才能防止被误导。AndroidLog的优先级在打印输出时会被转换成V，I，D，W，E等简单的字符标记。在做系统log分析时，我们很难把一个log文件从头看到尾，都是利用搜索工具来查找出错的标记。比如搜索“E/”来看看有没有指示错误的log。所以如果参与系统开发的每个工程师都能遵守Android定义的优先级含义来输出log，这会让我们繁重的log分析工作变得相对轻松些。Android比较常见的严重问题有两大类，一是程序发生崩溃；二是产生了ANR。程序崩溃和ANR既可能发生在java层，也可能发生在native层。如果问题发生在java层，出错的原因一般比较容易定位。如果是native层的问题，在很多情况下，解决问题就不是那么的容易了。我们先看一个java层的崩溃例子：I/ActivityManager( 396): Start proccom.test.crash for activity com.test.crash/.MainActivity:pid=1760 uid=10065 gids={50065, 1028}D/AndroidRuntime( 1760): Shutting downVMW/dalvikvm( 1760): threadid=1: threadexiting with uncaught exception(group=0x40c38930)E/AndroidRuntime( 1760): FATALEXCEPTION: mainE/AndroidRuntime( 1760):java.lang.RuntimeException: Unable to start activityComponentInfo{com.test.crash/com.test.crash.MainActivity}:java.lang.NullPointerExceptionE/AndroidRuntime( 1760): atandroid.app.ActivityThread.performLaunchActivity(ActivityThread.java:2180)E/AndroidRuntime( 1760): atandroid.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2230)E/AndroidRuntime( 1760): atandroid.app.ActivityThread.access$600(ActivityThread.java:141)E/AndroidRuntime( 1760): atandroid.app.ActivityThread$H.handleMessage(ActivityThread.java:1234)E/AndroidRuntime( 1760): atandroid.os.Handler.dispatchMessage(Handler.java:99)E/AndroidRuntime( 1760): atandroid.os.Looper.loop(Looper.java:137)E/AndroidRuntime( 1760): atandroid.app.ActivityThread.main(ActivityThread.java:5050)E/AndroidRuntime( 1760): atjava.lang.reflect.Method.invokeNative(NativeMethod)E/AndroidRuntime( 1760): atjava.lang.reflect.Method.invoke(Method.java:511)E/AndroidRuntime( 1760): atcom.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:793)E/AndroidRuntime( 1760): atcom.android.internal.os.ZygoteInit.main(ZygoteInit.java:560)E/AndroidRuntime( 1760): atdalvik.system.NativeStart.main(NativeMethod)E/AndroidRuntime( 1760): Caused by:java.lang.NullPointerExceptionE/AndroidRuntime( 1760): atcom.test.crash.MainActivity.setViewText(MainActivity.java:29)E/AndroidRuntime( 1760): atcom.test.crash.MainActivity.onCreate(MainActivity.java:17)E/AndroidRuntime( 1760): atandroid.app.Activity.performCreate(Activity.java:5104)E/AndroidRuntime( 1760): atandroid.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1080)E/AndroidRuntime( 1760): atandroid.app.ActivityThread.performLaunchActivity(ActivityThread.java:2144)E/AndroidRuntime( 1760): ... 11moreI/Process ( 1760): Sending signal.PID: 1760 SIG: 9W/ActivityManager( 396): Force finishing activitycom.test.crash/.MainActivityJave层的代码发生crash问题时，系统往往会打印出很详细的出错信息。比如上面这个例子，不但给出了出错的原因，还有出错的文件和行数。根据这些信息，我们会很容易的定位问题所在。native层的crash虽然也有栈log信息输出，但是就不那么容易看懂了。下面我们再看一个native层crash的例子：F/libc ( 2102): Fatal signal 11 (SIGSEGV) at 0x00000000 (code=1), thread2102 (testapp)D/dalvikvm(26630):GC_FOR_ALLOC freed 604K, 11% free 11980K/13368K, paused 36ms, total36msI/dalvikvm-heap(26630):Grow heap (frag case) to 11.831MB for 102416-byteallocationD/dalvikvm(26630):GC_FOR_ALLOC freed 1K, 11% free 12078K/13472K, paused 34ms, total34msI/DEBUG ( 127):*** *** *** *** *** *** *** *** *** *** *** *** *** *** ******I/DEBUG ( 127):Build fingerprint:"Android/full_maguro/maguro:4.2.2/JDQ39/eng.liuchao.20130619.201255:userdebug/test-keys"I/DEBUG ( 127):Revision: "9"I/DEBUG ( 127):pid: 2102, tid: 2102, name: testapp >>>./testapp <<<I/DEBUG ( 127):signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr00000000I/DEBUG ( 127): r0 00000020 r173696874 r2 400ff520 r300000000I/DEBUG ( 127): r4 400ff469 r5beb4ab24 r6 00000001 r7beb4ab2cI/DEBUG ( 127): r8 00000000 r900000000 sl 00000000 fpbeb4ab1cI/DEBUG ( 127): ip 4009b5dc spbeb4aae8 lr 400ff46f pc400ff45e cpsr 60000030I/DEBUG ( 127): d0 000000004108dae8 d1 4108ced84108cec8I/DEBUG ( 127): d2 4108cef84108cee8 d3 4108cf184108cf08I/DEBUG ( 127): d4 4108c5a84108c598 d5 4108ca084108c5b8I/DEBUG ( 127): d6 4108ce684108ce58 d7 4108ce884108ce78I/DEBUG ( 127): d8 0000000000000000 d9 0000000000000000I/DEBUG ( 127): d10 0000000000000000 d110000000000000000I/DEBUG ( 127): d120000000000000000 d130000000000000000I/DEBUG ( 127): d14 0000000000000000 d150000000000000000I/DEBUG ( 127): d16 c1dcf7c087fec8b4 d173f50624dd2f1a9fcI/DEBUG ( 127): d18 41c7b1ac89800000 d190000000000000000I/DEBUG ( 127): d20 0000000000000000 d210000000000000000I/DEBUG ( 127): d22 0000000000000000 d230000000000000000I/DEBUG ( 127): d24 0000000000000000 d250000000000000000I/DEBUG ( 127): d26 0000000000000000 d270000000000000000I/DEBUG ( 127): d28 0000000000000000 d290000000000000000I/DEBUG ( 127): d30 0000000000000000 d310000000000000000I/DEBUG ( 127): scr 00000010I/DEBUG ( 127):I/DEBUG ( 127):backtrace:I/DEBUG ( 127): #00 pc0000045e /system/bin/testappI/DEBUG ( 127): #01 pc0000046b /system/bin/testappI/DEBUG ( 127): #02 pc0001271f /system/lib/libc.so (__libc_init+38)I/DEBUG ( 127): #03 pc00000400 /system/bin/testappI/DEBUG ( 127):I/DEBUG ( 127):stack:I/DEBUG ( 127): beb4aaa8 000000c8 I/DEBUG ( 127): beb4aaac 00000000 I/DEBUG ( 127): beb4aab0 00000000 I/DEBUG ( 127): beb4aab4 401cbee0 /system/bin/linkerI/DEBUG ( 127): beb4aab8 00001000 I/DEBUG ( 127): beb4aabc 4020191d /system/lib/libc.so (__libc_fini)I/DEBUG ( 127): beb4aac0 4020191d /system/lib/libc.so (__libc_fini)I/DEBUG ( 127): beb4aac4 40100eac /system/bin/testappI/DEBUG ( 127): beb4aac8 00000000 I/DEBUG ( 127): beb4aacc 400ff469 /system/bin/testappI/DEBUG ( 127): beb4aad0 beb4ab24 [stack]I/DEBUG ( 127): beb4aad4 00000001 I/DEBUG ( 127): beb4aad8 beb4ab2c [stack]I/DEBUG ( 127): beb4aadc 00000000 I/DEBUG ( 127): beb4aae0 df0027ad I/DEBUG ( 127): beb4aae4 00000000 I/DEBUG ( 127): #00 beb4aae8 00000000 I/DEBUG ( 127): ........ ........I/DEBUG ( 127): #01 beb4aae8 00000000 I/DEBUG ( 127): beb4aaec 401e9721 /system/lib/libc.so (__libc_init+40)I/DEBUG ( 127): #02 beb4aaf0 beb4ab08 [stack]I/DEBUG ( 127): beb4aaf4 00000000 I/DEBUG ( 127): beb4aaf8 00000000 I/DEBUG ( 127): beb4aafc 00000000 I/DEBUG ( 127): beb4ab00 00000000 I/DEBUG ( 127): beb4ab04 400ff404 /system/bin/testappI/DEBUG ( 127):这个log就不那么容易懂了，但是还是能从中看出很多信息，让我们一起来学习如何分析这种log。首先看下面这行：pid: 2102, tid: 2102,name: testapp >>>./testapp <<<从这一行我们可以知道crash进程的pid和tid，前文我们已经提到过，Android调用gettid函数得到的实际是进程Id号，所以这里的pid和tid相同。知道进程号后我们可以往前翻翻log，看看该进程最后一次打印的log是什么，这样能缩小一点范围。接下来内容是进程名和启动参数。再接下来的一行比较重要了，它告诉了我们从系统角度看，出错的原因：signal 11 (SIGSEGV), code 1(SEGV_MAPERR), fault addr 00000000signal11是Linux定义的信号之一，含义是Invalidmemory reference，无效的内存引用。加上后面的“faultaddr 00000000”我们基本可以判定这是一个空指针导致的crash。当然这是笔者为了讲解而特地制造的一个Crash的例子，比较容易判断，大部分实际的例子可能就没有那么容易了。再接下来的log打印出了cpu的所有寄存器的信息和堆栈的信息，这里面最重要的是从堆栈中得到的backtrace信息：I/DEBUG ( 127):backtrace:I/DEBUG ( 127): #00 pc0000045e /system/bin/testappI/DEBUG ( 127): #01 pc0000046b /system/bin/testappI/DEBUG ( 127): #02 pc0001271f /system/lib/libc.so (__libc_init+38)I/DEBUG ( 127): #03 pc00000400 /system/bin/testapp因为实际的运行系统里没有符号信息，所以打印出的log里看不出文件名和行数。这就需要我们借助编译时留下的符号信息表来翻译了。Android提供了一个工具可以来做这种翻译工作：arm-eabi-addr2line，位于prebuilts/gcc/linux-x86/arm/arm-eabi-4.6/bin目录下。用法很简单：#./arm-eabi-addr2line -f -eout/target/product/hammerhead/symbols/system/bin/testapp0x0000045e参数-f表示打印函数名；参数-e表示带符号表的模块路径；最后是要转换的地址。这条命令在笔者的编译环境中得到的结果是：memcpy /home/rd/compile/android-4.4_r1.2/bionic/libc/include/string.h:108剩余三个地址翻译如下：main /home/rd/compile/android-4.4_r1.2/packages/apps/testapp/app_main.cpp:38out_vformat /home/rd/compile/android-4.4_r1.2/bionic/libc/bionic/libc_logging.cpp:361_start libgcc2.c:0利用这些信息我们很快就能定位问题了。不过这样手动一条一条的翻译比较麻烦，笔者使用的是从网上找到的一个脚本，可以一次翻译所有的行，有需要的读者可以在网上找一找。了解了如何分析普通的Log文件，下面让我们再看看如何分析ANR的Log文件。

修改方法：manifest.xml 添加权限<uses-permission android:name="android.permission.SYSTEM_ALERT_WINDOW"/><uses-permission android:name="android.permission.SYSTEM_OVERLAY_WINDOW" />

处理如下： Java code try { mRecorder.prepare();//预期准备 Log.i(TAG, "recorder.prepare()" ); } catch (IllegalStateException e) { // TODO Auto-generated catch block Log.i(TAG,e.getMessage()); e.printStackTrace(); return false; } catch (IOException e) { // TODO Auto-generated catch block Log.i(TAG,e.getMessage()); e.printStackTrace(); return false; } try{ mRecorder.start(); //开始刻录 }catch (IllegalStateException e) { // TODO Auto-generated catch block Log.i(TAG,e.getMessage()); e.printStackTrace(); return false; } 我对java不是很熟，不知道这样使用异常有没有问题？ 当一个进程再录音时，另一个进程启动时，我想得到mic的状态，类似于getStatuse（） 之类的函数，请问大家有没有好的办法？ 谢谢！ 出错信息如下： 04-26 02:23:59.241: E/MediaRecorder(3197): start failed: -1 04-26 02:23:59.251: D/AndroidRuntime(3197): Shutting down VM 04-26 02:23:59.251: W/dalvikvm(3197): threadid=1: thread exiting with uncaught exception (group=0x4001d800) 04-26 02:23:59.462: E/AndroidRuntime(3197): FATAL EXCEPTION: main 04-26 02:23:59.462: E/AndroidRuntime(3197): java.lang.RuntimeException: Error receiving broadcast Intent { act=android.provider.Telephony.SMS_RECEIVED (has extras) } in com.TS.SnsReceiver@44ef9be0 04-26 02:23:59.462: E/AndroidRuntime(3197): at android.app.ActivityThread$PackageInfo$ReceiverDispatcher$Args.run(ActivityThread.java:905) 04-26 02:23:59.462: E/AndroidRuntime(3197): at android.os.Handler.handleCallback(Handler.java:587) 04-26 02:23:59.462: E/AndroidRuntime(3197): at android.os.Handler.dispatchMessage(Handler.java:92) 04-26 02:23:59.462: E/AndroidRuntime(3197): at android.os.Looper.loop(Looper.java:123) 04-26 02:23:59.462: E/AndroidRuntime(3197): at android.app.ActivityThread.main(ActivityThread.java:4627) 04-26 02:23:59.462: E/AndroidRuntime(3197): at java.lang.reflect.Method.invokeNative(Native Method) 04-26 02:23:59.462: E/AndroidRuntime(3197): at java.lang.reflect.Method.invoke(Method.java:521) 04-26 02:23:59.462: E/AndroidRuntime(3197): at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:868) 04-26 02:23:59.462: E/AndroidRuntime(3197): at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:626) 04-26 02:23:59.462: E/AndroidRuntime(3197): at dalvik.system.NativeStart.main(Native Method) 04-26 02:23:59.462: E/AndroidRuntime(3197): Caused by: java.lang.RuntimeException: start failed. 04-26 02:23:59.462: E/AndroidRuntime(3197): at android.media.MediaRecorder.start(Native Method) 04-26 02:23:59.462: E/AndroidRuntime(3197): at com.TS.RcdMediaCtrl.StartRecord(RcdMediaCtrl.java:70) 04-26 02:23:59.462: E/AndroidRuntime(3197): at com.TS.SnsReceiver.onReceive(SnsReceiver.java:53) 04-26 02:23:59.462: E/AndroidRuntime(3197): at android.app.ActivityThread$PackageInfo$ReceiverDispatcher$Args.run(ActivityThread.java:892)

java.lang.RuntimeException: Unable to start activity ComponentInfo{com.garena.game.lfstw/com.aiming.lfs.LFSActivity}: java.lang.NullPointerException: Attempt to invoke interface method "boolean java.util.List.isEmpty()" on a null object reference at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2421) at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2481) at android.app.ActivityThread.access$900(ActivityThread.java:153) at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1349) at android.os.Handler.dispatchMessage(Handler.java:102) at android.os.Looper.loop(Looper.java:148) at android.app.ActivityThread.main(ActivityThread.java:5432) at java.lang.reflect.Method.invoke(Native Method) at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:735) at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:625)Caused by: java.lang.NullPointerException: Attempt to invoke interface method "boolean java.util.List.isEmpty()" on a null object reference at com.aiming.lfs.billing.util.IabHelper.startSetup(IabHelper.java:269) at com.aiming.lfs.billing.BillingProcessor.setupBilling(BillingProcessor.java:64) at com.aiming.lfs.billing.BillingProcessor.initialize(BillingProcessor.java:38) at com.aiming.lfs.LFSActivity.onCreate(LFSActivity.java:89) at android.app.Activity.performCreate(Activity.java:6289) at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1108

/storage/emulated/0/Files.zip: size is 193815java.util.zip.ZipException: End Of Central Directory signature not found at java.util.zip.ZipFile.readCentralDir(ZipFile.java:377) at java.util.zip.ZipFile.<init>(ZipFile.java:151) at java.util.zip.ZipFile.<init>(ZipFile.java:115) at net.zhuoweizhang.mcpelauncher.ZipTexturePack.<init>(ZipTexturePack.java:18) at com.mojang.minecraftpe.MainActivity.loadTexturePack(MainActivity.java:1617) at com.mojang.minecraftpe.MainActivity.onCreate(MainActivity.java:279) at net.zhuoweizhang.mcpelauncher.pro.LauncherProActivity.onCreate(LauncherProActivity.java:35) at android.app.Activity.performCreate(Activity.java:5245) at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1087) at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2160) at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2245) at android.app.ActivityThread.access$800(ActivityThread.java:139) at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1208) at android.os.Handler.dispatchMessage(Handler.java:102) at android.os.Looper.loop(Looper.java:136) at android.app.ActivityThread.main(ActivityThread.java:5026) at java.lang.reflect.Method.invokeNative(Native Method) at java.lang.reflect.Method.invoke(Method.java:515) at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:802) at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:618) at dalvik.system.NativeStart.main(Native Method)

之前我也有遇到过，没有实质解决。改用 getLastKnownLocation(LocationManager.NETWORK_PROVIDER) 可以得到位置 希望能帮到您vaqytqfniu

你有多个Activity么，没有在项目的androidManifest.xml里注册使用activity

来了小伙子，先自我介绍一下吧 什么？你精通Android系统？来，你给我说下Activity的启动流程。 Activity的启动过程是系统中比较有代表意义的过程，涉及到了各个进程之间的相互交互，以及生命周期的回调控制，这也是为什么在面试过程出现频率这么高的原因之一。 Activity的启动流程在API28以后变成了事务启动的方式，相比之前版本的逻辑有了一些变化，但是万变不离其宗，大致流程还是类似的，只是增加了一些类，用来更好的划分职责，更优的处理逻辑。 在开始之前，我们先简单普及下基础知识。 我们都知道进程与进程之间是数据隔离的，无法相互访问数据，所以进程之间通信是靠Binder来完成的。 面试官可能会问你 为什么会用Binder通信，Binder相比Socket有什么优势呢？ 然而果然被追问了 为啥Binder能做到1次拷贝，而其他的技术是2次拷贝 好，可以描述下具体的映射怎么做的么？.... 我们以 点击Launcher的一个icon 为开始，整体扯一下Activity的启动过程，桌面其实就是LauncherApp的一个Activity 最终调用performLaunchActivity方法创建activity和context并将其做关联，然后通过mInstrumentation.callActivityOnCreate()->Activity.performCreate()->Activity.onCreate()回调到了Activity的生命周期。 启动一个Activity一般通过startActivity() 关于Android进阶、架构设计、NDK、跨平台、底层源码，KT，Flutter，以及面试的资料在我的Github上面可自行查看 项目地址： https://github.com/hunanmaniu/AndroidNotes 我们先看下正常启动Activity的方式，一般我们都会通过以下的方式启动一个新的Activity。 其实这是在Activity中的调用方式，调用的即是父类Activity的startActivity()方法,因参数不同分为两个方法，具体如下 最终调用的是startActivityForResult() 核心逻辑是调用了Instrumentation.execStartActivity() ActivityManager.getService()这个获取的是谁？ 逻辑是从IActivityManagerSingleton.get()获取，那IActivityManagerSingleton又是谁？ IActivityManagerSingleton是这么定义的Singleton IActivityManagerSingleton get取出来的是IActivityManager,看这个大写I开头就知道是一个接口，实际调用过的是它的实现ActivityManagerService。 ActivityManagerService. startActivity() mActivityStartController.obtainStarter实际调用的是ActivityStarter.execute(),连带调用到ActivityStarter.startActivity() ActivityStarter.startActivityUnchecked()连带调用ActivityStackSupervisor.resumeFocusedStackTopActivityLocked(); targetStack为ActivityStack对象，ActivityStack.resumeTopActivityUncheckedLocked() ActivityStack.resumeTopActivityInnerLocked()调用了mStackSupervisor.startSpecificActivityLocked(next, true, true);其中mStackSupervisor为ActivityStackSupervisor。 ActivityStackSupervisor.startSpecificActivityLocked()中调用 ActivityStackSupervisor.realStartActivityLocked() 注意这个clientTransaction对象，通过这种方式初始化 ClientLifecycleManager.scheduleTransaction(clientTransaction); transaction.schedule();就要找到 mClient即是以上描述的ApplicationThread,因此我们跟进ApplicationThread.scheduleTransaction（） 我靠，调用了ActivityThread.scheduleTransaction(transaction),但是ActivityThread并没有scheduleTransaction(),所以我们找他继承的类ClientTransactionHandler，发现ClientTransactionHandler果然有scheduleTransaction() 以上消息通过ActivityThread H对象进行发送具体解析也在ActivityThread中 我们可以看下TransactionExecutor.execute(transaction); 这里我们主要看下executeCallbacks()方法 transaction.getCallbacks()就是上述过程中ClientTransaction创建过程赋值的LaunchActivityItem对象，因此主要看下LaunchActivityItem.execute() 此时的client为ActivityThread，因此调用ActivityThread.handleLaunchActivity() 主要跟进mInstrumentation.callActivityOnCreate() Activity.performCreate() 至此已经回调到了Activity的onCreate()方法，Activity也就正式启动了，后续就是对应的声明周期回调。

你缺少activity类么 默认要有一个入口activity的

内存泄露：生命周期长的对象A引用了生命周期短的对象B。生命周期短的B对象已经完成了使用，原本可以被GC回收，但被生命周期长的对象A引用，导致不可被GC回收，从而出现B对象泄露。 常见原因： 影响： 通过AS的Leaked Activities 工具得到的数据 产生原因： Activity被ActivityThread中的nextIdle(ActivityClientRecord)引用而出现了泄露！！！这个就有点意思了…… 常规分析: 没有发现可疑的逻辑。 百度，google一番，没有发现有相同或类似的现象。 既然Activity是中ActivityThread中引用而导致泄露的，那就从ActivityThread的源码分析着手。 定位到Activity泄露的原因，解决就不复杂了。

以android-28为基准,总结了一下Application的启动过程,记录下来，方便以后查阅。 Android application启动的入口类 ActivityThread的内部类,是主线程Handler类,负责处理主线程的所有消息,尤其是App，Activity声明周期相关的Message Instrumentation 是在Application被创建前 创建的,他负责Application、Activity的创建，以及application和Activity的所有生命周期。 ApplicationThread 是ActivityThread的内部类，可以视为一个Binder,他的一个重要作用就是，传递给ActivityManagerService,作为ActivityManagerService向当前进程发送消息(IPC)的桥梁 和ActivityManagerService IPC 通信的工具,通过它实现当前进程向ActivityManagerService 发送消息(IPC)的功能 ActivityMangerService 系统服务类, 统一管理Android系统中的Application、Activity的创建、启动和声明周期。 Application启动的主入口是ActivityThread了的main函数。 ActivityThread的几个重要属性 main中的主要操作 我们看看thread.attach()方法做了什么 attach() ActivityManagerService 最终调用IApplicationThread.bindApplication,跨进程调用ApplicationThread.bindApplication() ApplicationThread.bindApplication()最终向H发送了H.BIND_APPLICATION消息。 H 消息处理 data.info 即LoadedApk类，让我们看一下makeApplication做了什么。 内部也是通过Instrumentation创建的application实例。 我们再看一下Instrumentation的callApplicationOnCreate方法做了什么。newApplication()实现了Application实例的创建,以及attach()调用；callApplicationOnCreate()中实现了Application.onCreate()的调用。 Instrumentation.java 至此 就实现了Application类的创建，onAttach()、onCreate()声明周期的回调 https://www.jianshu.com/p/9ecea420eb52

Android的消息机制是指Handler的运行机制以及Handler所附带的MessageQueue和Looper的工作过程。Handler的主要作用是将一个任务切换到某个指定的线程中去执行。 Android规定访问UI只能在主线程中进行，如果在子线程中访问UI，那么程序就会抛出异常。 主线程即UI线程，它就是ActivityThread，ActivityThread被创建时就会初始化Looper，这也是主线程中默认可以使用Handler的原因。 1.Handler创建时会采用当前线程的Looper来构建内部的消息循环系统，Handler通过ThreadLocal来获取当前线程的Looper，ThreadLocal作用是可以在每个线程中存储数据； 2.Handler创建完毕后，这个时候其内部的Looper以及MessageQueue就可以和Handler一起协同工作了，通过Handler的post方法将一个Runnable投递到Handler内部的Looper中去处理，也可以通过Handler的send方法发送一个消息，这个消息同样会在Looper中处理； 3.当Handler的send方法被调用时，它会调用MessageQueue的enqueueMessage方法将这个消息放入消息队列，Looper发现有新消息到来时，就会处理这个消息，最终消息中的Runnable或者Handler的handleMessage方法就会被调用。 4.Looper是运行在创建Handler所在的线程中，这样Handler中的业务逻辑会被切换到创建Handler所在的线程中去执行了。 ThreadLocal是一个线程内部的数据存储类，通过它可以在指定的线程中存储数据，数据存储之后，只有在指定线程中可以获取到存储的数据，对于其他线程来说则无法获取到数据。 使用场景：android源码中会使用如Looper，ActivityThread，AMS中都用到了ThreadLocal还有就是复杂逻辑下的对象传递，比如监听器的传递。 MessageQueue主要包含两个操作，插入和读取分别对应enqueueMessage 和next，enqueueMessage的作用是往消息队列中插入一条消息，而next的作用是从消息队列中取出一条消息并将其从消息队列中移除。它是通过一个单链表的数据结构来维护消息列表。 消息循环，它会不停地从MessageQueue中查看是否有新消息，如果有新消息就会立刻处理，否则就一直阻塞在那里。 通过Looper.prepare()即可以为当前线程创建一个Looper，接着通过Looper.loop()来开启消息循环。 Looper除了prepare方法外，还提供了prepareMainLooper方法，这个方法主要是给主线程也就是ActivityThread创建Looper使用的，其本质也是通过prepare方法来实现的。Looper提供了getMainLooper方法，通过它可以在任何地方获取到主线程的Looper，Looper也可以退出，提供了quit和quitSafely方法。 Looper的loop方法是一个死循环，唯一跳出循环的方式是MessageQueue的next方法返回了null；当Looper的quit方法被调用时，Looper就会调用MessageQueue的quit或者quitSafely方法来通知消息队列退出，当消息队列被标记为退出状态时，它的next方法就会返回null。 loop方法会调用MessageQueue的next方法来获取新消息，而next是一个阻塞操作，当没有消息时，next方法会一直阻塞在那，这也导致了loop方法一直阻塞在那。 Android的主线程就是ActivityThread，主线程的入口方法为main，在main方法中系统会通过Looper.prepareMainLooper()来创建主线程的Looper以及MessageQueue，并通过Looper.loop()来开启主线程的消息循环。 主线程的消息循环开始了以后，ActivityThread还需要一个Handler来和消息队列进行交互，这个Handler就是ActivityThread.H,它内部定义了一组消息类型，主要包括了四大组件的启动和停止过程。 ActivityThread通过ApplicationThread和AMS进行进程间通信，AMS以进程间通信的方式完成ActivityThread的请求后会回调ApplicationThread中的Binder方法，然后ApplicationThread会向H发送 消息，H接收消息后会将ApplicationThread中的逻辑切换到ActivityThread中去执行，即切换到主线程中去执行，这个过程就是主线程的消息循环模型。 在子线程执行完耗时操作，Handler通过sendMessage发送消息后，会调用MessageQueue.enqueueMessage方法向消息队列中添加消息，然后Looper调用loop()方法开启循环后会不断地从消息队列中读取消息，然后调用目标Handler的dispatchMessage方法传递消息，然后回到Handler所在线程，目标Handler收到消息，调用handleMessage方法，接收消息，处理消息。 每个线程中只能存在一个Looper，Looper是保存在ThreadLocal中的。主线程（UI线程）已经创建了一个Looper，所以在主线程中不需要再创建Looper，但是在其他线程中需要创建Looper。每个线程中可以有多个Handler，即一个Looper可以处理来自多个Handler的消息。 Looper中维护一个MessageQueue，来维护消息队列，消息队列中的Message可以来自不同的Handler。

看不明

xml文件15行出错了

android sdk百度上有教程