Android 开发你需要了解的那些事-IT技术网站

背景
最近部门有新入职员工，作为规划技能道路的导师，这边给新员工安排了学习道路。
除了基本的学习道路之外，每次沟通，我都留了一个小问题，让小伙伴去思考。
这些问题有些是刚接触Android开发的小伙伴所不熟悉的，有些则是部分初级工程师都没有注意到的。
因而这边纪录一下，希望协助刚毕业进入职场的Android小伙伴，或是对这些还不是很熟悉的Android开发工程师们。
如有弥补或许沟通，欢迎留言。
第一点：ANR的其间一个条件并不是在Activity主线程做耗时使命
Q：你是否了解过ANR？
A：知道，但不是很了解。
Q：什么状况下会出现ANR？
假定这儿答复的不是“在主线程履行耗时使命”的话，能够不持续追问，直接让小伙伴去了解ANR，后期再评论。
假如答复了是“在主线程履行耗时使命”的话，那么持续：
Q：多久算耗时？
A：不要超越5s。
Q：那么假定我在Activitysleep20s，是不是就一定会ANR？
上代码比方：
MainActivity.java文件：
publicclassMainActivityextendsAppCompatActivity{@OverrideprotectedvoidonCreate(BundlesavedInstanceState){super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
findViewById(R.id.button).setOnClickListener(newView.OnClickListener(){@OverridepublicvoidonClick(Viewview){Log.e(“zengyu”,”beforesleep”);try{Thread.sleep(20000);
}catch(InterruptedExceptione){
e.printStackTrace();
}Log.e(“zengyu”,”aftersleep”);
}
});
}
}
activity_main.xml文件：
xmlversion=”1.0″encoding=”utf-8″?><android.support.constraint.ConstraintLayoutxmlns:android=”http://schemas.android.com/apk/res/android”xmlns:app=”http://schemas.android.com/apk/res-auto”xmlns:tools=”http://schemas.android.com/tools”android:layout_width=”match_parent”android:layout_height=”match_parent”tools:context=”.MainActivity”><Buttonandroid:id=”@+id/button”android:layout_width=”0dp”android:layout_height=”wrap_content”android:layout_marginTop=”8dp”android:text=”Button”app:layout_constraintEnd_toEndOf=”parent”app:layout_constraintStart_toStartOf=”parent”app:layout_constraintTop_toTopOf=”parent”/>android.support.constraint.ConstraintLayout>
代码功能很简单，便是一个按钮，点击之后会sleep20秒。在sleep前和sleep后都会打印日志。
假如你仅仅点击按钮，然后什么都不动，是不会有ANR的。
可是你点击了按钮之后，你持续屡次点击按钮，那么就会有ANR了。
以下四个条件都能够造成ANR发生：
InputDispatchingTimeout：5秒内无法响应屏幕接触事件或键盘输入事件
BroadcastQueueTimeout：在履行前台播送（BroadcastReceiver）的onReceive()函数时10秒没有处理完成，后台为60秒。
ServiceTimeout：前台服务20秒内，后台服务在200秒内没有履行完毕。
ContentProviderTimeout：ContentProvider的publish在10s内没进行完。
所以或许许多小伙伴会把上面四个条件的第一个和Activity直接挂钩，以为是在主线程耗时超越5s就会ANR。实际上是InputDispatching。
第二点：子线程运用
Q：已然主线程不能做耗时使命，那么有耗时使命怎么办？
A：经过newThread发动一个子线程，在子线程处理。
Q：考虑一个场景，比方相似微信这类IM软件收到音讯。需求写数据库，这个时分需求发动线程。当收到音讯N多的时分，假如都用newThread发动线程的话，是否会有问题。场景模仿能够经过循环创建子线程模仿。
上代码比方：
MainActivity.java文件：
publicclassMainActivityextendsAppCompatActivity{@OverrideprotectedvoidonCreate(BundlesavedInstanceState){super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);for(inti=0;i<10000;i++){newThread(newRunnable(){@Overridepublicvoidrun(){try{Thread.sleep(5000);
}catch(InterruptedExceptione){
e.printStackTrace();
}
}
}).start();
}
}
}
这个部分手机厂商比方（华为）有对线程数目做约束的话，一运行就会crash，Logcat会看到下面信息：
pthread_create(1040KBstack)failed:Outofmemory
我这边一开始在三星S7上面运行，并没有出现。后边换成华为5x手机就出现了。
Android开发的小伙伴都知道兼容是硬伤，所以咱们不能抱有侥幸心理。
针对这种状况，咱们不能一遇到耗时使命，就很潇洒的一个newThread全部搞定。
假如你当前界面只要一个耗时使命，而且只需求调用一次，那么你进入该界面用newThread来处理没有问题。
可是假定像上面咱们描述的场景那样，需求调用屡次的时分。你就不能简单粗暴的运用newThread了。
推荐方法是运用线程池。
一个原因是避免一些厂商的线程数目约束。
另一个原因是削减线程的频繁创建和销毁。
第三点：内部类都或许存在的问题
Q：上面咱们说到了，假如界面调用一次，而且需求发动线程的时分。能够运用newThread创建，那么直接运用newThread或许还有什么问题吗？
这儿想调查的点或许比较晦涩一点。
因为内部类会持有外部类的引证。假定在Activity里边经过匿名内部类的方法来发动线程做耗时使命。当用户退出界面时，因为内部类还持有Activity的引证，因而Activity无法得到开释。
就会存在内存走漏问题。
解决办法也比较统一，那便是将内部类改为静态内部类。
所以修正后的代码对比方下：
修正前：
publicclassMainActivityextendsAppCompatActivity{@OverrideprotectedvoidonCreate(BundlesavedInstanceState){super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);newThread(newRunnable(){@Overridepublicvoidrun(){//TODO}
}).start();
}
}
修正后：
publicclassMainActivityextendsAppCompatActivity{@OverrideprotectedvoidonCreate(BundlesavedInstanceState){super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);newStaticThread().start();
}privatestaticclassStaticThreadextendsThread{@Overridepublicvoidrun(){super.run();//TODO}
}
}
第四点：弱引证场景运用
Q：用过Handler吗？
A：用过。
Q：写一下简单的demo我看下。
这个是紧接第三点。假如不触及界面交互，只需求运用到静态内部类就能够解决。可是当Handler里边需求做界面更新处理时，那么需求运用弱引证。因为静态内部类的处理方法原本便是为了避免Activity无法得到开释。你假如把Activity直接传进来，那么Activity的引证被静态内部类持用了，所以这个时分就需求运用到弱引证了。
直接上代码：
publicclassMainActivityextendsAppCompatActivity{privatestaticclassStaticHandlerextendsHandler{privateWeakReference<MainActivity>activityWeakReference;
publicStaticHandler(MainActivitymainActivity){this.activityWeakReference=newWeakReference<>(mainActivity);
}@OverridepublicvoidhandleMessage(Messagemsg){super.handleMessage(msg);//TODO//useactivityWeakReference.get()togetview}
}privateStaticHandlermStaticHandler=newStaticHandler(this);@OverrideprotectedvoidonCreate(BundlesavedInstanceState){super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
mStaticHandler.sendEmptyMessage(0);
}
}
第五点：耐久化SharedPreferences的运用
一般许多网上教程和比方在SharedPreferences的数据写入时，一般都会运用Editor的commit办法。
因为commit办法是同步写入的。而且写文件归于I/O操作，假如你有很多的数据需求写入，而且你是在主线程处理的，或许会导致流畅性受影响。极端状况下或许会出现ANR。
咱们点进去源码看下：
Ifyoudon’tcareaboutthereturnvalueandyou’reusingthisfromyourapplication’smainthread,considerusing{@link#apply}instead.
其实源码也说的很清楚了。假如你不关心返回值而且你是在运用的主线程运用的话，考虑运用apply替换commit。
因为咱们一般不会处理返回值，因而主张运用apply替换commit。
apply会把变化立刻写进内存，然后经过异步方法去写入。
Unlike{@link#commit},whichwritesitspreferencesouttopersistentstoragesynchronously,{@link#apply}commitsitschangestothein-memory{@linkSharedPreferences}immediatelybutstartsanasynchronouscommittodiskandyouwon’tbenotifiedofanyfailures.
当然源码还有一个注释如下：
Ifanothereditoronthis{@linkSharedPreferences}doesaregular{@link#commit}whilea{@link#apply}isstilloutstanding,the{@link#commit}willblockuntilallasynccommitsarecompletedaswellasthecommititself.
大概意思便是apply假如在处理中还未完成的状况下，commit会堵塞直到一切异步操作完成才会去commit。
因而假如要替换，主张将commit都替换为apply。
第六点：数据库相关处理
这儿主要是考虑相似微信IM登录后拉取很多离线音讯写入数据库的问题。
经过对比开启业务和不开启业务的耗时来进行阐明。
比方不开启业务刺进10000条纪录和开启业务刺进10000条纪录耗时对比。