Drawing many UIBezierPaths in a view

I am drawing several UIBezierPaths on a view based on finger movements.

Every time a cycle of touches -- Began/Moved/Ended -- completes, I store the points and create a UIBezierPath that is stored in an array called bezierArray. I have another array called bezierArrayColors that stores the colors of each path.

The problem is this. The class uses drawRect. As far as I can see, every time drawRect runs, it has to draw all the paths that were ever created and the app is now slow.

This is my 开发者_Python百科drawRect now. I know it is pretty lame, but I am not seeing how this can be done.

- (void)drawRect:(CGRect)rect {
   for (int i=0; i<[self.bezierArray count]; i++) {
        UIBezierPath *aPath = (UIBezierPath*)[self.bezierArray objectAtIndex:i];
        UIColor *aColor = (UIColor*)[self.bezierArrayColor objectAtIndex:i];
    [aPath setLineWidth:LINE_WIDTH];

    [aColor setStroke];
    [aPath stroke];
    }
}

Is there a way to stroke a UIBezierPath with different colors or perhaps widths using subpaths? I mean, to change color, width and other properties of a subpath? That would allow me to use one UIBezierPath with several different subpaths. I wish one bezier could be drawn and left there without needing to be redrawn every time. What am I missing?

---

Make sure that you pay attention to the rect that's passed into -drawRect:. If your code takes the easy way out and redraws the entire view every time -drawRect: is called, you may be doing far more drawing than necessary at least some of the time.

---

Draw each bezier path in a separate subview. That way each bezier only has to be redrawn when it itself has changed.

---

I have a similar problem and plan to use a subview to hold all the "completed" paths and another subview to hold just the path "in progress". This way I don't have to draw all the completed paths as I get new touchesmoved events for the "in progress" path(s). Once the path is complete, I move it to the completed array, redraw the completed subview, and await the next touch. This avoids the "trillions of subviews" problem, and also avoids redrawing the whole array of paths while actually trying to respond to touches, which are very sensitive to delays. Once I get this going, I'll try to remember to return here with some code.