angularJS超长列表渲染优化

在维护基于ng1.x项目的过程中，接到了一个新的需求，那就是渲染一个超长的页面，调用接口什么的倒是顺风顺水，结果在出结果的时候我懵逼了，两千多条数据渲染超过了一分钟，还经常出错。
为了便于字母索引，两千多条数据得分类放在一起。大概是从a到z，每个分类里面有100条数据。为了确定速度慢的原因，我在页面打了多出log，并且引入了$last变量来确定最后一条数据的渲染事件，读取接口分类的时间大概一秒左右，那么关键问题就是渲染了。操作dom的过程实在是太慢了，而且由于angularJS所谓的脏检查的原因，来回查询浪费了很多时间。
为了应对这些问题，ng里面有个内置的筛选器。那么逐步加载提高首屏速度应该是个不错的方案，代码上体现就是

{{x}}

ps：这里为了模拟数据，添加了一些样式
项目之前的负责人处理时写了这样一个方法（类似这样，他用的是jquery写的）,
这里有个题外话有些浏览器的滑动距离需要用document.body.scrollTop

        $scope.limit = 20
        window.onscroll = function(){
            if (document.documentElement.scrollTop+window.innerHeight>document.body.offsetHeight-20) {
                console.log('滑到底了')
                $scope.limit+=20
                $scope.$apply()
            }
        }

看上去确实很美好，但是事实上这样会出现一个很致命的问题，只有拉到所有下面之后才会让每个分类加数据，所以这边要更换一下处理方式，将limit值与字母绑定起来，这样就可以分步加载其他的了。
结果在处理完之后发现并没有我想象的那样，优化到7秒左右后没办法再进一步了，找了很久才发现是检索页的原因，检索页没有做limit处理，而这个页面是要筛选所有数据的，使用ng-show控制显示。
在我改为ng-if之后，终于把加载时间降下来了，但是这时会有这样一个问题，就是在输入框做筛选的时候会很卡，于是，筛选的页面也加上了limit处理，这个时候没有分类就可以采用上面的加载方式了，但是还有一个问题，某个字符筛选后还是很长，而limitTo的值原来越大，删除的过程中会继续卡顿。
那么最后一步优化，监听一个onchange事件，在search框的内容发生变化时将limitTo的值重置，最后测试下，ok，大功告成。
附上一个模拟的分段加载代码

    
    
    
    
    
    



    

        

            

                

                    
{{z}}
                    
{{x}}
                
            
        
    
    

        
 a
        
 b
        
 c
        
 d
        
 e
        
 f
        
 g
        
 h
        
 i
        
 j
        
 k
        
 l
        
 m
        
 n
        
 o
        
 p
        
 q
        
 r
        
 s
        
 t
        
 u
        
 v
        
 w
        
 x
        
 y
        
 z