Android性能优化（第二章）

最新推荐文章于 2024-05-05 20:48:55 发布

TruthKeeper

最新推荐文章于 2024-05-05 20:48:55 发布

阅读量308

点赞数 1

分类专栏：性能优化 Android 文章标签：性能优化 android 屏幕适配

本文链接：https://blog.csdn.net/tk201509/article/details/52700850

版权

Android 同时被 2 个专栏收录

5 篇文章 0 订阅

订阅专栏

性能优化

2 篇文章 0 订阅

订阅专栏

这章就当填坑了，姑且也算是性能优化吧

⁄(⁄ ⁄•⁄ω⁄•⁄ ⁄)⁄

0x00 集合处理

对一些list和数组的操作其实Java已经帮我们做了不少功课了，回想起来在一些使用场景中笔者还傻乎乎的写一堆for each （滑稽），这里就当提个醒。

场景一：

List和数组的转换，这个看官应该都很了解了，这里还是贴出来做下记录。
数组 → List Arrays.asList()传入可变参数类型。例如

//一般写法
List<String> strList=Arrays.asList("1","2");
List<String> strList=Arrays.asList(new String[]{"1","2"});

值得一提的是这里有个隐藏的坑，上述写法是错误的，再用这个List的时候调用add，remove这些method时出现Java.lang.UnsupportedOperationException异常。这是由于Arrays.asList() 返回java.util.Arrays $ArrayList，而不是ArrayList。Arrays$ ArrayList和ArrayList都是继承AbstractList，remove，add等method在AbstractList中是默认throw UnsupportedOperationException而且不作任何操作。ArrayList override这些method来对list进行操作，但是Arrays$ArrayList没有override remove()，add()等，所以会throw UnsupportedOperationException。

//正确写法
List<String> strList=new ArrayList<String>(Arrays.asList("1","2"));
List<String> strList=new ArrayList<String>(Arrays.asList(new String[]{"1","2"}));

场景二：

要快速填充默认数据的数组：

 Arrays.fill();

例如

String strs=new String[10];
Arrays.fill(strs,"haha");

这样就能将tests的数组中都填充haha这个字段，这个方法还支持起始位置和末了位置。
List同理Collections.fill()

场景三：

数组的排序看官也应该很熟悉了，值得一提的是，对数组进行Object排序时

Arrays.sort(Object[] objects,Comparator comparator)

一般是写个匿名实现类来完成排序，也可以重新在Bean对象中重写Comparable接口，对的你没看错，Comparable和Comparator 两个接口的区别在于Comparable是一个类需要内部实现，而Comparator 是外部调用的解析实现。2者都实现时sort方法优先外部调用，也就是Comparator 的compare，Comparator 和Comparable 的实现方法返回值含义相同，1排到后面，-1排到前面，0不变。

场景四：

求数组中某个value的index。好像终于可以摆脱自己for each的实现了，突然间就激动了起来呢。（滑稽）

Arrays.binarySearch()

传入数组和要查找的对象就可以了。对于实体bean的处理有几个点要注意下，
1.不像List集合重写equals方法，执行indexOf就能定位到索引，在binarySearch的源码中的实现方式很不幸的发现不是依赖于equals，而是基于二分查找和Comparable来实现的。
核心方法：

public static int binarySearch(Object[] array, int startIndex, int endIndex, Object value) {
        checkBinarySearchBounds(startIndex, endIndex, array.length);
        int lo = startIndex;
        int hi = endIndex - 1;

        while (lo <= hi) {
            int mid = (lo + hi) >>> 1;
            @SuppressWarnings("unchecked")
            int midValCmp = ((Comparable) array[mid]).compareTo(value);

            if (midValCmp < 0) {
                lo = mid + 1;
            } else if (midValCmp > 0) {
                hi = mid - 1;
            } else {
                return mid;  // value found
            }
        }
        return ~lo;  // value not present
    }

也就是说compareTo返回0的时候才能定位到准确的位置，笔者这里认为，compareTo去做一些equals的活有点不太妥当。Arrays.binarySearch()不过这个方法对于基本类型的索引还是值得一用的。

0x01 屏幕适配

这里补上笔者当初一个坑，

场景：

UI：开发我把图切好了，1x，2x，3x，够了吗（其实我是把给IOS的图顺便给你了）
我：够了够了，（我有dp约束，用一套不颗粒化就OK）
说完我就把2x的随手放到了drawable-hdpi里面，dp一约束，低分辨，中等分辨，高分辨一跑，OK收工，心中还窃喜，还给APK节省了点空间(^__^)
后来在一些新建的工程中研究控件的时候定位了到了这个问题，明明初始化只渲染一些背景图，Monitors 中显示占用内存100M+，最后笔者进行了一些测试

测试一：

ImageView控件，真机samsung S7，1440*2560，测试图片为真机截屏

放置路径	wrap_content	180dp*320dp	Glide加载
drawable	230.1	228.0	11.3
drawable-mdpi	230.3	228.1	11.3
drawable-hdpi	105.5	104.3	11.3
drawable-xhdpi	60.7	62.2	11.2
drawable-xxhdpi	28.9	30.8	11.3
drawable-xxxhdpi	18.1	19.9	11.0